Intel 64 and IA-32 Architectures Software Developers Manual Volume 1, Basic Architecture

D-22 Vol. 1
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
MOV BYTE PTR [EBP-104], 0H
FRSTOR [EBP-108]
;DE-ALLOCATE STACK SPACE, RESTORE REGISTERS
MOV ESP, EBP
.
.
POP EBP
;
;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 excep-
tion 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:
FNSTSW save_sw ; save the x87 FPU status word
; using a no-wait x87 FPU instruction
OUT0F0H, AL ; clears IRQ13 & activates IGNNE#
. . . .
FLDCW new_cw ; loads new CW ignoring x87 FPU errors,
; since IGNNE# is assumed active; or any
; other x87 FPU instruction that is not a no-wait