FXSAVE

FXSAVE stores the x87, MMX and SSE state in 512 bytes of memory that must be aligned to 16 bytes; Zen 5 raised #GP for an address aligned only to 8. FXRSTOR loads it back. It came with the Pentium II, ready for the XMM registers that SSE then added, and it is still the first 512 bytes of every XSAVE area, whose page describes that layout as the legacy region; XSAVE added everything since, from the upper halves of the YMM registers on.

Not FNSAVE#

FXSAVE differs from the x87’s own FNSAVE in what it leaves behind and how it writes the x87 part:

• It changes no register: FNSAVE ends by initializing the FPU, FXSAVE leaves the stack, the control word and the status as they were.
• It does not check for a pending x87 exception: with one pending, Zen 5 wrote the area and the #MF came at the next waiting instruction.
• The tag word is abridged to one bit per register, set when the register is not empty, and each of ST(0) to ST(7) takes a 16-byte slot instead of 10 bytes.
• In 64-bit mode it saves XMM0 to XMM15 and MXCSR, together with MXCSR_MASK, the MXCSR bits the processor supports: Zen 5 reported 0002FFFFH, bit 6 (DAZ) and AMD’s bit 17 (MM, the misaligned exception mask) included. Zen 5 left bytes 416 to 511 alone, and Intel’s manual leaves bytes 464 to 511 to software.

The pointers, and the two manuals#

FXSAVE64 (REX.W) stores the last x87 instruction and data pointers as 64-bit offsets, FXSAVE as 32-bit offsets with their selectors. AMD’s manual saves the pointers and the opcode only while an unmasked exception is pending (ES set), and Zen 5 wrote zeros in their place otherwise. Intel’s manual stores them every time, with the selectors as 0 on processors that report FCS and FDS as deprecated. AMD also has a fast mode, EFER.FFXSR, in which FXSAVE at CPL 0 in 64-bit mode leaves out the XMM registers, to speed up a kernel’s own saves.

From C, _fxsave(p) and _fxsave64(p) need -mfxsr; GCC 14 and Clang 23 at -O2 emit one fxsave or fxsave64 with the pointer as its memory operand. AMD’s Zen 5 guide lists FXSAVE and FXRSTOR as microcoded.

Forms

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

a = mem.address
if a % 16:
    fault(GP, 0)
t = 0
for j in range(8):
    if ftw >> 2 * j & 3 != 3:        # Rj not empty
        t |= 1 << j
pend = fsw >> 7 & 1                  # ES: an exception pending
store(a, 16, fcw)
store(a + 2, 16, fsw)
store(a + 4, 16, t)                  # byte 5: 0
# the pointers, 32-bit offsets and the selectors, as zeros where
# no exception is pending (Zen 5; Intel's store them always)
store(a + 6, 16, fop if pend else 0)
store(a + 8, 32, fip if pend else 0)
store(a + 12, 32, fcs if pend else 0)
store(a + 16, 32, fdp if pend else 0)
store(a + 20, 32, fds if pend else 0)
store(a + 24, 32, mxcsr)
store(a + 28, 32, mxcsr_mask)
for i in range(8):                   # 80 bits, 48 of zeros
    store(a + 32 + 16 * i, 128, st[i])
for i in range(16):
    store(a + 160 + 16 * i, 128, xmm[i])

a = mem.address
if a % 16:
    fault(GP, 0)
t = 0
for j in range(8):
    if ftw >> 2 * j & 3 != 3:        # Rj not empty
        t |= 1 << j
pend = fsw >> 7 & 1                  # ES: an exception pending
store(a, 16, fcw)
store(a + 2, 16, fsw)
store(a + 4, 16, t)                  # byte 5: 0
# the pointers, 64-bit offsets, as zeros where no exception is
# pending (Zen 5; Intel's store them always)
store(a + 6, 16, fop if pend else 0)
store(a + 8, 64, fip if pend else 0)
store(a + 16, 64, fdp if pend else 0)
store(a + 24, 32, mxcsr)
store(a + 28, 32, mxcsr_mask)
for i in range(8):                   # 80 bits, 48 of zeros
    store(a + 32 + 16 * i, 128, st[i])
for i in range(16):
    store(a + 160 + 16 * i, 128, xmm[i])

Operands

Flags

None: XED records no flag that the forms test or change.

Attributes

What else XED records about the forms. How to read.

All forms

aligned memory operand; may abort a TSX transaction

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to FXSAVE, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More FXSR instructions

• FXRSTOR