D-10 Vol. 1
GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERS
The references above to the ERROR# output from the x87 FPU apply to the Intel 387 and Intel 287 math coproces-
sors (NPX chips). If one of these coprocessors encounters an unmasked exception condition, it signals the excep-
tion to the Intel 286 or Intel386 processor using the ERROR# status line between the processor and the
coprocessor. See Section D.1, “MS-DOS Compatibility Sub-mode for Handling x87 FPU Exceptions,” in this
appendix, and Chapter 22, “IA-32 Architecture Compatibility,” in the Intel® 64 and IA-32 Architectures Software
Developer’s Manual, Volume 3B, for differences in x87 FPU exception handling.
The exception-handling routine is normally a part of the systems software. The routine must clear (or disable) the
active exception flags in the x87 FPU status word before executing any floating-point instructions that cannot
complete execution when there is a pending floating-point exception. Otherwise, the floating-point instruction will
trigger the x87 FPU interrupt again, and the system will be caught in an endless loop of nested floating-point
exceptions, and hang. In any event, the routine must clear (or disable) the active exception flags in the x87 FPU
status word after handling them, and before IRET(D). Typical exception responses may include:
•
Incrementing an exception counter for later display or printing.
•
Printing or displaying diagnostic information (e.g., the x87 FPU environment and registers).
•
Aborting further execution, or using the exception pointers to build an instruction that will run without
exception and executing it.
Applications programmers should consult their operating system's reference manuals for the appropriate system
response to numerical exceptions. For systems programmers, some details on writing software exception handlers
are provided in Chapter 6, “Interrupt and Exception Handling,” in the Intel® 64 and IA-32 Architectures Software
Developer’s Manual, Volume 3A, as well as in Section D.3.4, “x87 FPU Exception Handling Examples,” in this
appendix.
As discussed in Section D.2.1.2, “Recommended External Hardware to Support the MS-DOS* Compatibility Sub-
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 x87 FPU exception interrupt request to
the PIC (by accessing port 0F0H) before the handler causes FERR# to be de-asserted by clearing the exception
from the x87 FPU itself. To eliminate the chance of a problem with this early hardware, Intel recommends that x87
FPU exception handlers always access port 0F0H before clearing the error condition from the x87 FPU.
D.3.3
Synchronization Required for Use of x87 FPU Exception Handlers
Concurrency or synchronization management requires a check for exceptions before letting the processor change
a value just used by the x87 FPU. It is important to remember that almost any numeric instruction can, under the
wrong circumstances, produce a numeric exception.
D.3.3.1
Exception Synchronization: What, Why, and When
Exception synchronization means that the exception handler inspects and deals with the exception in the context
in which it occurred. If concurrent execution is allowed, the state of the processor 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 recap-
ture the original context, it cannot reliably determine the cause of the exception or recover successfully from the
exception. To handle this situation, the x87 FPU has special registers updated at the start of each numeric instruc-
tion 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 synchronization must ensure that the x87 FPU and
other relevant parts of the context are in a well defined state when the handler is invoked after an unmasked
numeric exception occurs.
When the x87 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
x87 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 using higher-level languages, all required synchronization is automatically provided by the
appropriate compiler. However, for assembly language programmers exception synchronization remains the
responsibility of the programmer. It is not uncommon for a programmer to expect that their numeric program will