E-9
GUIDELINES FOR WRITING FPU EXCEPTIONS HANDLERS
asserting INTR is long enough, relative to the time elapsed before the no-wait floating-point in-
struction, INTR can be asserted inside the interrupt window for the latter. Second, consider two
no-wait FPU instructions in close sequence, and assume that a previous FPU instruction has
caused an unmasked numeric exception. Then if the INTR timing is too long for an FERR# sig-
nal triggered by the first no-wait instruction to hit the first instructions interrupt window, it
could catch the interrupt window of the second.
The possible malfunction of a no-wait FPU instruction explained above cannot happen if the in-
struction is being used in the manner for which Intel originally designed it. The no-wait instruc-
tions were intended to be used inside the FPU exception handler, to allow manipulation of the
FPU before the error condition is cleared, without hanging the processor because of the FPU er-
ror condition, and without the need to assert IGNNE#. They will perform this function correctly,
since before the error condition is cleared, the assertion of FERR# that caused the FPU error
handler to be invoked is still active. Thus the logic that would assert FERR# briefly at a no-wait
instruction causes no change since FERR# is already asserted. The no-wait instructions may also
be used without problem in the handler after the error condition is cleared, since now they will
not cause FERR# to be asserted at all.
If a no-wait instruction is used outside of the FPU exception handler, it may malfunction as ex-
plained above, depending on the details of the hardware interface implementation and which
particular processor is involved. The actual interrupt inside the window in the no-wait instruc-
tion may be blocked by surrounding it with the instructions: PUSHFD, CLI, no-wait, then
POPFD. (CLI blocks interrupts, and the push and pop of flags preserves and restores the original
value of the interrupt flag.) However, if FERR# was triggered by the no-wait, its latched value
and the PIC response will still be in effect. Further code can be used to check for and correct
such a condition, if needed. Section E.3.5., Considerations When FPU Shared Between Tasks
discusses an important example of this type of problem and gives a solution.
E.2.2.MS-DOS* Compatibility Mode in the P6 Family Processors
When bit NE=0 in CR0, the MS-DOS compatibility mode of the P6 family processors provides
FERR# and IGNNE# functionality that is almost identical to the Intel486 and Pentium
®
pro-
cessors. The same external hardware described in Section E.2.1.2., Recommended External
Hardware to Support the MS-DOS* Compatibility Mode is recommended for the P6 family
processors as well as the two previous generations. The only change to MS-DOS compatibility
FPU exception handling with the P6 family processors is that all exceptions for all FPU instruc-
tions cause immediate error reporting. That is, FERR# is asserted as soon as the FPU detects an
unmasked exception; there are no cases in which error reporting is deferred to the next FPU or
WAIT instruction. (As is discussed in Section E.2.1.1., Basic Rules: When FERR# Is Generat-
ed, most exception cases in the Intel486 and Pentium
®
processors are of the deferred type.)
Although FERR# is asserted immediately upon detection of an unmasked FPU error, this cer-
tainly does not mean that the requested interrupt will always be serviced before the next instruc-
tion in the code sequence is executed. To begin with, the P6 family processors executes several
instructions simultaneously. There also will be a delay, which depends on the external hardware
implementation, between the FERR# assertion from the processor and the responding INTR as-
sertion to the processor. Further, the interrupt request to the PICs (IRQ13) may be temporarily
blocked by the operating system, or delayed by higher priority interrupts, and processor re-
