Intel 64 and IA-32 Architectures Software Developers Manual Volume 1, Basic Architecture

D-14 Vol. 1
GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERS
least programming effort. Certain exceptions can usefully be left unmasked during
the debugging phase of software development, and then masked when the clean
software is actually run. An invalid-operation exception for example, typically indi-
cates a program error that must be corrected.
The exception flags in the x87 FPU status word provide a cumulative record of excep-
tions that have occurred since these flags were last cleared. Once set, these flags can
be cleared only by executing the FCLEX/FNCLEX (clear exceptions) instruction, by
reinitializing the x87 FPU with FINIT/FNINIT or FSAVE/FNSAVE, or by overwriting the
flags with an FRSTOR or FLDENV instruction. This allows a programmer to mask all
exceptions, run a calculation, and then inspect the status word to see if any excep-
tions were detected at any point in the calculation.
D.3.2.2 Software Exception Handling
If the x87 FPU in or with an IA-32 processor (Intel 286 and onwards) encounters an
unmasked exception condition, with the system operated in the MS-DOS compati-
bility mode and with IGNNE# not asserted, a software exception handler is invoked
through a PIC and the processor’s INTR pin. The FERR# (or ERROR#) output from
the x87 FPU that begins the process of invoking the exception handler may occur
when the error condition is first detected, or when the processor encounters the next
WAIT or x87 FPU instruction. Which of these two cases occurs depends on the
processor generation and also on which exception and which x87 FPU instruction trig-
gered it, as discussed earlier in Section D.1, “MS-DOS Compatibility Sub-mode for
Handling x87 FPU Exceptions,” and Section D.2, “Implementation of the MS-DOS
Compatibility Sub-mode in the Intel486, Pentium, and P6 Processor Family, and
Pentium 4 Processors.” The elapsed time between the initial error signal and the invo-
cation of the x87 FPU exception handler depends of course on the external hardware
interface, and also on whether the external interrupt for x87 FPU errors is enabled.
But the architecture ensures that the handler will be invoked before execution of the
next WAIT or floating-point instruction since an unmasked floating-point exception
causes the processor to freeze just before executing such an instruction (unless the
IGNNE# input is active, or it is a no-wait x87 FPU instruction).
The frozen processor waits for an external interrupt, which must be supplied by
external hardware in response to the FERR# (or ERROR#) output of the processor
(or coprocessor), usually through IRQ13 on the “slave” PIC, and then through INTR.
Then the external interrupt invokes the exception handling routine. Note that if the
external interrupt for x87 FPU errors is disabled when the processor executes an x87
FPU instruction, the processor will freeze until some other (enabled) interrupt occurs
if an unmasked x87 FPU exception condition is in effect. If NE = 0 but the IGNNE#
input is active, the processor disregards the exception and continues. Error reporting
via an external interrupt is supported for MS-DOS compatibility. Chapter 17, “IA-32
Architecture Compatibility,” of the Intel® 64 and IA-32 Architectures Software Devel-
oper’s Manual, Volume 3A, contains further discussion of compatibility issues.
The references above to the ERROR# output from the x87 FPU apply to the Intel 387
and Intel 287 math coprocessors (NPX chips). If one of these coprocessors encoun-
ters an unmasked exception condition, it signals the exception to the Intel 286 or