AP-578
2/21/97 12:57 PM 24329102.DOC
INTEL CONFIDENTIAL
(until publication date)
4.0 DIFFERENCES FOR HANDLERS
USING NATIVE MODE
The 8087 has a pin INT which it asserts when an
unmasked exception occurs. But there is no
interrupt input pin in the 8086 or 8088 dedicated to
its attachment, nor an interrupt vector number in the
8086 or 8088 specific for an FPU error assertion.
But beginning with the Intel 80286 and 80287,
hardware connections were dedicated to support
the FPU exception, and interrupt vector 16
assigned to it.
4.1 Origin with 80286 and 80287;
Intel386™ Processor and
Intel387 Math Coprocessor
The 80286 and 80287 and Intel386 processor and
Intel387 math coprocessor pairs are each provided
with ERROR# pins that are recommended to be
connected between the processor and FPU. If this
is done, when an unmasked FPU exception occurs,
the FPU records the exception, and asserts its
ERROR# pin. The processor recognizes this active
condition of the ERROR# status line immediately
before execution of the next WAIT or FPU
instruction (except for the “N0-Wait” type) in its
instruction stream, and branches to the routine at
interrupt vector 16. Thus an FPU exception will be
handled before any other FPU instruction (after the
one causing the error) is executed (except for “No-
Wait” instructions, which will be executed without
triggering the FPU exception interrupt, but it will
remain pending).
Using the dedicated interrupt 16 for FPU exception
handling is referred to as the native mode. It is the
simplest approach, and the one recommended
most highly by Intel.
4.2 Changes with Intel486,
Pentium
and Pentium Pro
Processors with CR0.NE=1
With these latest three generations of the Intel
Architecture, more enhancements and speedup
features have been added to the corresponding
FPUs. Also, the FPU is now built into the same chip
as the processor, which allows further increases in
the speed at which the FPU can operate as part of
the integrated system. This also means that the
native mode of FPU exception handling, selected
by setting bit NE of register CR0 to 1, is now
entirely internal.
If an unmasked exception occurs during an FPU
instruction, the FPU records the exception
internally, and triggers the exception handler
through interrupt 16 immediately before execution
of the next WAIT or FPU instruction (except for “No-
Wait” instructions, which will be executed as
described in Section 4.1 above).
An unmasked numerical exception causes the
FERR# output to be activated even with NE=1, and
at exactly the same point in the program flow as it
would have been asserted if NE were zero.
However, the system would not connect FERR# to
a PIC to generate INTR when operating in the
native, internal mode. (If the hardware of a system
has FERR# connected to trigger IRQ13 in order to
support MS-DOS, but an OS using the native mode
is actually running the system, it is the OSs
responsibility to make sure that IRQ13 is not
enabled in the slave PIC.) With this configuration a
system is immune to the problem discussed in
Section 2.3.3, where for Intel486 and Pentium
processors a “No-Wait” FPU instruction can get an
FPU exception.
4.3 Considerations When FPU
Shared Between Tasks Using
Native Mode
The protocols recommended in Section 3.6 for
MS-DOS compatible FPU exception handlers that
are shared between tasks may be used without
change with the native mode. However, the
protocols for a handler written specifically for native
mode can be simplified, because the problem of a
spurious floating-point exception interrupt occurring
while the kernel is executing cannot happen in
native mode.
The problem as actually found in practical code in a
MS-DOS compatible system happens when the
DNA handler uses FNSAVE to switch FPU
contexts. If an FPU exception is active, then
FNSAVE triggers FERR# briefly, which usually will
cause the FPU exception handler to be invoked
inside the DNA handler. In native mode, neither
FNSAVE nor any other “No-Wait” instructions can
trigger interrupt 16. (As discussed above, FERR#
gets asserted independent of the value of the NE
bit, but when NE=1, the OS should not enable its
path through the PIC.) Another possible (very rare)
way a floating-point exception interrupt could occur
while the kernel is executing is by an FPU
immediate exception case having its interrupt
delayed by the external hardware until execution
has switched to the kernel. This also cannot