AP-578
2/21/97 12:57 PM 24329102.DOC
INTEL CONFIDENTIAL
(until publication date)
• The frozen processor waits for an external
interrupt, which must be supplied by external
hardware in response to the FERR#
assertion.
• In MS-DOS compatible systems, FERR# is
fed to the IRQ13 input in the cascaded PIC,
which generates interrupt 75H, which then
branches to interrupt 2, as described above
for the 80286and 80287 and Intel386
processor and Intel387 processor-based
systems.
These cases in which FERR# is not asserted at
the time of the error, but rather at the next FPU or
WAIT instruction, include all exceptions caused by
the basic arithmetic instructions (including FADD,
FSUB, FMUL, FDIV, FSQRT, FCOM and
FUCOM), precision exceptions caused by all types
of FPU instructions, and numeric underflow and
overflow on all types of FPU instructions except
stores to memory. We will refer to these cases as
deferred (error reporting).
On the other hand, there are some exceptions,
which when caused by some instructions, drive
FERR# at the time that the exception occurs.
These include FPU stack fault, invalid operation
and denormal exceptions caused by all
transcendental instructions, FSCALE, FXTRACT,
FPREM and others, and all exceptions (except
precision) when caused by FPU store instructions.
These cases are called immediate (error
reporting). (These cases will, like the deferred,
cause the processor to freeze just before
executing the next WAIT or FPU instruction if the
error condition has not been cleared by that time.)
Note that in general, whether an FPU exception
case is deferred or immediate depends both on
which exception occurred, and which instruction
caused that exception. A complete specification of
these cases, which applies also to the Intel486, is
given in Section 5.1.21 in the Pentium
Processor
Family Developer’s Manual, Volume 1.
If NE=0 but the IGNNE# input is active while an
unmasked FPU exception is in effect, the
processor disregards the exception, does not
assert FERR#, and continues. If IGNNE# is then
de-asserted and the FPU exception has not been
cleared, the processor will respond as described
above. (That is, an immediate exception case will
assert FERR# immediately. A deferred exception
case will assert FERR# and freeze just before the
next FPU or WAIT instruction.) The assertion of
IGNNE# is intended for use only inside the FPU
exception handler, where it is needed if one wants
to execute non-control FPU instructions for
diagnosis, before clearing the exception condition.
When IGNNE# is asserted inside the exception
handler, a preceding FPU exception has already
caused FERR# to be asserted, and the external
interrupt hardware has responded, but IGNNE#
assertion still prevents the freeze at FPU
instructions. Note that if IGNNE# is left active
outside of the FPU exception handler, additional
FPU instructions may be executed after a given
instruction has caused an FPU exception. In this
case, if the FPU exception handler ever did get
invoked, it could not determine which instruction
caused the exception.
To properly manage the interface between the
processor’s FERR# output, its IGNNE# input, and
the IRQ13 input of the PIC, additional external
hardware is needed. A recommended
configuration is described below.
2.3.2 RECOMMENDED EXTERNAL
HARDWARE TO SUPPORT MS-DOS*
COMPATIBILITY
Figure 1 below provides an external circuit which
will assure proper handling of FERR# and IGNNE#
when an FPU exception occurs. In particular, it
assures that IGNNE# will be active only inside the
FPU exception handler without depending on the
order of actions by the exception handler. Some
hardware implementations have been less robust
because they have depended on the exception
handler to clear the FPU exception interrupt
request to the PIC (FP_IRQ signal) before the
handler causes FERR# to be de-asserted by
clearing the exception from the FPU itself. Figure
2 below shows the details of how IGNNE# will
behave when the circuit in Figure 1 is
implemented. The temporal regions within the FPU
exception handler activity are described as
follows:
1. The FERR# signal is activated by an FPU
exception and sends an interrupt request
through the PIC to the processor’s INTR pin.
2. During the FPU interrupt service routine
(exception handler) the processor will need to
clear the interrupt request latch (Flip Flop #1).
It may also want to execute non-control FPU
instructions before the exception is cleared
To Next Page
Loading...