<<<    Index    >>>
F-2
GUIDELINES FOR WRITING SIMD FLOATING-POINT EXCEPTION 
control word with FLDCW), or it must be implemented as re-entrant (for the case of FPU ex-
ceptions, refer to Example E-5 in Appendix E, Guidelines for Writing FPU Exceptions Han-
dlers). If this is not the case, the routine has to clear the status flags for FPU exceptions, or to
mask all FPU floating-point exceptions. For Streaming SIMD Extensions floating-point excep-
tions though, the exception flags in MXCSR do not have to be cleared, even if they remain un-
masked (they may still be cleared). Exceptions are in this case precise and occur immediately,
and a Streaming SIMD Extensions exception status flag that is set when the corresponding ex-
ception 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 the Streaming SIMD Extensions 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 pro-
cessor 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 4.4.1., “Call and
Return Operation for Interrupt or Exception Handling Procedures” in Chapter 4, Procedure
Calls, Interrupts, and Exceptions).
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 F.4., “SIMD Floating-Point Exceptions and
the IEEE-754 Standard for Binary Floating-Point Computations” 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 F-2 that
will follow in Section F.4.3., “SIMD Floating-Point Emulation Implementation Example”, as-
sume that the body of the handler (not shown here in detail) passes the saved state to a routine
that will examine in turn all the sub-operands of the excepting instruction, invoking a user float-
ing-point exception handler if a particular set of sub-operands raises an unmasked (enabled) ex-
ception, or emulating the instruction otherwise.
<<<    Index    >>>