GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERS

;APPLICATION-DEPENDENT EXCEPTION HANDLING CODE ;GOES HERE - AN UNMASKED EXCEPTION

;GENERATED HERE WILL CAUSE THE EXCEPTION HANDLER TO BE REENTERED ;IF LOCAL STORAGE IS NEEDED, IT MUST BE ALLOCATED ON THE STACK

.

;CLEAR EXCEPTION FLAGS IN STATUS WORD (WHICH IS IN MEMORY) ;RESTORE MODIFIED STATE IMAGE

;RETURN TO POINT OF INTERRUPTION IRETD

REENTRANT ENDP

D.3.5 Need for Storing State of IGNNE# Circuit If Using x87 FPU and SMM

The recommended circuit (see Figure D-1) for MS-DOS compatibility x87 FPU exception handling for Intel486 processors and beyond contains two flip flops. When the x87 FPU exception handler accesses I/O port 0F0H it clears the IRQ13 interrupt request output from Flip Flop #1 and also clocks out the IGNNE# signal (active) from Flip Flop #2.

The assertion of IGNNE# may be used by the handler if needed to execute any x87 FPU instruction while ignoring the pending x87 FPU errors. The problem here is that the state of Flip Flop #2 is effectively an additional (but hidden) status bit that can affect processor behavior, and so ideally should be saved upon entering SMM, and restored before resuming to normal operation. If this is not done, and also the SMM code saves the x87 FPU state, AND an x87 FPU error handler is being used which relies on IGNNE# assertion, then (very rarely) the x87 FPU handler will nest inside itself and malfunction. The following example shows how this can happen.

Suppose that the x87 FPU exception handler includes the following sequence:

D-22 Vol. 1