E-5
GUIDELINES FOR WRITING FPU EXCEPTIONS HANDLERS
If NE=0 but the IGNNE# input is active while an unmasked FPU exception is in effect, the pro-
cessor 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 excep-
tion case will assert FERR# and freeze just before the next FPU or WAIT instruction.) The as-
sertion 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 processors FERR# output, its IGNNE# input, and
the IRQ13 input of the PIC, additional external hardware is needed. A recommended configu-
ration is described in the following section.
E.2.1.2.RECOMMENDED EXTERNAL HARDWARE TO SUPPORT THE
MS-DOS* COMPATIBILITY MODE
Figure E-1 provides an external circuit that 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 ex-
ception 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. Fig-
ure E-2 shows the details of how IGNNE# will behave when the circuit in Figure E-1 is im-
plemented. 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 processors 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 from the FPU. For this purpose the
IGNNE# must be driven low. Typically in the PC environment an I/O access to Port 0F0H
clears the external FPU exception interrupt request (FP_IRQ). In the recommended circuit,
this access also is used to activate IGNNE#. With IGNNE# active the FPU exception
handler may execute any FPU instruction without being blocked by an active FPU
exception.
3.Clearing the exception within the FPU will cause the FERR# signal to be deactivated and
then there is no further need for IGNNE# to be active. In the recommended circuit, the
deactivation of FERR# is used to deactivate IGNNE#. If another circuit is used, the
software and circuit together must assure that IGNNE# is deactivated no later than the exit
from the FPU exception handler.
