Intel Itanium 9150M, Manual

Page: 381 / 420

3:372 Volume 3: Resource and Dependency Semantics
RAW and WAW dependencies are generally not allowed without some type of
serialization event (an implied, data, or instruction serialization after the first writing
instruction. (See
Section 3.2, “Serialization” on page 2:17 for details on serialization.)
The tables and associated rules in this appendix provide a comprehensive list of readers
and writers of resources and describe the serialization required for the dependency to
be observed and possible outcomes if the required serialization is not met. Even when
targeting code for machines which do not check for particular disallowed dependencies,
such code sequences are considered architecturally undefined and may cause code to
behave differently across processors, operating systems, or even separate executions
of the code sequence during the same program run. In some cases, different
serializations may yield different, but well-defined results.
The serialization of application level (non-privileged) resources is always implied. This
means that if a writer of that resource and a subsequent read of that same resource are
in different instruction groups, then the reader will see the value written. In addition,
for dependencies on PRs and BRs, where the writer is a non-branch instruction and the
reader is a branch instruction, the writer and reader may be in the same instruction
group.
System resources generally require explicit serialization, i.e., the use of a
srlz.i
or
srlz.d
instruction, between the writing and the reading of that resource. Note that
RAW accesses to CRs are not exceptional
–
they require explicit data or instruction
serialization. However, in some cases (other than CRs) where pairs of instructions
explicitly encode the same resource, serialization is implied.
There are cases where it is architecturally allowed to omit a serialization, and that the
response from the CPU must be atomic (act as if either the old or the new state were
fully in place). The tables in this appendix indicate dependency requirements under the
assumption that the desired result is for the dependency to always be observed. In
some such cases, the programmer may not care if the old or new state is used; such
situations are allowed, but the value seen is not deterministic.
On the other hand, if an impliedF dependency is violated, then the program is
incorrectly coded and the processor's behavior is undefined.
5.3 Resource and Dependency Table Format Notes
• The “Writers” and “Readers” columns of the dependency tables contain instruction
class names and instruction mnemonic prefixes as given in the format section of
each instruction page. To avoid ambiguity, instruction classes are shown in bold,
while instruction mnemonic prefixes are in regular font. For instruction mnemonic
prefixes, all instructions that exactly match the name specified or those that begin
with the specified text and are followed by a ‘.’ and then followed by any other text
will match.
• The dependency on a listed instruction is in effect no matter what values are
encoded in the instruction or what dynamic values occur in operands, unless a
superscript is present or one of the special case instruction rules in
Section 5.3.1
applies. Instructions listed are still subject to rules regarding qualifying predicates.
• Instruction classes are groups of related instructions. Such names appear in
boldface for clarity. The list of all instruction classes is contained in Table 5-5 . Note
that an instruction may appear in multiple instruction classes, instruction classes