background image

D-20 Vol. 1

GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERS

D.4.2  

Changes with Intel486, Pentium and Pentium Pro Processors with CR0.NE[bit 5] = 1

With these three generations of the IA-32 architecture, more enhancements and speedup features have been 
added to the corresponding x87 FPUs. Also, the x87 FPU is now built into the same chip as the processor, which 
allows further increases in the speed at which the x87 FPU can operate as part of the integrated system. This also 
means that the native mode of x87 FPU exception handling, selected by setting bit NE of register CR0 to 1, is now 
entirely internal.
If an unmasked exception occurs during an x87 FPU instruction, the x87 FPU records the exception internally, and 
triggers the exception handler through interrupt 16 immediately before execution of the next WAIT or x87 FPU 
instruction (except for no-wait instructions, which will be executed as described in Section D.4.1, “Origin with the 
Intel 286 and Intel 287, and Intel386 and Intel 387 Processors”).
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 operating system using the native mode 
is actually running the system, it is the operating system’s 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 D.2.1.3, “No-Wait 
x87 FPU Instructions Can Get x87 FPU Interrupt in Window,”
 where for Intel486 and Pentium processors a no-wait 
x87 FPU instruction can get an x87 FPU exception.

D.4.3  

Considerations When x87 FPU Shared Between Tasks Using Native Mode

The protocols recommended in Section D.3.6, “Considerations When x87 FPU Shared Between Tasks,” for MS-DOS 
compatibility x87 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 compatibility system happens when the DNA handler 
uses FNSAVE to switch x87 FPU contexts. If an x87 FPU exception is active, then FNSAVE triggers FERR# briefly, 
which usually will cause the x87 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 operating system 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 x87 FPU immediate exception case having its interrupt delayed by the external hardware until 
execution has switched to the kernel. This also cannot happen in native mode because there is no delay through 
external hardware.
Thus the native mode x87 FPU exception handler can omit the test to see if the kernel is the x87 FPU owner, and 
the DNA handler for a native mode system can omit the step of setting the kernel as the x87 FPU owner at the 
handler’s beginning. Since however these simplifications are minor and save little code, it would be a reasonable 
and conservative habit (as long as the MS-DOS compatibility mode is widely used) to include these steps in all 
systems.
Note that the special DP (Dual Processing) mode for Pentium processors, and also the more general Intel MultiPro-
cessor Specification for systems with multiple Pentium, P6 family, or Pentium 4 processors, support x87 FPU 
exception handling only in the native mode. Intel does not recommend using the MS-DOS compatibility mode for 
systems using more than one processor.