22-2 Vol. 3B

ARCHITECTURE COMPATIBILITY

22.2 RESERVED 

BITS

Throughout this manual, certain bits are marked as reserved in many register and memory layout descriptions. 
When bits are marked as undefined or reserved, it is essential for compatibility with future processors that software 
treat these bits as having a future, though unknown effect. Software should follow these guidelines in dealing with 
reserved bits:

•

Do not depend on the states of any reserved bits when testing the values of registers or memory locations that 
contain such bits. Mask out the reserved bits before testing.

•

Do not depend on the states of any reserved bits when storing them to memory or to a register.

•

Do not depend on the ability to retain information written into any reserved bits.

•

When loading a register, always load the reserved bits with the values indicated in the documentation, if any, or 
reload them with values previously read from the same register.

Software written for existing IA-32 processor that handles reserved bits correctly will port to future IA-32 proces-
sors without generating protection exceptions.

22.3 

ENABLING NEW FUNCTIONS AND MODES

Most of the new control functions defined for the P6 family and Pentium processors are enabled by new mode flags 
in the control registers (primarily register CR4). This register is undefined for IA-32 processors earlier than the 
Pentium processor. Attempting to access this register with an Intel486 or earlier IA-32 processor results in an 
invalid-opcode exception (#UD). Consequently, programs that execute correctly on the Intel486 or earlier IA-32 
processor cannot erroneously enable these functions. Attempting to set a reserved bit in register CR4 to a value 
other than its original value results in a general-protection exception (#GP). So, programs that execute on the P6 
family and Pentium processors cannot erroneously enable functions that may be implemented in future IA-32 
processors. 
The P6 family and Pentium processors do not check for attempts to set reserved bits in model-specific registers; 
however these bits may be checked on more recent processors. It is the obligation of the software writer to enforce 
this discipline. These reserved bits may be used in future Intel processors.

22.4 

DETECTING THE PRESENCE OF NEW FEATURES THROUGH SOFTWARE

Software can check for the presence of new architectural features and extensions in either of two ways:
1. Test for the presence of the feature or extension. Software can test for the presence of new flags in the EFLAGS 

register and control registers. If these flags are reserved (meaning not present in the processor executing the 
test), an exception is generated. Likewise, software can attempt to execute a new instruction, which results in 
an invalid-opcode exception (#UD) being generated if it is not supported.

2. Execute the CPUID instruction. The CPUID instruction (added to the IA-32 in the Pentium processor) indicates 

the presence of new features directly.

See Chapter 19, “Processor Identification and Feature Determination,” in the Intel® 64 and IA-32 Architectures 
Software Developer’s Manual, Volume 1, for detailed information on detecting new processor features and exten-
sions.

22.5 INTEL 

MMX 

TECHNOLOGY

The Pentium processor with MMX technology introduced the MMX technology and a set of MMX instructions to the 
IA-32. The MMX instructions are described in Chapter 9, “Programming with Intel® MMX™ Technology,” in the 
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, and in the Intel® 64 and IA-32 Archi-
tectures Software Developer’s Manual, Volumes 2A, 2B, 2C & 2D. The MMX technology and MMX instructions are 
also included in the Pentium II, Pentium III, Pentium 4, and Intel Xeon processors.