Specification Update

Errata
22 Specification Update
AT18. FP Inexact-Result Exception Flag May Not Be Set
Problem:
When the result of a floating-point operation is not exactly representable in the
destination format (1/3 in binary form, for example), an inexact-result (precision)
exception occurs. When this occurs, the PE bit (bit 5 of the FPU status word) is
normally set by the processor. Under certain rare conditions, this bit may not be set
when this rounding occurs. However, other actions taken by the processor (invoking
the software exception handler if the exception is unmasked) are not affected. This
erratum can only occur if one of the following FST instructions is one or two
instructions after the floating-point operation which causes the precision exception:
• FST m32real
• FST m64real
• FSTP m32real
• FSTP m64real
• FSTP m80real
• FIST m16int
• FIST m32int
• FISTP m16int
• FISTP m32int
• FISTP m64int
• FISTTP m16int
• FISTTP m32int
• FISTTP m64int
Note: Even if this combination of instructions is encountered, there is also a dependency on
the internal pipelining and execution state of both instructions in the processor.
Implication: Inexact-result exceptions are commonly masked or ignored by applications, as it
happens frequently, and produces a rounded result acceptable to most applications.
The PE bit of the FPU status word may not always be set upon receiving an inexact-
result exception. Thus, if these exceptions are unmasked, a floating-point error
exception handler may not recognize that a precision exception occurred. Note that
this is a "sticky" bit, i.e., once set by an inexact-result condition, it remains set until
cleared by software.
Workaround: This condition can be avoided by inserting either three NOPs or three non-floating-
point non-Jcc instructions between the two floating-point instructions.
Status: For the steppings affected, see the Summary Tables of Changes.
AT19. Global Pages in the Data Translation Look-Aside Buffer (DTLB) May
Not Be Flushed by RSM instruction before Restoring the Architectural
State from SMRAM
Problem:
The Resume from System Management Mode (RSM) instruction does not flush global
pages from the Data Translation Look-Aside Buffer (DTLB) prior to reloading the saved
architectural state.
Implication: If SMM turns on paging with global paging enabled and then maps any of linear
addresses of SMRAM using global pages, RSM load may load data from the wrong
location.
Workaround: Do not use global pages in system management mode.
Status: For the steppings affected, see the Summary Tables of Changes.