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

Page: 835 / 1898

Volume 2, Part 2: Floating-point System Software 2:587
Floating-point System Software 8
This chapter details the way floating-point exceptions are handled in the Itanium
architecture and how the architecture can be used to implement the ANSI/IEEE Std.
754-1985 for Binary Floating-point Arithmetic (IEEE-754). It is useful in creating and
maintaining floating-point exception handling software by operating system writers.
8.1 Floating-point Exceptions in the Intel
®
Itanium
®
Architecture
Floating-point exception handling in the Itanium architecture has two major
responsibilities. The first responsibility is to assist a hardware implementation to
conform to the Itanium floating-point architecture specification. The Floating-point
Software Assistance (FP SWA) Exception handler supports this conformance and is
included as a driver in the Unified Extensible Firmware Interface (UEFI). The second
responsibility is to provide conformance to the IEEE-754 standard. The IEEE
Floating-point Exception Filter (IEEE Filter) supports providing this conformance.
When a floating-point exception occurs, a minimal amount of processor state
information is saved in interruption control registers. Additional information is
contained in the Floating-point Status Register (FPSR), i.e. application register (AR40).
This register contains the IEEE exception enable controls, the IEEE rounding controls,
the IEEE status flags, and information to determine the dynamic precision and range of
the result to be produced.
When a floating-point exception occurs, execution is transferred to the appropriate
interruption vector, either the Floating-point Fault Vector (at vector address 0x5c00) or
the Floating-point Trap Vector (at vector address 0x5d00.) There the operating system
may handle the exception or save additional processor information and arrange for
handling of the exception elsewhere in the operating system. Floating-point exception
faults must be handled differently than other faults. Correcting the condition that
caused the fault (e.g. a page not present is brought into memory) and re-executing the
instruction is how most other faults are handled. For floating-point faults, software is
required to emulate the operation and continue execution at the next instruction as is
normally done for traps. Part of this emulation needs to include a check for any lower
priority traps that would have been raised if the instruction hadn’t faulted, e.g. a
single-step trap.
8.1.1 Software Assistance Exceptions (Faults and Traps)
There are three categories of Software Assistance (SWA) exceptions that must handled
by the operating system. The first two categories, SWA Faults and SWA Traps, are
implementation dependent and could be generated by any Itanium floating-point
arithmetic instruction that contains a status field specifier in the instruction's encoding.
An implementation may choose to raise a SWA Fault as needed. The SWA Trap can only
be raised under special circumstances. The third category, architecturally mandated