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

Vol. 1 D-5
GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERS
Some x87 FPU instructions with some x87 FPU exceptions use an “immediate”
method of reporting errors. Here, the FERR# is asserted immediately, at the time
that the exception occurs. The immediate method of error reporting is used for x87
FPU stack fault, invalid operation and denormal exceptions caused by all transcen-
dental instructions, FSCALE, FXTRACT, FPREM and others, and all exceptions (except
precision) when caused by x87 FPU store instructions. Like deferred error reporting,
immediate error reporting will cause the processor to freeze just before executing
the next WAIT or x87 FPU instruction if the error condition has not been cleared by
that time.
Note that in general, whether deferred or immediate error reporting is used for an
x87 FPU exception depends both on which exception occurred and which instruction
caused that exception. A complete specification of these cases, which applies to both
the Pentium and the Intel486 processors, is given in Section 5.1.21 in the Pentium
Processor Family Developer’s Manual: Volume 1.
If NE = 0 but the IGNNE# input is active while an unmasked x87 FPU exception is in
effect, the processor disregards the exception, does not assert FERR#, and
continues. If IGNNE# is then de-asserted and the x87 FPU exception has not been
cleared, the processor will respond as described above. (That is, an immediate
exception case will assert FERR# immediately. A deferred exception case will assert
FERR# and freeze just before the next x87 FPU or WAIT instruction.) The assertion of
IGNNE# is intended for use only inside the x87 FPU exception handler, where it is
needed if one wants to execute non-control x87 FPU instructions for diagnosis,
before clearing the exception condition. When IGNNE# is asserted inside the excep-
tion handler, a preceding x87 FPU exception has already caused FERR# to be
asserted, and the external interrupt hardware has responded, but IGNNE# assertion
still prevents the freeze at x87 FPU instructions. Note that if IGNNE# is left active
outside of the x87 FPU exception handler, additional x87 FPU instructions may be
executed after a given instruction has caused an x87 FPU exception. In this case, if
the x87 FPU exception handler ever did get invoked, it could not determine which
instruction caused the exception.
To properly manage the interface between the processor’s FERR# output, its IGNNE#
input, and the IRQ13 input of the PIC, additional external hardware is needed. A
recommended configuration is described in the following section.
D.2.1.2 Recommended External Hardware to Support the MS-DOS
Compatibility Sub-mode
Figure D-1 provides an external circuit that will assure proper handling of FERR# and
IGNNE# when an x87 FPU exception occurs. In particular, it assures that IGNNE# will
be active only inside the x87 FPU exception handler without depending on the order
of actions by the exception handler. Some hardware implementations have been less
robust because they have depended on the exception handler to clear the x87 FPU
exception interrupt request to the PIC (FP_IRQ signal) before the handler causes
FERR# to be de-asserted by clearing the exception from the x87 FPU itself.
Figure D-2 shows the details of how IGNNE# will behave when the circuit in