E-14
GUIDELINES FOR WRITING FPU EXCEPTIONS HANDLERS
As discussed in Section E.2.1.2., Recommended External Hardware to Support the MS-DOS*
Compatibility Mode, some early FERR# to INTR hardware interface implementations are less
robust than the recommended circuit. This is because they depended on the exception handler
to clear the FPU exception interrupt request to the PIC (by accessing port 0F0H) before the han-
dler causes FERR# to be de-asserted by clearing the exception from the FPU itself. To eliminate
the chance of a problem with this early hardware, Intel recommends that FPU exception han-
dlers always access port 0F0H before clearing the error condition from the FPU.
E.3.3.Synchronization Required for Use of FPU Exception
Handlers
Concurrency or synchronization management requires a check for exceptions before letting the
processor change a value just used by the FPU. It is important to remember that almost any nu-
meric instruction can, under the wrong circumstances, produce a numeric exception.
E.3.3.1.EXCEPTION SYNCHRONIZATION: WHAT, WHY AND WHEN
Exception synchronization means that the exception handler inspects and deals with the excep-
tion in the context in which it occurred. If concurrent execution is allowed, the state of the pro-
cessor when it recognizes the exception is often not in the context in which it occurred. The
processor may have changed many of its internal registers and be executing a totally different
program by the time the exception occurs. If the exception handler cannot recapture the original
context, it cannot reliably determine the cause of the exception or to recover successfully from
the exception. To handle this situation, the FPU has special registers updated at the start of each
numeric instruction to describe the state of the numeric program when the failed instruction was
attempted. This provides tools to help the exception handler recapture the original context, but
the application code must also be written with synchronization in mind. Overall, exception syn-
chronization must ensure that the FPU and other relevant parts of the context are in a well de-
fined state when the handler is invoked after an unmasked numeric exception occurs.
When the FPU signals an unmasked exception condition, it is requesting help. The fact that the
exception was unmasked indicates that further numeric program execution under the arithmetic
and programming rules of the FPU will probably yield invalid results. Thus the exception must
be handled, and with proper synchronization, or the program will not operate reliably.
For programmers in higher-level languages, all required synchronization is automatically pro-
vided by the appropriate compiler. However, for assembly language programmers exception
synchronization remains the responsibility of the programmer. It is not uncommon for a pro-
grammer to expect that their numeric program will not cause numeric exceptions after it has
been tested and debugged, but in a different system or numeric environment, exceptions may
occur regularly nonetheless. An obvious example would be use of the program with some num-
bers beyond the range for which it was designed and tested. Example E-1 and Example E-2 in
Section E.3.3.2., Exception Synchronization Examples shows a more subtle way in which un-
expected exceptions can occur.
