E-16
GUIDELINES FOR WRITING FPU EXCEPTIONS HANDLERS
invoked, so that the recovery routine will load an incorrect value of COUNT, causing the pro-
gram to fail or behave unreliably.
E.3.3.3.PROPER EXCEPTION SYNCHRONIZATION IN GENERAL
As explained in Section E.2.1.2., Recommended External Hardware to Support the MS-DOS*
Compatibility Mode, if the FPU encounters an unmasked exception condition a software ex-
ception handler is invoked before execution of the next WAIT or floating-point instruction. This
is because an unmasked floating-point exception causes the processor to freeze immediately be-
fore executing such an instruction (unless the IGNNE# input is active, or it is a no-wait FPU
instruction). Exactly when the exception handler will be invoked (in the interval between when
the exception is detected and the next WAIT or FPU instruction) is dependent on the processor
generation, the system, and which 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 E-1 and Example E-2) until after the next FPU instruction
following an FPU instruction that could cause an error. If the program needs to modify such a
value before the next FPU instruction (or if the next FPU instruction could also cause an error),
then a WAIT instruction should be inserted before the value is modified. This will force the han-
dling 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.
E.3.3.4.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 inter-
rupts have been disabled by hardware. The prologue performs all functions that must be protect-
ed from possible interruption by higher-priority sources. Typically, this involves saving registers
and transferring diagnostic information from the 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 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 in-
structions that cannot complete execution when there is a pending floating-point exception. (The
no-wait instructions are discussed in Section 7.5.12., Waiting Vs. Non-waiting Instructions in
Chapter 7, Floating-Point Unit.) Note that the handler must still clear the exception flag(s) be-
fore 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
