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

E-2 Vol. 1
GUIDELINES FOR WRITING SIMD FLOATING-POINT EXCEPTION HANDLERS
“Interrupt and Exception Handling,” in the Intel® 64 and IA-32 Architectures Soft-
ware Developer’s Manual, Volume 3A). Some compilers use specific run-time libraries
to assist in floating-point exception handling. If any x87 FPU floating-point operations
are going to be performed that might raise floating-point exceptions, then the excep-
tion handling routine must either disable all floating-point exceptions (for example,
loading a local control word with FLDCW), or it must be implemented as re-entrant
(for the case of x87 FPU exceptions, refer to Example D-1 in Appendix D, “Guidelines
for Writing x87 FPU Exception Handlers”). If this is not the case, the routine has to
clear the status flags for x87 FPU exceptions or to mask all x87 FPU floating-point
exceptions. For SIMD floating-point exceptions though, the exception flags in MXCSR
do not have to be cleared, even if they remain unmasked (but they may still be
cleared). Exceptions are in this case precise and occur immediately, and a SIMD
floating-point exception status flag that is set when the corresponding exception is
unmasked will not generate an exception.
Typical actions performed by this low-level exception handling routine are:
• Incrementing an exception counter for later display or printing
• Printing or displaying diagnostic information (e.g. the MXCSR and XMM registers)
• Aborting further execution, or using the exception pointers to build an instruction
that will run without exception and executing it
• Storing information about the exception in a data structure that will be passed to
a higher level user exception handler
In most cases (and this applies also to SSE/SSE2/SSE3 instructions), there will be
three main components of a low-level floating-point exception handler: a prologue, a
body, and an epilogue.
The prologue performs functions that must be protected from possible interruption
by higher-priority sources - typically saving registers and transferring diagnostic
information from the processor to memory. When the critical processing has been
completed, the prologue may re-enable interrupts to allow higher-priority interrupt
handlers to preempt the exception handler (assuming that the interrupt handler was
called through an interrupt gate, meaning that the processor cleared the interrupt
enable (IF) flag in the EFLAGS register - refer to Section 6.4.1, “Call and Return
Operation for Interrupt or Exception Handling Procedures”).
The body of the exception handler examines the diagnostic information and makes a
response that is application-dependent. It may range from halting execution, to
displaying a message, to attempting to fix the problem and then proceeding with
normal execution, to setting up a data structure, calling a higher-level user exception
handler and continuing execution upon return from it. This latter case will be
assumed in Section E.4, “SIMD Floating-Point Exceptions and the IEEE Standard
754” below.
Finally, the epilogue essentially reverses the actions of the prologue, restoring the
processor state so that normal execution can be resumed.
The following example represents a typical exception handler. To link it with
Example E-1 that will follow in Section E.4.3, “Example SIMD Floating-Point Emula-