Operation Section

The Operation section contains code that specifies the execution semantics of each instruction. It does not include any behavior relating to instruction fetch (e.g., interrupts and faults caused during fetch).

To see the Operation section, click the word Operation in the heading of any instruction.

The font conventions in this section are:

code - (Operation section) C code specifying instruction behavior.

code_italic - (Operation section) Assembly language field name corresponding to a italic field listed in the Format section.

Code Conventions

In the Operation section, registers are addressed using the notation reg[addr].field. The register file being accessed is specified by reg, and has a value chosen from the second column of the Register File Notation table. The addr field specifies a register address as an assembly language field name or a register mnemonic. The field option specifies a named bit field within the register. If field is absent, then all fields of the register are accessed. The only exception is when referencing the data field of the general registers (64-bits not including the NaT bit) where the notation GR[addr] is used. The syntactical differences between the code found in the Operation section and standard C is listed in the Syntax Differences Between C Code and Operation Section Code table.

Due to the sequential nature of traditional programming language statements, the code used to specify instruction operation places artificial restrictions on the implementation. An Intel® Itanium® processor may perform operations eagerly, later determine that the results of these operations are not needed, and then inhibit the update of architecturally visible state. To reflect this degree of freedom, the following rules apply to the code found in the Operation section:

  1. The operation(s) specified on the right-hand side of an assignment statement may be performed independent of any preceding controlling “if” statements. If the right-hand side of an assignment contains a procedure call, any procedure arguments may be evaluated independent of any preceding controlling “if” statements. The same rules apply recursively to the statements in the procedure itself and its descendents. In the instruction descriptions that follow, the expression for a procedure argument never has an architecturally visible side effect (e.g., an assignment to architectural state).

  2. If the variable on the left-hand side of an assignment statement represents architecturally visible state, the assignment will not occur unless all preceding controlling “if” statements evaluate to true. If the variable on the left-hand side of an assignment does not represent architecturally visible state (e.g., a temporary variable) then the assignment may occur independent of any preceding controlling “if” statements. If a statement consists of only a procedure call, same rule applies recursively to the statements in the procedure itself and its descendents.

  3. The conditional expression of an “if” statement may be evaluated independent of the outcome of any preceding controlling “if” statements. In the instruction descriptions that follow, the conditional expression of an “if” statement never has an architecturally visible side effect (e.g., an assignment to architectural state).

Enhanced mode pseudo-code functions are used in the code in the Operation section.

Pseudo-code Example

if (PR[qp]) {

if (!aligned(GR[r3], sz))

unaligned_data_reference_fault(READ, GR[r3]);

tmp_paddr = tlb_translate(GR[r3], sz, READ, &mtype, &defer);

if (!defer) {

GR[r1] = zero_ext(mem_read

(tmp_paddr, sz, UM.be, mtype, ldhint), sz * 8);

alat_inval_single_entry(GENERAL, r1);

if (register_form)

GR[r3] = GR[r3] + GR[r2];

}

}

In the pseudo-code example, according to the first rule:

Based on the second rule:

Using the third rule:

Variables in the Operation Section

All variables that appear in the code in the Operation section are a “universal data type” which is a variable length unsigned bit field. Variables that represent architectural state have a fixed field length consistent with their definition. Temporary variables (i.e., non-architectural) assume the length of the longest variable on the right-hand side of their most recent assignment.

If the variable on the right-hand side of an assignment is longer than the variable on the left-hand side, then the bit field representing the right-hand side variable is truncated to the length of the left-hand side variable before assignment. If the variable on the right-hand side of an assignment is shorter than the variable on the left-hand side, then the bit field representing the right-hand side variable is zero extended to the length of the left-hand side variable before assignment. These same rules apply to operations performed on variables of different length.

Certain common functions are used in the code in the Operation section. The Operation section contains code that specifies only the execution semantics of each instruction and does not include any behavior relating to instruction fetch (e.g., interrupts and faults caused during fetch). The Interruptions section does not list any faults that may be caused by instruction fetch or by mandatory RSE loads. The code to raise certain pervasive faults and actions is not included in the code in the Operation section. These faults and actions are listed below. The Single step trap applies to all instructions and is not listed in the Interruptions section.

Pervasive Conditions not Included in Instruction Description Code