Self Modifying Code

While operating in the IA-32 instruction set, self modifying code and instruction cache coherency (coherency with respect to the local processor’s data cache) is supported for all IA-32 programs. Self modifying code detection is directly supported at the same level of compatibility as the Pentium processor. Software must insert an IA-32 branch instruction between the store operation and the instruction modified for the updated instruction bytes to be recognized.

It is undefined whether the processor will detect a IA-32 self modifying code event for the following conditions; (1) PSR.dt or PSR.it is 0, or (2) there are virtual aliases to different physical addresses between the instruction and data TLBs. To ensure self modifying code works correctly for IA-32 applications, the operating system must ensure that there are no virtual aliases to different physical addresses between the instruction and data TLBs.

When switching from the IA-64 to the IA-32 instruction set, and while executing IA-64

instructions, self modifying code and instruction cache coherency are not directly supported by the processor hardware. Specifically, if a modification is made to IA-32 instructions by IA-64 instructions, IA-64 code must explicitly synchronize the instruction caches with the code sequence defined in Section 4.4.6.2, “Memory Consistency” on page 4-24. Otherwise the modification may or may not be observed by subsequent IA-32 instructions.

When switching from the IA-32 to the IA-64 instruction sets, modification of the local instruction cache contents by IA-32 instructions is detected by the processor hardware. The processor ensures that the instruction cache is made coherent with respect to the modification and all subsequent IA-64 instruction fetches see the modification.

6.3.4

Memory Ordering Interactions

IA-32 instructions are mapped into the IA-64 memory ordering model as follows: • All IA-32 stores have release semantics.

• All IA-32 loads have acquire semantics.

• All IA-32 read-modify-write or lock instructions have release and acquire semantics (fully fenced).

Instruction set transitions do not automatically fence memory data references. To ensure proper ordering software needs to take into account the following ordering rules:

IA-64 to IA-32 Transitions

• All data dependencies are honored, IA-32 loads see the results of all prior IA-64 stores. • IA-32 stores (release) can not pass any prior IA-64 load or store.

• IA-32 loads (acquire) can pass prior IA-64 unordered loads or any prior IA-64 store to a different address. IA-64 software can prevent IA-32 loads from passing prior IA-64 loads and stores by issuing an acquire operation (or mf) before the instruction set transition.

IA-32 to IA-64 Transitions

• All data dependencies are honored, IA-64 loads see the results of all prior IA-32 stores. • IA-64 stores or loads can not pass prior IA-32 loads (acquire).

• IA-64 unordered stores or any IA-64 load can pass prior IA-32 stores (release) to a different address. IA-64 software can prevent IA-64 loads and stores from passing prior IA-32 stores by issuing a release operation (or mf) after the instruction set transition.

6.4

IA-32 Usage of IA-64 Registers

This section lists software considerations for the IA-64 general and floating-point registers, and the ALAT when interacting with IA-32 code.

6.4.1

IA-64 Register Stack Engine

Software must ensure that all dirty registers in the register stack have been flushed to the backing store using a flushrs instruction before starting IA-32 execution either via the br.ia or rfi. Any dirty registers left in the current and prior register stack frames are left in an undefined state. Software can not rely on the value of these registers across an instruction set transition.

Once IA-32 instruction set execution is entered, the RSE is effectively disabled, regardless of any RSE control register enabling conditions.

After exiting the IA-32 instruction set due to a JMPE instruction or interruption, all stacked registers are marked as invalid and the number of clean registers is set to zero.

6.4.2

IA-64 ALAT

IA-32 instruction set execution leaves the contents of the ALAT undefined. Software cannot rely on ALAT state values being preserved across an instruction set transition. On entry to IA-32 code, existing entries in the ALAT are ignored. For details on ALAT, refer to Section 4.4.5.2, “Data Speculation and Instructions” on page 4-17.

6.4.3

IA-64 NaT/NaTVal Response for IA-32 Instructions

If IA-64 code sets a NaT condition in the integer registers or a NaTVal condition in a floating-point register, MMX technology register, or Streaming SIMD Extension register before switching to the IA-32 instruction set the following conditions can arise:

• When the IA-32 instruction set is entered, IA-64 NaT values must not be contained in any register defined to contain IA-32 state, otherwise processor operation is model specific and undefined. Processors may generate a NaT Register Consumption Abort on any IA-32 instruction at any time (including the first IA-32 instruction) for all IA-32 integer, MMX, SSE, or FP instructions regardless of whether not that instruction directly (or indirectly) references a register containing a NaT. NaT Register Consumption aborts encountered during IA-32 execution may terminate IA-32 instructions in the middle of execution with architectural state already modified.

• IA-64 floating-point NaTVal values must not be propagated into IA-32 floating-point instructions, otherwise processor operation is model specific and undefined. Processors may convert floating-point register(s) containing NaTVal to a SNAN (during entry to the IA-32

floating-point instructions that directly or indirectly consume a propagated NaTVal register will either propagate the NaTVal indication or generate an IA-32_Exception (FPError Invalid Operand) fault. Whether a processor generates the fault or propagates the NaTVal is model specific. In no case will the processor allow a NaTVal register to be used without either propagating the NaTVal or generating an IA-32_Exception (FPError Invalid Operand) fault.

Note: It is not possible for IA-32 code to read a NaTVal from a memory location with an IA-32 floating-point load instruction since a NatVal cannot be expressed by a 80-bit double extended precision number. It is highly recommended that floating-point val- ues be passed on the memory stack per typical IA-32 calling conventions to avoid problems with NatVal and IA-64 denormals.

• IA-32 Streaming SIMD Extension instructions that directly or indirectly consume a register containing a NaTVal encoding, will ignore the NaTVal encoding and interpret the register’s mantissa field as a legal data value.

• IA-32 MMX technology instructions that directly or indirectly consume a register containing a NaTVal encoding, will ignore the NaTVal encoding and interpret the register’s mantissa field as a legal data value.

Software should not rely on the behavior of NaT or NaTVal during IA-32 instruction execution, or propagate NaT or NaTVal into IA-32 instructions.