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

Runtime Support for Control and Data
Speculation
An Itanium architecture-based operating system needs to handle exceptions generated
by control speculative loads (ld.s or ld.sa), data speculative loads (ld.a) and
architectural loads (ld) in different ways.
Software does not have to worry about control or data speculative loads potentially
hitting uncacheable memory with side-effects, since ld.s, ld.sa, and ld.a instructions
to non-speculative memory are always deferred by the processor for details refer to
Section 4.4.6, "Speculation Attributes" on page
use control and data speculation to all program variables.
Control speculative loads require special exception handling and the Itanium
architecture provides a variety of deferral mechanisms for handling of control
speculative exception handling. This is discussed in
The Itanium architecture supports different control speculation recovery models. These
are discussed in
Handling of exceptions caused by architectural and data speculative loads is the same,
except for emulation of unaligned data speculative references, which require special
unaligned emulation handling. This is discussed in
6.1 Exception Deferral of Control Speculative Loads
Exceptions that occur on control speculative loads (ld.s or ld.sa) can be handled by
the operating system in different ways. The operating system can configure a processor
based on the Itanium architecture in three ways:
• Hardware-Only Deferral: automatic hardware deferral of all control speculative
exceptions. In this case, the processor hardware will always defer excepting control
speculative loads without invoking the operating system.
• Combined Hardware/Software Deferral: automatic deferral of some control
speculative exceptions, but deliver others to software. In this case, some
exceptions will result in hardware deferral as described above, other exceptions will
be reported to the operating system. The operating system fault handlers can
identify that an exception has been caused by a control speculative load (ISR.sp will
be 1). Furthermore, OS handlers can software-defer an exception on a control
speculative load by setting IPSR.ed to 1 prior to rfi-ing back to the ld.s or ld.sa.
This allows an operating system to service "cheap" non-fatal exceptions (e.g.
simple TLB misses), while software-deferring both "expensive" non-fatal (e.g. page
faults) as well as fatal exceptions (e.g. non-recovery protection violation).
• Software-Only Deferral: processor is configured to deliver all control speculative
exceptions to software. In this case, operating system software handles all
non-fatal control speculative exceptions, and software-defers all fatal control
speculative exceptions.
Volume 2, Part 2: Runtime Support for Control and Data Speculation
Section 6.2.
2:79. As a result, compilers can freely
Section 6.1.
Section 6.3.1.
6
2:579