Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3, Manual

Page: 785 / 1898

Volume 2, Part 2: Interruptions and Serialization 2:537
Interruptions and Serialization 3
This chapter discusses the interruption and serialization model. Although the Itanium
architecture is an explicitly parallel architecture, faults and traps are delivered in
program order based on IP, and from left-to-right in each instruction group. In other
words, faults and traps are reported precisely on the instruction that caused them.
3.1 Terminology
In the Itanium architecture, an interruption is an event which causes the hardware
automatically to stop execution of the current instruction stream, and start execution at
the instruction address corresponding to the
interruption handler for that
interruption. When this happens, we say that an interruption has been delivered to the
processor core.
There are two classes of interruptions in the Itanium architecture. IVA-based
interruptions are handled by the operating system (OS), at an address determined by
the location of the interrupt vector table (IVT) and the particular interruption that has
occurred.
PAL-based interruptions are handled by the processor firmware.
PAL-based interruptions are not visible to the OS, though PAL may notify the OS that a
PAL-based interruption has occurred; see
Section 13.3, “Event Handling in Firmware”
on page 2:632 .
The architecture supports several different types of interruptions. These are defined
below:
• A fault occurs when OS intervention is required before the current instruction can
be executed. For example, if the current instruction misses the TLBs on a data
reference, a Data TLB Miss fault may be delivered by the processor. Faults are
delivered precisely on the instruction that caused the fault. The faulting instruction
and all subsequent instructions do not update any architectural state (with the
possible exception of subsequent instructions which violate a resource
dependency
1
). All instructions executed prior to the faulting instruction update all
their architectural state before the fault handler begins execution.
• A trap occurs when OS intervention is required after the current instruction has
completed. For example, if the last instruction executed was a branch and PSR.tb is
1, a Taken Branch trap will be delivered after the instruction completes. Traps are
delivered precisely on the instruction following the trapping instruction. The
trapping instruction and all prior instructions update all their architectural state
before the trap handler begins execution. All instructions subsequent to the
trapping instruction do not update any architectural state.
1
1. When an interruption is delivered on an instruction whose instruction group contains one or more
illegal dependency violations, instructions which follow the interrupted instruction in program order
and which violate the resource dependency may appear to complete before the interruption handler
begins execution. Software cannot rely upon the value(s) written to the resource(s) whose depen-
dencies have been violated; the value(s) are undefined. For details refer to
Section 3.4, “Instruction
Sequencing Considerations” on page 1:39 .