AP-578
2/21/97 12:57 PM 24329102.DOC
INTEL CONFIDENTIAL
(until publication date)
immediately. If the system delay before asserting
INTR is long enough, relative to the time elapsed
before the “No-Wait” floating-point instruction, 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# signal triggered by the first “No-
Wait” instruction to hit the first instruction’s 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
instruction is being used in the manner for which
Intel originally designed it. The “No-Wait
instructions 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 error
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 explained
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” instruction 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 3.6
(Considerations When FPU Shared Between
Tasks) discusses an important example of this type
of problem and gives a solution.
2.4 Pentium
Pro Processor with
CR0.NE=0
When bit NE=0 in CR0, the MS-DOS* compatible
mode of the Pentium Pro processor provides
FERR# and IGNNE# functionality that is almost
identical to the Intel486 and Pentium processors.
The same external hardware, as described in
Section 2.3.2 above, is recommended for the
Pentium Pro processor as well as the two previous
generations. The only change to MS-DOS
compatible FPU exception handling with the
Pentium Pro processor is that all exceptions for all
FPU instructions 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
2.3.1, 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 certainly
does not mean that therequested interrupt will
always be serviced before the next instruction in the
code sequence is executed. To begin with, the
Pentium Pro processor 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 assertion to
the processor. Further, the interrupt request to the
PICs (IRQ13) may be temporarily blocked by the
OS, or delayed by higher priority interrupts, and
processor response to INTR itself is blocked if the
OS has cleared the IF bit in EFLAGS.
However, just as with the Intel486 and Pentium
processors, if the IGNNE# input is inactive, a
floating-point exception which occurred in the
previous FPU instruction and is unmasked causes
the processor to freeze immediately when
encountering the next WAIT or FPU instruction
(except for “No-Wait” instructions). This means that
if the FPU exception handler has not already been
invoked due to the earlier exception (and therefore
the handler has not cleared that exception state
from the FPU), the processor is forced to wait for
the handler to be invoked and handle the exception,
before the processor can execute another WAIT or
FPU instruction.
To Next Page
Loading...