AP-578
16
2/21/97 12:57 PM 24329102.DOC
INTEL CONFIDENTIAL
(until publication date)
if any exceptions were detected at any point in the
calculation.
3.2 Software Exception Handling
If the FPU in or with an Intel family processor
(80286 and onwards) encounters an unmasked
exception condition, with the system operated in the
MS-DOS compatible mode and with IGNNE# not
asserted, a software exception handler is invoked
through a PIC and the processor’s INTR pin. The
FERR# (or ERROR# ) output from the FPU that
begins the process of invoking the exception
handler may occur when the error condition is first
detected, or when the processor encounters the
next WAIT or FPU instruction. Which of these two
cases occurs depends on the processor generation
and also on which exception and which FPU
instruction triggered it, as discussed earlier in
Section 2. The elapsed time between the initial
error signal 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
architecture 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 instruction).
The frozen processor waits for an external interrupt,
which must be supplied by external hardware 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 (enabled) 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 23 of the
Pentium
Processor Family Developer’s Manual,
Volume 3 contains further discussion of
compatibility issues.
The references above to the ERROR# output from
the FPU apply to the Intel387 and 80287 math
coprocessors (NPX chips). If one of these
coprocessors encounters an unmasked exception
condition, it signals the exception to the 80286 or
Intel386 processor using the ERROR# status line
between the processor and the coprocessor. See
Section 2.2 above, and Chapter 23 of the Pentium
Processor Family 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 FP instructions that
cannot complete execution when there is a pending
FP exception. Otherwise, the FP instruction will
trigger the FPU interrupt again, and the system will
be caught in an endless loop of nested FP
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
appropriate system response to numerical
exceptions. For systems programmers, some
details on writing software exception handlers are
provided in Chapter 14 of the Pentium
Processor
Family Developer’s Manual, Volume 3, as well as in
this application note.
As discussed in Section 2.3.2, 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 handler causes
FERR# to be de-asserted by clearing the exception
from the FPU itself. To eliminate the chance of a
To Next Page
Loading...