D-12 Vol. 1

GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERS

active, or it is a no-wait x87 FPU instruction). Exactly when the exception handler will be invoked (in the interval 
between when the exception is detected and the next WAIT or x87 FPU instruction) is dependent on the processor 
generation, the system, and which x87 FPU instruction and exception is involved. 
To be safe in exception synchronization, one should assume the handler will be invoked at the end of the interval. 
Thus the program should not change any value that might be needed by the handler (such as COUNT in Example 
D-1 and Example D-2) until after the next x87 FPU instruction following an x87 FPU instruction that could cause 
an error. If the program needs to modify such a value before the next x87 FPU instruction (or if the next x87 FPU 
instruction could also cause an error), then a WAIT instruction should be inserted before the value is modified. This 
will force the handling of any exception before the value is modified. A WAIT instruction should also be placed after 
the last floating-point instruction in an application so that any unmasked exceptions will be serviced before the task 
completes.

D.3.4  

x87 FPU Exception Handling Examples

There are many approaches to writing exception handlers. One useful technique is to consider the exception 
handler procedure as consisting of “prologue,” “body,” and “epilogue” sections of code. 
In the transfer of control to the exception handler due to an INTR, NMI, or SMI, external interrupts have been 
disabled by hardware. The prologue performs all functions that must be protected from possible interruption by 
higher-priority sources. Typically, this involves saving registers and transferring diagnostic information from the 
x87 FPU to memory. When the critical processing has been completed, the prologue may re-enable interrupts to 
allow higher-priority interrupt handlers to preempt the exception handler. The standard “prologue” not only saves 
the registers and transfers diagnostic information from the x87 FPU to memory but also clears the floating-point 
exception flags in the status word. Alternatively, when it is not necessary for the handler to be re-entrant, another 
technique may also be used. In this technique, the exception flags are not cleared in the “prologue” and the body 
of the handler must not contain any floating-point instructions that cannot complete execution when there is a 
pending floating-point exception. (The no-wait instructions are discussed in Section 8.3.12, “Waiting vs. Non-
waiting Instructions.”) Note that the handler must still clear the exception flag(s) before executing the IRET. If the 
exception handler uses neither of these techniques, the system will be caught in an endless loop of nested floating-
point exceptions, and hang.
The body of the exception handler examines the diagnostic information and makes a response that is necessarily 
application-dependent. This response may range from halting execution, to displaying a message, to attempting to 
repair the problem and proceed with normal execution. The epilogue essentially reverses the actions of the 
prologue, restoring the processor so that normal execution can be resumed. The epilogue must not load an 
unmasked exception flag into the x87 FPU or another exception will be requested immediately.
The following code examples show the ASM386/486 coding of three skeleton exception handlers, with the save 
spaces given as correct for 32-bit protected mode. They show how prologues and epilogues can be written for 
various situations, but the application-dependent exception handling body is just indicated by comments showing 
where it should be placed.
The first two are very similar; their only substantial difference is their choice of instructions to save and restore the 
x87 FPU. The trade-off here is between the increased diagnostic information provided by FNSAVE and the faster 
execution of FNSTENV. (Also, after saving the original contents, FNSAVE re-initializes the x87 FPU, while FNSTENV 
only masks all x87 FPU exceptions.) For applications that are sensitive to interrupt latency or that do not need to 
examine register contents, FNSTENV reduces the duration of the “critical region,” during which the processor does 
not recognize another interrupt request. (See the Section 8.1.10, “Saving the x87 FPU’s State with 
FSTENV/FNSTENV and FSAVE/FNSAVE,” for a complete description of the x87 FPU save image.) If the processor 
supports Streaming SIMD Extensions and the operating system supports it, the FXSAVE instruction should be used 
instead of FNSAVE. If the FXSAVE instruction is used, the save area should be increased to 512 bytes and aligned 
to 16 bytes to save the entire state. These steps will ensure that the complete context is saved.
After the exception handler body, the epilogues prepare the processor to resume execution from the point of inter-
ruption (for example, the instruction following the one that generated the unmasked exception). Notice that the 
exception flags in the memory image that is loaded into the x87 FPU are cleared to zero prior to reloading (in fact, 
in these examples, the entire status word image is cleared).
Example D-3 and Example D-4 assume that the exception handler itself will not cause an unmasked exception. 
Where this is a possibility, the general approach shown in Example D-5 can be employed. The basic technique is to