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

D-8 Vol. 1
GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERS
inactive. So if the handler clears the x87 FPU exception condition before the 0F0H
access, IGNNE# does not get activated and left on after exit from the handler.
D.2.1.3 No-Wait x87 FPU Instructions Can Get x87 FPU Interrupt in
Window
The Pentium and Intel486 processors implement the “no-wait” floating-point instruc-
tions (FNINIT, FNCLEX, FNSTENV, FNSAVE, FNSTSW, FNSTCW, FNENI, FNDISI or
FNSETPM) in the MS-DOS compatibility mode in the following manner. (See Section
8.3.11, “x87 FPU Control Instructions,” and Section 8.3.12, “Waiting vs. Non-waiting
Instructions,” for a discussion of the no-wait instructions.)
If an unmasked numeric exception is pending from a preceding x87 FPU instruction,
a member of the no-wait class of instructions will, at the beginning of its execution,
assert the FERR# pin in response to that exception just like other x87 FPU instruc-
tions, but then, unlike the other x87 FPU instructions, FERR# will be de-asserted.
This de-assertion was implemented to allow the no-wait class of instructions to
proceed without an interrupt due to any pending numeric exception. However, the
brief assertion of FERR# is sufficient to latch the x87 FPU exception request into most
hardware interface implementations (including Intel’s recommended circuit).
All the x87 FPU instructions are implemented such that during their execution, there
is a window in which the processor will sample and accept external interrupts. If
there is a pending interrupt, the processor services the interrupt first before
resuming the execution of the instruction. Consequently, it is possible that the no-
wait floating-point instruction may accept the external interrupt caused by it’s own
assertion of the FERR# pin in the event of a pending unmasked numeric exception,
Figure D-2. Behavior of Signals During x87 FPU Exception Handling
0F0H Address
Decode