Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023)

CHAPTER 13

INTEL® MMX™ TECHNOLOGY SYSTEM PROGRAMMING

This chapter describes those features of the Intel^® MMX™ technology that must be considered when designing or

enhancing an operating system to support MMX technology. It covers MMX instruction set emulation, the MMX

state, aliasing of MMX registers, saving MMX state, task and context switching considerations, exception handling,

and debugging.

13.1

EMULATION OF THE MMX INSTRUCTION SET

The IA-32 or Intel 64 architecture does not support emulation of the MMX instructions, as it does for x87 FPU

instructions. The EM flag in control register CR0 (provided to invoke emulation of x87 FPU instructions) cannot be

used for MMX instruction emulation. If an MMX instruction is executed when the EM flag is set, an invalid opcode

exception (UD#) is generated. Table 13-1 shows the interaction of the EM, MP, and TS flags in control register CR0

when executing MMX instructions.

Table 13-1. Action Taken By MMX Instructions for Different Combinations of EM, MP, and TS

CR0 Flags

MP*

Action

Execute.

#NM exception.

#UD exception.

NOTE:

* For processors that support the MMX instructions, the MP flag should be set.

13.2

THE MMX STATE AND MMX REGISTER ALIASING

The MMX state consists of eight 64-bit registers (MM0 through MM7). These registers are aliased to the low 64-bits

(bits 0 through 63) of floating-point registers R0 through R7 (see Figure 13-1). Note that the MMX registers are

mapped to the physical locations of the floating-point registers (R0 through R7), not to the relative locations of the

registers in the floating-point register stack (ST0 through ST7). As a result, the MMX register mapping is fixed and

is not affected by value in the Top Of Stack (TOS) field in the floating-point status word (bits 11 through 13).

Vol. 3A

13-1

INTEL® MMX™ TECHNOLOGY SYSTEM PROGRAMMING

x87 FPU Tag

Floating-Point Registers

64 63

x87 FPU Status Register

000

MMX Registers

TOS

MM7

MM6

MM5

MM4

MM3

MM2

MM1

TOS = 0

MM0

Figure 13-1. Mapping of MMX Registers to Floating-Point Registers

When a value is written into an MMX register using an MMX instruction, the value also appears in the corresponding

floating-point register in bits 0 through 63. Likewise, when a floating-point value written into a floating-point

The execution of MMX instructions have several side effects on the x87 FPU state contained in the floating-point

registers, the x87 FPU tag word, and the x87 FPU status word. These side effects are as follows:

• When an MMX instruction writes a value into an MMX register, at the same time, bits 64 through 79 of the corre-

sponding floating-point register are set to all 1s.

• When an MMX instruction (other than the EMMS instruction) is executed, each of the tag fields in the x87 FPU

tag word is set to 00B (valid). (See also Section 13.2.1, “Effect of MMX, x87 FPU, FXSAVE, and FXRSTOR

Instructions on the x87 FPU Tag Word.”)

• When the EMMS instruction is executed, each tag field in the x87 FPU tag word is set to 11B (empty).

• Each time an MMX instruction is executed, the TOS value is set to 000B.

Execution of MMX instructions does not affect the other bits in the x87 FPU status word (bits 0 through 10 and bits

14 and 15) or the contents of the other x87 FPU registers that comprise the x87 FPU state (the x87 FPU control

word, instruction pointer, data pointer, or opcode registers).

Table 13-2 summarizes the effects of the MMX instructions on the x87 FPU state.

13-2

Vol. 3A

INTEL® MMX™ TECHNOLOGY SYSTEM PROGRAMMING

Table 13-2. Effects of MMX Instructions on x87 FPU State

MMX Instruction

x87 FPU Tag

TOS Field of x87

Other x87 FPU

Bits 64 Through 79

Bits 0 Through 63

Type

Word

FPU Status Word

Registers

of x87 FPU Data

Registers

Read from MMX

All tags set to 00B

000B

Unchanged

(Valid)

Write to MMX

All tags set to 00B

000B

Unchanged

Set to all 1s

Overwritten with

(Valid)

MMX data

EMMS

All fields set to

000B

Unchanged

11B (Empty)

13.2.1 Effect of MMX, x87 FPU, FXSAVE, and FXRSTOR Instructions on the x87 FPU Tag

Word

Table 13-3 summarizes the effect of MMX and x87 FPU instructions and the FXSAVE and FXRSTOR instructions on

the tags in the x87 FPU tag word and the corresponding tags in an image of the tag word stored in memory.

The values in the fields of the x87 FPU tag word do not affect the contents of the MMX registers or the execution of

MMX instructions. However, the MMX instructions do modify the contents of the x87 FPU tag word, as is described

in Section 13.2, “The MMX State and MMX Register Aliasing.” These modifications may affect the operation of the

x87 FPU when executing x87 FPU instructions, if the x87 FPU state is not initialized or restored prior to beginning

x87 FPU instruction execution.

Note that the FSAVE, FXSAVE, and FSTENV instructions (which save x87 FPU state information) read the x87 FPU

tag register and contents of each of the floating-point registers, determine the actual tag values for each register

(empty, nonzero, zero, or special), and store the updated tag word in memory. After executing these instructions,

all the tags in the x87 FPU tag word are set to empty (11B). Likewise, the EMMS instruction clears MMX state from

the MMX/floating-point registers by setting all the tags in the x87 FPU tag word to 11B.

Table 13-3. Effect of the MMX, x87 FPU, and FXSAVE/FXRSTOR Instructions on the x87 FPU Tag Word

Instruction

x87 FPU Tag Word

Image of x87 FPU Tag Word Stored in

Type

Memory

MMX

All (except EMMS)

All tags are set to 00B (valid).

Not affected.

MMX

EMMS

All tags are set to 11B (empty).

Not affected.

x87 FPU

All (except FSAVE,

Tag for modified floating-point register is

Not affected.

FSTENV, FRSTOR,

set to 00B or 11B.

FLDENV)

x87 FPU and

FSAVE, FSTENV, FXSAVE

Tags and register values are read and

Tags are set according to the actual

FXSAVE

interpreted; then all tags are set to 11B.

values in the floating-point registers;

that is, empty registers are marked 11B

and valid registers are marked 00B

(nonzero), 01B (zero), or 10B (special).

x87 FPU and

FRSTOR, FLDENV,

All tags marked 11B in memory are set

Tags are read and interpreted, but not

FXRSTOR

to 11B; all other tags are set according

modified.

to the value in the corresponding

floating-point register: 00B (nonzero),

01B (zero), or 10B (special).

13.3

SAVING AND RESTORING THE MMX STATE AND REGISTERS

Because the MMX registers are aliased to the x87 FPU data registers, the MMX state can be saved to memory and

restored from memory as follows:

Vol. 3A

13-3

INTEL® MMX™ TECHNOLOGY SYSTEM PROGRAMMING

• Execute an FSAVE, FNSAVE, or FXSAVE instruction to save the MMX state to memory. (The FXSAVE instruction

also saves the state of the XMM and MXCSR registers.)

• Execute an FRSTOR or FXRSTOR instruction to restore the MMX state from memory. (The FXRSTOR instruction

also restores the state of the XMM and MXCSR registers.)

The save and restore methods described above are required for operating systems (see Section 13.4, “Saving MMX

State on Task or Context Switches”). Applications can in some cases save and restore only the MMX registers in the

following way:

• Execute eight MOVQ instructions to save the contents of the MMX0 through MMX7 registers to memory. An

EMMS instruction may then (optionally) be executed to clear the MMX state in the x87 FPU.

• Execute eight MOVQ instructions to read the saved contents of MMX registers from memory into the MMX0

through MMX7 registers.

NOTE

The IA-32 architecture does not support scanning the x87 FPU tag word and then only saving valid

entries.

13.4

SAVING MMX STATE ON TASK OR CONTEXT SWITCHES

When switching from one task or context to another, it is often necessary to save the MMX state. As a general rule,

if the existing task switching code for an operating system includes facilities for saving the state of the x87 FPU,

these facilities can also be relied upon to save the MMX state, without rewriting the task switch code. This reliance

is possible because the MMX state is aliased to the x87 FPU state (see Section 13.2, “The MMX State and MMX

With the introduction of the FXSAVE and FXRSTOR instructions and of SSE/SSE2/SSE3/SSSE3 extensions, it is

possible (and more efficient) to create state saving facilities in the operating system or executive that save the x87

FPU/MMX/SSE/SSE2/SSE3/SSSE3 state in one operation. Section 14.4, “Designing OS Facilities for Saving x87

FPU, SSE, AND EXTENDED States on Task or Context Switches,” describes how to design such facilities. The tech-

niques describes in this section can be adapted to saving only the MMX and x87 FPU state if needed.

13.5

EXCEPTIONS THAT CAN OCCUR WHEN EXECUTING MMX INSTRUCTIONS

MMX instructions do not generate x87 FPU floating-point exceptions, nor do they affect the processor’s status flags

in the EFLAGS register or the x87 FPU status word. The following exceptions can be generated during the execution

of an MMX instruction:

• Exceptions during memory accesses:

- Stack-segment fault (#SS).

- General protection (#GP).

- Page fault (#PF).

- Alignment check (#AC), if alignment checking is enabled.

• System exceptions:

- Invalid Opcode (#UD), if the EM flag in control register CR0 is set when an MMX instruction is executed (see

Section 13.1, “Emulation of the MMX Instruction Set”).

- Device not available (#NM), if an MMX instruction is executed when the TS flag in control register CR0 is

set. (See Section 14.4.1, “Using the TS Flag to Control the Saving of the x87 FPU and SSE State.”)

• Floating-point error (#MF). (See Section 13.5.1, “Effect of MMX Instructions on Pending x87 Floating-Point

Exceptions.”)

• Other exceptions can occur indirectly due to the faulty execution of the exception handlers for the above

exceptions.

13-4

Vol. 3A

INTEL® MMX™ TECHNOLOGY SYSTEM PROGRAMMING

13.5.1 Effect of MMX Instructions on Pending x87 Floating-Point Exceptions

If an x87 FPU floating-point exception is pending and the processor encounters an MMX instruction, the processor

generates a x87 FPU floating-point error (#MF) prior to executing the MMX instruction, to allow the pending excep-

tion to be handled by the x87 FPU floating-point error exception handler. While this exception handler is executing,

the x87 FPU state is maintained and is visible to the handler. Upon returning from the exception handler, the MMX

instruction is executed, which will alter the x87 FPU state, as described in Section 13.2, “The MMX State and MMX

13.6

DEBUGGING MMX CODE

The debug facilities operate in the same manner when executing MMX instructions as when executing other IA-32

or Intel 64 architecture instructions.

To correctly interpret the contents of the MMX or x87 FPU registers from the FSAVE/FNSAVE or FXSAVE image in

memory, a debugger needs to take account of the relationship between the x87 FPU register’s logical locations

relative to TOS and the MMX register’s physical locations.

In the x87 FPU context, STn refers to an x87 FPU register at location n relative to the TOS. However, the tags in the

x87 FPU tag word are associated with the physical locations of the x87 FPU registers (R0 through R7). The MMX

registers always refer to the physical locations of the registers (with MM0 through MM7 being mapped to R0

through R7). Figure 13-2 shows this relationship. Here, the inner circle refers to the physical location of the x87

FPU and MMX registers. The outer circle refers to the x87 FPU register’s relative location to the current TOS.

When the TOS equals 0 (case A in Figure 13-2), ST0 points to the physical location R0 on the floating-point stack.

MM0 maps to ST0, MM1 maps to ST1, and so on.

When the TOS equals 2 (case B in Figure 13-2), ST0 points to the physical location R2. MM0 maps to ST6, MM1

maps to ST7, MM2 maps to ST0, and so on.

x87 FPU “push”

x87 FPU “pop”

ST0

ST6

ST7

ST1

ST7

MM0

(R0)

MM7

MM1

MM7

MM1

TOS

MM2

MM6

TOS

ST0

ST2

MM6

(R2)

MM5

MM3

MM5

MM3

x87 FPU “pop”

MM4

ST1

Case B: TOS=2

Case A: TOS=0

Outer circle = x87 FPU data register’s logical location relative to TOS

Inner circle = x87 FPU tags = MMX register’s location = FP register’s physical location

Figure 13-2. Mapping of MMX Registers to x87 FPU Data Register Stack

Vol. 3A

13-5

CHAPTER 14

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND

PROCESSOR EXTENDED STATES

This chapter describes system programming features for instruction set extensions operating on the processor

state extension known as the SSE state (XMM registers, MXCSR) and for other processor extended states. Instruc-

tion set extensions operating on the SSE state include the streaming SIMD extensions (SSE), streaming SIMD

extensions 2 (SSE2), streaming SIMD extensions 3 (SSE3), Supplemental SSE3 (SSSE3), and SSE4. Collectively,

these are called SSE extensions¹ and the corresponding instructions are called SSE instructions.

FXSAVE/FXRSTOR instructions can be used save/restore SSE state along with FP state. See Section 10.5 in the

Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, for information about FXSAVE and

FXRSTOR.

Sections 14.1 through 14.4 cover system programming requirements to enable the SSE extensions, providing

operating system or executive support for the SSE extensions, SIMD floating-point exceptions, exception handling,

and task (context) switching. These sections primarily discuss use of FXSAVE/FXRSTOR to save/restore SSE state.

XSAVE feature set refers to extensions to the Intel architecture that will allow system executives to implement

support for multiple processor extended states along with FP/SSE states that may be introduced over time without

requiring the system executive to be modified each time a new processor state extension is introduced. XSAVE

feature set provide mechanisms to enumerate the supported extended states, enable some or all of them for soft-

ware use, instructions to save/restore the states and enumerate the layout of the states when saved to memory.

XSAVE/XRSTOR instructions are part of the XSAVE feature set. These instructions are introduced after the intro-

duction of FP/SSE states but can be used to manage legacy FP/SSE state along with processor extended states. See

Chapter 13 in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, for information about

XSAVE feature set.

System programming for managing processor extended states is described in sections 14.5 through 14.6. XSAVE

feature set is designed to be compatible with FXSAVE/FXRSTOR and hence much of the material through sections

14.1 to 14.4 related to SSE state also applies to XSAVE feature set with the exception of enumeration and

saving/restoring state.

XSAVE Compaction is an XSAVE feature that allows operating systems to allocate space for only the states saved

to conserve memory usage. A new instruction called XSAVEC is introduced to save extended states in compacted

format and XRSTOR instruction is enhanced to comprehend compacted format. System programming for managing

processor extended states in compacted format is also described in section 14.5.

Supervisor state is an extended state that can only be accessed in ring 0. XSAVE feature set has been enhanced

to manage supervisor states. Two new ring 0 instructions, XSAVES/XRSTORS, are introduced to save/restore

supervisor states along with other XSAVE managed states. They are privileged instruction and only operate in

compacted format. System programming for managing supervisor states in described in section 14.7.

Each XSAVE managed features may have additional feature specific system programming requirements such as

exception handlers etc. Feature specific system programming requirements for XSAVE managed features are

described in Section 14.8.

14.1

PROVIDING OPERATING SYSTEM SUPPORT FOR SSE EXTENSIONS

To use SSE extensions, the operating system or executive must provide support for initializing the processor to use

these extensions, for handling SIMD floating-point exceptions, and for using FXSAVE and FXRSTOR (Section 10.5

of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1) to manage context. XSAVE

feature set can also be used to manage SSE state along with other processor extended states as described in 14.5.

This section primarily focuses on using FXSAVE/FXRSTOR to manage SSE state. Because SSE extensions share the

same state, experience the same sets of non-numerical and numerical exception behavior, these guidelines that

1. The collection also includes PCLMULQDQ and AES instructions operating on XMM state.

Vol. 3A

14-1

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES

apply to SSE also apply to other sets of SIMD extensions that operate on the same processor state and subject to

the same sets of non-numerical and numerical exception behavior.

Chapter 11, “Programming with Intel® Streaming SIMD Extensions 2 (Intel® SSE2)‚” and Chapter 12, “Program-

ming with Intel® SSE3, SSSE3, Intel® SSE4, and Intel® AES-NI,” in the Intel^® 64 and IA-32 Architectures Soft-

ware Developer’s Manual, Volume 1, provide details on the Intel SSE instruction set.

14.1.1 Adding Support to an Operating System for SSE Extensions

The following guidelines describe functions that an operating system or executive must perform to support SSE

extensions:

1. Check that the processor supports the SSE extensions.

2. Check that the processor supports the FXSAVE and FXRSTOR instructions or the XSAVE feature set.

3. Provide an initialization for the SSE states.

4. Provide support for the FXSAVE and FXRSTOR instructions or the XSAVE feature set.

5. Provide support (if necessary) in non-numeric exception handlers for exceptions generated by the SSE instruc-

tions.

6. Provide an exception handler for the SIMD floating-point exception (#XM).

The following sections describe how to implement each of these guidelines.

14.1.2 Checking for CPU Support

If the processor attempts to execute an unsupported SSE instruction, the processor generates an invalid-opcode

exception (#UD). Before an operating system or executive attempts to use SSE extensions, it should check that

support is present by confirming the following bit values returned by the CPUID instruction:

• CPUID.1:EDX.SSE[bit 25] = 1

• CPUID.1:EDX.SSE2[bit 26] = 1

• CPUID.1:ECX.SSE3[bit 0] = 1

• CPUID.1:ECX.SSSE3[bit 9] = 1

• CPUID.1:ECX.SSE4_1[bit 19] = 1

• CPUID.1:ECX.SSE4_2[bit 20] = 1

(To use POPCNT instruction, software must check CPUID.1:ECX.POPCNT[bit 23] = 1.)

Separate checks must be made to ensure that the processor supports either FXSAVE and FXRSTOR or the XSAVE

feature set. See Section 10.5 of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, and

Chapter 13 of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, respectively.

14.1.3 Initialization of the SSE Extensions

The operating system or executive should carry out the following steps to set up SSE extensions for use by appli-

cation programs:

1. Set CR4.OSFXSR[bit 9] = 1. Setting this flag implies that the operating system provides facilities for saving

and restoring SSE state using FXSAVE and FXRSTOR instructions. These instructions may be used to save the

SSE state during task switches and when invoking the SIMD floating-point exception (#XM) handler (see

Section 14.1.5, “Providing a Handler for the SIMD Floating-Point Exception (#XM)”).

If the processor does not support the FXSAVE and FXRSTOR instructions, attempting to set the OSFXSR flag

causes a general-protection exception (#GP) to be generated.

14-2

Vol. 3A

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES

2. Set CR4.OSXMMEXCPT[bit 10] = 1. Setting this flag implies that the operating system provides a SIMD

floating-point exception (#XM) handler (see Section 14.1.5, “Providing a Handler for the SIMD Floating-Point

Exception (#XM)”).

NOTE

The OSFXSR and OSXMMEXCPT bits in control register CR4 must be set by the operating system.

The processor has no other way of detecting operating-system support for the FXSAVE and

FXRSTOR instructions or for handling SIMD floating-point exceptions.

3. Clear CR0.EM[bit 2] = 0. This action disables emulation of the x87 FPU, which is required when executing SSE

instructions (see Section 2.5, “Control Registers”).

4. Set CR0.MP[bit 1] = 1. This setting is required for Intel 64 and IA-32 processors that support the SSE

extensions (see Section 10.2.1, “Configuring the x87 FPU Environment”).

Table 14-1 and Table 14-2 show the actions of the processor when an SSE instruction is executed, depending on

the following:

• OSFXSR and OSXMMEXCPT flags in control register CR4

• SSE/SSE2/SSE3/SSSE3/SSE4 feature flags returned by CPUID

• EM, MP, and TS flags in control register CR0

Table 14-1. Action Taken for Combinations of OSFXSR, OSXMMEXCPT, SSE, SSE2, SSE3, EM, MP, and TS¹

CR4

CPUID

CR0 Flags

OSFXSR

OSXMMEXCPT

SSE, SSE2,

MP⁴

Action

SSE3²,

SSE4_1³

X⁵

#UD exception.

Execute instruction; #UD exception if unmasked

SIMD floating-point exception is detected.

Execute instruction; #XM exception if unmasked

SIMD floating-point exception is detected.

#NM exception.

NOTES:

1. For execution of any SSE instruction except the PAUSE, PREFETCHh, SFENCE, LFENCE, MFENCE, MOVNTI, and CLFLUSH instructions.

2. Exception conditions due to CR4.OSFXSR or CR4.OSXMMEXCPT do not apply to FISTTP.

3. Only applies to DPPS, DPPD, ROUNDPS, ROUNDPD, ROUNDSS, ROUNDSD.

4. For processors that support the MMX instructions, the MP flag should be set.

5. X = Don’t care.

Vol. 3A

14-3

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES

Table 14-2. Action Taken for Combinations of OSFXSR, SSSE3, SSE4, EM, and TS

CR4

CPUID

CR0 Flags

OSFXSR

SSSE3

Action

SSE4_1¹

SSE4_2²

X³

#UD exception.

#NM exception.

NOTES:

1. Applies to SSE4_1 instructions except DPPS, DPPD, ROUNDPS, ROUNDPD, ROUNDSS, ROUNDSD.

2. Applies to SSE4_2 instructions except CRC32 and POPCNT.

3. X = Don’t care.

The SIMD floating-point exception mask bits (bits 7 through 12), the flush-to-zero flag (bit 15), the denormals-are-

zero flag (bit 6), and the rounding control field (bits 13 and 14) in the MXCSR register should be left in their default

values of 0. This permits the application to determine how these features are to be used.

14.1.4 Providing Non-Numeric Exception Handlers for Exceptions Generated by the SSE

Instructions

SSE instructions can generate the same type of memory-access exceptions (such as page faults and limit viola-

tions) and other non-numeric exceptions as other Intel 64 and IA-32 architecture instructions generate.

Ordinarily, existing exception handlers can handle these and other non-numeric exceptions without code modifica-

tion. However, depending on the mechanisms used in existing exception handlers, some modifications might need

to be made.

The SSE extensions can generate the non-numeric exceptions listed below:

• Memory Access Exceptions:

- Stack-segment fault (#SS).

- General protection exception (#GP). Executing most SSE instructions with an unaligned 128-bit memory

reference generates a general-protection exception. (The MOVUPS and MOVUPD instructions allow

unaligned a loads or stores of 128-bit memory locations, without generating a general-protection

exception.) A 128-bit reference within the stack segment that is not aligned to a 16-byte boundary will also

generate a general-protection exception, instead a stack-segment fault exception (#SS).

- Page fault (#PF).

- Alignment check (#AC). When enabled, this type of alignment check operates on operands that are less

than 128-bits in size: 16-bit, 32-bit, and 64-bit. To enable the generation of alignment check exceptions, do

the following:

• Set the AM flag (bit 18 of control register CR0)

• Set the AC flag (bit 18 of the EFLAGS register)

• CPL must be 3

If alignment check exceptions are enabled, 16-bit, 32-bit, and 64-bit misalignment will be detected for the

MOVUPD and MOVUPS instructions; detection of 128-bit misalignment is not guaranteed and may vary

with implementation.

14-4

Vol. 3A

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES

• System Exceptions:

- Invalid-opcode exception (#UD). This exception is generated when executing SSE instructions under the

following conditions:

• SSE/SSE2/SSE3/SSSE3/SSE4_1/SSE4_2 feature flags returned by CPUID are set to 0. This condition

does not affect the CLFLUSH instruction, nor POPCNT.

• The CLFSH feature flag returned by the CPUID instruction is set to 0. This exception condition only

pertains to the execution of the CLFLUSH instruction.

• The POPCNT feature flag returned by the CPUID instruction is set to 0. This exception condition only

pertains to the execution of the POPCNT instruction.

• The EM flag (bit 2) in control register CR0 is set to 1, regardless of the value of TS flag (bit 3) of CR0.

This condition does not affect the PAUSE, PREFETCHh, MOVNTI, SFENCE, LFENCE, MFENCE, CLFLUSH,

CRC32, and POPCNT instructions.

• The OSFXSR flag (bit 9) in control register CR4 is set to 0. This condition does not affect the PSHUFW,

MOVNTQ, MOVNTI, PAUSE, PREFETCHh, SFENCE, LFENCE, MFENCE, CLFLUSH, CRC32, and POPCNT

instructions.

• Executing an instruction that causes a SIMD floating-point exception when the OSXMMEXCPT flag (bit

10) in control register CR4 is set to 0. See Section 14.4.1, “Using the TS Flag to Control the Saving of

the x87 FPU and SSE State.”

- Device not available (#NM). This exception is generated by executing a SSE instruction when the TS flag

(bit 3) of CR0 is set to 1.

Other exceptions can occur during delivery of the above exceptions.

14.1.5 Providing a Handler for the SIMD Floating-Point Exception (#XM)

SSE instructions do not generate numeric exceptions on packed integer operations. They can generate the

following numeric (SIMD floating-point) exceptions on packed and scalar single precision and double precision

floating-point operations.

• Invalid operation (#I)

• Divide-by-zero (#Z)

• Denormal operand (#D)

• Numeric overflow (#O)

• Numeric underflow (#U)

• Inexact result (Precision) (#P)

These SIMD floating-point exceptions (with the exception of the denormal operand exception) are defined in the

IEEE Standard 754 for Floating-Point Arithmetic and represent the same conditions that cause x87 FPU floating-

point error exceptions (#MF) to be generated for x87 FPU instructions.

Each of these exceptions can be masked, in which case the processor returns a reasonable result to the destination

operand without invoking an exception handler. However, if any of these exceptions are left unmasked, detection

of the exception condition results in a SIMD floating-point exception (#XM) being generated. See Chapter 6,

“Interrupt 19-SIMD Floating-Point Exception (#XM).”

To handle unmasked SIMD floating-point exceptions, the operating system or executive must provide an exception

handler. The section titled “SSE and SSE2 SIMD Floating-Point Exceptions” in Chapter 11, “Programming with

Intel® Streaming SIMD Extensions 2 (Intel® SSE2),” of the Intel^® 64 and IA-32 Architectures Software Devel-

oper’s Manual, Volume 1, describes the SIMD floating-point exception classes and gives suggestions for writing an

exception handler to handle them.

To indicate that the operating system provides a handler for SIMD floating-point exceptions (#XM), the OSXM-

MEXCPT flag (bit 10) must be set in control register CR4.

Vol. 3A

14-5

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES

14.1.5.1 Numeric Error flag and IGNNE#

SSE extensions ignore the NE flag in control register CR0 (that is, they treat it as if it were always set) and the

IGNNE# pin. When an unmasked SIMD floating-point exception is detected, it is always reported by generating a

SIMD floating-point exception (#XM).

14.2

EMULATION OF SSE EXTENSIONS

The Intel 64 and IA-32 architectures do not support emulation of the SSE instructions, as they do for x87 FPU

instructions.

The EM flag in control register CR0 (provided to invoke emulation of x87 FPU instructions) cannot be used to invoke

emulation of SSE instructions. If an SSE instruction is executed when CR0.EM = 1, an invalid opcode exception

(#UD) is generated. See Table 14-1.

14.3

SAVING AND RESTORING SSE STATE

The SSE state consists of the state of the XMM and MXCSR registers. Intel recommends the following method for

saving and restoring this state:

• Execute the FXSAVE instruction to save the state of the XMM and MXCSR registers to memory.

• Execute the FXRSTOR instruction to restore the state of the XMM and MXCSR registers from the image saved in

memory earlier.

This save and restore method is required for all operating systems. XSAVE feature set can also be used to

save/restore SSE state. See Section 14.5, “The XSAVE Feature Set and Processor Extended State Management,”

for using the XSAVE feature set to save/restore SSE state.

In some cases, applications may choose to save only the XMM and MXCSR registers in the following manner:

• Execute MOVDQ instructions to save the contents of the XMM registers to memory.

• Execute a STMXCSR instruction to save the state of the MXCSR register to memory.

Such applications must restore the XMM and MXCSR registers as follows:

• Execute MOVDQ instructions to load the saved contents of the XMM registers from memory into the XMM

registers.

• Execute a LDMXCSR instruction to restore the state of the MXCSR register from memory.

14.4

DESIGNING OS FACILITIES FOR SAVING X87 FPU, SSE, AND EXTENDED

STATES ON TASK OR CONTEXT SWITCHES

The x87 FPU and SSE state consist of the state of the x87 FPU, XMM, and MXCSR registers. The FXSAVE and

FXRSTOR instructions provide a fast method for saving and restoring this state. The XSAVE feature set can also be

used to save FP and SSE state along with other extended states (see Section 14.5).

Older operating systems may use FSAVE/FNSAVE and FRSTOR to save the x87 FPU state. These facilities can be

extended to save and restore SSE state by substituting FXSAVE and FXRSTOR or the XSAVE feature set in place of

FSAVE/FNSAVE and FRSTOR.

If task or context switching facilities are written from scratch, any of several approaches may be taken for using the

FXSAVE and FXRSTOR instructions or the XSAVE feature set to save and restore x87 FPU and SSE state:

• The operating system can require applications that are intended to be run as tasks take responsibility for saving

the states prior to a task suspension during a task switch and for restoring the states when the task is resumed.

This approach is appropriate for cooperative multitasking operating systems, where the application has control

over (or is able to determine) when a task switch is about to occur and can save state prior to the task switch.

14-6

Vol. 3A

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES

• The operating system can take the responsibility for saving the states as part of the task switch process and

restoring the state of the registers when a suspended task is resumed. This approach is appropriate for

preemptive multitasking operating systems, where the application cannot know when it is going to be

preempted and cannot prepare in advance for task switching.

• The operating system can take the responsibility for saving the states as part of the task switch process, but

delay the restoring of the states until an instruction operating on the states is actually executed by the new

task. See Section 14.4.1, “Using the TS Flag to Control the Saving of the x87 FPU and SSE State,” for more

information. This approach is called lazy restore.

The use of lazy restore mechanism in context switches is not recommended when XSAVE feature set is used to

save/restore states for the following reasons.

- With XSAVE feature set, Intel processors have optimizations in place to avoid saving the state components

that are in their initial configurations or when they have not been modified since they were restored last.

These optimizations eliminate the need for lazy restore. See section 13.5.4 in Intel^® 64 and IA-32 Architec-

tures Software Developer’s Manual, Volume 1.

- Intel processors have power optimizations when state components are in their initial configurations. Use of

lazy restore retains the non-initial configuration of the last thread and is not power efficient.

- Not all extended states support lazy restore mechanisms. As such, when one or more such states are

enabled it becomes very inefficient to use lazy restore as it results in two separate state restore, one in

context switch for the states that does not support lazy restore and one in the #NM handler for states that

support lazy restore.

14.4.1 Using the TS Flag to Control the Saving of the x87 FPU and SSE State

The TS flag in control register CR0 is provided to allow the operating system to delay saving/restoring the x87 FPU

and SSE state until an instruction that actually accesses this state is encountered in a new task. When the TS flag

is set, the processor monitors the instruction stream for x87 FPU, MMX, SSE instructions. When the processor

detects one of these instructions, it raises a device-not-available exception (#NM) prior to executing the instruc-

tion. The #NM exception handler can then be used to save the x87 FPU and SSE state for the previous task (using

an FXSAVE, XSAVE, or XSAVEOPT instruction) and load the x87 FPU and SSE state for the current task (using an

FXRSTOR or XRSOTR instruction). If the task never encounters an x87 FPU, MMX, or SSE instruction, the device-

not-available exception will not be raised and a task state will not be saved/restored unnecessarily.

NOTE

The CRC32 and POPCNT instructions do not operate on the x87 FPU or SSE state. They operate on

the general-purpose registers and are not involved with the techniques described above.

The TS flag can be set either explicitly (by executing a MOV instruction to control register CR0) or implicitly (using

the IA-32 architecture’s native task switching mechanism). When the native task switching mechanism is used, the

processor automatically sets the TS flag on a task switch. After the device-not-available handler has saved the x87

FPU and SSE state, it should execute the CLTS instruction to clear the TS flag.

14.5

THE XSAVE FEATURE SET AND PROCESSOR EXTENDED STATE

MANAGEMENT

The architecture of XSAVE feature set is described in Chapter 13 of Intel^® 64 and IA-32 Architectures Software

Developer’s Manual, Volume 1. The XSAVE feature set includes the following:

• An extensible data layout for existing and future processor state extensions. The layout of the XSAVE area

extends from the 512-byte FXSAVE/FXRSTOR layout to provide compatibility and migration path from

managing the legacy FXSAVE/FXRSTOR area. The XSAVE area is described in more detail in Section 13.4 of the

Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.

• CPUID enhancements for feature enumeration. See Section 13.2 of the Intel^® 64 and IA-32 Architectures

Software Developer’s Manual, Volume 1.

Vol. 3A

14-7

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES

• Control register enhancement and dedicated register for enabling each processor extended state. See Section

13.3 of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.

• Instructions to save state to and restore state from the XSAVE area. See Section 13.7 through Section 13.9 of

the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.

Operating systems can utilize XSAVE feature set to manage both FP/SSE state and processor extended states.

CPUID leaf 0DH enumerates XSAVE feature set related information. The following guidelines provide the steps an

operating system needs to take to support legacy FP/SSE states and processor extended states.

1. Check that the processor supports the XSAVE feature set

2. Determine the set of XSAVE managed features that the operating system intends to enable and calculate the

size of the buffer needed to save/restore the states during context switch and other flows

3. Enable use of XSAVE feature set and XSAVE managed features

4. Provide an initialization for the XSAVE managed feature state components

5. Provide (if necessary) required exception handlers for exceptions generated each of the XSAVE managed

features.

14.5.1 Checking the Support for XSAVE Feature Set

Support for XSAVE Feature set is enumerated in CPUID.1.ECX.XSAVE[bit 26]. Enumeration of this bit indicates that

the processor supports XSAVE/XRSTOR instructions to manage state and XSETBV/XGETBV on XCR0 to enable and

get enabled states. An operating system needs to enable XSAVE feature set as described later.

Additionally, CPUID.(EAX=0DH, ECX=1).EAX enumerates additional XSAVE sub features such as optimized save,

compaction, and supervisor state support. The following table summarizes XSAVE sub features. Once an operating

system enables XSAVE feature set, all the sub-features enumerated are also available. There is no need to enable

each additional sub feature.

Table 14-3. CPUID.(EAX=0DH, ECX=1) EAX Bit Assignment

EAX Bit Position

Meaning

If set, indicates availability of the XSAVEOPT instruction.

If set, indicates availability of the XSAVEC instruction and the corresponding compaction enhancements

to the legacy XRSTOR instruction.

If set, indicates support for execution of XGETBV with ECX=1. This execution returns the state-compo-

nent bitmap XINUSE. If XINUSE[i] = 0, state component i is in its initial configuration. Execution of

XSETBV with ECX=1 causes a #GP.

If set, indicates support for XSAVES/XRSTORS and IA32_XSS MSR

31:4

Reserved

14.5.2 Determining the XSAVE Managed Feature States And The Required Buffer Size

Each XSAVE managed feature has one or more state components associated with it. An operating system policy

needs to determine the XSAVE managed features to support and determine the corresponding state components to

enable. When determining the XSAVE managed features to support, operating system needs to take into account

the dependencies between them (e.g., AVX feature depends on SSE feature). Similarly, when a XSAVE managed

feature has more than one state component, all of them need to be enabled. Each logical processor enumerates

supported XSAVE state components in CPUID.(EAX=0DH, ECX=0).EDX:EAX. An operating system may enable all

or a subset of the state components enumerated by the processor based on the OS policy.

The size of the memory buffer needed to save enabled XSAVE state components depends on whether the OS opts-

in to use compacted format or not. Section 13.4.3 of the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1, describes the layout of the extended region of the XSAVE area.

14-8

Vol. 3A

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES

14.5.3 Enable the Use Of XSAVE Feature Set And XSAVE State Components

Operating systems need to enable the use of XSAVE feature set by writing to CR4.OSXSAVE[bit 18] to enable

XSETBV/XGETBV instructions to access XCR0 and to support processor extended state management using

XSAVE/XRSTOR. When the XSAVE feature set is enabled, all enumerated XSAVE sub features such as optimized

save, compaction, and supervisor state support are also enabled. Operating systems also need to enable the

XSAVE state components in XCR0 using the XSETBV instruction.

XSAVE state components can subsequently be disabled in XCR0. However, disabling state components of AVX or

AVX-512 that are not in initial configuration may incur power and performance penalty on SSE and AVX instructions

respectively. If AVX state is disabled when it is not in its initial configuration, subsequent SSE instructions may

incur a penalty. If AVX-512 state is disabled when it is not in its initial configuration, subsequent SSE and AVX

instructions may incur a penalty. It is recommended that the operating systems and VMM set AVX or AVX-512 state

components to their initial configuration before disabling them. This can be achieved by one of the two methods

below.

• Using XRSTOR: Operating system or VMM can set the state of AVX or AVX-512 state components using XRSTOR

instruction before disabling them in XCR0.

• Using VZEROUPPER: Operating system or VMM can set AVX and AVX-512 state components to their initial

configuration using VZEROUPPER instruction before disabling them in XCR0. Note that this will set both AVX

and AVX-512 state components to their initial configuration. If the intent is to only disable AVX-512 state,

Operating system or VMM will need to save AVX state before executing VZEROUPPER and restore it afterwards.

14.5.4 Provide an Initialization for the XSAVE State Components

The XSAVE header of a newly allocated XSAVE area should be initialized to all zeroes before saving context. An

operating system may choose to establish beginning state-component values for a task by executing XRSTOR from

an XSAVE area that the OS has configured. If it is desired to begin state component i in its initial configuration, the

OS should clear bit i in the XSTATE_BV field in the XSAVE header; otherwise, it should set that bit and place the

desired beginning value in the appropriate location in the XSAVE area.

When a buffer is allocated for compacted size, software must ensure that the XCOMP_BV field is setup correctly

before restoring from the buffer. Bit 63 of the XCOMP_BV field indicates that the save area is in the compacted

format and the remaining bits indicate the states that have space allocated in the save area. If the buffer is first

used to save the state in compacted format, then the save instructions will setup the XCOMP_BV field appropri-

ately. If the buffer is first used to restore the state, then software must set up the XCOMP_BV field.

14.5.5 Providing the Required Exception Handlers

Instructions part of each XSAVE managed features may generate exceptions and operating system may need to

enable such exceptions and provide handlers for them. Section 14.8 describes feature specific OS requirements for

each XSAVE managed features.

14.6

INTEROPERABILITY OF THE XSAVE FEATURE SET AND FXSAVE/FXRSTOR

The FXSAVE instruction writes x87 FPU and SSE state information to a 512-byte FXSAVE save area. FXRSTOR

restores the processor’s x87 FPU and SSE states from an FXSAVE area. The XSAVE features set supports x87 FPU

and SSE states using the same layout as the FXSAVE area to provide interoperability of FXSAVE versus XSAVE, and

FXRSTOR versus XRSTOR. The XSAVE feature set allows system software to manage SSE state independent of x87

FPU states. Thus system software that had been using FXSAVE and FXRSTOR to manage x87 FPU and SSE states

can transition to using the XSAVE feature set to manage x87 FPU, SSE, and other processor extended states in a

systematic and forward-looking manner. See Section 10.5 and Chapter 13 of the Intel^® 64 and IA-32 Architectures

Software Developer’s Manual, Volume 1, for more details.

System software can implement forward-looking processor extended state management using the XSAVE feature

set. In this case, system software must specify the bit vector mask in EDX:EAX appropriately when executing

XSAVE/XRSTOR instructions.

Vol. 3A

14-9

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES

For instance, the OS can supply instructions in the XSAVE feature set with a bit vector in EDX:EAX with the two

least significant bits (corresponding to x87 FPU and SSE state) equal to 0. Then, the XSAVE instruction will not

write the processor’s x87 FPU and SSE state into memory. Similarly, the XRSTOR instruction executed with a value

in EDX:EAX with the least two significant bit equal to 0 will not restore nor initialize the processor’s x87 FPU and

SSE state.

The processor’s action as a result of executing XRSTOR is given in Section 13.8 of the Intel^® 64 and IA-32 Archi-

tectures Software Developer’s Manual, Volume 1. The instruction may be used to initialize x87 FPU or XMM regis-

ters. When the MXCSR register is updated from memory, reserved bit checking is enforced. The saving/restoring of

MXCSR is bound to the SSE state, independent of the x87 FPU state. The action of XSAVE is given in Section 13.7

of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1.

14.7

THE XSAVE FEATURE SET AND PROCESSOR SUPERVISOR STATE

MANAGEMENT

Supervisor state is a processor state that is only accessible in ring 0. An extension to the XSAVE feature set,

enumerated by CPUID.(EAX=0DH, ECX=1).EAX[bit 3] allows the management of the supervisor states using the

XSAVE feature set. See Chapter 13 of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1,

for the details of the supervisor state XSAVE feature set extension. The supervisor state extension includes the

following:

• CPUID enhancements to enumerate the set of supervisor states and their sizes that can be managed by the

XSAVE feature set.

• The IA32_XSS MSR to enable the XSAVE feature set to manage one or more enumerated supervisor states.

• A pair of privileged save/restore instructions, XSAVES and XRSTORS, to save/restore supervisor states along

with other XSAVE managed feature states.

The guidelines to enable the XSAVE feature set to manage supervisor state are very similar to the steps outlined in

Section 13.6 with the differences noted below. The set of supervisor states that can be managed by the XSAVE

feature set is enumerated in (EAX=0DH, ECX=1).EDX:ECX. XSAVE managed supervisor states are enabled in the

IA32_XSS MSR instead of the XCR0 control register. There are semantic differences between user states enabled in

XCR0 and supervisor state enabled in the IA32_XSS MSR. A supervisor state enabled in the IA32_XSS MSR:

• May be accessed via other mechanisms such as RDMSR/WRMSR even when they are not enabled in the

IA32_XSS MSR. Enabling a supervisor state in the IA32_XSS MSR merely indicates that the state can be

saved/restored using XSAVES/XRSTORS instructions.

• May have side effects when saving/restoring the state such as disabling/enabling the feature associated with

the state. This behavior is feature specific and will be documented along with the feature description.

• May generate faults when saving/restoring the state. XSAVES/XRSTORS will follow the faulting behavior of

RDMSR/WRMSR respectively if the corresponding state is also accessible using RDMSR/WRMSR.

• XRSTORS may fault when restoring the state for supervisor features that are already enabled via feature

specific mechanisms. This behavior is feature specific and will be documented along with the feature

description.

When a supervisor state is disabled via a feature specific mechanism, the state does not automatically get marked

as INIT. Hence XSAVES/XRSTORS will continue to save/restore the state subject to available optimizations. If the

software does not intend to preserve the state when it disables the feature, it should initialize it to hardware INIT

value with the XRSTORS instruction so that XSAVES/XRSTORS perform optimally for that state.

14.8

SYSTEM PROGRAMMING FOR XSAVE MANAGED FEATURES

This section describes system programming requirement for each XSAVE managed features that are feature

specific, such as exception handling.

14-10

Vol. 3A

SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES

14.8.1 Intel® Advanced Vector Extensions (Intel® AVX)

Intel AVX instructions comprises of 256-bit and 128-bit instructions that operates on 256-bit YMM registers. The

XSAVE feature set allows software to save and restore the state of these registers. See Chapter 13 of the Intel^® 64

and IA-32 Architectures Software Developer’s Manual, Volume 1.

For processors that support YMM states, the YMM state exists in all operating modes. However, the available

instruction interfaces to access YMM states may vary in different modes.

Operating systems must use the XSAVE feature set for YMM state management. The XSAVE feature set also

provides flexible and efficient interface to manage XMM/MXCSR states and x87 FPU states in conjunction with

newer processor extended states like YMM states. Operating systems may need to be aware of the following when

supporting AVX.

• Saving/Restoring AVX state in non-compacted format without SSE state will also save/restore MXCSR even

though MXCSR is not part of AVX state. This does not happen when compacted format is used.

• Few AVX instructions such as VZEROUPPER/VZEROALL may operate on future expansion of YMM registers.

An operating system must enable its YMM state management to support AVX and any 256-bit extensions that

operate on YMM registers. Otherwise, an attempt to execute an instruction in AVX extensions (including an

enhanced 128-bit SIMD instructions using VEX encoding) will cause a #UD exception.

AVX instructions may generate SIMD floating-point exceptions. An OS must enable SIMD floating-point exception

support by setting CR4.OSXMMEXCPT[bit 10]=1.

14.8.2 Intel® Advanced Vector Extensions 512 (Intel® AVX-512)

Intel AVX-512 instructions are encoded using EVEX prefix. The EVEX encoding scheme can support 512-bit, 256-

bit and 128-bit instructions that operate on opmask, ZMM, YMM, and XMM registers.

For processors that support the Intel AVX-512 family of instructions, the extended processor states (ZMM and

opmask registers) exist in all operating modes. However, the access to these states may vary in different modes.

The processor's support for instruction extensions that employ EVEX prefix encoding is independent of the

processor's support for using XSAVE feature set on those states.

Instructions requiring EVEX prefix encoding are generally supported in 64-bit, 32-bit modes, and 16-bit protected

mode. They are not supported in Real mode, Virtual-8086 mode or entering into SMM mode. Note that bits MAXVL-

1:256 (511:256) of ZMM register state are maintained across transitions into and out of these modes. Because the

XSAVE feature set instruction can operate in all operating modes, it is possible that the processor's ZMM register

state can be modified by software in any operating mode by executing XRSTOR.

Operating systems must use the XSAVE/XRSTOR/XSAVEOPT instructions for ZMM and opmask state management.

An OS must enable its ZMM and opmask state management to support Intel AVX-512 Foundation instructions.

Otherwise, an attempt to execute an instruction in Intel AVX-512 Foundation instructions (including a scalar 128-

bit SIMD instructions using EVEX encoding) will cause a #UD exception. An operating system, which enables the

AVX-512 state to support Intel AVX-512 Foundation instructions, is also sufficient to support the rest of the Intel

AVX-512 family of instructions. Note that even though ZMM8-ZMM31 are not accessible in 32 bit mode, a 32 bit OS

is still required to allocate memory for the entire ZMM state.

Intel AVX-512 Foundation instructions may generate SIMD floating-point exceptions. An OS must enable SIMD

floating-point exception support by setting CR4.OSXMMEXCPT[bit 10]=1.

Vol. 3A

14-11

Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023) - page 53