Specification Update

MOBILE INTEL
®
CELERON
®
PROCESSOR at 466 MHz, 433 MHz, 400 MHz,
366 MHz, 333 MHz, 300 MHz, 266 MHz SPECIFICATION UPDATE
23
3. If there is an unmasked floating-point exception pending, then the store could happen prior to the triggered
unmasked floating-point exception.
4. If CR0.TS = 1 (Task Switched bit), then the store could happen prior to the triggered Device Not Available
(DNA) exception.
If the MOVD/MOVQ instruction is restarted after handling any of the above events, then the store will be
performed again, overwriting with the expected data. The instruction will not be restarted after event 1. The
instruction will definitely be restarted after events 2 and 4. The instruction may or may not be restarted after
event 3, depending on the specific exception handler.
Implication:
This erratum causes unpredictable behavior in an application if MOVD/MOVQ instructions are
used to manipulate semaphores for multiprocessor synchronization, or if these MMX instructions are used to
write to uncacheable memory or memory mapped I/O that has side effects, e.g., graphics devices. This erratum
is completely transparent to all applications that do not have these characteristics. When each of the above
conditions are analyzed:
1. Setting the CR0.EM bit forces all floating-point/MMX instructions to be handled by software emulation. The
MOVD/MOVQ instruction, which is an MMX instruction, would be considered an invalid instruction.
Operating systems typically terminates the application after getting the expected invalid opcode fault.
2. The FP TOS not equal to 0 case only occurs when the MOVD/MOVQ store is the first MMX instruction in an
MMX technology routine and the previous floating-point routine did not clean up the floating-point states
properly when it exited. Floating-point routines commonly leave TOS to 0 prior to exiting. For a store to be
executed as the first MMX instruction in an MMX technology routine following a floating-point routine, the
software would be implementing instruction level intermixing of floating-point and MMX instructions. Intel
does not recommend this practice.
3. The unmasked floating-point exception case only occurs if the store is the first MMX technology instruction
in an MMX technology routine and the previous floating-point routine exited with an unmasked floating-point
exception pending. Again, for a store to be executed as the first MMX instruction in an MMX technology
routine following a floating-point routine, the software would be implementing instruction level intermixing of
floating-point and MMX instructions. Intel does not recommend this practice.
4. Device Not Available (DNA) exceptions occur naturally when a task switch is made between two tasks that
use either floating-point instructions and/or MMX instructions. For this erratum, in the event of the DNA
exception, data from the prior task may be temporarily stored to the present task’s program state.
Workaround: Do not use MMX instructions to manipulate semaphores for multiprocessor synchronization. Do
not use MOVD/MOVQ instructions to write directly to I/O devices if doing so triggers user visible side effects. An
OS can prevent old data from being stored to a new task’s program state by cleansing the FPU explicitly after
every task switch. Follow Intel’s recommended programming paradigms in the Intel Architecture Optimization
Manual for writing MMX technology programs. Specifically, do not mix floating-point and MMX instructions.
When transitioning to new a MMX technology routine, begin with an instruction that does not depend on the
prior state of either the MMX technology registers or the floating-point registers, such as a load or PXOR mm0,
mm0. Be sure that the FP TOS is clear before using MMX instructions.
Status: For the steppings affected see the Summary of Changes at the beginning of this section.
H21. Memory Type Undefined for Nonmemory Operations
Problem: The Memory Type field for nonmemory transactions such as I/O and Special Cycles are undefined.
Although the Memory Type attribute for nonmemory operations logically should (and usually does) manifest
itself as UC, this feature is not designed into the implementation and is therefore inconsistent.
Implication:
Bus agents may decode a non-UC memory type for nonmemory bus transactions.