<<<    Index    >>>
E-13
GUIDELINES FOR WRITING FPU EXCEPTIONS HANDLERS
cussed earlier in Section E.1., “Origin of the MS-DOS* Compatibility Mode for Handling FPU
Exceptions” and Section E.2., “Implementation of the MS-DOS* Compatibility Mode in the
Intel486™, Pentium®, and P6 family processors” The elapsed time between the initial error sig-
nal and the invocation of the FPU exception handler depends of course on the external hardware
interface, and also on whether the external interrupt for FPU errors is enabled. But the architec-
ture ensures that the handler will be invoked before execution of the next WAIT or floating-point
instruction since an unmasked floating-point exception causes the processor to freeze just before
executing such an instruction (unless the IGNNE# input is active, or it is a no-wait FPU instruc-
tion). 
The frozen processor waits for an external interrupt, which must be supplied by external hard-
ware in response to the FERR# (or ERROR#) output of the processor (or coprocessor), usually
through IRQ13 on the “slave” PIC, and then through INTR. Then the external interrupt invokes
the exception handling routine. Note that if the external interrupt for FPU errors is disabled
when the processor executes an FPU instruction, the processor will freeze until some other (en-
abled) interrupt occurs if an unmasked FPU exception condition is in effect. If NE = 0 but the
IGNNE# input is active, the processor disregards the exception and continues. Error reporting
via an external interrupt is supported for MS-DOS compatibility. Chapter 18, Intel Architecture
Compatibility of the Intel Architecture Software Developer’s Manual, Volume 3, contains further
discussion of compatibility issues.
The references above to the ERROR# output from the FPU apply to the Intel 387 and Intel 287
math coprocessors (NPX chips). If one of these coprocessors encounters an unmasked exception
condition, it signals the exception to the Intel 286 or Intel386™ processor using the ERROR#
status line between the processor and the coprocessor. Refer to Section E.1., “Origin of the MS-
DOS* Compatibility Mode for Handling FPU Exceptions”, in this appendix, and Chapter 18,
Intel Architecture Compatibility, in the Intel Architecture Software Developer’s Manual, Volume
3 for differences in 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 FPU status word before executing any float-
ing-point instructions that cannot complete execution when there is a pending floating-point ex-
ception. Otherwise, the floating-point instruction will trigger the 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 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 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 ap-
propriate system response to numerical exceptions. For systems programmers, some details on
writing software exception handlers are provided in Chapter 5, Interrupt and Exception Han-
dling, in the Intel Architecture Software Developer’s Manual, Volume 3, as well as in Section
E.3.3.4., “FPU Exception Handling Examples” in this appendix.
<<<    Index    >>>