Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS MANUAL VOLUME 1 REV 2.3 Manual page 51

4. Update architectural state, if necessary (update).
An instruction group is a sequence of instructions starting at a given bundle address
and slot number and including all instructions at sequentially increasing slot numbers
and bundle addresses up to the first stop, taken branch, Break Instruction fault due to
a break.b, or Illegal Operation fault due to a Reserved or Reserved if PR[qp] is one
encoding in the B-type opcode space. For the instructions in an instruction group to
have well-defined behavior, they must meet the ordering and dependency requirements
described below.
For the purpose of clarification, the following do not end instruction groups:
• Break instructions other than break.b (break.f, break.i, break.m, break.x)
• Check instructions (chk.s, chk.a, fchkf)
• rfi instructions not followed by a stop
• brl instructions not followed by a stop
• Interruptions other than a Break Instruction fault due to a break.b or an Illegal
Operation fault due to a Reserved or Reserved if PR[qp] is 1 encoding in the B-type
opcode space
Thus, even if one of the above causes a change in control flow, the instructions at
sequentially increasing addresses beyond the location of the change in control flow up
to the next true end of the instruction group had the change of control flow not
occurred, can still cause undefined values to be seen at the target of the change of
control flow, if they cause a dependency violation. There are never, however, any
dependencies between the instructions at the target of the change in control flow and
those preceding the change in control flow, even for the above cases.
If the instructions in instruction groups meet the resource-dependency requirements,
then the behavior of a program will be as though each individual instruction is
sequenced through these phases in the order listed above. The order of a phase of a
given instruction relative to any phase of a previous instruction is prescribed by the
instruction sequencing rules below.
• There is no a priori relationship between the fetch of an instruction and the read,
execute, or update of any dynamically previous instruction. The sync.i and srlz.i
instructions can be used to enforce a sequential relationship between the fetch of
all dynamically succeeding instructions and the update of all dynamically previous
instructions.
• Between instruction groups, every instruction in a given instruction group will
behave as though its read occurred after the update of all the instructions from the
previous instruction group. All instructions are assumed to have unit latency.
Instructions on opposing sides of a stop are architecturally considered to be
separated by at least one unit of latency.
Some system state updates require more stringent requirements than those
described here. See
• Within an instruction group, every instruction will behave as though its read of the
memory and ALAT state occurred after the update of the memory and ALAT state of
all prior instructions in that instruction group.
• Within an instruction group, every instruction will behave as though its read of the
register state occurred before the update of the register state by any instruction
(prior or later) in that instruction group, except as noted in the Register
dependencies and Memory dependencies described below.
1:40
Section 3.2, "Serialization" on page 2:17 for details.
Volume 1, Part 1: Execution Environment