D-6 Vol. 1

GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERS

Figure D-3 assumes that a floating-point instruction that generates a “deferred” error (as defined in the Section 
D.2.1.1, “Basic Rules: When FERR# Is Generated”), which asserts the FERR# pin only on encountering the next 
floating-point instruction, causes an unmasked numeric exception. Assume that the next floating-point instruction 
following this instruction is one of the no-wait floating-point instructions. The FERR# pin is asserted by the 
processor to indicate the pending exception on encountering the no-wait floating-point instruction. After the asser-
tion of the FERR# pin the no-wait floating-point instruction opens a window where the pending external interrupts 
are sampled.
Then there are two cases possible depending on the timing of the receipt of the interrupt via the INTR pin (asserted 
by the system in response to the FERR# pin) by the processor.
Case 1

If the system responds to the assertion of FERR# pin by the no-wait floating-point instruction via 
the INTR pin during this window then the interrupt is serviced first, before resuming the execu-
tion of the no-wait floating-point instruction. 

Case 2

If the system responds via the INTR pin after the window has closed then the interrupt is recognized 
only at the next instruction boundary.

There are two other ways, in addition to Case 1 above, in which a no-wait floating-point instruction can service a 
numeric exception inside its interrupt window. First, the first floating-point error condition could be of the “imme-
diate” category (as defined in Section D.2.1.1, “Basic Rules: When FERR# Is Generated”) that asserts FERR# 
immediately. If the system delay before asserting INTR is long enough, relative to the time elapsed before the no-
wait floating-point instruction, INTR can be asserted inside the interrupt window for the latter. Second, consider 
two no-wait x87 FPU instructions in close sequence, and assume that a previous x87 FPU instruction has caused an 
unmasked numeric exception. Then if the INTR timing is too long for an FERR# signal triggered by the first no-wait 
instruction to hit the first instruction’s interrupt window, it could catch the interrupt window of the second.
The possible malfunction of a no-wait x87 FPU instruction explained above cannot happen if the instruction is being 
used in the manner for which Intel originally designed it. The no-wait instructions were intended to be used inside 
the x87 FPU exception handler, to allow manipulation of the x87 FPU before the error condition is cleared, without 
hanging the processor because of the x87 FPU error condition, and without the need to assert IGNNE#. They will 
perform this function correctly, since before the error condition is cleared, the assertion of FERR# that caused the 
x87 FPU error handler to be invoked is still active. Thus the logic that would assert FERR# briefly at a no-wait 
instruction causes no change since FERR# is already asserted. The no-wait instructions may also be used without 
problem in the handler after the error condition is cleared, since now they will not cause FERR# to be asserted at 
all.

Figure D-3.  Timing of Receipt of External Interrupt

Assertion of FERR#

Exception Generating

Floating-Point

Instruction

by the Processor

System

Assertion of INTR Pin

by the System

Case 1

Case 2

Start of the “No-Wait”

Floating-Point

Instruction

External Interrupt

Sampling Window

Window Closed

Dependent

Delay