INTEL
®
CELERON® PROCESSOR SPECIFICATION UPDATE
31
Status:
For the steppings affected see the
Summary of Changes
at the beginning of this section.
C13.
Reporting of Floating-Point Exception May Be Delayed
Problem:
The Celeron processor normally reports a floating-point exception for an instruction when the next
floating-point or Intel
®
MMX™ technology instruction is executed. The assertion of FERR# and/or the INT 16
interrupt corresponding to the exception may be delayed until the floating-point or MMX technology instruction
after
the one which is expected to trigger the exception, if the following conditions are met:
1.
A floating-point instruction causes an exception.
2.
Before another floating-point or MMX technology instruction, any one of the following occurs:
•
A subsequent data access occurs to a page which has not been marked as accessed
•
Data is referenced which crosses a page boundary
•
A possible page-fault condition is detected which, when resolved, completes without faulting
3.
The instruction causing event 2 above is followed by a MOVQ or MOVD store instruction.
Implication:
This erratum only affects software which operates with floating-point exceptions unmasked.
Software which requires floating-point exceptions to be visible on the next floating-point or MMX technology
instruction, and which uses floating-point calculations on data which is then used for MMX technology
instructions, may see a delay in the reporting of a floating-point instruction exception in some cases. Note that
mixing floating-point and MMX technology instructions in this way is not recommended.
Workaround:
Inserting a WAIT or FWAIT instruction (or reading the floating-point status register) between
the floating-point instruction and the MOVQ or MOVD instruction will give the expected results. This is already
the recommended practice for software.
Status:
For the steppings affected see the
Summary of Changes
at the beginning of this section.
C14.
Near CALL to ESP Creates Unexpected EIP Address
Problem:
As documented, the CALL instruction saves procedure linking information in the procedure stack
and jumps to the called procedure specified with the destination (target) operand. The target operand
specifies the address of the first instruction in the called procedure. This operand can be an immediate value,
a general purpose register, or a memory location. When accessing an absolute address indirectly using the
stack pointer (ESP) as a base register, the base value used is the value in the ESP register before the
instruction executes. However, when accessing an absolute address directly using ESP as the base register,
the base value used is the value of ESP
after
the return value is pushed on the stack, not the value in the ESP
register
before
the instruction executed.
Implication:
Due to this erratum, the processor may transfer control to an unintended address. Results are
unpredictable, depending on the particular application, and can range from no effect to the unexpected
termination of the application due to an exception. Intel has observed this erratum only in a focused testing
environment. Intel has not observed any commercially available operating system, application, or compiler
that makes use of or generates this instruction.
Workaround:
If the other seven general purpose registers are unavailable for use, and it is necessary to do
a CALL via the ESP register, first push ESP onto the stack, then perform an
indirect
call using ESP (e.g.,
CALL [ESP]). The saved version of ESP should be popped off the stack after the call returns.
Status:
For the steppings affected see the
Summary of Changes
at the beginning of this section.
