The specification for the Intel IA64 architecture seems to be rather well done and available at their site.
I record here some questions as I read the material closely.
Some of these questions may be answered later but I have scanned the material and do not know the answers.
Not all of them demand answers.
Volume 1
I presume that privileged IA32 instructions trap within the IA64 system environment, no matter what the privilige level.
Ans: It depends on which “System Environment” was selected at boot time.
See pdf 1.2.1.
I think that “call site” is used incompatibly with computer literature in section 2.7.
Standard usage has “call site” meaning the neighborhood of the call instruction, not the beginning (or prolog) of the called routine.
Volume 2
Section 4.1.1.1
This section tries to say what TRs are for while saying how they work.
This can be confusing.
Probably power on reset and the instruction are the only things that change TRs but I can’t confirm that.
Here are some facts that I think that have deduced from the text.
- An itr execution is the only event that causes new values in a TR.
- An itr execution, putting value X into some TR will invalidate other TR’s when they conflict.
- A ptr execution will invalidate a TR.
Questions and unresolved issues:
- How does a program learn how many TRs there are? It must know this to allocate them.
- The end of the section speaks of the software allocating TRs among the TLB entries.
Must the software tell the hardware of this allocation and if so how?
The note on page 143 of volume 3 suggests that the hardware treats a TR with an invalid value as a TC.
This is one possible answer.
- Page 142 of Volume 3 says of itr that it does not purge the old content of the addressed TR but just before that it says that all conflicting TLB entries are purged.
This sounds like a contradiction.
Perhaps they meant to say that itr would not suffice to purge the old value in the addressed TR.
- I suppose that one can put a new value in a TR which has been invalidated.
Rational: I think that the TR’s are designed to hold constant maps, set once per boot, and that talk of invalidating entries is merely to protect the circuitry from damage and perhaps report conflicts to the programmer for debugging.
Volume 3
Section 2.2: Instruction load: page 2-126 or 146 pdf-wise
“natd_gr_read” undefined.
Section 3, Table 3-1: page 3-8 or 264 pdf-wise
The definition of tlb_translate is vague.
It is not clear whether it looks beyond the TLB at ...
It says that it checks the “Data TLB fault”.
pdf page 441 of volume 2 has something to say about these.
Volume 4 indicates that the Itanium indeed does have a page table walker.
Presumably it fetches entries produced by the kernel to produce a TLB entry.
I have not found where the format of these entries is specified.