Vol. 1 D-3
GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERS
The Pentium, P6 family, and Pentium 4 processors offer the same mechanism (the NE bit and the FERR# and
IGNNE# pins) as the Intel486 processors for generating x87 FPU exceptions in MS-DOS compatibility mode. The
actions of these mechanisms are slightly different and more straightforward for the P6 family and Pentium 4
processors, as described in Section D.2.2, “MS-DOS* Compatibility Sub-mode in the P6 Family and Pentium® 4
Processors.”
For Pentium, P6 family, and Pentium 4 processors, it is important to note that the special DP (Dual Processing)
mode for Pentium processors and also the more general Intel MultiProcessor Specification for systems with
multiple Pentium, P6 family, or Pentium 4 processors support x87 FPU exception handling only in the native mode.
Intel does not recommend using the MS-DOS compatibility x87 FPU mode for systems using more than one
processor.
D.2.1.1
Basic Rules: When FERR# Is Generated
When MS-DOS compatibility mode is enabled for the Intel486 or Pentium processors (NE bit is set to 0) and the
IGNNE# input pin is de-asserted, the FERR# signal is generated as follows:
1. When an x87 FPU instruction causes an unmasked x87 FPU exception, the processor (in most cases) uses a
“deferred” method of reporting the error. This means that the processor does not respond immediately, but
rather freezes just before executing the next WAIT or x87 FPU instruction (except for “no-wait” instructions,
which the x87 FPU executes regardless of an error condition).
2. When the processor freezes, it also asserts the FERR# output.
3. The frozen processor waits for an external interrupt, which must be supplied by external hardware in response
to the FERR# assertion.
4. In MS-DOS compatibility systems, FERR# is fed to the IRQ13 input in the cascaded PIC. The PIC generates
interrupt 75H, which then branches to interrupt 2, as described earlier in this appendix for systems using the
Intel 286 and Intel 287 or Intel386 and Intel 387 processors.
The deferred method of error reporting is used for all exceptions caused by the basic arithmetic instructions
(including FADD, FSUB, FMUL, FDIV, FSQRT, FCOM and FUCOM), for precision exceptions caused by all types of x87
FPU instructions, and for numeric underflow and overflow exceptions caused by all types of x87 FPU instructions
except stores to memory.
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 transcendental
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 disre-
gards the exception, does not assert FERR#, and continues. If IGNNE# is then de-asserted and the x87 FPU excep-
tion 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 exception 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 excep-
tion. 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.