Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023) - page 1
Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Documentation Changes
December 2023
Notice: The Intel® 64 and IA-32 architectures may contain design defects or errors known as errata
that may cause the product to deviate from published specifications. Current characterized errata are
documented in the specification updates.
Document Number: 252046-074
Contents
Revision History
4
Preface
7
Summary Tables of Changes
8
Documentation Changes
9
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
3
Revision History
Revision History
Revision
Description
Date
-001
•
Initial release
November 2002
•
Added 1-10 Documentation Changes.
-002
•
Removed old Documentation Changes items that already have been
December 2002
incorporated in the published Software Developer’s manual
•
Added 9 -17 Documentation Changes.
•
Removed Documentation Change #6 - References to bits Gen and Len
-003
Deleted.
February 2003
•
Removed Documentation Change #4 - VIF Information Added to CLI
Discussion
•
Removed Documentation changes 1-17.
-004
June 2003
•
Added Documentation changes 1-24.
•
Removed Documentation Changes 1-24.
-005
September 2003
•
Added Documentation Changes 1-15.
-006
•
Added Documentation Changes 16- 34.
November 2003
•
Updated Documentation changes 14, 16, 17, and 28.
-007
January 2004
•
Added Documentation Changes 35-45.
•
Removed Documentation Changes 1-45.
-008
March 2004
•
Added Documentation Changes 1-5.
-009
•
Added Documentation Changes 7-27.
May 2004
•
Removed Documentation Changes 1-27.
-010
August 2004
•
Added Documentation Changes 1.
-011
•
Added Documentation Changes 2-28.
November 2004
•
Removed Documentation Changes 1-28.
-012
March 2005
•
Added Documentation Changes 1-16.
•
Updated title.
-013
•
There are no Documentation Changes for this revision of the
July 2005
document.
-014
•
Added Documentation Changes 1-21.
September 2005
•
Removed Documentation Changes 1-21.
-015
March 9, 2006
•
Added Documentation Changes 1-20.
-016
•
Added Documentation changes 21-23.
March 27, 2006
•
Removed Documentation Changes 1-23.
-017
September 2006
•
Added Documentation Changes 1-36.
-018
•
Added Documentation Changes 37-42.
October 2006
•
Removed Documentation Changes 1-42.
-019
March 2007
•
Added Documentation Changes 1-19.
-020
•
Added Documentation Changes 20-27.
May 2007
•
Removed Documentation Changes 1-27.
-021
November 2007
•
Added Documentation Changes 1-6
•
Removed Documentation Changes 1-6
-022
August 2008
•
Added Documentation Changes 1-6
•
Removed Documentation Changes 1-6
-023
March 2009
•
Added Documentation Changes 1-21
4
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
Revision History
Revision
Description
Date
•
Removed Documentation Changes 1-21
-024
June 2009
•
Added Documentation Changes 1-16
•
Removed Documentation Changes 1-16
-025
September 2009
•
Added Documentation Changes 1-18
•
Removed Documentation Changes 1-18
-026
December 2009
•
Added Documentation Changes 1-15
•
Removed Documentation Changes 1-15
-027
March 2010
•
Added Documentation Changes 1-24
•
Removed Documentation Changes 1-24
-028
June 2010
•
Added Documentation Changes 1-29
•
Removed Documentation Changes 1-29
-029
September 2010
•
Added Documentation Changes 1-29
•
Removed Documentation Changes 1-29
-030
January 2011
•
Added Documentation Changes 1-29
•
Removed Documentation Changes 1-29
-031
April 2011
•
Added Documentation Changes 1-29
•
Removed Documentation Changes 1-29
-032
May 2011
•
Added Documentation Changes 1-14
•
Removed Documentation Changes 1-14
-033
October 2011
•
Added Documentation Changes 1-38
•
Removed Documentation Changes 1-38
-034
December 2011
•
Added Documentation Changes 1-16
•
Removed Documentation Changes 1-16
-035
March 2012
•
Added Documentation Changes 1-18
•
Removed Documentation Changes 1-18
-036
May 2012
•
Added Documentation Changes 1-17
•
Removed Documentation Changes 1-17
-037
August 2012
•
Added Documentation Changes 1-28
•
Removed Documentation Changes 1-28
-038
January 2013
•
Add Documentation Changes 1-22
•
Removed Documentation Changes 1-22
-039
June 2013
•
Add Documentation Changes 1-17
•
Removed Documentation Changes 1-17
-040
September 2013
•
Add Documentation Changes 1-24
•
Removed Documentation Changes 1-24
-041
February 2014
•
Add Documentation Changes 1-20
•
Removed Documentation Changes 1-20
-042
February 2014
•
Add Documentation Changes 1-8
•
Removed Documentation Changes 1-8
-043
June 2014
•
Add Documentation Changes 1-43
•
Removed Documentation Changes 1-43
-044
September 2014
•
Add Documentation Changes 1-12
•
Removed Documentation Changes 1-12
-045
January 2015
•
Add Documentation Changes 1-22
•
Removed Documentation Changes 1-22
-046
April 2015
•
Add Documentation Changes 1-25
•
Removed Documentation Changes 1-25
-047
June 2015
•
Add Documentation Changes 1-19
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
5
Revision History
Revision
Description
Date
•
Removed Documentation Changes 1-19
-048
September 2015
•
Add Documentation Changes 1-33
•
Removed Documentation Changes 1-33
-049
December 2015
•
Add Documentation Changes 1-33
•
Removed Documentation Changes 1-33
-050
April 2016
•
Add Documentation Changes 1-9
•
Removed Documentation Changes 1-9
-051
June 2016
•
Add Documentation Changes 1-20
•
Removed Documentation Changes 1-20
-052
September 2016
•
Add Documentation Changes 1-22
•
Removed Documentation Changes 1-22
-053
December 2016
•
Add Documentation Changes 1-26
•
Removed Documentation Changes 1-26
-054
March 2017
•
Add Documentation Changes 1-20
•
Removed Documentation Changes 1-20
-055
July 2017
•
Add Documentation Changes 1-28
•
Removed Documentation Changes 1-28
-056
October 2017
•
Add Documentation Changes 1-18
•
Removed Documentation Changes 1-18
-057
December 2017
•
Add Documentation Changes 1-29
•
Removed Documentation Changes 1-29
-058
March 2018
•
Add Documentation Changes 1-17
•
Removed Documentation Changes 1-17
-059
May 2018
•
Add Documentation Changes 1-24
•
Removed Documentation Changes 1-24
-060
November 2018
•
Add Documentation Changes 1-23
•
Removed Documentation Changes 1-23
-061
January 2019
•
Add Documentation Changes 1-21
•
Removed Documentation Changes 1-21
-062
May 2019
•
Add Documentation Changes 1-28
•
Removed Documentation Changes 1-28
-063
October 2019
•
Add Documentation Changes 1-34
•
Removed Documentation Changes 1-34
-064
May 2020
•
Add Documentation Changes 1-36
•
Removed Documentation Changes 1-36
-065
November 2020
•
Add Documentation Changes 1-31
•
Removed Documentation Changes 1-31
-066
April 2021
•
Add Documentation Changes 1-24
•
Removed Documentation Changes 1-24
-067
June 2021
•
Add Documentation Changes 1-30
•
Removed Documentation Changes 1-30
-068
December 2021
•
Add Documentation Changes 1-29
•
Removed Documentation Changes 1-29
-069
April 2022
•
Add Documentation Changes 1-18
•
Removed Documentation Changes 1-18
-070
December 2022
•
Add Documentation Changes 1-41
•
Removed Documentation Changes 1-41
-071
March 2023
•
Add Documentation Changes 1-23
6
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
Revision History
Revision
Description
Date
• Removed Documentation Changes 1-23
-072
June 2023
• Add Documentation Changes 1-19
• Removed Documentation Changes 1-19
-073
September 2023
• Add Documentation Changes 1-19
• Removed Documentation Changes 1-19
-074
December 2023
• Add Documentation Changes 1-20
§
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
7
Revision History
8
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
Preface
This document is an update to the specifications contained in the Affected Documents table below. This
document is a compilation of device and documentation errata, specification clarifications and changes. It is
intended for hardware system manufacturers and software developers of applications, operating systems, or
tools.
Affected Documents
Document Number/
Document Title
Location
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1: Basic Architecture
253665
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A: Instruction Set
253666
Reference, A-L
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2B: Instruction Set
253667
Reference, M-U
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2C: Instruction Set
326018
Reference, V
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2D: Instruction Set
334569
Reference, W-Z
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A: System
253668
Programming Guide, Part 1
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3B: System
253669
Programming Guide, Part 2
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3C: System
326019
Programming Guide, Part 3
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3D: System
332831
Programming Guide, Part 4
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4: Model Specific
335592
Registers
Nomenclature
Documentation Changes include typos, errors, or omissions from the current published specifications. These
will be incorporated in any new release of the specification.
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
7
Summary Tables of Changes
The following table indicates documentation changes which apply to the Intel® 64 and IA-32 architectures. This
table uses the following notations:
Codes Used in Summary Tables
A violet change bar to left of table row indicates this erratum is either new or modified from the previous version
of the document.
Documentation Changes
No.
DOCUMENTATION CHANGES
1
Updates to Chapter 1, Volume 1
2
Updates to Chapter 13, Volume 1
3
Updates to Chapter 1, Volume 2A
4
Updates to Chapter 2, Volume 2A
5
Updates to Chapter 3, Volume 2A
6
Updates to Chapter 4, Volume 2B
7
Updates to Chapter 5, Volume 2C
8
Updates to Chapter 1, Volume 3A
9
Updates to Chapter 2, Volume 3A
10
Updates to Chapter 9, Volume 3A
11
Updates to Chapter 12, Volume 3A
12
Updates to Chapter 16, Volume 3B
13
Updates to Chapter 19, Volume 3B
14
Updates to Chapter 23, Volume 3B
15
Updates to Chapter 25, Volume 3C
16
Updates to Chapter 27, Volume 3C
17
Updates to Chapter 28, Volume 3C
18
Updates to Chapter 32, Volume 3C
19
Updates to Chapter 1, Volume 4
20
Updates to Chapter 2, Volume 4
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
8
Documentation Changes
Changes to the Intel® 64 and IA-32 Architectures Software Developer’s Manual volumes follow, and are listed
by chapter. Only chapters with changes are included in this document.
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
9
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
10
1. Updates to Chapter 1, Volume 1
Change bars and violet text show changes to Chapter 1 of the Intel® 64 and IA-32 Architectures Software
Developer’s Manual, Volume 1: Basic Architecture.
------------------------------------------------------------------------------------------
Changes to this chapter:
• Added the 5th generation Intel® Xeon® Scalable Processor Family and the Intel® Core™ Ultra 7 processors to
the list of supported processors in Section 1.1, “Intel® 64 and IA-32 Processors Covered in this Manual.”
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
11
CHAPTER 1
ABOUT THIS MANUAL
The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1: Basic Architecture (order number
253665) is part of a set that describes the architecture and programming environment of Intel® 64 and IA-32
architecture processors. Other volumes in this set are:
• The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B, 2C & 2D: Instruction Set
Reference (order numbers 253666, 253667, 326018, and 334569).
• The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A, 3B, 3C & 3D: System
Programming Guide (order numbers 253668, 253669, 326019, and 332831).
• The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4: Model-Specific Registers (order
number 335592).
The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, describes the basic architecture
and programming environment of Intel 64 and IA-32 processors. The Intel® 64 and IA-32 Architectures Software
Developer’s Manual, Volumes 2A, 2B, 2C, & 2D, describe the instruction set of the processor and the opcode struc-
ture. These volumes apply to application programmers and to programmers who write operating systems or exec-
utives. The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A, 3B, 3C, & 3D, describe
the operating-system support environment of Intel 64 and IA-32 processors. These volumes target operating-
system and BIOS designers. In addition, the Intel® 64 and IA-32 Architectures Software Developer’s Manual,
Volume 3B, addresses the programming environment for classes of software that host operating systems. The
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4, describes the model-specific registers
of Intel 64 and IA-32 processors.
1.1
INTEL® 64 AND IA-32 PROCESSORS COVERED IN THIS MANUAL
This manual set includes information pertaining primarily to the most recent Intel 64 and IA-32 processors, which
include:
• Pentium® processors
• P6 family processors
• Pentium® 4 processors
• Pentium® M processors
• Intel® Xeon® processors
• Pentium® D processors
• Pentium® processor Extreme Editions
•
64-bit Intel® Xeon® processors
• Intel® Core™ Duo processor
• Intel® Core™ Solo processor
• Dual-Core Intel® Xeon® processor LV
• Intel® Core™ 2 Duo processor
• Intel® Core™ 2 Quad processor Q6000 series
• Intel® Xeon® processor 3000, 3200 series
• Intel® Xeon® processor 5000 series
• Intel® Xeon® processor 5100, 5300 series
• Intel® Core™ 2 Extreme processor X7000 and X6800 series
• Intel® Core™ 2 Extreme processor QX6000 series
• Intel® Xeon® processor 7100 series
Vol. 1
1-1
ABOUT THIS MANUAL
•
Intel® Pentium® Dual-Core processor
•
Intel® Xeon® processor 7200, 7300 series
•
Intel® Xeon® processor 5200, 5400, 7400 series
•
Intel® Core™ 2 Extreme processor QX9000 and X9000 series
•
Intel® Core™ 2 Quad processor Q9000 series
•
Intel® Core™ 2 Duo processor E8000, T9000 series
•
Intel Atom® processor family
•
Intel Atom® processors 200, 300, D400, D500, D2000, N200, N400, N2000, E2000, Z500, Z600, Z2000,
C1000 series are built from 45 nm and 32 nm processes
•
Intel® Core™ i7 processor
•
Intel® Core™ i5 processor
•
Intel® Xeon® processor E7-8800/4800/2800 product families
•
Intel® Core™ i7-3930K processor
•
2nd generation Intel® Core™ i7-2xxx, Intel® Core™ i5-2xxx, Intel® Core™ i3-2xxx processor series
•
Intel® Xeon® processor E3-1200 product family
•
Intel® Xeon® processor E5-2400/1400 product family
•
Intel® Xeon® processor E5-4600/2600/1600 product family
•
3rd generation Intel® Core™ processors
•
Intel® Xeon® processor E3-1200 v2 product family
•
Intel® Xeon® processor E5-2400/1400 v2 product families
•
Intel® Xeon® processor E5-4600/2600/1600 v2 product families
•
Intel® Xeon® processor E7-8800/4800/2800 v2 product families
•
4th generation Intel® Core™ processors
•
The Intel® Core™ M processor family
•
Intel® Core™ i7-59xx Processor Extreme Edition
•
Intel® Core™ i7-49xx Processor Extreme Edition
•
Intel® Xeon® processor E3-1200 v3 product family
•
Intel® Xeon® processor E5-2600/1600 v3 product families
•
5th generation Intel® Core™ processors
•
Intel® Xeon® processor D-1500 product family
•
Intel® Xeon® processor E5 v4 family
•
Intel Atom® processor X7-Z8000 and X5-Z8000 series
•
Intel Atom® processor Z3400 series
•
Intel Atom® processor Z3500 series
•
6th generation Intel® Core™ processors
•
Intel® Xeon® processor E3-1500m v5 product family
•
7th generation Intel® Core™ processors
•
Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
•
Intel® Xeon® Scalable Processor Family
•
8th generation Intel® Core™ processors
•
Intel® Xeon Phi™ Processor 7215, 7285, 7295 Series
•
Intel® Xeon® E processors
•
9th generation Intel® Core™ processors
•
2nd generation Intel® Xeon® Scalable Processor Family
1-2
Vol. 1
ABOUT THIS MANUAL
•
10th generation Intel® Core™ processors
•
11th generation Intel® Core™ processors
• 3rd generation Intel® Xeon® Scalable Processor Family
•
12th generation Intel® Core™ processors
•
13th generation Intel® Core™ processors
• 4th generation Intel® Xeon® Scalable Processor Family
• 5th generation Intel® Xeon® Scalable Processor Family
• Intel® Core™ Ultra 7 processors
P6 family processors are IA-32 processors based on the P6 family microarchitecture. This includes the Pentium®
Pro, Pentium® II, Pentium® III, and Pentium® III Xeon® processors.
The Pentium® 4, Pentium® D, and Pentium® processor Extreme Editions are based on the Intel NetBurst® microar-
chitecture. Most early Intel® Xeon® processors are based on the Intel NetBurst® microarchitecture. Intel Xeon
processor 5000, 7100 series are based on the Intel NetBurst® microarchitecture.
The Intel® Core™ Duo, Intel® Core™ Solo and dual-core Intel® Xeon® processor LV are based on an improved
Pentium® M processor microarchitecture.
The Intel® Xeon® processor 3000, 3200, 5100, 5300, 7200, and 7300 series, Intel® Pentium® dual-core, Intel®
Core™ 2 Duo, Intel® Core™ 2 Quad, and Intel® Core™ 2 Extreme processors are based on Intel® Core™ microar-
chitecture.
The Intel® Xeon® processor 5200, 5400, 7400 series, Intel® Core™ 2 Quad processor Q9000 series, and Intel®
Core™ 2 Extreme processors QX9000, X9000 series, Intel® Core™ 2 processor E8000 series are based on
Enhanced Intel® Core™ microarchitecture.
The Intel Atom® processors 200, 300, D400, D500, D2000, N200, N400, N2000, E2000, Z500, Z600, Z2000,
C1000 series are based on the Intel Atom® microarchitecture and supports Intel 64 architecture.
P6 family, Pentium® M, Intel® Core™ Solo, Intel® Core™ Duo processors, dual-core Intel® Xeon® processor LV,
and early generations of Pentium 4 and Intel Xeon processors support IA-32 architecture. The Intel® AtomTM
processor Z5xx series support IA-32 architecture.
The Intel® Xeon® processor 3000, 3200, 5000, 5100, 5200, 5300, 5400, 7100, 7200, 7300, 7400 series, Intel®
Core™ 2 Duo, Intel® Core™ 2 Extreme, Intel® Core™ 2 Quad processors, Pentium® D processors, Pentium® Dual-
Core processor, newer generations of Pentium 4 and Intel Xeon processor family support Intel® 64 architecture.
The Intel® Core™ i7 processor and Intel® Xeon® processor 3400, 5500, 7500 series are based on 45 nm Nehalem
microarchitecture. Westmere microarchitecture is a 32 nm version of the Nehalem microarchitecture. Intel®
Xeon® processor 5600 series, Intel Xeon processor E7 and various Intel Core i7, i5, i3 processors are based on the
Westmere microarchitecture. These processors support Intel 64 architecture.
The Intel® Xeon® processor E5 family, Intel® Xeon® processor E3-1200 family, Intel® Xeon® processor E7-
8800/4800/2800 product families, Intel® Core™ i7-3930K processor, and 2nd generation Intel® Core™ i7-2xxx,
Intel® CoreTM i5-2xxx, Intel® Core™ i3-2xxx processor series are based on the Sandy Bridge microarchitecture and
support Intel 64 architecture.
The Intel® Xeon® processor E7-8800/4800/2800 v2 product families, Intel® Xeon® processor E3-1200 v2 product
family and 3rd generation Intel® Core™ processors are based on the Ivy Bridge microarchitecture and support
Intel 64 architecture.
The Intel® Xeon® processor E5-4600/2600/1600 v2 product families, Intel® Xeon® processor E5-2400/1400 v2
product families and Intel® Core™ i7-49xx Processor Extreme Edition are based on the Ivy Bridge-E microarchitec-
ture and support Intel 64 architecture.
The Intel® Xeon® processor E3-1200 v3 product family and 4th Generation Intel® Core™ processors are based on
the Haswell microarchitecture and support Intel 64 architecture.
The Intel® Xeon® processor E5-2600/1600 v3 product families and the Intel® Core™ i7-59xx Processor Extreme
Edition are based on the Haswell-E microarchitecture and support Intel 64 architecture.
The Intel Atom® processor Z8000 series is based on the Airmont microarchitecture.
Vol. 1
1-3
ABOUT THIS MANUAL
The Intel Atom® processor Z3400 series and the Intel Atom® processor Z3500 series are based on the Silvermont
microarchitecture.
The Intel® Core™ M processor family, 5th generation Intel® Core™ processors, Intel® Xeon® processor D-1500
product family and the Intel® Xeon® processor E5 v4 family are based on the Broadwell microarchitecture and
support Intel 64 architecture.
The Intel® Xeon® Scalable Processor Family, Intel® Xeon® processor E3-1500m v5 product family and 6th gener-
ation Intel® Core™ processors are based on the Skylake microarchitecture and support Intel 64 architecture.
The 7th generation Intel® Core™ processors are based on the Kaby Lake microarchitecture and support Intel 64
architecture.
The Intel Atom® processor C series, the Intel Atom® processor X series, the Intel® Pentium® processor J series,
the Intel® Celeron® processor J series, and the Intel® Celeron® processor N series are based on the Goldmont
microarchitecture.
The Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series is based on the Knights Landing microarchitecture and
supports Intel 64 architecture.
The Intel® Pentium® Silver processor series, the Intel® Celeron® processor J series, and the Intel® Celeron®
processor N series are based on the Goldmont Plus microarchitecture.
The 8th generation Intel® Core™ processors, 9th generation Intel® Core™ processors, and Intel® Xeon® E proces-
sors are based on the Coffee Lake microarchitecture and support Intel 64 architecture.
The Intel® Xeon Phi™ Processor 7215, 7285, 7295 Series is based on the Knights Mill microarchitecture and
supports Intel 64 architecture.
The 2nd generation Intel® Xeon® Scalable Processor Family is based on the Cascade Lake product and supports
Intel 64 architecture.
Some 10th generation Intel® Core™ processors are based on the Ice Lake microarchitecture, and some are based
on the Comet Lake microarchitecture; both support Intel 64 architecture.
Some 11th generation Intel® Core™ processors are based on the Tiger Lake microarchitecture, and some are
based on the Rocket Lake microarchitecture; both support Intel 64 architecture.
Some 3rd generation Intel® Xeon® Scalable Processor Family processors are based on the Cooper Lake product,
and some are based on the Ice Lake microarchitecture; both support Intel 64 architecture.
The 12th generation Intel® Core™ processors are based on the Alder Lake performance hybrid architecture and
support Intel 64 architecture.
The 13th generation Intel® Core™ processors are based on the Raptor Lake performance hybrid architecture and
support Intel 64 architecture.
The 4th generation Intel® Xeon® Scalable Processor Family is based on Sapphire Rapids microarchitecture and
supports Intel 64 architecture.
The 5th generation Intel® Xeon® Scalable Processor Family is based on Emerald Rapids microarchitecture and
supports Intel 64 architecture.
The Intel® Core™ Ultra 7 processor is based on Meteor Lake hybrid architecture and supports Intel 64 architecture.
IA-32 architecture is the instruction set architecture and programming environment for Intel's 32-bit microproces-
sors. Intel® 64 architecture is the instruction set architecture and programming environment which is the superset
of Intel’s 32-bit and 64-bit architectures. It is compatible with the IA-32 architecture.
1.2
OVERVIEW OF VOLUME 1: BASIC ARCHITECTURE
A description of this manual’s content follows:
Chapter 1 - About This Manual. Gives an overview of all volumes of the Intel® 64 and IA-32 Architectures Soft-
ware Developer’s Manual. It also describes the notational conventions in these manuals and lists related Intel
manuals and documentation of interest to programmers and hardware designers.
1-4
Vol. 1
ABOUT THIS MANUAL
Chapter 2 - Intel® 64 and IA-32 Architectures. Introduces the Intel 64 and IA-32 architectures along with
the families of Intel processors that are based on these architectures. It also gives an overview of the common
features found in these processors and brief history of the Intel 64 and IA-32 architectures.
Chapter 3 - Basic Execution Environment. Introduces the models of memory organization and describes the
register set used by applications.
Chapter 4 - Data Types. Describes the data types and addressing modes recognized by the processor; provides
an overview of real numbers and floating-point formats and of floating-point exceptions.
Chapter 5 - Instruction Set Summary. Lists all Intel 64 and IA-32 instructions, divided into technology groups.
Chapter 6 - Procedure Calls, Interrupts, and Exceptions. Describes the procedure stack and mechanisms
provided for making procedure calls and for servicing interrupts and exceptions.
Chapter 7 - Programming with General-Purpose Instructions. Describes basic load and store, program
control, arithmetic, and string instructions that operate on basic data types, general-purpose and segment regis-
ters; also describes system instructions that are executed in protected mode.
Chapter 8 - Programming with the x87 FPU. Describes the x87 floating-point unit (FPU), including floating-
point registers and data types; gives an overview of the floating-point instruction set and describes the processor's
floating-point exception conditions.
Chapter 9 - Programming with Intel® MMX™ Technology. Describes Intel MMX technology, including MMX
registers and data types; also provides an overview of the MMX instruction set.
Chapter 10 - Programming with Intel® Streaming SIMD Extensions (Intel® SSE). Describes SSE exten-
sions, including XMM registers, the MXCSR register, and packed single precision floating-point data types; provides
an overview of the SSE instruction set and gives guidelines for writing code that accesses the SSE extensions.
Chapter 11 - Programming with Intel® Streaming SIMD Extensions 2 (Intel® SSE2). Describes SSE2
extensions, including XMM registers and packed double precision floating-point data types; provides an overview
of the SSE2 instruction set and gives guidelines for writing code that accesses SSE2 extensions. This chapter also
describes SIMD floating-point exceptions that can be generated with SSE and SSE2 instructions. It also provides
general guidelines for incorporating support for SSE and SSE2 extensions into operating system and applications
code.
Chapter 12 - Programming with Intel® Streaming SIMD Extensions 3 (Intel® SSE3), Supplemental
Streaming SIMD Extensions 3 (SSSE3), Intel® Streaming SIMD Extensions 4 (Intel® SSE4) and Intel®
AES New Instructions (Intel® AES-NI). Provides an overview of the SSE3 instruction set, Supplemental SSE3,
SSE4, AESNI instructions, and guidelines for writing code that access these extensions.
Chapter 13 - Managing State Using the XSAVE Feature Set. Describes the XSAVE feature set instructions
and explains how software can enable the XSAVE feature set and XSAVE-enabled features.
Chapter 14 - Programming with Intel® AVX, FMA, and Intel® AVX2. Provides an overview of the Intel® AVX
instruction set, FMA, and Intel® AVX2 extensions and gives guidelines for writing code that access these exten-
sions.
Chapter 15 - Programming with Intel® AVX-512. Provides an overview of the Intel® AVX-512 instruction set
extensions and gives guidelines for writing code that access these extensions.
Chapter 16 - Programming with Intel® Transactional Synchronization Extensions. Describes the instruc-
tion extensions that support lock elision techniques to improve the performance of multi-threaded software with
contended locks.
Chapter 17 - Control-flow Enforcement Technology. Provides an overview of the Control-flow Enforcement
Technology (CET) and gives guidelines for writing code that access these extensions.
Chapter 18 - Programming with Intel® Advanced Matrix Extensions. Provides an overview of the Intel®
Advanced Matrix Extensions and gives guidelines for writing code that access these extensions.
Chapter 19 - Input/Output. Describes the processor’s I/O mechanism, including I/O port addressing, I/O
instructions, and I/O protection mechanisms.
Chapter 20 - Processor Identification and Feature Determination. Describes how to determine the CPU
type and features available in the processor.
Vol. 1
1-5
ABOUT THIS MANUAL
Appendix A - EFLAGS Cross-Reference. Summarizes how the IA-32 instructions affect the flags in the EFLAGS
register.
Appendix B - EFLAGS Condition Codes. Summarizes how conditional jump, move, and ‘byte set on condition
code’ instructions use condition code flags (OF, CF, ZF, SF, and PF) in the EFLAGS register.
Appendix C - Floating-Point Exceptions Summary. Summarizes exceptions raised by the x87 FPU floating-
point and SSE/SSE2/SSE3 floating-point instructions.
Appendix D - Guidelines for Writing SIMD Floating-Point Exception Handlers. Gives guidelines for writing
exception handlers for exceptions generated by SSE/SSE2/SSE3 floating-point instructions.
Appendix E - Intel® Memory Protection Extensions. Provides an overview of the Intel® Memory Protection
Extensions, a feature that has been deprecated and will not be available on future processors.
1.3
NOTATIONAL CONVENTIONS
This manual uses specific notation for data-structure formats, for symbolic representation of instructions, and for
hexadecimal and binary numbers. This notation is described below.
1.3.1
Bit and Byte Order
In illustrations of data structures in memory, smaller addresses appear toward the bottom of the figure; addresses
increase toward the top. Bit positions are numbered from right to left. The numerical value of a set bit is equal to
two raised to the power of the bit position. Intel 64 and IA-32 processors are “little endian” machines; this means
the bytes of a word are numbered starting from the least significant byte. See Figure 1-1.
Highest
Data Structure
Address
31
24 23
16 15
8 7
0
Bit offset
28
24
20
16
12
8
4
Lowest
Byte 3
Byte 2
Byte 1
Byte 0
0
Address
Byte Offset
Figure 1-1. Bit and Byte Order
1.3.2
Reserved Bits and Software Compatibility
In many register and memory layout descriptions, certain bits are marked as reserved. When bits are marked as
reserved, it is essential for compatibility with future processors that software treat these bits as having a future,
though unknown, effect. The behavior of reserved bits should be regarded as not only undefined, but unpredict-
able.
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 that contain such bits.
Mask out the reserved bits before testing.
• Do not depend on the states of any reserved bits when storing to memory or to a register.
• Do not depend on the ability to retain information written into any reserved bits.
1-6
Vol. 1
ABOUT THIS MANUAL
• 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.
NOTE
Avoid any software dependence upon the state of reserved bits in Intel 64 and IA-32 registers.
Depending upon the values of reserved register bits will make software dependent upon the
unspecified manner in which the processor handles these bits. Programs that depend upon
reserved values risk incompatibility with future processors.
1.3.2.1
Instruction Operands
When instructions are represented symbolically, a subset of the IA-32 assembly language is used. In this subset,
an instruction has the following format:
label: mnemonic argument1, argument2, argument3
where:
• A label is an identifier which is followed by a colon.
• A mnemonic is a reserved name for a class of instruction opcodes which have the same function.
• The operands argument1, argument2, and argument3 are optional. There may be from zero to three
operands, depending on the opcode. When present, they take the form of either literals or identifiers for data
items. Operand identifiers are either reserved names of registers or are assumed to be assigned to data items
declared in another part of the program (which may not be shown in the example).
When two operands are present in an arithmetic or logical instruction, the right operand is the source and the left
operand is the destination.
For example:
LOADREG: MOV EAX, SUBTOTAL
In this example, LOADREG is a label, MOV is the mnemonic identifier of an opcode, EAX is the destination operand,
and SUBTOTAL is the source operand. Some assembly languages put the source and destination in reverse order.
1.3.3
Hexadecimal and Binary Numbers
Base 16 (hexadecimal) numbers are represented by a string of hexadecimal digits followed by the character H (for
example, 0F82EH). A hexadecimal digit is a character from the following set: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D,
E, and F.
Base 2 (binary) numbers are represented by a string of 1s and 0s, sometimes followed by the character B (for
example, 1010B). The “B” designation is only used in situations where confusion as to the type of number might
arise.
1.3.4
Segmented Addressing
The processor uses byte addressing. This means memory is organized and accessed as a sequence of bytes.
Whether one or more bytes are being accessed, a byte address is used to locate the byte or bytes memory. The
range of memory that can be addressed is called an address space.
The processor also supports segmented addressing. This is a form of addressing where a program may have many
independent address spaces, called segments. For example, a program can keep its code (instructions) and stack
in separate segments. Code addresses would always refer to the code space, and stack addresses would always
refer to the stack space. The following notation is used to specify a byte address within a segment:
Segment-register:Byte-address
For example, the following segment address identifies the byte at address FF79H in the segment pointed by the DS
register:
Vol. 1
1-7
ABOUT THIS MANUAL
DS:FF79H
The following segment address identifies an instruction address in the code segment. The CS register points to the
code segment and the EIP register contains the address of the instruction.
CS:EIP
1.3.5
A New Syntax for CPUID, CR, and MSR Values
Obtain feature flags, status, and system information by using the CPUID instruction, by checking control register
bits, and by reading model-specific registers. We are moving toward a new syntax to represent this information.
See Figure 1-2.
CPUID Input and Output
CPUID.01H:EDX.SSE[bit 25] = 1
Input value for EAX register
Output register and feature flag or field
name with bit position(s)
Value (or range) of output
Control Register Values
CR4.OSFXSR[bit 9] = 1
Example CR name
Feature flag or field name
with bit position(s)
Value (or range) of output
Model-Specific Register Values
IA32_MISC_ENABLE.ENABLEFOPCODE[bit 2] = 1
Example MSR name
Feature flag or field name with bit position(s)
Value (or range) of output
SDM29002
Figure 1-2. Syntax for CPUID, CR, and MSR Data Presentation
1.3.6
Exceptions
An exception is an event that typically occurs when an instruction causes an error. For example, an attempt to
divide by zero generates an exception. However, some exceptions, such as breakpoints, occur under other condi-
1-8
Vol. 1
ABOUT THIS MANUAL
tions. Some types of exceptions may provide error codes. An error code reports additional information about the
error. An example of the notation used to show an exception and error code is shown below:
#PF(fault code)
This example refers to a page-fault exception under conditions where an error code naming a type of fault is
reported. Under some conditions, exceptions that produce error codes may not be able to report an accurate code.
In this case, the error code is zero, as shown below for a general-protection exception:
#GP(0)
1.4
RELATED LITERATURE
Literature related to Intel 64 and IA-32 processors is listed and viewable on-line at:
See also:
• The latest security information on Intel® products:
• Software developer resources, guidance, and insights for security advisories:
• The data sheet for a particular Intel 64 or IA-32 processor
• The specification update for a particular Intel 64 or IA-32 processor
• Intel® C++ Compiler documentation and online help:
• Intel® Fortran Compiler documentation and online help:
• Intel® Software Development Tools:
• Intel® 64 and IA-32 Architectures Software Developer’s Manual (in one, four or ten volumes):
• Intel® 64 and IA-32 Architectures Optimization Reference Manual:
• Intel® Trusted Execution Technology Measured Launched Environment Programming Guide:
http://www.intel.com/content/www/us/en/software-developers/intel-txt-software-development-guide.html
• Intel® Software Guard Extensions (Intel® SGX) Information:
• Developing Multi-threaded Applications: A Platform Consistent Approach:
tions.pdf
• Using Spin-Loops on Intel® Pentium® 4 Processor and Intel® Xeon® Processor:
• Performance Monitoring Unit Sharing Guide:
Literature related to select features in future Intel processors are available at:
• Intel® Architecture Instruction Set Extensions Programming Reference:
More relevant links are:
• Intel® Developer Zone:
Vol. 1
1-9
ABOUT THIS MANUAL
• Developer centers:
• Processor support general link:
• Intel® Hyper-Threading Technology (Intel® HT Technology):
1-10
Vol. 1
2. Updates to Chapter 13, Volume 1
Change bars and violet text show changes to Chapter 13 of the Intel® 64 and IA-32 Architectures Software
Developer’s Manual, Volume 1: Basic Architecture.
------------------------------------------------------------------------------------------
Changes to this chapter:
• XFD updates made to Section 13.13, “Memory Accesses by the XSAVE Feature Set,” and Section 13.14,
“Extended Feature Disable (XFD).”
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
13
CHAPTER 13
MANAGING STATE USING THE XSAVE FEATURE SET
The XSAVE feature set extends the functionality of the FXSAVE and FXRSTOR instructions (see Section 10.5,
“FXSAVE and FXRSTOR Instructions”) by supporting the saving and restoring of processor state in addition to the
x87 execution environment (x87 state) and the registers used by the streaming SIMD extensions (SSE state).
The XSAVE feature set comprises eight instructions. XGETBV and XSETBV allow software to read and write the
extended control register XCR0, which controls the operation of the XSAVE feature set. XSAVE, XSAVEOPT,
XSAVEC, and XSAVES are four instructions that save processor state to memory; XRSTOR and XRSTORS are corre-
sponding instructions that load processor state from memory. XGETBV, XSAVE, XSAVEOPT, XSAVEC, and XRSTOR
can be executed at any privilege level; XSETBV, XSAVES, and XRSTORS can be executed only if CPL = 0. In addition
to XCR0, the XSAVES and XRSTORS instructions are controlled also by the IA32_XSS MSR (index DA0H).
The XSAVE feature set organizes the state that manages into state components. Operation of the instructions is
based on state-component bitmaps that have the same format as XCR0 and as the IA32_XSS MSR: each bit
corresponds to a state component. Section 13.1 discusses these state components and bitmaps in more detail.
Section 13.2 describes how the processor enumerates support for the XSAVE feature set and for XSAVE-enabled
features (those features that require the use of the XSAVE feature set for their enabling). Section 13.3 explains
how software can enable the XSAVE feature set and XSAVE-enabled features.
The XSAVE feature set allows saving and loading processor state from a region of memory called an XSAVE area.
Section 13.4 presents details of the XSAVE area and its organization. Each XSAVE-managed state component is
associated with a section of the XSAVE area. Section 13.5 describes in detail each of the XSAVE-managed state
components.
Section 13.7 through Section 13.12 describe the operation of XSAVE, XRSTOR, XSAVEOPT, XSAVEC, XSAVES, and
XRSTORS, respectively.
Section 13.13 provides some details about memory accesses performed by instructions in the XSAVE feature set,
and Section 13.14 describes a facility called extended feature disable (XFD).
13.1
XSAVE-SUPPORTED FEATURES AND STATE-COMPONENT BITMAPS
The XSAVE feature set supports the saving and restoring of state components, each of which is a discrete set of
processor registers (or parts of registers). In general, each such state component corresponds to a particular CPU
feature. Such a feature is XSAVE-supported. Some XSAVE-supported features use registers in multiple XSAVE-
managed state components.
The XSAVE feature set organizes the state components of the XSAVE-supported features using state-component
bitmaps. A state-component bitmap comprises 64 bits; each bit in such a bitmap corresponds to a single state
component. The following bits are defined in state-component bitmaps (details on individual state components are
provided in subsections of Section 13.5):
• Bit 0 corresponds to the state component used for the x87 FPU execution environment (x87 state).
• Bit 1 corresponds to the state component used for registers used by the streaming SIMD extensions (SSE
state).
• Bit 2 corresponds to the state component used for the additional register state used by the Intel® Advanced
Vector Extensions (AVX state).
• Bits 4:3 correspond to the two state components used for the additional register state used by Intel® Memory
Protection Extensions (MPX state):
- State component 3 is used for the 4 128-bit bounds registers BND0-BND3 (BNDREGS state).
- State component 4 is used for the 64-bit user-mode MPX configuration register BNDCFGU and the 64-bit
MPX status register BNDSTATUS (BNDCSR state).
• Bits 7:5 correspond to the three state components used for the additional register state used by Intel®
Advanced Vector Extensions 512 (AVX-512 state):
Vol. 1
13-1
MANAGING STATE USING THE XSAVE FEATURE SET
- State component 5 is used for the 8 64-bit opmask registers k0-k7 (opmask state).
- State component 6 is used for the upper 256 bits of the registers ZMM0-ZMM15. These 16 256-bit values
are denoted ZMM0_H-ZMM15_H (ZMM_Hi256 state).
- State component 7 is used for the 16 512-bit registers ZMM16-ZMM31 (Hi16_ZMM state).
• Bit 8 corresponds to the state component used for the Intel Processor Trace MSRs (PT state).
• Bit 9 corresponds to the state component used for the protection-key feature’s register PKRU (PKRU state).
• Bit 10 corresponds to the state component used for the IA32_PASID MSR used by the ENQCMD instruction for
a process address space identifiers (PASID state).
• Bits 12:11 correspond to the two state components used for the additional register state used by Control-Flow
Enforcement Technology (CET state):
- State component 11 is used for the 2 MSRs controlling user-mode functionality for CET (CET_U state).
- State component 12 is used for the 3 MSRs containing shadow-stack pointers for privilege levels 0-2
(CET_S state).
• Bit 13 corresponds to the state component used for an MSR used to control hardware duty cycling (HDC
state).
• Bit 14 corresponds to the state component used for user interrupts (UINTR state).
• Bit 15 corresponds to the state component used for last-branch record configuration (LBR state).
• Bit 16 corresponds to the state component used for an MSR used to control hardware P-states (HWP state).
• Bits 18:17 correspond to the two state components used for the additional register state used by Intel®
Advanced Matrix Extensions (AMX state):
- State component 17 is used for the 64-byte TILECFG register (TILECFG state).
- State component 18 is used for the 8192 bytes of tile data (TILEDATA state).
Bits in the range 62:19 are not currently defined in state-component bitmaps and are reserved for future expan-
sion. As individual state components are defined using those bits, additional sub-sections will be updated within
Section 13.5 over time. Bit 63 is used for special functionality in some bitmaps and does not correspond to any
state component.
The state component corresponding to bit i of state-component bitmaps is called state component i. Thus, x87
state is state component 0; SSE state is state component 1; AVX state is state component 2; MPX state comprises
state components 3-4; AVX-512 state comprises state components 5-7; PT state is state component 8; PKRU state
is state component 9; PASID state is state component 10; CET state comprises state components 11-12; HDC
state is state component 13; UINTR state is state component 14; LBR state is state component 15; HWP state is
state component 16; AMX state comprises state components 17-18.
The XSAVE feature set uses state-component bitmaps in multiple ways. Most of the instructions use an implicit
operand (in EDX:EAX), called the instruction mask, which is the state-component bitmap that specifies the state
components on which the instruction operates.
Some state components are user state components, and they can be managed by the entire XSAVE feature set.
Other state components are supervisor state components, and they can be managed only by XSAVES and
XRSTORS. The state components corresponding to bit 9, to bits 18:17, and to bits in the range 7:0 are user state
components; those corresponding to bit 8, to bits in the range 13:10, and to bits 16:14 are supervisor state
components.
Extended control register XCR0 contains a state-component bitmap that specifies the user state components that
software has enabled the XSAVE feature set to manage. If the bit corresponding to a state component is clear in
XCR0, instructions in the XSAVE feature set will not operate on that state component, regardless of the value of the
instruction mask.
The IA32_XSS MSR (index DA0H) contains a state-component bitmap that specifies the supervisor state compo-
nents that software has enabled XSAVES and XRSTORS to manage (XSAVE, XSAVEC, XSAVEOPT, and XRSTOR
cannot manage supervisor state components). If the bit corresponding to a state component is clear in the
IA32_XSS MSR, XSAVES and XRSTORS will not operate on that state component, regardless of the value of the
instruction mask.
13-2
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
Some XSAVE-supported features can be used only if XCR0 has been configured so that the features’ state compo-
nents can be managed by the XSAVE feature set. (This applies only to features with user state components.) Such
state components and features are XSAVE-enabled. In general, the processor will not modify (or allow modifica-
tion of) the registers of a state component of an XSAVE-enabled feature if the bit corresponding to that state
component is clear in XCR0. (If software clears such a bit in XCR0, the processor preserves the corresponding state
component.) If an XSAVE-enabled feature has not been fully enabled in XCR0, execution of any instruction defined
for that feature causes an invalid-opcode exception (#UD).
As will be explained in Section 13.3, the XSAVE feature set is enabled only if CR4.OSXSAVE[bit 18] = 1. If
CR4.OSXSAVE = 0, the processor treats XSAVE-enabled state features and their state components as if all bits in
XCR0 were clear; the state components cannot be modified and the features’ instructions cannot be executed.
The state components for x87 state, for SSE state, for PT state, for PKRU state, for PASID state, for CET state, for
HDC state, for UINTR state, for LBR state, and for HWP state are XSAVE-managed but the corresponding features
are not XSAVE-enabled. Processors allow modification of this state, as well as execution of x87 FPU instructions
and SSE instructions and use of Intel Processor Trace, protection keys, the ENQCMD instruction and the
IA32_PASID MSR, CET, hardware duty cycling, user interrupts, LBRs, and hardware P-states, regardless of the
value of CR4.OSXSAVE and XCR0.
13.2
ENUMERATION OF CPU SUPPORT FOR XSAVE INSTRUCTIONS AND XSAVE-
SUPPORTED FEATURES
A processor enumerates support for the XSAVE feature set and for features supported by that feature set using the
CPUID instruction. The following items provide specific details:
• CPUID.1:ECX.XSAVE[bit 26] enumerates general support for the XSAVE feature set:
- If this bit is 0, the processor does not support any of the following instructions: XGETBV, XRSTOR,
XRSTORS, XSAVE, XSAVEC, XSAVEOPT, XSAVES, and XSETBV; the processor provides no further
enumeration through CPUID function 0DH (see below).
- If this bit is 1, the processor supports the following instructions: XGETBV, XRSTOR, XSAVE, and XSETBV.1
Further enumeration is provided through CPUID function 0DH.
CR4.OSXSAVE can be set to 1 if and only if CPUID.1:ECX.XSAVE[bit 26] is enumerated as 1.
• CPUID function 0DH enumerates details of CPU support through a set of sub-functions. Software selects a
specific sub-function by the value placed in the ECX register. The following items provide specific details:
- CPUID function 0DH, sub-function 0.
• EDX:EAX is a bitmap of all the user state components that can be managed using the XSAVE feature
set. A bit can be set in XCR0 if and only if the corresponding bit is set in this bitmap. Every processor
that supports the XSAVE feature set will set EAX[0] (x87 state) and EAX[1] (SSE state).
If EAX[i] = 1 (for 1 < i < 32) or EDX[i-32] = 1 (for 32 ≤ i < 63), sub-function i enumerates details for
state component i (see below).
• ECX enumerates the size (in bytes) required by the XSAVE instruction for an XSAVE area containing all
the user state components supported by this processor.
• EBX enumerates the size (in bytes) required by the XSAVE instruction for an XSAVE area containing all
the user state components corresponding to bits currently set in XCR0.
- CPUID function 0DH, sub-function 1.
• EAX[0] enumerates support for the XSAVEOPT instruction. The instruction is supported if and only if
this bit is 1. If EAX[0] = 0, execution of XSAVEOPT causes an invalid-opcode exception (#UD).
• EAX[1] enumerates support for compaction extensions to the XSAVE feature set. The following are
supported if this bit is 1:
1. If CPUID.1:ECX.XSAVE[bit 26] = 1, XGETBV and XSETBV may be executed with ECX = 0 (to read and write XCR0). Any support for
execution of these instructions with other values of ECX is enumerated separately.
Vol. 1
13-3
MANAGING STATE USING THE XSAVE FEATURE SET
- The compacted format of the extended region of XSAVE areas (see Section 13.4.3).
- The XSAVEC instruction. If EAX[1] = 0, execution of XSAVEC causes a #UD.
- Execution of the compacted form of XRSTOR (see Section 13.8).
• EAX[2] enumerates support for execution of XGETBV with ECX = 1. This allows software to determine
the state of the init optimization. See Section 13.6.
• EAX[3] enumerates support for XSAVES, XRSTORS, and the IA32_XSS MSR. If EAX[3] = 0, execution
of XSAVES or XRSTORS causes a #UD; an attempt to access the IA32_XSS MSR using RDMSR or
WRMSR causes a general-protection exception (#GP). Every processor that supports a supervisor state
component sets EAX[3]. Every processor that sets EAX[3] (XSAVES, XRSTORS, IA32_XSS) will also set
EAX[1] (the compaction extensions).
• EAX[4] enumerates general support for extended feature disable (XFD). See Section 13.14 for details.
• EAX[31:5] are reserved.
• EBX enumerates the size (in bytes) defined as follows:
- If EAX[3] is enumerated as 1, EBX enumerates the size required by the XSAVES instruction for an
XSAVE area containing all the state components corresponding to bits currently set in XCR0 |
IA32_XSS.
- If EAX[3] is enumerated as 0 and EAX[1] is enumerated as 1, EBX enumerates the size required by
the XSAVEC instruction for an XSAVE area containing all the state components corresponding to bits
currently set in XCR0.
- If EAX[1] and EAX[3] are both enumerated as 0, EBX enumerates zero.
• EDX:ECX is a bitmap of all the supervisor state components that can be managed by XSAVES and
XRSTORS. A bit can be set in the IA32_XSS MSR if and only if the corresponding bit is set in this bitmap.
NOTE
In summary, the XSAVE feature set supports state component i (0 ≤ i < 63) if one of the following
is true: (1) i < 32 and CPUID.(EAX=0DH,ECX=0):EAX[i] = 1; (2) i ≥ 32 and
CPUID.(EAX=0DH,ECX=0):EAX[i-32] = 1; (3) i < 32 and CPUID.(EAX=0DH,ECX=1):ECX[i] = 1;
or (4) i ≥ 32 and CPUID.(EAX=0DH,ECX=1):EDX[i-32] = 1. The XSAVE feature set supports user
state component i if (1) or (2) holds; if (3) or (4) holds, state component i is a supervisor state
component and support is limited to XSAVES and XRSTORS.
- CPUID function 0DH, sub-function i (i > 1). This sub-function enumerates details for state component i. If
the XSAVE feature set supports state component i (see note above), the following items provide specific
details:
• EAX enumerates the size (in bytes) required for state component i.
• If state component i is a user state component, EBX enumerates the offset (in bytes, from the base of
the XSAVE area) of the section used for state component i. (This offset applies only when the standard
format for the extended region of the XSAVE area is being used; see Section 13.4.3.)
• If state component i is a supervisor state component, EBX returns 0.
• If state component i is a user state component, ECX[0] return 0; if state component i is a supervisor
state component, ECX[0] returns 1.
• The value returned by ECX[1] indicates the alignment of state component i when the compacted format
of the extended region of an XSAVE area is used (see Section 13.4.3). If ECX[1] returns 0, state
component i is located immediately following the preceding state component; if ECX[1] returns 1, state
component i is located on the next 64-byte boundary following the preceding state component.
• If the processor supports XFD for state component i, ECX[2] returns 1; otherwise, ECX[2] returns 0.
• ECX[31:3] and EDX return 0.
If the XSAVE feature set does not support state component i, sub-function i returns 0 in EAX, EBX, ECX, and
EDX.
13-4
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
13.3
ENABLING THE XSAVE FEATURE SET AND XSAVE-ENABLED FEATURES
Software enables the XSAVE feature set by setting CR4.OSXSAVE[bit 18] to 1 (e.g., with the MOV to CR4 instruc-
tion). If this bit is 0, execution of any of XGETBV, XRSTOR, XRSTORS, XSAVE, XSAVEC, XSAVEOPT, XSAVES, and
XSETBV causes an invalid-opcode exception (#UD).
When CR4.OSXSAVE = 1 and CPL = 0, executing the XSETBV instruction with ECX = 0 writes the 64-bit value in
EDX:EAX to XCR0 (EAX is written to XCR0[31:0] and EDX to XCR0[63:32]). (Execution of the XSETBV instruction
causes a general-protection fault - #GP - if CPL > 0.) The following items provide details regarding individual bits
in XCR0:
•
XCR0[0] is associated with x87 state (see Section 13.5.1). XCR0[0] is always 1. It has that value coming out of
RESET. Executing the XSETBV instruction causes a general-protection fault (#GP) if ECX = 0 and EAX[0] is 0.
•
XCR0[1] is associated with SSE state (see Section 13.5.2). Software can use the XSAVE feature set to manage
SSE state only if XCR0[1] = 1. The value of XCR0[1] in no way determines whether software can execute SSE
instructions (these instructions can be executed even if XCR0[1] = 0).
XCR0[1] is 0 coming out of RESET. As noted in Section 13.2, every processor that supports the XSAVE feature
set allows software to set XCR0[1].
•
XCR0[2] is associated with AVX state (see Section 13.5.3). Software can use the XSAVE feature set to manage
AVX state only if XCR0[2] = 1. In addition, software can execute Intel AVX instructions only if CR4.OSXSAVE =
XCR0[2] = 1. Otherwise, any execution of an Intel AVX instruction causes an invalid-opcode exception (#UD).
XCR0[2] is 0 coming out of RESET. As noted in Section 13.2, a processor allows software to set XCR0[2] if and
only if CPUID.(EAX=0DH,ECX=0):EAX[2] = 1. In addition, executing the XSETBV instruction causes a general-
protection fault (#GP) if ECX = 0 and EAX[2:1] has the value 10b; that is, software cannot enable the XSAVE
feature set for AVX state but not for SSE state.
As noted in Section 13.1, the processor will preserve AVX state unmodified if software clears XCR0[2].
However, clearing XCR0[2] while AVX state is not in its initial configuration may cause SSE instructions to incur
a power and performance penalty. See Section 14.5.3, “Enable the Use Of XSAVE Feature Set And XSAVE State
Components,” of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, for how
system software can avoid this penalty.
•
XCR0[4:3] are associated with MPX state (see Section 13.5.4). Software can use the XSAVE feature set to
manage MPX state only if XCR0[4:3] = 11b. In addition, MPX instructions operate as defined only if
CR4.OSXSAVE = 1 and XCR0[4:3] = 11b. Otherwise, execution of an MPX instruction causes no operation (as
a NOP instruction); in addition, executions of CALL, RET, JMP, and Jcc do not initialize the bounds registers, and
they ignore any F2H (BND) prefix.1
XCR0[4:3] have value 00b coming out of RESET. As noted in Section 13.2, a processor allows software to set
XCR0[4:3] to 11b if and only if CPUID.(EAX=0DH,ECX=0):EAX[4:3] = 11b. In addition, executing the XSETBV
instruction causes a general-protection fault (#GP) if ECX = 0, EAX[4:3] is neither 00b nor 11b; that is,
software can enable the XSAVE feature set for MPX state only if it does so for both state components.
As noted in Section 13.1, the processor will preserve MPX state unmodified if software clears XCR0[4:3].
•
XCR0[7:5] are associated with AVX-512 state (see Section 13.5.5). Software can use the XSAVE feature set to
manage AVX-512 state only if XCR0[7:5] = 111b. In addition, software can execute Intel AVX-512 instructions
only if CR4.OSXSAVE = 1 and XCR0[7:5] = 111b. Otherwise, any execution of an Intel AVX-512 instruction
causes an invalid-opcode exception (#UD).
XCR0[7:5] have value 000b coming out of RESET. As noted in Section 13.2, a processor allows software to set
XCR0[7:5] to 111b if and only if CPUID.(EAX=0DH,ECX=0):EAX[7:5] = 111b. In addition, executing the
XSETBV instruction causes a general-protection fault (#GP) if ECX = 0, EAX[7:5] is not 000b, and any bit is
clear in EAX[2:1] or EAX[7:5]; that is, software can enable the XSAVE feature set for AVX-512 state only if it
does so for all three state components, and only if it also does so for AVX state and SSE state. This implies that
the value of XCR0[7:5] is always either 000b or 111b.
As noted in Section 13.1, the processor will preserve AVX-512 state unmodified if software clears XCR0[7:5].
However, clearing XCR0[7:5] while AVX-512 state is not in its initial configuration may cause SSE and Intel AVX
instructions to incur a power and performance penalty. See Section 14.5.3, “Enable the Use Of XSAVE Feature
1.
Prior to the introduction of MPX, the opcodes defining MPX instructions operated as NOP, and the CALL, RET, JMP, and Jcc instruc-
tions ignored any F2H prefix.
Vol. 1
13-5
MANAGING STATE USING THE XSAVE FEATURE SET
Set And XSAVE State Components,” of the Intel® 64 and IA-32 Architectures Software Developer’s Manual,
Volume 3A, for how system software can avoid this penalty.
• XCR0[9] is associated with PKRU state (see Section 13.5.7). Software can use the XSAVE feature set to
manage PKRU state only if XCR0[9] = 1. The value of XCR0[9] in no way determines whether software can use
protection keys or execute other instructions that access PKRU state (these instructions can be executed even
if XCR0[9] = 0).
XCR0[9] is 0 coming out of RESET. As noted in Section 13.2, a processor allows software to set XCR0[9] if and
only if CPUID.(EAX=0DH,ECX=0):EAX[9] = 1.
• XCR0[18:17] are associated with AMX state (see Section 13.5.5). Software can use the XSAVE feature set to
manage AMX state only if XCR0[18:17] = 11b. In addition, software can execute Intel AMX instructions only if
CR4.OSXSAVE = 1 and XCR0[18:17] = 11b. Otherwise, any execution of an Intel AMX instruction causes an
invalid-opcode exception (#UD).
XCR0[18:17] have value 00b coming out of RESET. As noted in Section 13.2, a processor allows software to set
XCR0[18:17] to 11b if and only if CPUID.(EAX=0DH,ECX=0):EAX[18:17] = 11b. In addition, executing the
XSETBV instruction causes a general-protection fault (#GP) if ECX = 0 and EAX[17] ≠ EAX[18] (TILECFG and
TILEDATA must be enabled together). This implies that the value of XCR0[18:17] is always either 00b or 11b.
While Intel AMX instructions can be executed only in 64-bit mode, instructions of the XSAVE feature set can
operate on TILECFG and TILEDATA in any mode. It is recommended that only 64-bit operating systems enable
Intel AMX by setting XCR0[18:17].
• XCR0[63:19], XCR0[16:10], and XCR0[8] are reserved.1 Executing the XSETBV instruction causes a general-
protection fault (#GP) if ECX = 0 and any corresponding bit in EDX:EAX is not 0. These bits in XCR0 are all 0
coming out of RESET.
Software operating with CPL > 0 may need to determine whether the XSAVE feature set and certain XSAVE-
enabled features have been enabled. If CPL > 0, execution of the MOV from CR4 instruction causes a general-
protection fault (#GP). The following alternative mechanisms allow software to discover the enabling of the XSAVE
feature set regardless of CPL:
• The value of CR4.OSXSAVE is returned in CPUID.1:ECX.OSXSAVE[bit 27]. If software determines that
CPUID.1:ECX.OSXSAVE = 1, the processor supports the XSAVE feature set and the feature set has been
enabled in CR4.
• Executing the XGETBV instruction with ECX = 0 returns the value of XCR0 in EDX:EAX. XGETBV can be
executed if CR4.OSXSAVE = 1 (if CPUID.1:ECX.OSXSAVE = 1), regardless of CPL.
Thus, software can use the following algorithm to determine the support and enabling for the XSAVE feature set:
1. Use CPUID to discover the value of CPUID.1:ECX.OSXSAVE.
- If the bit is 0, either the XSAVE feature set is not supported by the processor or has not been enabled by
software. Either way, the XSAVE feature set is not available, nor are XSAVE-enabled features such as AVX.
- If the bit is 1, the processor supports the XSAVE feature set - including the XGETBV instruction - and it
has been enabled by software. The XSAVE feature set can be used to manage x87 state (because XCR0[0]
is always 1). Software requiring more detailed information can go on to the next step.
2. Execute XGETBV with ECX = 0 to discover the value of XCR0. If XCR0[1] = 1, the XSAVE feature set can be
used to manage SSE state. If XCR0[2] = 1, the XSAVE feature set can be used to manage AVX state and
software can execute Intel AVX instructions. If XCR0[4:3] is 11b, the XSAVE feature set can be used to manage
MPX state and software can execute Intel MPX instructions. If XCR0[7:5] is 111b, the XSAVE feature set can be
used to manage AVX-512 state and software can execute Intel AVX-512 instructions. If XCR0[9] = 1, the
XSAVE feature set can be used to manage PKRU state.
The IA32_XSS MSR (with MSR index DA0H) is zero coming out of RESET. If CR4.OSXSAVE = 1,
CPUID.(EAX=0DH,ECX=1):EAX[3] = 1, and CPL = 0, executing the WRMSR instruction with ECX = DA0H writes
the 64-bit value in EDX:EAX to the IA32_XSS MSR (EAX is written to IA32_XSS[31:0] and EDX to
IA32_XSS[63:32]). The following items provide details regarding individual bits in the IA32_XSS MSR:
1. Bit 8 and bits 16:10 correspond to supervisor state components. Since bits can be set in XCR0 only for user state components, those
bits of XCR0 must be 0.
13-6
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
• IA32_XSS[8] is associated with PT state (see Section 13.5.6). Software can use XSAVES and XRSTORS to
manage PT state only if IA32_XSS[8] = 1. The value of IA32_XSS[8] does not determine whether software can
use Intel Processor Trace (the feature can be used even if IA32_XSS[8] = 0).
• IA32_XSS[10] is associated with PASID state (see Section 13.5.8). Software can use the XSAVES and
XRSTORS to manage PASID state only if IA32_XSS[10] = 1. The value of IA32_XSS[10] does not determine
whether software can use the ENQCMD instruction, which uses the IA32_PASID MSR. (ENQCMD can be used
even if IA32_XSS[10] is 0.)
• IA32_XSS[12:11] are associated with CET state (see Section 13.5.9), IA32_XSS[11] with CET_U state and
IA32_XSS[12] with CET_S state. Software can use the XSAVES and XRSTORS to manage CET_U state (respec-
tively, CET_S state) only if IA32_XSS[11] = 1 (respectively, IA32_XSS[12] = 1). The value of
IA32_XSS[12:11] does not determine whether software can use CET (the feature can be used even if either of
IA32_XSS[12:11] is 0).
• IA32_XSS[13] is associated with HDC state (see Section 13.5.10). Software can use XSAVES and XRSTORS to
manage HDC state only if IA32_XSS[13] = 1. The value of IA32_XSS[13] does not determine whether software
can use hardware duty cycling (the feature can be used even if IA32_XSS[13] = 0).
• IA32_XSS[14] is associated with UINTR state (see Section 13.5.11). Software can use XSAVES and XRSTORS
to manage UINTR state only if IA32_XSS[14] = 1. The value of IA32_XSS[14] does not determine whether
software can use user interrupts (the feature can be used even if IA32_XSS[14] = 0).
• IA32_XSS[15] is associated with LBR state (see Section 13.5.12). Software can use XSAVES and XRSTORS to
manage LBR state only if IA32_XSS[15] = 1. The value of IA32_XSS[15] does not determine whether software
can use LBRs (the feature can be used even if IA32_XSS[15] = 0).
• IA32_XSS[16] is associated with HWP state (see Section 13.5.13). Software can use XSAVES and XRSTORS to
manage HWP state only if IA32_XSS[16] = 1. The value of IA32_XSS[16] does not determine whether
software can use hardware P-states (the feature can be used even if IA32_XSS[16] = 0).
• IA32_XSS[63:17], IA32_XSS[9] and IA32_XSS[7:0] are reserved.1 Executing the WRMSR instruction causes
a general-protection fault (#GP) if ECX = DA0H and any corresponding bit in EDX:EAX is not 0. These bits in
XCR0 are all 0 coming out of RESET.
The IA32_XSS MSR is 0 coming out of RESET.
There is no mechanism by which software operating with CPL > 0 can discover the value of the IA32_XSS MSR.
13.4
XSAVE AREA
The XSAVE feature set includes instructions that save and restore the XSAVE-managed state components to and
from memory: XSAVE, XSAVEOPT, XSAVEC, and XSAVES (for saving); and XRSTOR and XRSTORS (for restoring).
The processor organizes the state components in a region of memory called an XSAVE area. Each of the save and
restore instructions takes a memory operand that specifies the 64-byte aligned base address of the XSAVE area on
which it operates.
Every XSAVE area has the following format:
• The legacy region. The legacy region of an XSAVE area comprises the 512 bytes starting at the area’s base
address. It is used to manage the state components for x87 state and SSE state. The legacy region is described
in more detail in Section 13.4.1.
• The XSAVE header. The XSAVE header of an XSAVE area comprises the 64 bytes starting at an offset of 512
bytes from the area’s base address. The XSAVE header is described in more detail in Section 13.4.2.
• The extended region. The extended region of an XSAVE area starts at an offset of 576 bytes from the area’s
base address. It is used to manage the state components other than those for x87 state and SSE state. The
extended region is described in more detail in Section 13.4.3. The size of the extended region is determined by
which state components the processor supports and which bits have been set in XCR0 and IA32_XSS (see
Section 13.3).
1. Bit 9 and bits 7:0 correspond to user state components. Since bits can be set in the IA32_XSS MSR only for supervisor state compo-
nents, those bits of the MSR must be 0.
Vol. 1
13-7
MANAGING STATE USING THE XSAVE FEATURE SET
13.4.1 Legacy Region of an XSAVE Area
The legacy region of an XSAVE area comprises the 512 bytes starting at the area’s base address. It has the same
format as the FXSAVE area (see Section 10.5.1). The XSAVE feature set uses the legacy area for x87 state (state
component 0) and SSE state (state component 1). Table 13-1 illustrates the format of the first 416 bytes of the
legacy region of an XSAVE area.
Table 13-1. Format of the Legacy Region of an XSAVE Area
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
FIP[63:48] or
FCS or
FIP[31:0]
FOP
Rsvd.
FTW
FSW
FCW
0
reserved
FIP[47:32]
FDP[63:48]
FDS or
MXCSR_MASK
MXCSR
FDP[31:0]
16
or reserved
FDP[47:32]
Reserved
ST0/MM0
32
Reserved
ST1/MM1
48
Reserved
ST2/MM2
64
Reserved
ST3/MM3
80
Reserved
ST4/MM4
96
Reserved
ST5/MM5
112
Reserved
ST6/MM6
128
Reserved
ST7/MM7
144
XMM0
160
XMM1
176
XMM2
192
XMM3
208
XMM4
224
XMM5
240
XMM6
256
XMM7
272
XMM8
288
XMM9
304
XMM10
320
XMM11
336
XMM12
352
XMM13
368
XMM14
384
XMM15
400
The x87 state component comprises bytes 23:0 and bytes 159:32. The SSE state component comprises
bytes 31:24 and bytes 415:160. The XSAVE feature set does not use bytes 511:416; bytes 463:416 are reserved.
Section 13.7 through Section 13.9 provide details of how instructions in the XSAVE feature set use the legacy
region of an XSAVE area.
13-8
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
13.4.2 XSAVE Header
The XSAVE header of an XSAVE area comprises the 64 bytes starting at offset 512 from the area’s base address:
• Bytes 7:0 of the XSAVE header is a state-component bitmap (see Section 13.1) called XSTATE_BV. It
identifies the state components in the XSAVE area.
• Bytes 15:8 of the XSAVE header is a state-component bitmap called XCOMP_BV. It is used as follows:
- XCOMP_BV[63] indicates the format of the extended region of the XSAVE area (see Section 13.4.3). If it is
clear, the standard format is used. If it is set, the compacted format is used; XCOMP_BV[62:0] provide
format specifics as specified in Section 13.4.3.
- XCOMP_BV[63] determines which form of the XRSTOR instruction is used. If the bit is set, the compacted
form is used; otherwise, the standard form is used. See Section 13.8.
- All bits in XCOMP_BV should be 0 if the processor does not support the compaction extensions to the XSAVE
feature set.
• Bytes 63:16 of the XSAVE header are reserved.
Section 13.7 through Section 13.9 provide details of how instructions in the XSAVE feature set use the XSAVE
header of an XSAVE area.
13.4.3 Extended Region of an XSAVE Area
The extended region of an XSAVE area starts at byte offset 576 from the area’s base address. The size of the
extended region is determined by which state components the processor supports and which bits have been set in
XCR0 | IA32_XSS (see Section 13.3). The XSAVE feature set uses the extended area for each state component i,
where i ≥ 2.
The extended region of the an XSAVE area may have one of two formats. The standard format is supported by all
processors that support the XSAVE feature set; the compacted format is supported by those processors that
support the compaction extensions to the XSAVE feature set (see Section 13.2). Bit 63 of the XCOMP_BV field in
the XSAVE header (see Section 13.4.2) indicates which format is used.
The following items describe the two possible formats of the extended region:
• Standard format. Each state component i (i ≥ 2) is located at the byte offset from the base address of the
XSAVE area enumerated in CPUID.(EAX=0DH,ECX=i):EBX. (CPUID.(EAX=0DH,ECX=i):EAX enumerates the
number of bytes required for state component i.
• Compacted format. Each state component i (i ≥ 2) is located at a byte offset from the base address of the
XSAVE area based on the XCOMP_BV field in the XSAVE header:
- If XCOMP_BV[i] = 0, state component i is not in the XSAVE area.
- If XCOMP_BV[i] = 1, state component i is located at a byte offset locationI from the base address of the
XSAVE area, where locationI is determined by the following items:
• If XCOMP_BV[j] = 0 for every j, 2 ≤ j < i, locationI is 576. (This item applies if i is the first bit set in
bits 62:2 of the XCOMP_BV; it implies that state component i is located at the beginning of the
extended region.)
• Otherwise, let j, 2 ≤ j < i, be the greatest value such that XCOMP_BV[j] = 1. Then locationI is
determined by the following values: locationJ; sizeJ, as enumerated in CPUID.(EAX=0DH,ECX=j):EAX;
and the value of alignI, as enumerated in CPUID.(EAX=0DH,ECX=i):ECX[1]:
- If alignI = 0, locationI = locationJ + sizeJ. (This item implies that state component i is located
immediately following the preceding state component whose bit is set in XCOMP_BV.)
- If alignI = 1, locationI = ceiling(locationJ + sizeJ, 64). (This item implies that state component i is
located on the next 64-byte boundary following the preceding state component whose bit is set in
XCOMP_BV.)
Vol. 1
13-9
MANAGING STATE USING THE XSAVE FEATURE SET
13.5
XSAVE-MANAGED STATE
The section provides details regarding how the XSAVE feature set interacts with the various XSAVE-managed state
components.
Unless otherwise state, the state pertaining to a particular state component is saved beginning at byte 0 of the
section of the XSAVE are corresponding to that state component.
13.5.1 x87 State
Instructions in the XSAVE feature set can manage the same state of the x87 FPU execution environment (x87
state) that can be managed using the FXSAVE and FXRSTOR instructions. They organize all x87 state as a user
state component in the legacy region of the XSAVE area (see Section 13.4.1). This region is illustrated in
Table 13-1; the x87 state is listed below, along with details of its interactions with the XSAVE feature set:
• Bytes 1:0, 3:2, 7:6. These are used for the x87 FPU Control Word (FCW), the x87 FPU Status Word (FSW), and
the x87 FPU Opcode (FOP), respectively.
• Byte 4 is used for an abridged version of the x87 FPU Tag Word (FTW). The following items describe its usage:
- For each j, 0 ≤ j ≤ 7, XSAVE, XSAVEOPT, XSAVEC, and XSAVES save a 0 into bit j of byte 4 if x87 FPU data
register STj has a empty tag; otherwise, XSAVE, XSAVEOPT, XSAVEC, and XSAVES save a 1 into bit j of byte
4.
- For each j, 0 ≤ j ≤ 7, XRSTOR and XRSTORS establish the tag value for x87 FPU data register STj as follows.
If bit j of byte 4 is 0, the tag for STj in the tag register for that data register is marked empty (11B);
otherwise, the x87 FPU sets the tag for STj based on the value being loaded into that register (see below).
• Bytes 15:8 are used as follows:
- If the instruction has no REX prefix, or if REX.W = 0:
• Bytes 11:8 are used for bits 31:0 of the x87 FPU Instruction Pointer Offset (FIP).
• If CPUID.(EAX=07H,ECX=0H):EBX[bit 13] = 0, bytes 13:12 are used for x87 FPU Instruction Pointer
Selector (FCS). Otherwise, XSAVE, XSAVEOPT, XSAVEC, and XSAVES save these bytes as 0000H, and
XRSTOR and XRSTORS ignore them.
• Bytes 15:14 are not used.
- If the instruction has a REX prefix with REX.W = 1, bytes 15:8 are used for the full 64 bits of FIP.
• Bytes 23:16 are used as follows:
- If the instruction has no REX prefix, or if REX.W = 0:
• Bytes 19:16 are used for bits 31:0 of the x87 FPU Data Pointer Offset (FDP).
• If CPUID.(EAX=07H,ECX=0H):EBX[bit 13] = 0, bytes 21:20 are used for x87 FPU Data Pointer Selector
(FDS). Otherwise, XSAVE, XSAVEOPT, XSAVEC, and XSAVES save these bytes as 0000H; and XRSTOR
and XRSTORS ignore them.
• Bytes 23:22 are not used.
- If the instruction has a REX prefix with REX.W = 1, bytes 23:16 are used for the full 64 bits of FDP.
• Bytes 31:24 are used for SSE state (see Section 13.5.2).
• Bytes 159:32 are used for the registers ST0-ST7 (MM0-MM7). Each of the 8 register is allocated a 128-bit
region, with the low 80 bits used for the register and the upper 48 bits unused.
x87 state is XSAVE-managed but the x87 FPU feature is not XSAVE-enabled. The XSAVE feature set can operate on
x87 state only if the feature set is enabled (CR4.OSXSAVE = 1).1 Software can otherwise use x87 state even if the
XSAVE feature set is not enabled.
1. The processor ensures that XCR0[0] is always 1.
13-10
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
13.5.2 SSE State
Instructions in the XSAVE feature set can manage the registers used by the streaming SIMD extensions (SSE
state) just as the FXSAVE and FXRSTOR instructions do. They organize all SSE state as a user state component in
the legacy region of the XSAVE area (see Section 13.4.1). This region is illustrated in Table 13-1; the SSE state is
listed below, along with details of its interactions with the XSAVE feature set:
• Bytes 23:0 are used for x87 state (see Section 13.5.1).
• Bytes 27:24 are used for the MXCSR register. XRSTOR and XRSTORS generate general-protection faults (#GP)
in response to attempts to set any of the reserved bits of the MXCSR register.1
• Bytes 31:28 are used for the MXCSR_MASK value. XRSTOR and XRSTORS ignore this field.
• Bytes 159:32 are used for x87 state.
• Bytes 287:160 are used for the registers XMM0-XMM7.
• Bytes 415:288 are used for the registers XMM8-XMM15. These fields are used only in 64-bit mode. Executions
of XSAVE, XSAVEOPT, XSAVEC, and XSAVES outside 64-bit mode do not modify these bytes; executions of
XRSTOR and XRSTORS outside 64-bit mode do not update XMM8-XMM15. See Section 13.13.
SSE state is XSAVE-managed but the SSE feature is not XSAVE-enabled. The XSAVE feature set can operate on SSE
state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage SSE state
(XCR0[1] = 1). Software can otherwise use SSE state even if the XSAVE feature set is not enabled or has not been
configured to manage SSE state.
13.5.3 AVX State
The register state used by the Intel® Advanced Vector Extensions (Intel AVX) comprises the MXCSR register and
16 256-bit vector registers called YMM0-YMM15. The low 128 bits of each register YMMi is identical to the SSE
register XMMi. Thus, the new state register state added by Intel AVX comprises the upper 128 bits of the registers
YMM0-YMM15. These 16 128-bit values are denoted YMM0_H-YMM15_H and are collectively called AVX state.
As noted in Section 13.1, the XSAVE feature set manages AVX state as user state component 2. Thus, AVX state is
located in the extended region of the XSAVE area (see Section 13.4.3).
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=2):EBX enumerates the offset (in bytes, from the base of the
XSAVE area) of the section of the extended region of the XSAVE area used for AVX state (when the standard format
of the extended region is used). CPUID.(EAX=0DH,ECX=2):EAX enumerates the size (in bytes) required for AVX
state.
The XSAVE feature set partitions YMM0_H-YMM15_H in a manner similar to that used for the XMM registers (see
Section 13.5.2). Bytes 127:0 of the AVX-state section are used for YMM0_H-YMM7_H. Bytes 255:128 are used for
YMM8_H-YMM15_H, but they are used only in 64-bit mode. Executions of XSAVE, XSAVEOPT, XSAVEC, and
XSAVES outside 64-bit mode do not modify bytes 255:128; executions of XRSTOR and XRSTORS outside 64-bit
mode do not update YMM8_H-YMM15_H. See Section 13.13. In general, bytes 16i+15:16i are used for YMMi_H
(for 0 ≤ i ≤ 15).
AVX state is XSAVE-managed and the Intel AVX feature is XSAVE-enabled. The XSAVE feature set can operate on
AVX state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage AVX state
(XCR0[2] = 1). Intel AVX instructions cannot be used unless the XSAVE feature set is enabled and has been config-
ured to manage AVX state.
13.5.4 MPX State
The register state used by the Intel® Memory Protection Extensions (MPX) comprises the 4 128-bit bounds regis-
ters BND0-BND3 (BNDREGS state); and the 64-bit user-mode configuration register BNDCFGU and the 64-bit
MPX status register BNDSTATUS (collectively, BNDCSR state). Together, these two user state components
compose MPX state.
1. While MXCSR and MXCSR_MASK are part of SSE state, their treatment by the XSAVE feature set is not the same as that of the XMM
registers. See Section 13.7 through Section 13.11 for details.
Vol. 1
13-11
MANAGING STATE USING THE XSAVE FEATURE SET
As noted in Section 13.1, the XSAVE feature set manages MPX state as state components 3-4. Thus, MPX state is
located in the extended region of the XSAVE area (see Section 13.4.3). The following items detail how these state
components are organized in this region:
• BNDREGS state.
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=3):EBX enumerates the offset (in bytes, from the base of the
XSAVE area) of the section of the extended region of the XSAVE area used for BNDREGS state (when the
standard format of the extended region is used). CPUID.(EAX=0DH,ECX=3):EAX enumerates the size (in
bytes) required for BNDREGS state. The BNDREGS section is used for the 4 128-bit bound registers BND0-
BND3, with bytes 16i+15:16i being used for BNDi.
• BNDCSR state.
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=4):EBX enumerates the offset of the section of the extended
region of the XSAVE area used for BNDCSR state (when the standard format of the extended region is used).
CPUID.(EAX=0DH,ECX=4):EAX enumerates the size (in bytes) required for BNDCSR state. In the BNDSCR
section, bytes 7:0 are used for BNDCFGU and bytes 15:8 are used for BNDSTATUS.
Both components of MPX state are XSAVE-managed and the Intel MPX feature is XSAVE-enabled. The XSAVE
feature set can operate on MPX state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured
to manage MPX state (XCR0[4:3] = 11b). Intel MPX instructions cannot be used unless the XSAVE feature set is
enabled and has been configured to manage MPX state.
13.5.5 AVX-512 State
The register state used by the Intel® Advanced Vector Extensions 512 (Intel AVX-512) comprises the MXCSR
register, the 8 64-bit opmask registers k0-k7, and 32 512-bit vector registers called ZMM0-ZMM31. For each i, 0 ≤
i≤ 15, the low 256 bits of register ZMMi is identical to the Intel AVX register YMMi. Thus, the new state register
state added by Intel AVX-512 comprises the following user state components:
• The opmask registers, collectively called opmask state.
• The upper 256 bits of the registers ZMM0-ZMM15. These 16 256-bit values are denoted ZMM0_H-ZMM15_H
and are collectively called ZMM_Hi256 state.
• The 16 512-bit registers ZMM16-ZMM31, collectively called Hi16_ZMM state.
Together, these three state components compose AVX-512 state.
As noted in Section 13.1, the XSAVE feature set manages AVX-512 state as state components 5-7. Thus, AVX-512
state is located in the extended region of the XSAVE area (see Section 13.4.3). The following items detail how these
state components are organized in this region:
• Opmask state.
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=5):EBX enumerates the offset (in bytes, from the base of the
XSAVE area) of the section of the extended region of the XSAVE area used for opmask state (when the standard
format of the extended region is used). CPUID.(EAX=0DH,ECX=5):EAX enumerates the size (in bytes) required
for opmask state. The opmask section is used for the 8 64-bit opmask registers k0-k7, with bytes 8i+7:8i
being used for ki.
• ZMM_Hi256 state.
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=6):EBX enumerates the offset of the section of the extended
region of the XSAVE area used for ZMM_Hi256 state (when the standard format of the extended region is
used). CPUID.(EAX=0DH,ECX=6):EAX enumerates the size (in bytes) required for ZMM_Hi256 state.
The XSAVE feature set partitions ZMM0_H-ZMM15_H in a manner similar to that used for the XMM registers
(see Section 13.5.2). Bytes 255:0 of the ZMM_Hi256-state section are used for ZMM0_H-ZMM7_H.
Bytes 511:256 are used for ZMM8_H-ZMM15_H, but they are used only in 64-bit mode. Executions of XSAVE,
XSAVEOPT, XSAVEC, and XSAVES outside 64-bit mode do not modify bytes 511:256; executions of XRSTOR
and XRSTORS outside 64-bit mode do not update ZMM8_H-ZMM15_H. See Section 13.13. In general,
bytes 32i+31:32i are used for ZMMi_H (for 0 ≤ i ≤ 15).
• Hi16_ZMM state.
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=7):EBX enumerates the offset of the section of the extended
region of the XSAVE area used for Hi16_ZMM state (when the standard format of the extended region is used).
CPUID.(EAX=0DH,ECX=7):EAX enumerates the size (in bytes) required for Hi16_ZMM state.
13-12
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
The XSAVE feature set accesses Hi16_ZMM state only in 64-bit mode. Executions of XSAVE, XSAVEOPT,
XSAVEC, and XSAVES outside 64-bit mode do not modify the Hi16_ZMM section; executions of XRSTOR and
XRSTORS outside 64-bit mode do not update ZMM16-ZMM31. See Section 13.13. In general,
bytes 64(i-16)+63:64(i-16) are used for ZMMi (for 16 ≤ i ≤ 31).
All three components of AVX-512 state are XSAVE-managed and the Intel AVX-512 feature is XSAVE-enabled. The
XSAVE feature set can operate on AVX-512 state only if the feature set is enabled (CR4.OSXSAVE = 1) and has
been configured to manage AVX-512 state (XCR0[7:5] = 111b). Intel AVX-512 instructions cannot be used unless
the XSAVE feature set is enabled and has been configured to manage AVX-512 state.
13.5.6 PT State
The register state used by Intel Processor Trace (PT state) comprises the following 9 MSRs: IA32_RTIT_CTL,
IA32_RTIT_OUTPUT_BASE, IA32_RTIT_OUTPUT_MASK_PTRS, IA32_RTIT_STATUS, IA32_RTIT_CR3_MATCH,
IA32_RTIT_ADDR0_A, IA32_RTIT_ADDR0_B, IA32_RTIT_ADDR1_A, and IA32_RTIT_ADDR1_B.1
As noted in Section 13.1, the XSAVE feature set manages PT state as supervisor state component 8. Thus, PT state
is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section 13.2,
CPUID.(EAX=0DH,ECX=8):EAX enumerates the size (in bytes) required for PT state. The MSRs are each allocated
8 bytes in the state component in the order given above. Thus, IA32_RTIT_CTL is at byte offset 0,
IA32_RTIT_OUTPUT_BASE at byte offset 8, etc. Any locations in the state component at or beyond byte offset 72
are reserved.
PT state is XSAVE-managed but Intel Processor Trace is not XSAVE-enabled. The XSAVE feature set can operate on
PT state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage PT state
(IA32_XSS[8] = 1). Software can otherwise use Intel Processor Trace and access its MSRs (using RDMSR and
WRMSR) even if the XSAVE feature set is not enabled or has not been configured to manage PT state.
The following items describe special treatment of PT state by the XSAVES and XRSTORS instructions:
• If XSAVES saves PT state, the instruction clears IA32_RTIT_CTL.TraceEn (bit 0) after saving the value of the
IA32_RTIT_CTL MSR and before saving any other PT state. If XSAVES causes a fault or a VM exit, it restores
IA32_RTIT_CTL.TraceEn to its original value.
• If XSAVES saves PT state, the instruction saves zeroes in the reserved portions of the state component.
• If XRSTORS would restore (or initialize) PT state and IA32_RTIT_CTL.TraceEn = 1, the instruction causes a
general-protection exception (#GP) before modifying PT state.
• If XRSTORS causes an exception or a VM exit, it does so before any modification to IA32_RTIT_CTL.TraceEn
(even if it has loaded other PT state).
13.5.7 PKRU State
The register state used by the protection-key feature (PKRU state) is the 32-bit PKRU register. As noted in Section
13.1, the XSAVE feature set manages PKRU state as user state component 9. Thus, PKRU state is located in the
extended region of the XSAVE area (see Section 13.4.3).
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=9):EBX enumerates the offset (in bytes, from the base of the
XSAVE area) of the section of the extended region of the XSAVE area used for PKRU state (when the standard
format of the extended region is used). CPUID.(EAX=0DH,ECX=9):EAX enumerates the size (in bytes) required for
PKRU state. The XSAVE feature set uses bytes 3:0 of the PK-state section for the PKRU register.
PKRU state is XSAVE-managed but the protection-key feature is not XSAVE-enabled. The XSAVE feature set can
operate on PKRU state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage
PKRU state (XCR0[9] = 1). Software can otherwise use protection keys and access PKRU state even if the XSAVE
feature set is not enabled or has not been configured to manage PKRU state.
1. These MSRs might not be supported by every processor that supports Intel Processor Trace. Software can use the CPUID instruction
to discover which are supported; see Section 33.3.1, “Detection of Intel Processor Trace and Capability Enumeration,” of Intel® 64
and IA-32 Architectures Software Developer’s Manual, Volume 3C.
Vol. 1
13-13
MANAGING STATE USING THE XSAVE FEATURE SET
The value of the PKRU register determines the access rights for user-mode linear addresses. (See Section 4.6,
“Access Rights,” of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A.) The access rights
that pertain to an execution of the XRSTOR and XRSTORS instructions are determined by the value of the register
before the execution and not by any value that the execution might load into the PKRU register.
13.5.8 PASID State
The register state used by the ENQCMD instruction and process address space identifiers (PASID state) comprises
the IA32_PASID MSR.
As noted in Section 13.1, the XSAVE feature set manages PASID state as supervisor state component 10. Thus,
PASID state is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section 13.2,
CPUID.(EAX=0DH,ECX=10):EAX enumerates the size (in bytes) required for PASID state. The IA32_PASID MSR is
allocated 8 bytes at byte offset 0 in the state component.
PASID state is XSAVE-managed but the ENQCMD instruction and process address space identifiers are not XSAVE-
enabled. The XSAVE feature set can operate on PASID state only if the feature set is enabled (CR4.OSXSAVE = 1)
and has been configured to manage PASID state (IA32_XSS[10] = 1). Software can otherwise use the ENQCMD
instruction and process address space identifiers, and access the IA32_PASID MSR (using RDMSR and WRMSR)
even if the XSAVE feature set is not enabled or has not been configured to manage PASID state.
13.5.9 CET State
The register state used by Control-Flow Enforcement Technology (CET) comprises the two 64-bit MSRs
(IA32_U_CET and IA32_PL3_SSP) that manage CET when CPL = 3 (CET_U state); and the three 64-bit MSRs
(IA32_PL0_SSP-IA32_PL2_SSP) that manage CET when CPL < 3 (CET_S state). Together, these two supervisor
state components compose CET state.1
As noted in Section 13.1, the XSAVE feature set manages CET state as supervisor state components 11-12. Thus,
CET state is located in the extended region of the XSAVE area (see Section 13.4.3). The following items detail how
these state components are organized in this region:
• CET_U state.
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=11):EAX enumerates the size (in bytes) required for CET_U
state. The CET_U section is used for the 64-bit MSRs IA32_U_CET and IA32_PL3_SSP, with bytes 7:0 being
used for IA32_U_CET and bytes 15:8 being used for IA32_PL3_SSP.
• CET_S state.
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=12):EAX enumerates the size (in bytes) required for CET_S
state. The CET_S section is used for the three 64-bit MSRs IA32_PL0_SSP-IA32_PL2_SSP, with bytes 8i+7:8i
being used for IA32_PLi_SSP.
The two components of CET state are XSAVE-managed and CET is not XSAVE-enabled. The XSAVE feature set can
operate on CET_U state (respectively, CET_S state) only if the feature set is enabled (CR4.OSXSAVE = 1) and has
been configured to manage CET_U state (respectively, CET_S state) by setting IA32_XSS[11] (respectively,
IA32_XSS[12]). Software can otherwise use CET and access the CET MSRs (using RDMSR and WRMSR) even if the
XSAVE feature set is not enabled or has not been configured to manage CET state.
13.5.10 HDC State
The register state used by hardware duty cycling (HDC state) comprises the IA32_PM_CTL1 MSR.
As noted in Section 13.1, the XSAVE feature set manages HDC state as supervisor state component 13. Thus, HDC
state is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section 13.2,
CPUID.(EAX=0DH,ECX=13):EAX enumerates the size (in bytes) required for HDC state. The IA32_PM_CTL1 MSR
is allocated 8 bytes at byte offset 0 in the state component.
1. The IA32_S_CET and IA32_INTERRUPT_SSP_TABLE_ADDR MSRs also control CET when CPL < 3. However, they are not managed by
the XSAVE feature set and are thus not considered in this chapter.
13-14
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
HDC state is XSAVE-managed but hardware duty cycling is not XSAVE-enabled. The XSAVE feature set can operate
on HDC state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage HDC state
(IA32_XSS[13] = 1). Software can otherwise use hardware duty cycling and access the IA32_PM_CTL1 MSR (using
RDMSR and WRMSR) even if the XSAVE feature set is not enabled or has not been configured to manage HDC state.
13.5.11 UINTR State
The register state used by user interrupts (UINTR state) comprises 48 bytes in memory with the following layout:
• Bytes 7:0 are for the IA32_UINTR_HANDLER MSR.
• Bytes 15:8 are for the IA32_UINTR_STACKADJUST MSR.
• Bytes 23:16 are for the IA32_UINTR_MISC MSR with exception of the last bit (bit 7 of byte 23), which is used
for UIF. (Because UIF is not part of the IA32_UINTR_MISC MSR, software that reads a value from bytes 23:16
should clear bit 63 of that 64-bit value before attempting to write it to the IA32_UINTR_MISC MSR.).
• Bytes 31:24 are for the IA32_UINTR_PD MSR.
• Bytes 39:32 are for the IA32_UINTR_RR MSR.
• Bytes 47:40 are for the IA32_UINTR_TT MSR.
As noted in Section 13.1, the XSAVE feature set manages UINTR state as supervisor state component 14. Thus,
UINTR state is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section 13.2,
CPUID.(EAX=0DH,ECX=14):EAX enumerates the size (in bytes) required for UINTR state.
UINTR state is XSAVE-managed but user interrupts are not XSAVE-enabled. The XSAVE feature set can operate on
UINTR state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage UINTR state
(IA32_XSS[14] = 1). Software can otherwise use user interrupts and access the MSRs (using RDMSR and WRMSR)
even if the XSAVE feature set is not enabled or has not been configured to manage UINTR state.
The management of the UINTR state component by XSAVES follows the architecture of the XSAVE feature set. The
following items identify points that are specific to saving the UINTR state component:
• XSAVES writes the user-interrupt registers to the user-interrupt state component using the format specified
above.
• XSAVES stores zeros to bits and bytes identified above as reserved.
• The values saved for the IA32_UINTR_HANDLER, IA32_UINTR_STACKADJUST, IA32_UINTR_PD, and
IA32_UINTR_TT MSRs are always canonical relative to the maximum linear-address width enumerated by
CPUID1.
• After saving the user-interrupt state component, XSAVES clears UINV. (UINV is IA32_UINTR_MISC[39:32];
XSAVES does not modify the remainder of that MSR.)
The management of the user-interrupt state component by XRSTORS follows the architecture of the XSAVE feature
set. The following items identify points that are specific to restoring the user-interrupt state component:
• Before restoring the user-interrupt state component, XRSTORS verifies that UINV is 0. If it is not, XRSTORS
causes a general-protection fault (#GP) before loading any part of the user-interrupt state component. (UINV
is IA32_UINTR_MISC[39:32]; XRSTORS does not check the contents of the remainder of that MSR.)
• If the instruction mask and XSAVE area used by XRSTORS indicates that the user-interrupt state component
should be loaded from the XSAVE area, XRSTORS reads the user-interrupt registers from the XSAVE area using
the format identified above. The values read cause a general-protection fault (#GP) in any of the following
cases:
- If the value to be loaded into any one of the IA32_UINTR_HANDLER, IA32_UINTR_STACKADJUST,
IA32_UINTR_PD, or IA32_UINTR_TT MSRs is not canonical relative to the maximum linear-address width
enumerated by CPUID.
- If the value to be loaded into the IA32_UINTR_MISC MSR sets any of bits 62:40. These bits are reserved in
the MSR. (Bit 63 is also reserved in the MSR, but the XSAVE feature set uses bit 63 of this value for UIF.)
1. They might not be canonical relative to the current paging mode if it supports only smaller linear addresses.
Vol. 1
13-15
MANAGING STATE USING THE XSAVE FEATURE SET
- If the value to be loaded into the IA32_UINTR_ PD MSR sets any of bits 5:0. These bits are reserved in the
MSR.
- If the value to be loaded into the IA32_UINTR_ TT MSR sets any of bits 3:1. These bits are reserved in the
MSR.
• If XRSTORS causes a fault or a VM exit after loading any part of the user-interrupt state component, XRSTORS
clears UINV before delivering the fault or VM exit. (Other elements of user-interrupt state, including other parts
of the IA32_UINTR_MISC MSR, may retain the values that were loaded by XRSTORS.)
• After an execution of XRSTORS that loads the user-interrupt state component, the logical processor recognizes
a pending user interrupt if and only if some bit is set in the IA32_UINTR_RR MSR (see Section 7.4.1 in the
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A).
13.5.12 LBR State
The register state used by last-branch records (LBR state) comprises 101 MSRs organized as follows:
IA32_LBR_CTL; IA32_LBR_DEPTH; IA32_LER_FROM_IP; IA32_LER_TO_IP; IA32_LER_INFO; and 32 triples of
MSRs, IA32_LBR_i_FROM_IP, IA32_LBR_i_TO_IP, IA32_LBR_i_INFO, for each value of i, 0 ≤ i ≤ 31.
As noted in Section 13.1, the XSAVE feature set manages LBR state as supervisor state component 15. Thus, LBR
state is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section 13.2,
CPUID.(EAX=0DH,ECX=15):EAX enumerates the size (in bytes) required for LBR state. The IA32_LBR_CTL MSR is
allocated 8 bytes at byte offset 0 in the state component. The remaining MSRs are each allocated 8 bytes in the
state component in the order given above. Thus, IA32_LBR_DEPTH is at byte offset 8, … , IA32_LBR_0_FROM_IP
at byte offset 40, IA32_LBR_0_TO_IP at byte offset 48, IA32_LBR_0_INFO at byte offset 56,
IA32_LBR_1_FROM_IP at byte offset 64, …, and IA32_LBR_31_INFO at byte offset 800. Any locations in the state
component at or beyond byte offset 808 are reserved.
LBR state is XSAVE-managed but LBRs are not XSAVE-enabled. The XSAVE feature set can operate on LBR state
only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage LBR state
(IA32_XSS[15] = 1). Software can otherwise use LBRs and access the MSRs (using RDMSR and WRMSR) even if
the XSAVE feature set is not enabled or has not been configured to manage LBR state.
The following items describe special treatment of LBR state by the XSAVES and XRSTORS instructions:
• If XSAVES would save LBR state and that state is not in its initial configuration (see Section 13.6), the
instruction always saves IA32_LBR_CTL, IA32_LBR_DEPTH, IA32_LER_FROM_IP, IA32_LER_TO_IP, and
IA32_LER_INFO. It saves the triples IA32_LBR_i_FROM_IP, IA32_LBR_i_TO_IP, IA32_LBR_i_INFO, for each
value of i, 0 ≤ i < D, where D is the value of IA32_LBR_DEPTH. It will not save the values of the remaining
triples, although it may access the corresponding fields in the XSAVE area.
• If XSAVES would save LBR state and that state is in its initial configuration, the instruction does not save any
LBR state and will not access that component of the XSAVE area.
• If XRSTORS would initialize LBR state, IA32_LBR_DEPTH is not modified and zero is written to the other MSRs
that compose LBR state.
• If XRSTORS would restore LBR state, behavior depends on the current value of IA32_LBR_DEPTH and the value
of corresponding field in the XSAVE area:
- If the current value of IA32_LBR_DEPTH equals the value of corresponding field in the XSAVE area, the
instruction restores IA32_LBR_CTL, IA32_LER_FROM_IP, IA32_LER_TO_IP, IA32_LER_INFO, and the
triples IA32_LBR_i_FROM_IP, IA32_LBR_i_TO_IP, IA32_LBR_i_INFO, for each value of i, 0 ≤ i < D, where
D is the value of IA32_LBR_DEPTH. It will not restore the values of the remaining triples, although it may
access the corresponding fields in the XSAVE area.
- If the IA32_LBR_DEPTH field in the XSAVE area sets any reserved bits, the instruction causes a general-
protection exception (#GP).
- If neither of the previous items apply, the instruction restores IA32_LBR_CTL, IA32_LER_FROM_IP,
IA32_LER_TO_IP, and IA32_LER_INFO, but it writes zero to the triples IA32_LBR_i_FROM_IP,
IA32_LBR_i_TO_IP, IA32_LBR_i_INFO, for each value of i, 0 ≤ i ≤ 31. Such an execution does not modify
XINUSE[15] (see Section 13.6 and Section 13.12).
13-16
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
13.5.13 HWP State
The register state used by hardware P-states (HWP state) comprises the IA32_HWP_REQUEST MSR.
As noted in Section 13.1, the XSAVE feature set manages HWP state as supervisor state component 16. Thus, HWP
state is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section 13.2,
CPUID.(EAX=0DH,ECX=16):EAX enumerates the size (in bytes) required for HWP state. The IA32_HWP_REQUEST
MSR is allocated 8 bytes at byte offset 0 in the state component.
HWP state is XSAVE-managed but the hardware P-states feature is not XSAVE-enabled. The XSAVE feature set can
operate on HWP state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage
HWP state (IA32_XSS[16] = 1). Software can otherwise use hardware P-states and access the
IA32_HWP_REQUEST MSR (using RDMSR and WRMSR) even if the XSAVE feature set is not enabled or has not
been configured to manage HWP state.
13.5.14 AMX State
The register state used by the Intel® Advanced Matrix Extensions (Intel AMX) comprises two state components,
TILECFG and TILEDATA. Together, these two state components compose AMX state.
As noted in Section 13.1, the XSAVE feature set manages AMX state as state components 17-18. Thus, AMX state
is located in the extended region of the XSAVE area (see Section 13.4.3). The following items detail how these
state components are organized in this region:
• TILECFG state.
As noted in Section 13.1, the XSAVE feature set manages TILECFG state as user state component 17. Thus,
TILECFG state is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section
13.2, CPUID.(EAX=0DH,ECX=17):EAX enumerates the size (in bytes) required for TILECFG state.
• TILEDATA state.
As noted in Section 13.1, the XSAVE feature set manages TILEDATA state as user state component 18. Thus,
TILEDATA state is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section
13.2, CPUID.(EAX=0DH,ECX=18):EAX enumerates the size (in bytes) required for TILEDATA state.
Both components of AMX state are XSAVE-managed, and the AMX feature is XSAVE-enabled. The XSAVE feature
set can operate on AMX state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to
manage AMX state (XCR0[18:17] = 11b). Intel AMX instructions cannot be used unless the XSAVE feature set is
enabled and has been configured to manage AMX state.
The following items describe special treatment of TILECFG and TILEDATA by the XSAVE feature set:
• Loading of TILECFG and TILEDATA by XRSTOR and XRSTORS:
- While the LDTILECFG instruction generates a general-protection fault (#GP) if it would load the TILECFG
register with an unsupported value executions of XRSTOR and XRSTORS do not do so. Instead, they
initialize the register (resulting in TILES_CONFIGURED = 0).
While executions of LDTILECFG initialize TILEDATA, executions of XRSTOR and XRSTORS do not modify
TILEDATA unless loading it from memory.
While the value of the TILECFG register can limit how Intel AMX instructions access TILEDATA, such
limitations do not apply to XRSTOR and XRSTORS. An execution of either of those instructions loads all 8
KBytes of TILEDATA regardless of the value in the TILECFG register (or the value that the instruction may
be loading into that register).
• Saving of TILEDATA by XSAVE, XSAVEC, XSAVEOPT, and XSAVES:
- While the value of the TILECFG register can limit how Intel AMX instructions access TILEDATA, such
limitations do not apply to XSAVE, XSAVEC, XSAVEOPT, and XSAVES. An execution of any of those instruc-
tions saves all 8 KBytes of TILEDATA regardless of the value in the TILECFG register.
Vol. 1
13-17
MANAGING STATE USING THE XSAVE FEATURE SET
13.6
PROCESSOR TRACKING OF XSAVE-MANAGED STATE
The XSAVEOPT, XSAVEC, and XSAVES instructions use two optimizations to reduce the amount of data that they
write to memory. They avoid writing data for any state component known to be in its initial configuration (the init
optimization). In addition, if either XSAVEOPT or XSAVES is using the same XSAVE area as that used by the most
recent execution of XRSTOR or XRSTORS, it may avoid writing data for any state component whose configuration
is known not to have been modified since then (the modified optimization). (XSAVE does not use these optimi-
zations, and XSAVEC does not use the modified optimization.) The operation of XSAVEOPT, XSAVEC, and XSAVES
are described in more detail in Section 13.9 through Section 13.11.
A processor can support the init and modified optimizations with special hardware that tracks the state components
that might benefit from those optimizations. Other implementations might not include such hardware; such a
processor would always consider each such state component as not in its initial configuration and as modified since
the last execution of XRSTOR or XRSTORS.
The following notation describes the state of the init and modified optimizations:
• XINUSE denotes the state-component bitmap corresponding to the init optimization. If XINUSE[i] = 0, state
component i is known to be in its initial configuration; otherwise XINUSE[i] = 1. It is possible for XINUSE[i] to
be 1 even when state component i is in its initial configuration. On a processor that does not support the init
optimization, XINUSE[i] is always 1 for every value of i.
Executing XGETBV with ECX = 1 returns in EDX:EAX the logical-AND of XCR0 and the current value of the
XINUSE state-component bitmap. Such an execution of XGETBV always sets EAX[1] to 1 if XCR0[1] = 1 and
MXCSR does not have its RESET value of 1F80H. Section 13.2 explains how software can determine whether a
processor supports this use of XGETBV.
• XMODIFIED denotes the state-component bitmap corresponding to the modified optimization. If
XMODIFIED[i] = 0, state component i is known not to have been modified since the most recent execution of
XRSTOR or XRSTORS; otherwise XMODIFIED[i] = 1. It is possible for XMODIFIED[i] to be 1 even when state
component i has not been modified since the most recent execution of XRSTOR or XRSTORS. On a processor
that does not support the modified optimization, XMODIFIED[i] is always 1 for every value of i.
A processor that implements the modified optimization saves information about the most recent execution of
XRSTOR or XRSTORS in a quantity called XRSTOR_INFO, a 4-tuple containing the following: (1) the CPL;
(2) whether the logical processor was in VMX non-root operation; (3) the linear address of the XSAVE area; and
(4) the XCOMP_BV field in the XSAVE area. An execution of XSAVEOPT or XSAVES uses the modified optimization
only if that execution corresponds to XRSTOR_INFO on these four parameters.
This mechanism implies that, depending on details of the operating system, the processor might determine that an
execution of XSAVEOPT by one user application corresponds to an earlier execution of XRSTOR by a different appli-
cation. For this reason, Intel recommends the application software not use the XSAVEOPT instruction.
The following items specify the initial configuration each state component (for the purposes of defining the XINUSE
bitmap):
• x87 state. x87 state is in its initial configuration if the following all hold: FCW is 037FH; FSW is 0000H; FTW is
FFFFH; FCS and FDS are each 0000H; FIP and FDP are each 00000000_00000000H; each of ST0-ST7 is
0000_00000000_00000000H.
• SSE state. In 64-bit mode, SSE state is in its initial configuration if each of XMM0-XMM15 is 0. Outside 64-bit
mode, SSE state is in its initial configuration if each of XMM0-XMM7 is 0. XINUSE[1] pertains only to the state
of the XMM registers and not to MXCSR. An execution of XRSTOR or XRSTORS outside 64-bit mode does not
update XMM8-XMM15. (See Section 13.13.)
• AVX state. In 64-bit mode, AVX state is in its initial configuration if each of YMM0_H-YMM15_H is 0. Outside
64-bit mode, AVX state is in its initial configuration if each of YMM0_H-YMM7_H is 0. An execution of XRSTOR
or XRSTORS outside 64-bit mode does not update YMM8_H-YMM15_H. (See Section 13.13.)
• BNDREGS state. BNDREGS state is in its initial configuration if the value of each of BND0-BND3 is 0.
• BNDCSR state. BNDCSR state is in its initial configuration if BNDCFGU and BNDCSR each has value 0.
• Opmask state. Opmask state is in its initial configuration if each of the opmask registers k0-k7 is 0.
• ZMM_Hi256 state. In 64-bit mode, ZMM_Hi256 state is in its initial configuration if each of ZMM0_H-
ZMM15_H is 0. Outside 64-bit mode, ZMM_Hi256 state is in its initial configuration if each of ZMM0_H-ZMM7_H
13-18
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
is 0. An execution of XRSTOR or XRSTORS outside 64-bit mode does not update ZMM8_H-ZMM15_H. (See
Section 13.13.)
• Hi16_ZMM state. In 64-bit mode, Hi16_ZMM state is in its initial configuration if each of ZMM16-ZMM31 is 0.
Outside 64-bit mode, Hi16_ZMM state is always in its initial configuration. An execution of XRSTOR or XRSTORS
outside 64-bit mode does not update ZMM31-ZMM31. (See Section 13.13.)
• PT state. PT state is in its initial configuration if each of the 9 MSRs is 0.
• PKRU state. PKRU state is in its initial configuration if the value of the PKRU is 0.
• PASID state. PASID state is in its initial configuration if the value of the IA32_PASID MSR is 0.
• CET_U state. CET_U state is in its initial configuration if both of the MSRs are 0.
• CET_S state. CET_S state is in its initial configuration if each of the three MSRs is 0.
• HDC state. HDC state is in its initial configuration if the value of the IA32_PM_CTL1 MSR is 1.
• UINTR state. UINTR state is in its initial configuration if all user-interrupt registers (including UIF) are zero.
• LBR state. LBR state is in its initial configuration if the value of each of the MSRs is 0, with the exception of
IA32_LBR_DEPTH. XINUSE[15] does not pertain to IA32_LBR_DEPTH.
• HWP state. HWP state is in its initial configuration if the value of the IA32_HWP_REQUEST MSR is 8000FF01H.
• AMX state. AMX state is in its initial configuration if the TILECFG register is zero and all tile data are zero.
13.7
OPERATION OF XSAVE
The XSAVE instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction
mask. The logical-AND of XCR0 and the instruction mask is the requested-feature bitmap (RFBM) of the user
state components to be saved.
The following conditions cause execution of the XSAVE instruction to generate a fault:
• If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs.
• If CR0.TS[bit 3] is 1, a device-not-available exception (#NM) occurs.
• If the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP) occurs.1
If none of these conditions cause a fault, execution of XSAVE reads the XSTATE_BV field of the XSAVE header (see
Section 13.4.2) and writes it back to memory, setting XSTATE_BV[i] (0 ≤ i ≤ 63) as follows:
• If RFBM[i] = 0, XSTATE_BV[i] is not changed.
• If RFBM[i] = 1, XSTATE_BV[i] is set to the value of XINUSE[i]. Section 13.6 defines XINUSE to describe the
processor init optimization and specifies the initial configuration of each state component. The nature of that
optimization implies the following:
- If state component i is in its initial configuration, XINUSE[i] may be either 0 or 1, and XSTATE_BV[i] may
be written with either 0 or 1.
XINUSE[1] pertains only to the state of the XMM registers and not to MXCSR. Thus, XSTATE_BV[1] may be
written with 0 even if MXCSR does not have its RESET value of 1F80H.
- If state component i is not in its initial configuration, XINUSE[i] = 1 and XSTATE_BV[i] is written with 1.
(As explained in Section 13.6, the initial configurations of some state components may depend on whether the
processor is in 64-bit mode.)
The XSAVE instruction does not write any part of the XSAVE header other than the XSTATE_BV field; in particular,
it does not write to the XCOMP_BV field.
Execution of XSAVE saves into the XSAVE area those state components corresponding to bits that are set in RFBM.
State components 0 and 1 are located in the legacy region of the XSAVE area (see Section 13.4.1). Each state
component i, 2 ≤ i ≤ 62, is located in the extended region; the XSAVE instruction always uses the standard format
for the extended region (see Section 13.4.3).
1. If CR0.AM = 1, CPL = 3, and EFLAGS.AC =1, an alignment-check exception (#AC) may occur instead of #GP.
Vol. 1
13-19
MANAGING STATE USING THE XSAVE FEATURE SET
The MXCSR register and MXCSR_MASK are part of SSE state (see Section 13.5.2) and are thus associated with
RFBM[1]. However, the XSAVE instruction also saves these values when RFBM[2] = 1 (even if RFBM[1] = 0).
See Section 13.5 for specifics for each state component and for details regarding mode-specific operation and
operation determined by instruction prefixes. See Section 13.13 for details regarding faults caused by memory
accesses.
13.8
OPERATION OF XRSTOR
The XRSTOR instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction
mask. The logical-AND of XCR0 and the instruction mask is the requested-feature bitmap (RFBM) of the user
state components to be restored.
The following conditions cause execution of the XRSTOR instruction to generate a fault:
• If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs.
• If CR0.TS[bit 3] is 1, a device-not-available exception (#NM) occurs.
• If the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP) occurs.1
After checking for these faults, the XRSTOR instruction reads the XCOMP_BV field in the XSAVE area’s XSAVE
header (see Section 13.4.2). If XCOMP_BV[63] = 0, the standard form of XRSTOR is executed (see Section
13.8.1); otherwise, the compacted form of XRSTOR is executed (see Section 13.8.2).2
See Section 13.2 for details of how to determine whether the compacted form of XRSTOR is supported.
13.8.1 Standard Form of XRSTOR
The standard from of XRSTOR performs additional fault checking. Either of the following conditions causes a
general-protection exception (#GP):
• The XSTATE_BV field of the XSAVE header sets a bit that is not set in XCR0.
• Bytes 23:8 of the XSAVE header are not all 0 (this implies that all bits in XCOMP_BV are 0).3
If none of these conditions cause a fault, the processor updates each state component i for which RFBM[i] = 1.
XRSTOR updates state component i based on the value of bit i in the XSTATE_BV field of the XSAVE header:
• If XSTATE_BV[i] = 0, the state component is set to its initial configuration. Section 13.6 specifies the initial
configuration of each state component.
The initial configuration of state component 1 pertains only to the XMM registers and not to MXCSR. See below
for the treatment of MXCSR
• If XSTATE_BV[i] = 1, the state component is loaded with data from the XSAVE area. See Section 13.5 for
specifics for each state component and for details regarding mode-specific operation and operation determined
by instruction prefixes. See Section 13.13 for details regarding faults caused by memory accesses.
State components 0 and 1 are located in the legacy region of the XSAVE area (see Section 13.4.1). Each state
component i, 2 ≤ i ≤ 62, is located in the extended region; the standard form of XRSTOR uses the standard
format for the extended region (see Section 13.4.3).
The MXCSR register is part of state component 1, SSE state (see Section 13.5.2). However, the standard form of
XRSTOR loads the MXCSR register from memory whenever the RFBM[1] (SSE) or RFBM[2] (AVX) is set, regardless
1. If CR0.AM = 1, CPL = 3, and EFLAGS.AC =1, an alignment-check exception (#AC) may occur instead of #GP.
2. If the processor does not support the compacted form of XRSTOR, it may execute the standard form of XRSTOR without first read-
ing the XCOMP_BV field. A processor supports the compacted form of XRSTOR only if it enumerates
CPUID.(EAX=0DH,ECX=1):EAX[1] as 1.
3. Bytes 63:24 of the XSAVE header are also reserved. Software should ensure that bytes 63:16 of the XSAVE header are all 0 in any
XSAVE area. (Bytes 15:8 should also be 0 if the XSAVE area is to be used on a processor that does not support the compaction
extensions to the XSAVE feature set.)
13-20
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
of the values of XSTATE_BV[1] and XSTATE_BV[2]. The standard form of XRSTOR causes a general-protection
exception (#GP) if it would load MXCSR with an illegal value.
13.8.2 Compacted Form of XRSTOR
The compacted from of XRSTOR performs additional fault checking. Any of the following conditions causes a #GP:
• The XCOMP_BV field of the XSAVE header sets a bit in the range 62:0 that is not set in XCR0.
• The XSTATE_BV field of the XSAVE header sets a bit (including bit 63) that is not set in XCOMP_BV.
• Bytes 63:16 of the XSAVE header are not all 0.
If none of these conditions cause a fault, the processor updates each state component i for which RFBM[i] = 1.
XRSTOR updates state component i based on the value of bit i in the XSTATE_BV field of the XSAVE header:
• If XSTATE_BV[i] = 0, the state component is set to its initial configuration. Section 13.6 specifies the initial
configuration of each state component.
If XSTATE_BV[1] = 0, the compacted form XRSTOR initializes MXCSR to 1F80H. (This differs from the standard
from of XRSTOR, which loads MXCSR from the XSAVE area whenever either RFBM[1] or RFBM[2] is set.)
State component i is set to its initial configuration as indicated above if RFBM[i] = 1 and XSTATE_BV[i] = 0 -
even if XCOMP_BV[i] = 0. This is true for all values of i, including 0 (x87 state) and 1 (SSE state).
• If XSTATE_BV[i] = 1, the state component is loaded with data from the XSAVE area.1 See Section 13.5 for
specifics for each state component and for details regarding mode-specific operation and operation determined
by instruction prefixes. See Section 13.13 for details regarding faults caused by memory accesses.
State components 0 and 1 are located in the legacy region of the XSAVE area (see Section 13.4.1). Each state
component i, 2 ≤ i ≤ 62, is located in the extended region; the compacted form of the XRSTOR instruction uses
the compacted format for the extended region (see Section 13.4.3).
The MXCSR register is part of SSE state (see Section 13.5.2) and is thus loaded from memory if RFBM[1] =
XSTATE_BV[i] = 1. The compacted form of XRSTOR does not consider RFBM[2] (AVX) when determining whether
to update MXCSR. (This is a difference from the standard form of XRSTOR.) The compacted form of XRSTOR causes
a general-protection exception (#GP) if it would load MXCSR with an illegal value.
13.8.3 XRSTOR and the Init and Modified Optimizations
Execution of the XRSTOR instruction causes the processor to update its tracking for the init and modified optimiza-
tions (see Section 13.6). The following items provide details:
• The processor updates its tracking for the init optimization as follows:
- If RFBM[i] = 0, XINUSE[i] is not changed.
- If RFBM[i] = 1 and XSTATE_BV[i] = 0, state component i may be tracked as init; XINUSE[i] may be set to
0 or 1. (As noted in Section 13.6, a processor need not implement the init optimization for state component
i; a processor that does not do so implicitly maintains XINUSE[i] = 1 at all times.)
- If RFBM[i] = 1 and XSTATE_BV[i] = 1, state component i is tracked as not init; XINUSE[i] is set to 1.
• The processor updates its tracking for the modified optimization and records information about the XRSTOR
execution for future interaction with the XSAVEOPT and XSAVES instructions (see Section 13.9 and Section
13.11) as follows:
- If RFBM[i] = 0, state component i is tracked as modified; XMODIFIED[i] is set to 1.
- If RFBM[i] = 1, state component i may be tracked as unmodified; XMODIFIED[i] may be set to 0 or 1. (As
noted in Section 13.6, a processor need not implement the modified optimization for state component i; a
processor that does not do so implicitly maintains XMODIFIED[i] = 1 at all times.)
1. Earlier fault checking ensured that, if the instruction has reached this point in execution and XSTATE_BV[i] is 1, then XCOMP_BV[i] is
also 1.
Vol. 1
13-21
MANAGING STATE USING THE XSAVE FEATURE SET
- XRSTOR_INFO is set to the 4-tuple w,x,y,z, where w is the CPL (0); x is 1 if the logical processor is in VMX
non-root operation and 0 otherwise; y is the linear address of the XSAVE area; and z is XCOMP_BV. In
particular, the standard form of XRSTOR always sets z to all zeroes, while the compacted form of XRSTORS
never does so (because it sets at least bit 63 to 1).
Note that, if RFBM is entirely zero (e.g., because the instruction mask in EDX:EAX is zero), no state components are
modified, the XINUSE bitmap is not modified, and all bits are set in the XMODIFIED bitmap. Thus, if EDX:EAX was
zero for the most recent execution of XRSTOR, an execution of XSAVEOPT or XSAVES will identify all state compo-
nents as modified and will thus not use the modified optimization.
13.9
OPERATION OF XSAVEOPT
The operation of XSAVEOPT is similar to that of XSAVE. Unlike XSAVE, XSAVEOPT uses the init optimization (by
which it may omit saving state components that are in their initial configuration) and the modified optimization (by
which it may omit saving state components that have not been modified since the last execution of XRSTOR); see
Section 13.6. See Section 13.2 for details of how to determine whether XSAVEOPT is supported.
The XSAVEOPT instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction
mask. The logical (bitwise) AND of XCR0 and the instruction mask is the requested-feature bitmap (RFBM) of
the user state components to be saved.
The following conditions cause execution of the XSAVEOPT instruction to generate a fault:
• If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs.
• If CR0.TS[bit 3] is 1, a device-not-available exception (#NM) occurs.
• If the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP) occurs.1
If none of these conditions cause a fault, execution of XSAVEOPT reads the XSTATE_BV field of the XSAVE header
(see Section 13.4.2) and writes it back to memory, setting XSTATE_BV[i] (0 ≤ i ≤ 63) as follows:
• If RFBM[i] = 0, XSTATE_BV[i] is not changed.
• If RFBM[i] = 1, XSTATE_BV[i] is set to the value of XINUSE[i]. Section 13.6 defines XINUSE to describe the
processor init optimization and specifies the initial configuration of each state component. The nature of that
optimization implies the following:
- If the state component is in its initial configuration, XINUSE[i] may be either 0 or 1, and XSTATE_BV[i] may
be written with either 0 or 1.
XINUSE[1] pertains only to the state of the XMM registers and not to MXCSR. Thus, XSTATE_BV[1] may be
written with 0 even if MXCSR does not have its RESET value of 1F80H.
- If the state component is not in its initial configuration, XSTATE_BV[i] is written with 1.
(As explained in Section 13.6, the initial configurations of some state components may depend on whether the
processor is in 64-bit mode.)
The XSAVEOPT instruction does not write any part of the XSAVE header other than the XSTATE_BV field; in partic-
ular, it does not write to the XCOMP_BV field.
Execution of XSAVEOPT saves into the XSAVE area those state components corresponding to bits that are set in
RFBM (subject to the optimizations described below). State components 0 and 1 are located in the legacy region of
the XSAVE area (see Section 13.4.1). Each state component i, 2 ≤ i ≤ 62, is located in the extended region; the
XSAVEOPT instruction always uses the standard format for the extended region (see Section 13.4.3).
See Section 13.5 for specifics for each state component and for details regarding mode-specific operation and
operation determined by instruction prefixes. See Section 13.13 for details regarding faults caused by memory
accesses.
Execution of XSAVEOPT performs two optimizations that reduce the amount of data written to memory:
1. If CR0.AM = 1, CPL = 3, and EFLAGS.AC =1, an alignment-check exception (#AC) may occur instead of #GP.
13-22
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
• Init optimization.
If XINUSE[i] = 0, state component i is not saved to the XSAVE area (even if RFBM[i] = 1). (See below for
exceptions made for MXCSR.)
• Modified optimization.
Each execution of XRSTOR and XRSTORS establishes XRSTOR_INFO as a 4-tuple w,x,y,z (see Section 13.8.3
and Section 13.12). Execution of XSAVEOPT uses the modified optimization only if the following all hold for the
current value of XRSTOR_INFO:
- w = CPL;
- x = 1 if and only if the logical processor is in VMX non-root operation;
- y is the linear address of the XSAVE area being used by XSAVEOPT; and
- z is 00000000_00000000H. (This last item implies that XSAVEOPT does not use the modified optimization
if the last execution of XRSTOR used the compacted form, or if an execution of XRSTORS followed the last
execution of XRSTOR.)
If XSAVEOPT uses the modified optimization and XMODIFIED[i] = 0 (see Section 13.6), state component i is
not saved to the XSAVE area.
(In practice, the benefit of the modified optimization for state component i depends on how the processor is
tracking state component i; see Section 13.6. Limitations on the tracking ability may result in state component
i being saved even though is in the same configuration that was loaded by the previous execution of XRSTOR.)
Depending on details of the operating system, an execution of XSAVEOPT by a user application might use the
modified optimization when the most recent execution of XRSTOR was by a different application. Because of
this, Intel recommends the application software not use the XSAVEOPT instruction.
The MXCSR register and MXCSR_MASK are part of SSE state (see Section 13.5.2) and are thus associated with
bit 1 of RFBM. However, the XSAVEOPT instruction also saves these values when RFBM[2] = 1 (even if RFBM[1] =
0). The init and modified optimizations do not apply to the MXCSR register and MXCSR_MASK.
13.10 OPERATION OF XSAVEC
The operation of XSAVEC is similar to that of XSAVE. Two main differences are (1) XSAVEC uses the compacted
format for the extended region of the XSAVE area; and (2) XSAVEC uses the init optimization (see Section 13.6).
Unlike XSAVEOPT, XSAVEC does not use the modified optimization. See Section 13.2 for details of how to deter-
mine whether XSAVEC is supported.
The XSAVEC instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction
mask. The logical (bitwise) AND of XCR0 and the instruction mask is the requested-feature bitmap (RFBM) of
the user state components to be saved.
The following conditions cause execution of the XSAVEC instruction to generate a fault:
• If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs.
• If CR0.TS[bit 3] is 1, a device-not-available exception (#NM) occurs.
• If the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP) occurs.1
If none of these conditions cause a fault, execution of XSAVEC writes the XSTATE_BV field of the XSAVE header
(see Section 13.4.2), setting XSTATE_BV[i] (0 ≤ i ≤ 63) as follows:2
• If RFBM[i] = 0, XSTATE_BV[i] is written as 0.
• If RFBM[i] = 1, XSTATE_BV[i] is set to the value of XINUSE[i] (see below for an exception made for
XSTATE_BV[1]). Section 13.6 defines XINUSE to describe the processor init optimization and specifies the
initial configuration of each state component. The nature of that optimization implies the following:
- If state component i is in its initial configuration, XSTATE_BV[i] may be written with either 0 or 1.
1. If CR0.AM = 1, CPL = 3, and EFLAGS.AC =1, an alignment-check exception (#AC) may occur instead of #GP.
2. Unlike the XSAVE and XSAVEOPT instructions, the XSAVEC instruction does not read the XSTATE_BV field of the XSAVE header.
Vol. 1
13-23
MANAGING STATE USING THE XSAVE FEATURE SET
- If state component i is not in its initial configuration, XSTATE_BV[i] is written with 1.
XINUSE[1] pertains only to the state of the XMM registers and not to MXCSR. However, if RFBM[1] = 1 and
MXCSR does not have the value 1F80H, XSAVEC writes XSTATE_BV[1] as 1 even if XINUSE[1] = 0.
(As explained in Section 13.6, the initial configurations of some state components may depend on whether the
processor is in 64-bit mode.)
The XSAVEC instructions sets bit 63 of the XCOMP_BV field of the XSAVE header while writing RFBM[62:0] to
XCOMP_BV[62:0]. The XSAVEC instruction does not write any part of the XSAVE header other than the XSTATE_BV
and XCOMP_BV fields.
Execution of XSAVEC saves into the XSAVE area those state components corresponding to bits that are set in RFBM
(subject to the init optimization described below). State components 0 and 1 are located in the legacy region of the
XSAVE area (see Section 13.4.1). Each state component i, 2 ≤ i ≤ 62, is located in the extended region; the XSAVEC
instruction always uses the compacted format for the extended region (see Section 13.4.3).
See Section 13.5 for specifics for each state component and for details regarding mode-specific operation and
operation determined by instruction prefixes. See Section 13.13 for details regarding faults caused by memory
accesses.
Execution of XSAVEC performs the init optimization to reduce the amount of data written to memory. If
XINUSE[i] = 0, state component i is not saved to the XSAVE area (even if RFBM[i] = 1). However, if RFBM[1] = 1
and MXCSR does not have the value 1F80H, XSAVEC saves all of state component 1 (SSE - including the XMM
registers) even if XINUSE[1] = 0. Unlike the XSAVE instruction, RFBM[2] does not determine whether XSAVEC
saves MXCSR and MXCSR_MASK.
13.11 OPERATION OF XSAVES
The operation of XSAVES is similar to that of XSAVEC. The main differences are (1) XSAVES can be executed only
if CPL = 0; (2) XSAVES can operate on the state components whose bits are set in XCR0 | IA32_XSS and can thus
operate on supervisor state components; and (3) XSAVES uses the modified optimization (see Section 13.6). See
Section 13.2 for details of how to determine whether XSAVES is supported.
The XSAVES instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction
mask. EDX:EAX & (XCR0 | IA32_XSS) (the logical AND the instruction mask with the logical OR of XCR0 and
IA32_XSS) is the requested-feature bitmap (RFBM) of the state components to be saved.
The following conditions cause execution of the XSAVES instruction to generate a fault:
• If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs.
• If CR0.TS[bit 3] is 1, a device-not-available exception (#NM) occurs.
• If CPL > 0 or if the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP)
occurs.
If none of these conditions cause a fault, execution of XSAVES writes the XSTATE_BV field of the XSAVE header
(see Section 13.4.2), setting XSTATE_BV[i] (0 ≤ i ≤ 63) as follows:
• If RFBM[i] = 0, XSTATE_BV[i] is written as 0.
• If RFBM[i] = 1, XSTATE_BV[i] is set to the value of XINUSE[i] (see below for an exception made for
XSTATE_BV[1]). Section 13.6 defines XINUSE to describe the processor init optimization and specifies the
initial configuration of each state component. The nature of that optimization implies the following:
- If state component i is in its initial configuration, XSTATE_BV[i] may be written with either 0 or 1.
- If state component i is not in its initial configuration, XSTATE_BV[i] is written with 1.
XINUSE[1] pertains only to the state of the XMM registers and not to MXCSR. However, if RFBM[1] = 1 and
MXCSR does not have the value 1F80H, XSAVES writes XSTATE_BV[1] as 1 even if XINUSE[1] = 0.
(As explained in Section 13.6, the initial configurations of some state components may depend on whether the
processor is in 64-bit mode.)
13-24
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
The XSAVES instructions sets bit 63 of the XCOMP_BV field of the XSAVE header while writing RFBM[62:0] to
XCOMP_BV[62:0]. The XSAVES instruction does not write any part of the XSAVE header other than the XSTATE_BV
and XCOMP_BV fields.
Execution of XSAVES saves into the XSAVE area those state components corresponding to bits that are set in RFBM
(subject to the optimizations described below). State components 0 and 1 are located in the legacy region of the
XSAVE area (see Section 13.4.1). Each state component i, 2 ≤ i ≤ 62, is located in the extended region; the XSAVES
instruction always uses the compacted format for the extended region (see Section 13.4.3).
See Section 13.5 for specifics for each state component and for details regarding mode-specific operation and
operation determined by instruction prefixes; in particular, see Section 13.5.6, Section 13.5.11, Section 13.5.12,
and Section 13.5.14 for special treatment by XSAVES of PT state, UINTR state, LBR state, and AMX state, respec-
tively. See Section 13.13 for details regarding faults caused by memory accesses.
Execution of XSAVES performs the init optimization to reduce the amount of data written to memory. If
XINUSE[i] = 0, state component i is not saved to the XSAVE area (even if RFBM[i] = 1). However, if RFBM[1] = 1
and MXCSR does not have the value 1F80H, XSAVES saves all of state component 1 (SSE - including the XMM
registers) even if XINUSE[1] = 0.
Like XSAVEOPT, XSAVES may perform the modified optimization. Each execution of XRSTOR and XRSTORS estab-
lishes XRSTOR_INFO as a 4-tuple w,x,y,z (see Section 13.8.3 and Section 13.12). Execution of XSAVES uses the
modified optimization only if the following all hold:
• w = CPL;
• x = 1 if and only if the logical processor is in VMX non-root operation;
• y is the linear address of the XSAVE area being used by XSAVEOPT; and
• z[63] is 1 and z[62:0] = RFBM[62:0]. (This last item implies that XSAVES does not use the modified optimi-
zation if the last execution of XRSTOR used the standard form and followed the last execution of XRSTORS.)
If XSAVES uses the modified optimization and XMODIFIED[i] = 0 (see Section 13.6), state component i is not
saved to the XSAVE area.
13.12 OPERATION OF XRSTORS
The operation of XRSTORS is similar to that of XRSTOR. Three main differences are (1) XRSTORS can be executed
only if CPL = 0; (2) XRSTORS can operate on the state components whose bits are set in XCR0 | IA32_XSS and can
thus operate on supervisor state components; and (3) XRSTORS has only a compacted form (no standard form;
see Section 13.8). See Section 13.2 for details of how to determine whether XRSTORS is supported.
The XRSTORS instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction
mask. EDX:EAX & (XCR0 | IA32_XSS) (the logical AND the instruction mask with the logical OR of XCR0 and
IA32_XSS) is the requested-feature bitmap (RFBM) of the state components to be restored.
The following conditions cause execution of the XRSTOR instruction to generate a fault:
• If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs.
• If CR0.TS[bit 3] is 1, a device-not-available exception (#NM) occurs.
• If CPL > 0 or if the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP)
occurs.
After checking for these faults, the XRSTORS instruction reads the first 64 bytes of the XSAVE header, including the
XSTATE_BV and XCOMP_BV fields (see Section 13.4.2). A #GP occurs if any of the following conditions hold for the
values read:
• XCOMP_BV[63] = 0.
• XCOMP_BV sets a bit in the range 62:0 that is not set in XCR0 | IA32_XSS.
• XSTATE_BV sets a bit (including bit 63) that is not set in XCOMP_BV.
• Bytes 63:16 of the XSAVE header are not all 0.
Vol. 1
13-25
MANAGING STATE USING THE XSAVE FEATURE SET
If none of these conditions cause a fault, the processor updates each state component i for which RFBM[i] = 1.
XRSTORS updates state component i based on the value of bit i in the XSTATE_BV field of the XSAVE header:
• If XSTATE_BV[i] = 0, the state component is set to its initial configuration. Section 13.6 specifies the initial
configuration of each state component. If XSTATE_BV[1] = 0, XRSTORS initializes MXCSR to 1F80H.
State component i is set to its initial configuration as indicated above if RFBM[i] = 1 and XSTATE_BV[i] = 0 -
even if XCOMP_BV[i] = 0. This is true for all values of i, including 0 (x87 state) and 1 (SSE state).
• If XSTATE_BV[i] = 1, the state component is loaded with data from the XSAVE area.1 See Section 13.5 for
specifics for each state component and for details regarding mode-specific operation and operation determined
by instruction prefixes; in particular, see Section 13.5.6 and Section 13.5.12 for special treatment by XRSTORS
of PT state and LBR state, respectively. See Section 13.13 for details regarding faults caused by memory
accesses.
If XRSTORS is restoring a supervisor state component, the instruction causes a general-protection exception
(#GP) if it would load any element of that component with an unsupported value (e.g., by setting a reserved bit
in an MSR) or if a bit is set in any reserved portion of the state component in the XSAVE area.
State components 0 and 1 are located in the legacy region of the XSAVE area (see Section 13.4.1). Each state
component i, 2 ≤ i ≤ 62, is located in the extended region; XRSTORS uses the compacted format for the
extended region (see Section 13.4.3).
The MXCSR register is part of SSE state (see Section 13.5.2) and is thus loaded from memory if RFBM[1] =
XSTATE_BV[i] = 1. XRSTORS causes a general-protection exception (#GP) if it would load MXCSR with an
illegal value.
If an execution of XRSTORS causes an exception or a VM exit during or after restoring a supervisor state compo-
nent, each element of that state component may have the value it held before the XRSTORS execution, the value
loaded from the XSAVE area, or the element’s initial value (as defined in Section 13.6). See Section 13.5.6 for some
special treatment of PT state for the case in which XRSTORS causes an exception or a VM exit.
Like XRSTOR, execution of XRSTORS causes the processor to update is tracking for the init and modified optimiza-
tions (see Section 13.6 and Section 13.8.3). The following items provide details:
• The processor updates its tracking for the init optimization as follows:
- If RFBM[i] = 0, XINUSE[i] is not changed.
- If RFBM[i] = 1 and XSTATE_BV[i] = 0, state component i may be tracked as init; XINUSE[i] may be set to
0 or 1.
- If RFBM[i] = 1 and XSTATE_BV[i] = 1, state component i is tracked as not init; XINUSE[i] is set to 1.2
• The processor updates its tracking for the modified optimization and records information about the XRSTORS
execution for future interaction with the XSAVEOPT and XSAVES instructions as follows:
- If RFBM[i] = 0, state component i is tracked as modified; XMODIFIED[i] is set to 1.
- If RFBM[i] = 1, state component i may be tracked as unmodified; XMODIFIED[i] may be set to 0 or 1.
- XRSTOR_INFO is set to the 4-tuple w,x,y,z, where w is the CPL; x is 1 if the logical processor is in VMX
non-root operation and 0 otherwise; y is the linear address of the XSAVE area; and z is XCOMP_BV (this
implies that z[63] = 1).
Note that, if RFBM is entirely zero (e.g., because the instruction mask in EDX:EAX is zero), no state components are
modified, the XINUSE bitmap is not modified, and all bits are set in the XMODIFIED bitmap. Thus, if EDX:EAX was
zero for the most recent execution of XRSTORS, an execution of XSAVEOPT or XSAVES will identify all state compo-
nents as modified and will thus not use the modified optimization.
1. Earlier fault checking ensured that, if the instruction has reached this point in execution and XSTATE_BV[i] is 1, then XCOMP_BV[i] is
also 1.
2. For LBR state (state component 15), XRSTORS may leave XINIUSE[15] unmodified in certain situations even if RFBM[15] = 1 =
XSTATE_BV[15] = 1. See Section 13.5.12.
13-26
Vol. 1
MANAGING STATE USING THE XSAVE FEATURE SET
13.13 MEMORY ACCESSES BY THE XSAVE FEATURE SET
Each instruction in the XSAVE feature set operates on a set of XSAVE-managed state components. The specific set
of components on which an instruction operates is determined by the values of XCR0, the IA32_XSS MSR,
EDX:EAX, and (for XRSTOR and XRSTORS) the XSAVE header.
Section 13.4 provides the details necessary to determine the location of each state component for any execution of
an instruction in the XSAVE feature set. An execution of an instruction in the XSAVE feature set may access any
byte of any state component on which that execution operates even when saving a state component is omitted
because it is in its initial configuration; when restoring a state component to its initial configuration; or when XFD
is enabled for the state components (see Section 13.14).
Section 13.5 provides details of the different XSAVE-managed state components. Some portions of some of these
components are accessible only in 64-bit mode. Executions of XRSTOR and XRSTORS outside 64-bit mode will not
update those portions; executions of XSAVE, XSAVEC, XSAVEOPT, and XSAVES will not modify the corresponding
locations in memory.
Despite this fact, any execution of these instructions outside 64-bit mode may access any byte in any state compo-
nent on which that execution operates - even those at addresses corresponding to registers that are accessible
only in 64-bit mode. As a result, such an execution may incur a fault due to an attempt to access such an address.
For example, an execution of XSAVE outside 64-bit mode may incur a page fault if paging does not map as
read/write the section of the XSAVE area containing state component 7 (Hi16_ZMM state) - despite the fact that
state component 7 can be accessed only in 64-bit mode.
13.14 EXTENDED FEATURE DISABLE (XFD)
Extended feature disable (XFD) is an extension to the XSAVE feature set that allows an operating system to
enable a feature while preventing specific user threads from using the feature. This section describes XFD.
As noted in Section 13.2, a processor that supports XFD enumerates CPUID.(EAX=0DH,ECX=1):EAX[4] as 1. Such
a processor supports two new MSRs: IA32_XFD (MSR address 1C4H) and IA32_XFD_ERR (MSR address 1C5H).
Each of these MSRs contains a state-component bitmap. Bit i of either MSR can be set to 1 only if
CPUID.(EAX=0DH,ECX=i):ECX[2] is enumerated as 1 (see Section 13.2). An execution of WRMSR that attempts to
set an unsupported bit in either MSR causes a general-protection fault (#GP). The reset values of both of these
MSRs are zero.
XFD is enabled for state component i if XCR0[i] = IA32_XFD[i] = 1. (IA32_XFD[i] does not affect processor oper-
ations if XCR0[i] = 0.) In compacted format, the IA32_XFD MSR does not impact the computation of XCOMP_BV by
the XSAVEC or XSAVES instructions and thus does not impact the format of the extended region of the XSAVE area.
When XFD is enabled for a state component, any instruction that would access that state component does not
execute and instead generates a device-not-available exception (#NM).
Exceptions are made for certain instructions (including those that initialize the state component). The following
items provide details:
• LDTILECFG and TILERELEASE initialize the TILEDATA state component. An execution of either of these instruc-
tions does not generate #NM when XCR0[18] = IA32_XFD[18] = 1; instead, it initializes TILEDATA normally.
(Note that STTILECFG does not use the TILEDATA state component. Thus, an execution of this instruction does
not generate #NM when XCR0[18] = IA32_XFD[18] = 1.)
• If XRSTOR or XRSTORS is loading state component i and bit i of the XSTATE_BV field of the XSAVE header is 0,
the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it initializes the state
component normally. (If bit i of the XSTATE_BV field of the XSAVE header is 1, the instruction does generate
#NM.)
• If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate
#NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was
in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the
initial configuration of the state component (the other instructions do not save state component i).
• Enclave entry instructions (ENCLU[EENTER] and ENCLU[ERESUME]) generate #NM if XCR0[i] = IA32_XFD[i] =
1 and bit i is set in the XFRM field in the attributes of the enclave being entered.
Vol. 1
13-27
MANAGING STATE USING THE XSAVE FEATURE SET
When XFD causes an instruction to generate #NM, the processor loads the IA32_XFD_ERR MSR to identify the
disabled state component(s). Specifically, the MSR is loaded with the logical AND of the IA32_XFD MSR and the
bitmap corresponding to the state component(s) required by the faulting instruction.
Device-not-available exceptions that are not due to XFD - those resulting from setting CR0.TS to 1 - do not
modify the IA32_XFD_ERR MSR.
13-28
Vol. 1
3. Updates to Chapter 1, Volume 2A
Change bars and violet text show changes to Chapter 1 of the Intel® 64 and IA-32 Architectures Software
Developer’s Manual, Volume 2A: Instruction Set Reference, A-L.
------------------------------------------------------------------------------------------
Changes to this chapter:
• Added the 5th generation Intel® Xeon® Scalable Processor Family and the Intel® Core™ Ultra 7 processors to
the list of supported processors in Section 1.1, “Intel® 64 and IA-32 Processors Covered in this Manual.”
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
13
CHAPTER 1
ABOUT THIS MANUAL
The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B, 2C, & 2D: Instruction Set
Reference (order numbers 253666, 253667, 326018, and 334569), is part of a set that describes the architecture
and programming environment of all Intel 64 and IA-32 architecture processors. Other volumes in this set are:
• The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1: Basic Architecture (Order
Number 253665).
• The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A, 3B, 3C, & 3D: System
Programming Guide (order numbers 253668, 253669, 326019, and 332831).
• The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4: Model-Specific Registers
(order number 335592).
The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, describes the basic architecture
and programming environment of Intel 64 and IA-32 processors. The Intel® 64 and IA-32 Architectures Software
Developer’s Manual, Volumes 2A, 2B, 2C, & 2D, describes the instruction set of the processor and the opcode struc-
ture. These volumes apply to application programmers and to programmers who write operating systems or exec-
utives. The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A, 3B, 3C, & 3D, describes
the operating-system support environment of Intel 64 and IA-32 processors. These volumes target operating-
system and BIOS designers. In addition, the Intel® 64 and IA-32 Architectures Software Developer’s Manual,
Volume 3B, addresses the programming environment for classes of software that host operating systems. The
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4, describes the model-specific registers
of Intel 64 and IA-32 processors.
1.1
INTEL® 64 AND IA-32 PROCESSORS COVERED IN THIS MANUAL
This manual set includes information pertaining primarily to the most recent Intel 64 and IA-32 processors, which
include:
• Pentium® processors
• P6 family processors
• Pentium® 4 processors
• Pentium® M processors
• Intel® Xeon® processors
• Pentium® D processors
• Pentium® processor Extreme Editions
•
64-bit Intel® Xeon® processors
• Intel® Core™ Duo processor
• Intel® Core™ Solo processor
• Dual-Core Intel® Xeon® processor LV
• Intel® Core™ 2 Duo processor
• Intel® Core™ 2 Quad processor Q6000 series
• Intel® Xeon® processor 3000, 3200 series
• Intel® Xeon® processor 5000 series
• Intel® Xeon® processor 5100, 5300 series
• Intel® Core™ 2 Extreme processor X7000 and X6800 series
• Intel® Core™ 2 Extreme processor QX6000 series
• Intel® Xeon® processor 7100 series
Vol. 2A
1-1
ABOUT THIS MANUAL
•
Intel® Pentium® Dual-Core processor
•
Intel® Xeon® processor 7200, 7300 series
•
Intel® Xeon® processor 5200, 5400, 7400 series
•
Intel® Core™ 2 Extreme processor QX9000 and X9000 series
•
Intel® Core™ 2 Quad processor Q9000 series
•
Intel® Core™ 2 Duo processor E8000, T9000 series
•
Intel Atom® processor family
•
Intel Atom® processors 200, 300, D400, D500, D2000, N200, N400, N2000, E2000, Z500, Z600, Z2000,
C1000 series are built from 45 nm and 32 nm processes
•
Intel® Core™ i7 processor
•
Intel® Core™ i5 processor
•
Intel® Xeon® processor E7-8800/4800/2800 product families
•
Intel® Core™ i7-3930K processor
•
2nd generation Intel® Core™ i7-2xxx, Intel® Core™ i5-2xxx, Intel® Core™ i3-2xxx processor series
•
Intel® Xeon® processor E3-1200 product family
•
Intel® Xeon® processor E5-2400/1400 product family
•
Intel® Xeon® processor E5-4600/2600/1600 product family
•
3rd generation Intel® Core™ processors
•
Intel® Xeon® processor E3-1200 v2 product family
•
Intel® Xeon® processor E5-2400/1400 v2 product families
•
Intel® Xeon® processor E5-4600/2600/1600 v2 product families
•
Intel® Xeon® processor E7-8800/4800/2800 v2 product families
•
4th generation Intel® Core™ processors
•
The Intel® Core™ M processor family
•
Intel® Core™ i7-59xx Processor Extreme Edition
•
Intel® Core™ i7-49xx Processor Extreme Edition
•
Intel® Xeon® processor E3-1200 v3 product family
•
Intel® Xeon® processor E5-2600/1600 v3 product families
•
5th generation Intel® Core™ processors
•
Intel® Xeon® processor D-1500 product family
•
Intel® Xeon® processor E5 v4 family
•
Intel Atom® processor X7-Z8000 and X5-Z8000 series
•
Intel Atom® processor Z3400 series
•
Intel Atom® processor Z3500 series
•
6th generation Intel® Core™ processors
•
Intel® Xeon® processor E3-1500m v5 product family
•
7th generation Intel® Core™ processors
•
Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
•
Intel® Xeon® Scalable Processor Family
•
8th generation Intel® Core™ processors
•
Intel® Xeon Phi™ Processor 7215, 7285, 7295 Series
•
Intel® Xeon® E processors
•
9th generation Intel® Core™ processors
•
2nd generation Intel® Xeon® Scalable Processor Family
1-2
Vol. 2A
ABOUT THIS MANUAL
•
10th generation Intel® Core™ processors
•
11th generation Intel® Core™ processors
• 3rd generation Intel® Xeon® Scalable Processor Family
•
12th generation Intel® Core™ processors
•
13th generation Intel® Core™ processors
• 4th generation Intel® Xeon® Scalable Processor Family
• 5th generation Intel® Xeon® Scalable Processor Family
• Intel® Core™ Ultra 7 processors
P6 family processors are IA-32 processors based on the P6 family microarchitecture. This includes the Pentium®
Pro, Pentium® II, Pentium® III, and Pentium® III Xeon® processors.
The Pentium® 4, Pentium® D, and Pentium® processor Extreme Editions are based on the Intel NetBurst® microar-
chitecture. Most early Intel® Xeon® processors are based on the Intel NetBurst® microarchitecture. Intel Xeon
processor 5000, 7100 series are based on the Intel NetBurst® microarchitecture.
The Intel® Core™ Duo, Intel® Core™ Solo and dual-core Intel® Xeon® processor LV are based on an improved
Pentium® M processor microarchitecture.
The Intel® Xeon® processor 3000, 3200, 5100, 5300, 7200, and 7300 series, Intel® Pentium® dual-core, Intel®
Core™ 2 Duo, Intel® Core™ 2 Quad, and Intel® Core™ 2 Extreme processors are based on Intel® Core™ microar-
chitecture.
The Intel® Xeon® processor 5200, 5400, 7400 series, Intel® Core™ 2 Quad processor Q9000 series, and Intel®
Core™ 2 Extreme processors QX9000, X9000 series, Intel® Core™ 2 processor E8000 series are based on
Enhanced Intel® Core™ microarchitecture.
The Intel Atom® processors 200, 300, D400, D500, D2000, N200, N400, N2000, E2000, Z500, Z600, Z2000,
C1000 series are based on the Intel Atom® microarchitecture and supports Intel 64 architecture.
P6 family, Pentium® M, Intel® Core™ Solo, Intel® Core™ Duo processors, dual-core Intel® Xeon® processor LV,
and early generations of Pentium 4 and Intel Xeon processors support IA-32 architecture. The Intel® AtomTM
processor Z5xx series support IA-32 architecture.
The Intel® Xeon® processor 3000, 3200, 5000, 5100, 5200, 5300, 5400, 7100, 7200, 7300, 7400 series, Intel®
Core™ 2 Duo, Intel® Core™ 2 Extreme, Intel® Core™ 2 Quad processors, Pentium® D processors, Pentium® Dual-
Core processor, newer generations of Pentium 4 and Intel Xeon processor family support Intel® 64 architecture.
The Intel® Core™ i7 processor and Intel® Xeon® processor 3400, 5500, 7500 series are based on 45 nm Nehalem
microarchitecture. Westmere microarchitecture is a 32 nm version of the Nehalem microarchitecture. Intel®
Xeon® processor 5600 series, Intel Xeon processor E7 and various Intel Core i7, i5, i3 processors are based on the
Westmere microarchitecture. These processors support Intel 64 architecture.
The Intel® Xeon® processor E5 family, Intel® Xeon® processor E3-1200 family, Intel® Xeon® processor E7-
8800/4800/2800 product families, Intel® Core™ i7-3930K processor, and 2nd generation Intel® Core™ i7-2xxx,
Intel® CoreTM i5-2xxx, Intel® Core™ i3-2xxx processor series are based on the Sandy Bridge microarchitecture and
support Intel 64 architecture.
The Intel® Xeon® processor E7-8800/4800/2800 v2 product families, Intel® Xeon® processor E3-1200 v2 product
family and 3rd generation Intel® Core™ processors are based on the Ivy Bridge microarchitecture and support
Intel 64 architecture.
The Intel® Xeon® processor E5-4600/2600/1600 v2 product families, Intel® Xeon® processor E5-2400/1400 v2
product families and Intel® Core™ i7-49xx Processor Extreme Edition are based on the Ivy Bridge-E microarchitec-
ture and support Intel 64 architecture.
The Intel® Xeon® processor E3-1200 v3 product family and 4th Generation Intel® Core™ processors are based on
the Haswell microarchitecture and support Intel 64 architecture.
The Intel® Xeon® processor E5-2600/1600 v3 product families and the Intel® Core™ i7-59xx Processor Extreme
Edition are based on the Haswell-E microarchitecture and support Intel 64 architecture.
The Intel Atom® processor Z8000 series is based on the Airmont microarchitecture.
Vol. 2A
1-3
ABOUT THIS MANUAL
The Intel Atom® processor Z3400 series and the Intel Atom® processor Z3500 series are based on the Silvermont
microarchitecture.
The Intel® Core™ M processor family, 5th generation Intel® Core™ processors, Intel® Xeon® processor D-1500
product family and the Intel® Xeon® processor E5 v4 family are based on the Broadwell microarchitecture and
support Intel 64 architecture.
The Intel® Xeon® Scalable Processor Family, Intel® Xeon® processor E3-1500m v5 product family and 6th gener-
ation Intel® Core™ processors are based on the Skylake microarchitecture and support Intel 64 architecture.
The 7th generation Intel® Core™ processors are based on the Kaby Lake microarchitecture and support Intel 64
architecture.
The Intel Atom® processor C series, the Intel Atom® processor X series, the Intel® Pentium® processor J series,
the Intel® Celeron® processor J series, and the Intel® Celeron® processor N series are based on the Goldmont
microarchitecture.
The Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series is based on the Knights Landing microarchitecture and
supports Intel 64 architecture.
The Intel® Pentium® Silver processor series, the Intel® Celeron® processor J series, and the Intel® Celeron®
processor N series are based on the Goldmont Plus microarchitecture.
The 8th generation Intel® Core™ processors, 9th generation Intel® Core™ processors, and Intel® Xeon® E proces-
sors are based on the Coffee Lake microarchitecture and support Intel 64 architecture.
The Intel® Xeon Phi™ Processor 7215, 7285, 7295 Series is based on the Knights Mill microarchitecture and
supports Intel 64 architecture.
The 2nd generation Intel® Xeon® Scalable Processor Family is based on the Cascade Lake product and supports
Intel 64 architecture.
Some 10th generation Intel® Core™ processors are based on the Ice Lake microarchitecture, and some are based
on the Comet Lake microarchitecture; both support Intel 64 architecture.
Some 11th generation Intel® Core™ processors are based on the Tiger Lake microarchitecture, and some are
based on the Rocket Lake microarchitecture; both support Intel 64 architecture.
Some 3rd generation Intel® Xeon® Scalable Processor Family processors are based on the Cooper Lake product,
and some are based on the Ice Lake microarchitecture; both support Intel 64 architecture.
The 12th generation Intel® Core™ processors are based on the Alder Lake performance hybrid architecture and
support Intel 64 architecture.
The 13th generation Intel® Core™ processors are based on the Raptor Lake performance hybrid architecture and
support Intel 64 architecture.
The 4th generation Intel® Xeon® Scalable Processor Family is based on Sapphire Rapids microarchitecture and
supports Intel 64 architecture.
The 5th generation Intel® Xeon® Scalable Processor Family is based on Emerald Rapids microarchitecture and
supports Intel 64 architecture.
The Intel® Core™ Ultra 7 processor is based on Meteor Lake hybrid architecture and supports Intel 64 architecture.
IA-32 architecture is the instruction set architecture and programming environment for Intel's 32-bit microproces-
sors. Intel® 64 architecture is the instruction set architecture and programming environment which is the superset
of Intel’s 32-bit and 64-bit architectures. It is compatible with the IA-32 architecture.
1.2
OVERVIEW OF VOLUME 2A, 2B, 2C, AND 2D: INSTRUCTION SET
REFERENCE
A description of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B, 2C, & 2D,
content follows:
1-4
Vol. 2A
ABOUT THIS MANUAL
Chapter 1 - About This Manual. Gives an overview of all ten volumes of the Intel® 64 and IA-32 Architectures
Software Developer’s Manual. It also describes the notational conventions in these manuals and lists related Intel®
manuals and documentation of interest to programmers and hardware designers.
Chapter 2 - Instruction Format. Describes the machine-level instruction format used for all IA-32 instructions
and gives the allowable encodings of prefixes, the operand-identifier byte (ModR/M byte), the addressing-mode
specifier byte (SIB byte), and the displacement and immediate bytes.
Chapter 3 - Instruction Set Reference, A-L. Describes Intel 64 and IA-32 instructions in detail, including an
algorithmic description of operations, the effect on flags, the effect of operand- and address-size attributes, and
the exceptions that may be generated. The instructions are arranged in alphabetical order. General-purpose, x87
FPU, Intel MMX™ technology, SSE/SSE2/SSE3/SSSE3/SSE4 extensions, and system instructions are included.
Chapter 4 - Instruction Set Reference, M-U. Continues the description of Intel 64 and IA-32 instructions
started in Chapter 3. It starts Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2B.
Chapter 5 - Instruction Set Reference, V. Continues the description of Intel 64 and IA-32 instructions started
in chapters 3 and 4. This chapter starts Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume
2C.
Chapter 6 - Instruction Set Reference, W-Z. Continues the description of Intel 64 and IA-32 instructions
started in chapters 3, 4, and 5. It provides the balance of the alphabetized list of instructions and starts Intel® 64
and IA-32 Architectures Software Developer’s Manual, Volume 2D.
Chapter 7 - Safer Mode Extensions Reference. Describes the safer mode extensions (SMX). SMX is intended
for a system executive to support launching a measured environment in a platform where the identity of the soft-
ware controlling the platform hardware can be measured for the purpose of making trust decisions.
Chapter 8- Instruction Set Reference Unique to Intel® Xeon Phi™ Processors. Describes the instruction
set that is unique to Intel® Xeon Phi™ processors based on the Knights Landing and Knights Mill microarchitec-
tures. The set is not supported in any other Intel processors.
Appendix A - Opcode Map. Gives an opcode map for the IA-32 instruction set.
Appendix B - Instruction Formats and Encodings. Gives the binary encoding of each form of each IA-32
instruction.
Appendix C - Intel® C/C++ Compiler Intrinsics and Functional Equivalents. Lists the Intel® C/C++ compiler
intrinsics and their assembly code equivalents for each of the IA-32 MMX and SSE/SSE2/SSE3 instructions.
1.3
NOTATIONAL CONVENTIONS
This manual uses specific notation for data-structure formats, for symbolic representation of instructions, and for
hexadecimal and binary numbers. A review of this notation makes the manual easier to read.
1.3.1
Bit and Byte Order
In illustrations of data structures in memory, smaller addresses appear toward the bottom of the figure; addresses
increase toward the top. Bit positions are numbered from right to left. The numerical value of a set bit is equal to
two raised to the power of the bit position. IA-32 processors are “little endian” machines; this means the bytes of
a word are numbered starting from the least significant byte. Figure 1-1 illustrates these conventions.
Vol. 2A
1-5
ABOUT THIS MANUAL
Highest
Data Structure
Address
31
24 23
16 15
8 7
0
Bit offset
28
24
20
16
12
8
4
Lowest
Byte 3
Byte 2
Byte 1
Byte 0
0
Address
Byte Offset
Figure 1-1. Bit and Byte Order
1.3.2
Reserved Bits and Software Compatibility
In many register and memory layout descriptions, certain bits are marked as reserved. When bits are marked as
reserved, it is essential for compatibility with future processors that software treat these bits as having a future,
though unknown, effect. The behavior of reserved bits should be regarded as not only undefined, but unpredict-
able. 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 which contain such bits.
Mask out the reserved bits before testing.
• Do not depend on the states of any reserved bits when storing 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.
NOTE
Avoid any software dependence upon the state of reserved bits in IA-32 registers. Depending upon
the values of reserved register bits will make software dependent upon the unspecified manner in
which the processor handles these bits. Programs that depend upon reserved values risk incompat-
ibility with future processors.
1.3.3
Instruction Operands
When instructions are represented symbolically, a subset of the IA-32 assembly language is used. In this subset,
an instruction has the following format:
label: mnemonic argument1, argument2, argument3
where:
• A label is an identifier which is followed by a colon.
• A mnemonic is a reserved name for a class of instruction opcodes which have the same function.
• The operands argument1, argument2, and argument3 are optional. There may be from zero to three operands,
depending on the opcode. When present, they take the form of either literals or identifiers for data items.
Operand identifiers are either reserved names of registers or are assumed to be assigned to data items
declared in another part of the program (which may not be shown in the example).
When two operands are present in an arithmetic or logical instruction, the right operand is the source and the left
operand is the destination.
For example:
1-6
Vol. 2A
ABOUT THIS MANUAL
LOADREG: MOV EAX, SUBTOTAL
In this example, LOADREG is a label, MOV is the mnemonic identifier of an opcode, EAX is the destination operand,
and SUBTOTAL is the source operand. Some assembly languages put the source and destination in reverse order.
1.3.4
Hexadecimal and Binary Numbers
Base 16 (hexadecimal) numbers are represented by a string of hexadecimal digits followed by the character H (for
example, F82EH). A hexadecimal digit is a character from the following set: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D,
E, and F.
Base 2 (binary) numbers are represented by a string of 1s and 0s, sometimes followed by the character B (for
example, 1010B). The “B” designation is only used in situations where confusion as to the type of number might
arise.
1.3.5
Segmented Addressing
The processor uses byte addressing. This means memory is organized and accessed as a sequence of bytes.
Whether one or more bytes are being accessed, a byte address is used to locate the byte or bytes in memory. The
range of memory that can be addressed is called an address space.
The processor also supports segmented addressing. This is a form of addressing where a program may have many
independent address spaces, called segments. For example, a program can keep its code (instructions) and stack
in separate segments. Code addresses would always refer to the code space, and stack addresses would always
refer to the stack space. The following notation is used to specify a byte address within a segment:
Segment-register:Byte-address
For example, the following segment address identifies the byte at address FF79H in the segment pointed by the DS
register:
DS:FF79H
The following segment address identifies an instruction address in the code segment. The CS register points to the
code segment and the EIP register contains the address of the instruction.
CS:EIP
1.3.6
Exceptions
An exception is an event that typically occurs when an instruction causes an error. For example, an attempt to
divide by zero generates an exception. However, some exceptions, such as breakpoints, occur under other condi-
tions. Some types of exceptions may provide error codes. An error code reports additional information about the
error. An example of the notation used to show an exception and error code is shown below:
#PF(fault code)
This example refers to a page-fault exception under conditions where an error code naming a type of fault is
reported. Under some conditions, exceptions which produce error codes may not be able to report an accurate
code. In this case, the error code is zero, as shown below for a general-protection exception:
#GP(0)
1.3.7
A New Syntax for CPUID, CR, and MSR Values
Obtain feature flags, status, and system information by using the CPUID instruction, by checking control register
bits, and by reading model-specific registers. We are moving toward a new syntax to represent this information.
See Figure 1-2.
Vol. 2A
1-7
ABOUT THIS MANUAL
CPUID Input and Output
CPUID.01H:EDX.SSE[bit 25] = 1
Input value for EAX register
Output register and feature flag or field
name with bit position(s)
Value (or range) of output
Control Register Values
CR4.OSFXSR[bit 9] = 1
Example CR name
Feature flag or field name
with bit position(s)
Value (or range) of output
Model-Specific Register Values
IA32_MISC_ENABLE.ENABLEFOPCODE[bit 2] = 1
Example MSR name
Feature flag or field name with bit position(s)
Value (or range) of output
SDM29002
Figure 1-2. Syntax for CPUID, CR, and MSR Data Presentation
1.4
RELATED LITERATURE
Literature related to Intel 64 and IA-32 processors is listed and viewable on-line at:
See also:
• The latest security information on Intel® products:
• Software developer resources, guidance, and insights for security advisories:
• The data sheet for a particular Intel 64 or IA-32 processor
• The specification update for a particular Intel 64 or IA-32 processor
• Intel® C++ Compiler documentation and online help:
1-8
Vol. 2A
ABOUT THIS MANUAL
• Intel® Fortran Compiler documentation and online help:
• Intel® Software Development Tools:
• Intel® 64 and IA-32 Architectures Software Developer’s Manual (in one, four or ten volumes):
• Intel® 64 and IA-32 Architectures Optimization Reference Manual:
• Intel® Trusted Execution Technology Measured Launched Environment Programming Guide:
http://www.intel.com/content/www/us/en/software-developers/intel-txt-software-development-guide.html
• Intel® Software Guard Extensions (Intel® SGX) Information:
• Developing Multi-threaded Applications: A Platform Consistent Approach:
tions.pdf
• Using Spin-Loops on Intel® Pentium® 4 Processor and Intel® Xeon® Processor:
• Performance Monitoring Unit Sharing Guide:
Literature related to select features in future Intel processors are available at:
• Intel® Architecture Instruction Set Extensions Programming Reference:
More relevant links are:
• Intel® Developer Zone:
• Developer centers:
• Processor support general link:
• Intel® Hyper-Threading Technology (Intel® HT Technology):
Vol. 2A
1-9
ABOUT THIS MANUAL
1-10
Vol. 2A
4. Updates to Chapter 2, Volume 2A
Change bars and violet text show changes to Chapter 2 of the Intel® 64 and IA-32 Architectures Software
Developer’s Manual, Volume 2A: Instruction Set Reference, A-L.
------------------------------------------------------------------------------------------
Changes to this chapter:
• Updated Section 2.2.1, “REX Prefixes,” to clarify that only one meaningful REX prefix is allowed per
instruction.
• Corrected two inaccurate cross-references in Section 2.3.12, “Vector SIB (VSIB) Memory Addressing.”
Previously, this section contained two references to Table 2-3; the correct table is Table 2-13.
Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes
13
CHAPTER 2
INSTRUCTION FORMAT
This chapter describes the instruction format for all Intel 64 and IA-32 processors. The instruction format for
protected mode, real-address mode and virtual-8086 mode is described in Section 2.1. Increments provided for IA-
32e mode and its sub-modes are described in Section 2.2.
2.1
INSTRUCTION FORMAT FOR PROTECTED MODE, REAL-ADDRESS MODE,
AND VIRTUAL-8086 MODE
The Intel 64 and IA-32 architectures instruction encodings are subsets of the format shown in Figure 2-1. Instruc-
tions consist of optional instruction prefixes (in any order), primary opcode bytes (up to three bytes), an
addressing-form specifier (if required) consisting of the ModR/M byte and sometimes the SIB (Scale-Index-Base)
byte, a displacement (if required), and an immediate data field (if required).
Instruction
Opcode
ModR/M
SIB
Displacement
Immediate
Prefixes
Prefixes of
1-, 2-, or 3-byte
1 byte
1 byte
Address
Immediate
1 byte each
opcode
(if required)
(if required)
displacement
data of
(optional)1, 2
of 1, 2, or 4
1, 2, or 4
bytes or none3
bytes or none3
7
6 5
3
2
0
7
6 5
3
2
0
Reg/
Mod
R/M
Scale
Index
Base
Opcode
1. The REX prefix is optional, but if used must be immediately before the opcode; see Section
2.2.1, “REX Prefixes” for additional information.
2. For VEX encoding information, see Section 2.3, “Intel® Advanced Vector Extensions (Intel®
AVX)”.
3. Some rare instructions can take an 8B immediate or 8B displacement.
Figure 2-1. Intel 64 and IA-32 Architectures Instruction Format
2.1.1
Instruction Prefixes
Instruction prefixes are divided into four groups, each with a set of allowable prefix codes. For each instruction, it
is only useful to include up to one prefix code from each of the four groups (Groups 1, 2, 3, 4). Groups 1 through 4
may be placed in any order relative to each other.
• Group 1
- Lock and repeat prefixes:
• LOCK prefix is encoded using F0H.
• REPNE/REPNZ prefix is encoded using F2H. Repeat-Not-Zero prefix applies only to string and
input/output instructions. (F2H is also used as a mandatory prefix for some instructions.)
• REP or REPE/REPZ is encoded using F3H. The repeat prefix applies only to string and input/output
instructions. (F3H is also used as a mandatory prefix for some instructions.)
Vol. 2A
2-1
INSTRUCTION FORMAT
- BND prefix is encoded using F2H if the following conditions are true:
• CPUID.(EAX=07H, ECX=0):EBX.MPX[bit 14] is set.
• BNDCFGU.EN and/or IA32_BNDCFGS.EN is set.
• When the F2 prefix precedes a near CALL, a near RET, a near JMP, a short Jcc, or a near Jcc instruction
(see Appendix E, “Intel® Memory Protection Extensions,” of the Intel® 64 and IA-32 Architectures
Software Developer’s Manual, Volume 1).
• Group 2
- Segment override prefixes:
• 2EH-CS segment override (use with any branch instruction is reserved).
•
36H-SS segment override prefix (use with any branch instruction is reserved).
• 3EH-DS segment override prefix (use with any branch instruction is reserved).
•
26H-ES segment override prefix (use with any branch instruction is reserved).
•
64H-FS segment override prefix (use with any branch instruction is reserved).
•
65H-GS segment override prefix (use with any branch instruction is reserved).
— Branch hints1:
• 2EH-Branch not taken (used only with Jcc instructions).
• 3EH-Branch taken (used only with Jcc instructions).
• Group 3
• Operand-size override prefix is encoded using 66H (66H is also used as a mandatory prefix for some
instructions).
• Group 4
•
67H-Address-size override prefix.
The LOCK prefix (F0H) forces an operation that ensures exclusive use of shared memory in a multiprocessor envi-
ronment. See “LOCK-Assert LOCK# Signal Prefix” in Chapter 3, “Instruction Set Reference, A-L,” for a description
of this prefix.
Repeat prefixes (F2H, F3H) cause an instruction to be repeated for each element of a string. Use these prefixes
only with string and I/O instructions (MOVS, CMPS, SCAS, LODS, STOS, INS, and OUTS). Use of repeat prefixes
and/or undefined opcodes with other Intel 64 or IA-32 instructions is reserved; such use may cause unpredictable
behavior.
Some instructions may use F2H,F3H as a mandatory prefix to express distinct functionality.
Branch hint prefixes (2EH, 3EH) allow a program to give a hint to the processor about the most likely code path for
a branch. Use these prefixes only with conditional branch instructions (Jcc). Other use of branch hint prefixes
and/or other undefined opcodes with Intel 64 or IA-32 instructions is reserved; such use may cause unpredictable
behavior.
The operand-size override prefix allows a program to switch between 16- and 32-bit operand sizes. Either size can
be the default; use of the prefix selects the non-default size.
Some SSE2/SSE3/SSSE3/SSE4 instructions and instructions using a three-byte sequence of primary opcode bytes
may use 66H as a mandatory prefix to express distinct functionality.
Other use of the 66H prefix is reserved; such use may cause unpredictable behavior.
The address-size override prefix (67H) allows programs to switch between 16- and 32-bit addressing. Either size
can be the default; the prefix selects the non-default size. Using this prefix and/or other undefined opcodes when
operands for the instruction do not reside in memory is reserved; such use may cause unpredictable behavior.
1. Some earlier microarchitectures used these as branch hints, but recent generations have not and they are reserved for future hint
usage.
2-2
Vol. 2A
INSTRUCTION FORMAT
2.1.2
Opcodes
A primary opcode can be 1, 2, or 3 bytes in length. An additional 3-bit opcode field is sometimes encoded in the
ModR/M byte. Smaller fields can be defined within the primary opcode. Such fields define the direction of opera-
tion, size of displacements, register encoding, condition codes, or sign extension. Encoding fields used by an
opcode vary depending on the class of operation.
Two-byte opcode formats for general-purpose and SIMD instructions consist of one of the following:
• An escape opcode byte 0FH as the primary opcode and a second opcode byte.
• A mandatory prefix (66H, F2H, or F3H), an escape opcode byte, and a second opcode byte (same as previous
bullet).
For example, CVTDQ2PD consists of the following sequence: F3 0F E6. The first byte is a mandatory prefix (it is not
considered as a repeat prefix).
Three-byte opcode formats for general-purpose and SIMD instructions consist of one of the following:
• An escape opcode byte 0FH as the primary opcode, plus two additional opcode bytes.
• A mandatory prefix (66H, F2H, or F3H), an escape opcode byte, plus two additional opcode bytes (same as
previous bullet).
For example, PHADDW for XMM registers consists of the following sequence: 66 0F 38 01. The first byte is the
mandatory prefix.
Valid opcode expressions are defined in Appendix A and Appendix B.
2.1.3
ModR/M and SIB Bytes
Many instructions that refer to an operand in memory have an addressing-form specifier byte (called the ModR/M
byte) following the primary opcode. The ModR/M byte contains three fields of information:
• The mod field combines with the r/m field to form 32 possible values: eight registers and 24 addressing modes.
• The reg/opcode field specifies either a register number or three more bits of opcode information. The purpose
of the reg/opcode field is specified in the primary opcode.
• The r/m field can specify a register as an operand or it can be combined with the mod field to encode an
addressing mode. Sometimes, certain combinations of the mod field and the r/m field are used to express
opcode information for some instructions.
Certain encodings of the ModR/M byte require a second addressing byte (the SIB byte). The base-plus-index and
scale-plus-index forms of 32-bit addressing require the SIB byte. The SIB byte includes the following fields:
• The scale field specifies the scale factor.
• The index field specifies the register number of the index register.
• The base field specifies the register number of the base register.
See Section 2.1.5 for the encodings of the ModR/M and SIB bytes.
2.1.4
Displacement and Immediate Bytes
Some addressing forms include a displacement immediately following the ModR/M byte (or the SIB byte if one is
present). If a displacement is required, it can be 1, 2, or 4 bytes.
If an instruction specifies an immediate operand, the operand always follows any displacement bytes. An imme-
diate operand can be 1, 2 or 4 bytes.
Vol. 2A
2-3
INSTRUCTION FORMAT
2.1.5
Addressing-Mode Encoding of ModR/M and SIB Bytes
The values and corresponding addressing forms of the ModR/M and SIB bytes are shown in Table 2-1 through Table
2-3: 16-bit addressing forms specified by the ModR/M byte are in Table 2-1 and 32-bit addressing forms are in
Table 2-2. Table 2-3 shows 32-bit addressing forms specified by the SIB byte. In cases where the reg/opcode field
in the ModR/M byte represents an extended opcode, valid encodings are shown in Appendix B.
In Table 2-1 and Table 2-2, the Effective Address column lists 32 effective addresses that can be assigned to the
first operand of an instruction by using the Mod and R/M fields of the ModR/M byte. The first 24 options provide
ways of specifying a memory location; the last eight (Mod = 11B) provide ways of specifying general-purpose, MMX
technology and XMM registers.
The Mod and R/M columns in Table 2-1 and Table 2-2 give the binary encodings of the Mod and R/M fields required
to obtain the effective address listed in the first column. For example: see the row indicated by Mod = 11B, R/M =
000B. The row identifies the general-purpose registers EAX, AX or AL; MMX technology register MM0; or XMM
register XMM0. The register used is determined by the opcode byte and the operand-size attribute.
Now look at the seventh row in either table (labeled “REG =”). This row specifies the use of the 3-bit Reg/Opcode
field when the field is used to give the location of a second operand. The second operand must be a general-
purpose, MMX technology, or XMM register. Rows one through five list the registers that may correspond to the
value in the table. Again, the register used is determined by the opcode byte along with the operand-size attribute.
If the instruction does not require a second operand, then the Reg/Opcode field may be used as an opcode exten-
sion. This use is represented by the sixth row in the tables (labeled “/digit (Opcode)”). Note that values in row six
are represented in decimal form.
The body of Table 2-1 and Table 2-2 (under the label “Value of ModR/M Byte (in Hexadecimal)”) contains a 32 by
8 array that presents all of 256 values of the ModR/M byte (in hexadecimal). Bits 3, 4, and 5 are specified by the
column of the table in which a byte resides. The row specifies bits 0, 1, and 2; and bits 6 and 7. The figure below
demonstrates interpretation of one table value.
Mod
11
RM
000
/digit (Opcode); REG =
001
C8H
11001000
Figure 2-2. Table Interpretation of ModR/M Byte (C8H)
2-4
Vol. 2A
INSTRUCTION FORMAT
Table 2-1. 16-Bit Addressing Forms with the ModR/M Byte
r8(/r)
AL
CL
DL
BL
AH
CH
DH
BH
r16(/r)
AX
CX
DX
BX
SP
BP1
SI
DI
r32(/r)
EAX
ECX
EDX
EBX
ESP
EBP
ESI
EDI
mm(/r)
MM0
MM1
MM2
MM3
MM4
MM5
MM6
MM7
xmm(/r)
XMM0
XMM1
XMM2
XMM3
XMM4
XMM5
XMM6
XMM7
(In decimal) /digit (Opcode)
0
1
2
3
4
5
6
7
(In binary) REG =
000
001
010
011
100
101
110
111
Effective Address
Mod
R/M
Value of ModR/M Byte (in Hexadecimal)
[BX+SI]
00
000
00
08
10
18
20
28
30
38
[BX+DI]
001
01
09
11
19
21
29
31
39
[BP+SI]
010
02
0A
12
1A
22
2A
32
3A
[BP+DI]
011
03
0B
13
1B
23
2B
33
3B
[SI]
100
04
0C
14
1C
24
2C
34
3C
[DI]
101
05
0D
15
1D
25
2D
35
3D
disp162
110
06
0E
16
1E
26
2E
36
3E
[BX]
111
07
0F
17
1F
27
2F
37
3F
[BX+SI]+disp83
01
000
40
48
50
58
60
68
70
78
[BX+DI]+disp8
001
41
49
51
59
61
69
71
79
[BP+SI]+disp8
010
42
4A
52
5A
62
6A
72
7A
[BP+DI]+disp8
011
43
4B
53
5B
63
6B
73
7B
[SI]+disp8
100
44
4C
54
5C
64
6C
74
7C
[DI]+disp8
101
45
4D
55
5D
65
6D
75
7D
[BP]+disp8
110
46
4E
56
5E
66
6E
76
7E
[BX]+disp8
111
47
4F
57
5F
67
6F
77
7F
[BX+SI]+disp16
10
000
80
88
90
98
A0
A8
B0
B8
[BX+DI]+disp16
001
81
89
91
99
A1
A9
B1
B9
[BP+SI]+disp16
010
82
8A
92
9A
A2
AA
B2
BA
[BP+DI]+disp16
011
83
8B
93
9B
A3
AB
B3
BB
[SI]+disp16
100
84
8C
94
9C
A4
AC
B4
BC
[DI]+disp16
101
85
8D
95
9D
A5
AD
B5
BD
[BP]+disp16
110
86
8E
96
9E
A6
AE
B6
BE
[BX]+disp16
111
87
8F
97
9F
A7
AF
B7
BF
EAX/AX/AL/MM0/XMM0
11
000
C0
C8
D0
D8
E0
E8
F0
F8
ECX/CX/CL/MM1/XMM1
001
C1
C9
D1
D9
E1
E9
F1
F9
EDX/DX/DL/MM2/XMM2
010
C2
CA
D2
DA
E2
EA
F2
FA
EBX/BX/BL/MM3/XMM3
011
C3
CB
D3
DB
E3
EB
F3
FB
ESP/SP/AHMM4/XMM4
100
C4
CC
D4
DC
E4
EC
F4
FC
EBP/BP/CH/MM5/XMM5
101
C5
CD
D5
DD
E5
ED
F5
FD
ESI/SI/DH/MM6/XMM6
110
C6
CE
D6
DE
E6
EE
F6
FE
EDI/DI/BH/MM7/XMM7
111
C7
CF
D7
DF
E7
EF
F7
FF
NOTES:
1. The default segment register is SS for the effective addresses containing a BP index, DS for other effective addresses.
2. The disp16 nomenclature denotes a 16-bit displacement that follows the ModR/M byte and that is added to the index.
3. The disp8 nomenclature denotes an 8-bit displacement that follows the ModR/M byte and that is sign-extended and added to the
index.
Vol. 2A
2-5
INSTRUCTION FORMAT
Table 2-2. 32-Bit Addressing Forms with the ModR/M Byte
r8(/r)
AL
CL
DL
BL
AH
CH
DH
BH
r16(/r)
AX
CX
DX
BX
SP
BP
SI
DI
r32(/r)
EAX
ECX
EDX
EBX
ESP
EBP
ESI
EDI
mm(/r)
MM0
MM1
MM2
MM3
MM4
MM5
MM6
MM7
xmm(/r)
XMM0
XMM1
XMM2
XMM3
XMM4
XMM5
XMM6
XMM7
(In decimal) /digit (Opcode)
0
1
2
3
4
5
6
7
(In binary) REG =
000
001
010
011
100
101
110
111
Effective Address
Mod
R/M
Value of ModR/M Byte (in Hexadecimal)
[EAX]
00
000
00
08
10
18
20
28
30
38
[ECX]
001
01
09
11
19
21
29
31
39
[EDX]
010
02
0A
12
1A
22
2A
32
3A
[EBX]
011
03
0B
13
1B
23
2B
33
3B
[--][--]1
100
04
0C
14
1C
24
2C
34
3C
disp322
101
05
0D
15
1D
25
2D
35
3D
[ESI]
110
06
0E
16
1E
26
2E
36
3E
[EDI]
111
07
0F
17
1F
27
2F
37
3F
[EAX]+disp83
01
000
40
48
50
58
60
68
70
78
[ECX]+disp8
001
41
49
51
59
61
69
71
79
[EDX]+disp8
010
42
4A
52
5A
62
6A
72
7A
[EBX]+disp8
011
43
4B
53
5B
63
6B
73
7B
[--][--]+disp8
100
44
4C
54
5C
64
6C
74
7C
[EBP]+disp8
101
45
4D
55
5D
65
6D
75
7D
[ESI]+disp8
110
46
4E
56
5E
66
6E
76
7E
[EDI]+disp8
111
47
4F
57
5F
67
6F
77
7F
[EAX]+disp32
10
000
80
88
90
98
A0
A8
B0
B8
[ECX]+disp32
001
81
89
91
99
A1
A9
B1
B9
[EDX]+disp32
010
82
8A
92
9A
A2
AA
B2
BA
[EBX]+disp32
011
83
8B
93
9B
A3
AB
B3
BB
[--][--]+disp32
100
84
8C
94
9C
A4
AC
B4
BC
[EBP]+disp32
101
85
8D
95
9D
A5
AD
B5
BD
[ESI]+disp32
110
86
8E
96
9E
A6
AE
B6
BE
[EDI]+disp32
111
87
8F
97
9F
A7
AF
B7
BF
EAX/AX/AL/MM0/XMM0
11
000
C0
C8
D0
D8
E0
E8
F0
F8
ECX/CX/CL/MM/XMM1
001
C1
C9
D1
D9
E1
E9
F1
F9
EDX/DX/DL/MM2/XMM2
010
C2
CA
D2
DA
E2
EA
F2
FA
EBX/BX/BL/MM3/XMM3
011
C3
CB
D3
DB
E3
EB
F3
FB
ESP/SP/AH/MM4/XMM4
100
C4
CC
D4
DC
E4
EC
F4
FC
EBP/BP/CH/MM5/XMM5
101
C5
CD
D5
DD
E5
ED
F5
FD
ESI/SI/DH/MM6/XMM6
110
C6
CE
D6
DE
E6
EE
F6
FE
EDI/DI/BH/MM7/XMM7
111
C7
CF
D7
DF
E7
EF
F7
FF
NOTES:
1. The [--][--] nomenclature means a SIB follows the ModR/M byte.
2. The disp32 nomenclature denotes a 32-bit displacement that follows the ModR/M byte (or the SIB byte if one is present) and that is
added to the index.
3. The disp8 nomenclature denotes an 8-bit displacement that follows the ModR/M byte (or the SIB byte if one is present) and that is
sign-extended and added to the index.
Table 2-3 is organized to give 256 possible values of the SIB byte (in hexadecimal). General purpose registers used
as a base are indicated across the top of the table, along with corresponding values for the SIB byte’s base field.
Table rows in the body of the table indicate the register used as the index (SIB byte bits 3, 4, and 5) and the scaling
factor (determined by SIB byte bits 6 and 7).
2-6
Vol. 2A
INSTRUCTION FORMAT
Table 2-3. 32-Bit Addressing Forms with the SIB Byte
r32
EAX
ECX
EDX
EBX
ESP
[*]
ESI
EDI
(In decimal) Base =
0
1
2
3
4
5
6
7
(In binary) Base =
000
001
010
011
100
101
110
111
Scaled Index
SS
Index
Value of SIB Byte (in Hexadecimal)
[EAX]
00
000
00
01
02
03
04
05
06
07
[ECX]
001
08
09
0A
0B
0C
0D
0E
0F
[EDX]
010
10
11
12
13
14
15
16
17
[EBX]
011
18
19
1A
1B
1C
1D
1E
1F
none
100
20
21
22
23
24
25
26
27
[EBP]
101
28
29
2A
2B
2C
2D
2E
2F
[ESI]
110
30
31
32
33
34
35
36
37
[EDI]
111
38
39
3A
3B
3C
3D
3E
3F
[EAX*2]
01
000
40
41
42
43
44
45
46
47
[ECX*2]
001
48
49
4A
4B
4C
4D
4E
4F
[EDX*2]
010
50
51
52
53
54
55
56
57
[EBX*2]
011
58
59
5A
5B
5C
5D
5E
5F
none
100
60
61
62
63
64
65
66
67
[EBP*2]
101
68
69
6A
6B
6C
6D
6E
6F
[ESI*2]
110
70
71
72
73
74
75
76
77
[EDI*2]
111
78
79
7A
7B
7C
7D
7E
7F
[EAX*4]
10
000
80
81
82
83
84
85
86
87
[ECX*4]
001
88
89
8A
8B
8C
8D
8E
8F
[EDX*4]
010
90
91
92
93
94
95
96
97
[EBX*4]
011
98
99
9A
9B
9C
9D
9E
9F
none
100
A0
A1
A2
A3
A4
A5
A6
A7
[EBP*4]
101
A8
A9
AA
AB
AC
AD
AE
AF
[ESI*4]
110
B0
B1
B2
B3
B4
B5
B6
B7
[EDI*4]
111
B8
B9
BA
BB
BC
BD
BE
BF
[EAX*8]
11
000
C0
C1
C2
C3
C4
C5
C6
C7
[ECX*8]
001
C8
C9
CA
CB
CC
CD
CE
CF
[EDX*8]
010
D0
D1
D2
D3
D4
D5
D6
D7
[EBX*8]
011
D8
D9
DA
DB
DC
DD
DE
DF
none
100
E0
E1
E2
E3
E4
E5
E6
E7
[EBP*8]
101
E8
E9
EA
EB
EC
ED
EE
EF
[ESI*8]
110
F0
F1
F2
F3
F4
F5
F6
F7
[EDI*8]
111
F8
F9
FA
FB
FC
FD
FE
FF
NOTES:
1. The [*] nomenclature means a disp32 with no base if the MOD is 00B. Otherwise, [*] means disp8 or disp32 + [EBP]. This provides the
following address modes:
MOD bits Effective Address
00
[scaled index] + disp32
01
[scaled index] + disp8 + [EBP]
10
[scaled index] + disp32 + [EBP]
2.2
IA-32E MODE
IA-32e mode has two sub-modes. These are:
• Compatibility Mode. Enables a 64-bit operating system to run most legacy protected mode software
unmodified.
•
64-Bit Mode. Enables a 64-bit operating system to run applications written to access 64-bit address space.
2.2.1
REX Prefixes
REX prefixes are instruction-prefix bytes used in 64-bit mode. They do the following:
• Specify GPRs and SSE registers.
Vol. 2A
2-7
INSTRUCTION FORMAT
• Specify 64-bit operand size.
• Specify extended control registers.
Not all instructions require a REX prefix in 64-bit mode. A prefix is necessary only if an instruction references one
of the extended registers or uses a 64-bit operand. If a REX prefix is used when it has no meaning, it is ignored, as
are individual bits in the prefix when they have no meaning.
Only one meaningful REX prefix is allowed per instruction. If used, the REX prefix byte must immediately precede
the opcode byte or the escape opcode byte (0FH). When a REX prefix is used in conjunction with an instruction
containing a mandatory prefix, the mandatory prefix must come before the REX so the REX prefix can immediately
precede the opcode or the escape byte. For example, CVTDQ2PD with a REX prefix should have REX placed
between F3 and 0F E6. Other placements are ignored. The instruction-size limit of 15 bytes still applies to instruc-
tions with a REX prefix. See Figure 2-3.
Legacy
REX
Opcode
ModR/M
SIB
Displacement
Immediate
Prefixes
Prefix
(optional)
1-, 2-, or
1 byte
Address
Immediate data
1 byte
Grp 1,
Grp
3-byte
(if required)
displacement of
of 1, 2, or 4
(if required)
2, Grp 3,
Grp 4
opcode
1, 2, or 4 bytes
bytes or none
(optional)
Figure 2-3. Prefix Ordering in 64-bit Mode
2.2.1.1
Encoding
Intel 64 and IA-32 instruction formats specify up to three registers by using 3-bit fields in the encoding, depending
on the format:
• ModR/M: the reg and r/m fields of the ModR/M byte.
• ModR/M with SIB: the reg field of the ModR/M byte, the base and index fields of the SIB (scale, index, base)
byte.
• Instructions without ModR/M: the reg field of the opcode.
In 64-bit mode, these formats do not change. Bits needed to define fields in the 64-bit context are provided by the
addition of REX prefixes.
2.2.1.2
More on REX Prefix Fields
REX prefixes are a set of 16 opcodes that span one row of the opcode map and occupy entries 40H to 4FH. These
opcodes represent valid instructions (INC or DEC) in IA-32 operating modes and in compatibility mode. In 64-bit
mode, the same opcodes represent the instruction prefix REX and are not treated as individual instructions.
The single-byte-opcode forms of the INC/DEC instructions are not available in 64-bit mode. INC/DEC functionality
is still available using ModR/M forms of the same instructions (opcodes FF/0 and FF/1).
See Table 2-4 for a summary of the REX prefix format. Figure 2-4 though Figure 2-7 show examples of REX prefix
fields in use. Some combinations of REX prefix fields are invalid. In such cases, the prefix is ignored. Some addi-
tional information follows:
• Setting REX.W can be used to determine the operand size but does not solely determine operand width. Like
the 66H size prefix, 64-bit operand size override has no effect on byte-specific operations.
• For non-byte operations: if a 66H prefix is used with prefix (REX.W = 1), 66H is ignored.
• If a 66H override is used with REX and REX.W = 0, the operand size is 16 bits.
• REX.R modifies the ModR/M reg field when that field encodes a GPR, SSE, control or debug register. REX.R is
ignored when ModR/M specifies other registers or defines an extended opcode.
• REX.X bit modifies the SIB index field.
2-8
Vol. 2A
INSTRUCTION FORMAT
• REX.B either modifies the base in the ModR/M r/m field or SIB base field; or it modifies the opcode reg field
used for accessing GPRs.
Table 2-4. REX Prefix Fields [BITS: 0100WRXB]
Field Name
Bit Position
Definition
-
7:4
0100
W
3
0 = Operand size determined by CS.D
1 = 64 Bit Operand Size
R
2
Extension of the ModR/M reg field
X
1
Extension of the SIB index field
B
0
Extension of the ModR/M r/m field, SIB base field, or Opcode reg field
ModRM Byte
REX PREFIX
Opcode
mod
reg
r/m
0100WR0B
≠11
rrr
bbb
Rrrr
Bbbb
OM17Xfig1-3
Figure 2-4. Memory Addressing Without an SIB Byte; REX.X Not Used
ModRM Byte
REX PREFIX
Opcode
mod
reg
r/m
0100WR0B
11
rrr
bbb
Rrrr
Bbbb
OM17Xfig1-4
Figure 2-5. Register-Register Addressing (No Memory Operand); REX.X Not Used
Vol. 2A
2-9
INSTRUCTION FORMAT
ModRM Byte
SIB Byte
REX PREFIX
Opcode
mod
reg
r/m
scale
index
base
0100WRXB
≠ 11
rrr
100
ss
xxx
bbb
Rrrr
Xxxx
Bbbb
OM17Xfig1-5
Figure 2-6. Memory Addressing With a SIB Byte
REX PREFIX
Opcode
reg
0100W00B
bbb
Bbbb
OM17Xfig1-6
Figure 2-7. Register Operand Coded in Opcode Byte; REX.X & REX.R Not Used
In the IA-32 architecture, byte registers (AH, AL, BH, BL, CH, CL, DH, and DL) are encoded in the ModR/M byte’s
reg field, the r/m field or the opcode reg field as registers 0 through 7. REX prefixes provide an additional
addressing capability for byte-registers that makes the least-significant byte of GPRs available for byte operations.
Certain combinations of the fields of the ModR/M byte and the SIB byte have special meaning for register encod-
ings. For some combinations, fields expanded by the REX prefix are not decoded. Table 2-5 describes how each
case behaves.
2-10
Vol. 2A
INSTRUCTION FORMAT
Table 2-5. Special Cases of REX Encodings
ModR/M or
Sub-field
Compatibility Mode
Compatibility Mode
SIB
Encodings
Operation
Implications
Additional Implications
ModR/M Byte
mod ? 11
SIB byte present.
SIB byte required for
REX prefix adds a fourth bit (b) which is not decoded
ESP-based addressing.
(don't care).
r/m =
b*100(ESP)
SIB byte also required for R12-based addressing.
ModR/M Byte
mod = 0
Base register not
EBP without a
REX prefix adds a fourth bit (b) which is not decoded
used.
displacement must be
(don't care).
r/m =
done using
b*101(EBP)
Using RBP or R13 without displacement must be done
mod = 01 with
using mod = 01 with a displacement of 0.
displacement of 0.
SIB Byte
index =
Index register not
ESP cannot be used as
REX prefix adds a fourth bit (b) which is decoded.
0100(ESP)
used.
an index register.
There are no additional implications. The expanded
index field allows distinguishing RSP from R12,
therefore R12 can be used as an index.
SIB Byte
base =
Base register is
Base register depends
REX prefix adds a fourth bit (b) which is not decoded.
0101(EBP)
unused if mod = 0.
on mod encoding.
This requires explicit displacement to be used with
EBP/RBP or R13.
NOTES:
* Don’t care about value of REX.B
2.2.1.3
Displacement
Addressing in 64-bit mode uses existing 32-bit ModR/M and SIB encodings. The ModR/M and SIB displacement
sizes do not change. They remain 8 bits or 32 bits and are sign-extended to 64 bits.
2.2.1.4
Direct Memory-Offset MOVs
In 64-bit mode, direct memory-offset forms of the MOV instruction are extended to specify a 64-bit immediate
absolute address. This address is called a moffset. No prefix is needed to specify this 64-bit memory offset. For
these MOV instructions, the size of the memory offset follows the address-size default (64 bits in 64-bit mode). See
Table 2-6.
Table 2-6. Direct Memory Offset Form of MOV
Opcode
Instruction
A0
MOV AL, moffset
A1
MOV EAX, moffset
A2
MOV moffset, AL
A3
MOV moffset, EAX
2.2.1.5
Immediates
In 64-bit mode, the typical size of immediate operands remains 32 bits. When the operand size is 64 bits, the
processor sign-extends all immediates to 64 bits prior to their use.
Support for 64-bit immediate operands is accomplished by expanding the semantics of the existing move (MOV
reg, imm16/32) instructions. These instructions (opcodes B8H - BFH) move 16-bits or 32-bits of immediate data
(depending on the effective operand size) into a GPR. When the effective operand size is 64 bits, these instructions
can be used to load an immediate into a GPR. A REX prefix is needed to override the 32-bit default operand size to
a 64-bit operand size.
For example:
48 B8
8877665544332211 MOV RAX,1122334455667788H
Vol. 2A
2-11
INSTRUCTION FORMAT
2.2.1.6
RIP-Relative Addressing
A new addressing form, RIP-relative (relative instruction-pointer) addressing, is implemented in 64-bit mode. An
effective address is formed by adding displacement to the 64-bit RIP of the next instruction.
In IA-32 architecture and compatibility mode, addressing relative to the instruction pointer is available only with
control-transfer instructions. In 64-bit mode, instructions that use ModR/M addressing can use RIP-relative
addressing. Without RIP-relative addressing, all ModR/M modes address memory relative to zero.
RIP-relative addressing allows specific ModR/M modes to address memory relative to the 64-bit RIP using a signed
32-bit displacement. This provides an offset range of ±2GB from the RIP. Table 2-7 shows the ModR/M and SIB
encodings for RIP-relative addressing. Redundant forms of 32-bit displacement-addressing exist in the current
ModR/M and SIB encodings. There is one ModR/M encoding and there are several SIB encodings. RIP-relative
addressing is encoded using a redundant form.
In 64-bit mode, the ModR/M Disp32 (32-bit displacement) encoding is re-defined to be RIP+Disp32 rather than
displacement-only. See Table 2-7.
Table 2-7. RIP-Relative Addressing
ModR/M and SIB Sub-field Encodings
Compatibility Mode
64-bit Mode
Additional Implications in 64-bit mode
Operation
Operation
ModR/M Byte
mod = 00
Disp32
RIP + Disp32
In 64-bit mode, if one wants to use a Disp32
without specifying a base register, one can use a
r/m = 101 (none)
SIB byte encoding (indicated by ModR/M.r/m=100)
as described in the next row.
SIB Byte
base = 101 (none)
If mod = 00, Disp32
Same as legacy
None
index = 100 (none)
scale = 0, 1, 2, 4
The ModR/M encoding for RIP-relative addressing does not depend on using a prefix. Specifically, the r/m bit field
encoding of 101B (used to select RIP-relative addressing) is not affected by the REX prefix. For example, selecting
R13 (REX.B = 1, r/m = 101B) with mod = 00B still results in RIP-relative addressing. The 4-bit r/m field of REX.B
combined with ModR/M is not fully decoded. In order to address R13 with no displacement, software must encode
R13 + 0 using a 1-byte displacement of zero.
RIP-relative addressing is enabled by 64-bit mode, not by a 64-bit address-size. The use of the address-size prefix
does not disable RIP-relative addressing. The effect of the address-size prefix is to truncate and zero-extend the
computed effective address to 32 bits.
2.2.1.7
Default 64-Bit Operand Size
In 64-bit mode, two groups of instructions have a default operand size of 64 bits (do not need a REX prefix for this
operand size). These are:
• Near branches.
• All instructions, except far branches, that implicitly reference the RSP.
2.2.2
Additional Encodings for Control and Debug Registers
In 64-bit mode, more encodings for control and debug registers are available. The REX.R bit is used to modify the
ModR/M reg field when that field encodes a control or debug register (see Table 2-4). These encodings enable the
processor to address CR8-CR15 and DR8- DR15. An additional control register (CR8) is defined in 64-bit mode. CR8
becomes the Task Priority Register (TPR).
In the first implementation of IA-32e mode, CR9-CR15 and DR8-DR15 are not implemented. Any attempt to access
unimplemented registers results in an invalid-opcode exception (#UD).
2-12
Vol. 2A
INSTRUCTION FORMAT
2.3
INTEL® ADVANCED VECTOR EXTENSIONS (INTEL® AVX)
Intel AVX instructions are encoded using an encoding scheme that combines prefix bytes, opcode extension field,
operand encoding fields, and vector length encoding capability into a new prefix, referred to as VEX. In the VEX
encoding scheme, the VEX prefix may be two or three bytes long, depending on the instruction semantics. Despite
the two-byte or three-byte length of the VEX prefix, the VEX encoding format provides a more compact represen-
tation/packing of the components of encoding an instruction in Intel 64 architecture. The VEX encoding scheme
also allows more headroom for future growth of Intel 64 architecture.
2.3.1
Instruction Format
Instruction encoding using VEX prefix provides several advantages:
• Instruction syntax support for three operands and up-to four operands when necessary. For example, the third
source register used by VBLENDVPD is encoded using bits 7:4 of the immediate byte.
• Encoding support for vector length of 128 bits (using XMM registers) and 256 bits (using YMM registers).
• Encoding support for instruction syntax of non-destructive source operands.
• Elimination of escape opcode byte (0FH), SIMD prefix byte (66H, F2H, F3H) via a compact bit field represen-
tation within the VEX prefix.
• Elimination of the need to use REX prefix to encode the extended half of general-purpose register sets (R8-
R15) for direct register access, memory addressing, or accessing XMM8-XMM15 (including YMM8-YMM15).
• Flexible and more compact bit fields are provided in the VEX prefix to retain the full functionality provided by
REX prefix. REX.W, REX.X, REX.B functionalities are provided in the three-byte VEX prefix only because only a
subset of SIMD instructions need them.
• Extensibility for future instruction extensions without significant instruction length increase.
Figure 2-8 shows the Intel 64 instruction encoding format with VEX prefix support. Legacy instruction without a
VEX prefix is fully supported and unchanged. The use of VEX prefix in an Intel 64 instruction is optional, but a VEX
prefix is required for Intel 64 instructions that operate on YMM registers or support three and four operand syntax.
VEX prefix is not a constant-valued, “single-purpose” byte like 0FH, 66H, F2H, F3H in legacy SSE instructions. VEX
prefix provides substantially richer capability than the REX prefix.
# Bytes
2,3
1
1
0,1
0,1,2,4
0,1
[Prefixes]
[VEX]
OPCODE
ModR/M
[SIB]
[DISP]
[IMM]
Figure 2-8. Instruction Encoding Format with VEX Prefix
2.3.2
VEX and the LOCK prefix
Any VEX-encoded instruction with a LOCK prefix preceding VEX will #UD.
2.3.3
VEX and the 66H, F2H, and F3H prefixes
Any VEX-encoded instruction with a 66H, F2H, or F3H prefix preceding VEX will #UD.
2.3.4
VEX and the REX prefix
Any VEX-encoded instruction with a REX prefix proceeding VEX will #UD.
Vol. 2A
2-13
INSTRUCTION FORMAT
2.3.5
The VEX Prefix
The VEX prefix is encoded in either the two-byte form (the first byte must be C5H) or in the three-byte form (the
first byte must be C4H). The two-byte VEX is used mainly for 128-bit, scalar, and the most common 256-bit AVX
instructions; while the three-byte VEX provides a compact replacement of REX and 3-byte opcode instructions
(including AVX and FMA instructions). Beyond the first byte of the VEX prefix, it consists of a number of bit fields
providing specific capability, they are shown in Figure 2-9.
The bit fields of the VEX prefix can be summarized by its functional purposes:
• Non-destructive source register encoding (applicable to three and four operand syntax): This is the first source
operand in the instruction syntax. It is represented by the notation, VEX.vvvv. This field is encoded using 1’s
complement form (inverted form), i.e., XMM0/YMM0/R0 is encoded as 1111B, XMM15/YMM15/R15 is encoded
as 0000B.
• Vector length encoding: This 1-bit field represented by the notation VEX.L. L= 0 means vector length is 128 bits
wide, L=1 means 256 bit vector. The value of this field is written as VEX.128 or VEX.256 in this document to
distinguish encoded values of other VEX bit fields.
• REX prefix functionality: Full REX prefix functionality is provided in the three-byte form of VEX prefix. However
the VEX bit fields providing REX functionality are encoded using 1’s complement form, i.e., XMM0/YMM0/R0 is
encoded as 1111B, XMM15/YMM15/R15 is encoded as 0000B.
- Two-byte form of the VEX prefix only provides the equivalent functionality of REX.R, using 1’s complement
encoding. This is represented as VEX.R.
- Three-byte form of the VEX prefix provides REX.R, REX.X, REX.B functionality using 1’s complement
encoding and three dedicated bit fields represented as VEX.R, VEX.X, VEX.B.
- Three-byte form of the VEX prefix provides the functionality of REX.W only to specific instructions that need
to override default 32-bit operand size for a general purpose register to 64-bit size in 64-bit mode. For
those applicable instructions, VEX.W field provides the same functionality as REX.W. VEX.W field can
provide completely different functionality for other instructions.
Consequently, the use of REX prefix with VEX encoded instructions is not allowed. However, the intent of the
REX prefix for expanding register set is reserved for future instruction set extensions using VEX prefix
encoding format.
• Compaction of SIMD prefix: Legacy SSE instructions effectively use SIMD prefixes (66H, F2H, F3H) as an
opcode extension field. VEX prefix encoding allows the functional capability of such legacy SSE instructions
(operating on XMM registers, bits 255:128 of corresponding YMM unmodified) to be encoded using the VEX.pp
field without the presence of any SIMD prefix. The VEX-encoded 128-bit instruction will zero-out bits 255:128
of the destination register. VEX-encoded instruction may have 128 bit vector length or 256 bits length.
• Compaction of two-byte and three-byte opcode: More recently introduced legacy SSE instructions employ two
and three-byte opcode. The one or two leading bytes are: 0FH, and 0FH 3AH/0FH 38H. The one-byte escape
(0FH) and two-byte escape (0FH 3AH, 0FH 38H) can also be interpreted as an opcode extension field. The
VEX.mmmmm field provides compaction to allow many legacy instruction to be encoded without the constant
byte sequence, 0FH, 0FH 3AH, 0FH 38H. These VEX-encoded instruction may have 128 bit vector length or 256
bits length.
The VEX prefix is required to be the last prefix and immediately precedes the opcode bytes. It must follow any other
prefixes. If VEX prefix is present a REX prefix is not supported.
The 3-byte VEX leaves room for future expansion with 3 reserved bits. REX and the 66h/F2h/F3h prefixes are
reclaimed for future use.
VEX prefix has a two-byte form and a three byte form. If an instruction syntax can be encoded using the two-byte
form, it can also be encoded using the three byte form of VEX. The latter increases the length of the instruction by
one byte. This may be helpful in some situations for code alignment.
The VEX prefix supports 256-bit versions of floating-point SSE, SSE2, SSE3, and SSE4 instructions. Note, certain
new instruction functionality can only be encoded with the VEX prefix.
The VEX prefix will #UD on any instruction containing MMX register sources or destinations.
2-14
Vol. 2A
INSTRUCTION FORMAT
Byte 0
Byte 1
Byte 2
(Bit Position) 7
0
7
6
5
4
0
7
6
3
2
1
0
3-byte VEX
11000100
R X B
m-mmmm
W
vvvv
L
pp
7
0
7
6
3
2
1
0
2-byte VEX
11000101
R
vvvv
L
pp
R: REX.R in 1’s complement (inverted) form
1: Same as REX.R=0 (must be 1 in 32-bit mode)
0: Same as REX.R=1 (64-bit mode only)
X: REX.X in 1’s complement (inverted) form
1: Same as REX.X=0 (must be 1 in 32-bit mode)
0: Same as REX.X=1 (64-bit mode only)
B: REX.B in 1’s complement (inverted) form
1: Same as REX.B=0 (Ignored in 32-bit mode).
0: Same as REX.B=1 (64-bit mode only)
W: opcode specific (use like REX.W, or used for opcode
extension, or ignored, depending on the opcode byte)
m-mmmm:
00000: Reserved for future use (will #UD)
00001: implied 0F leading opcode byte
00010: implied 0F 38 leading opcode bytes
00011: implied 0F 3A leading opcode bytes
00100-11111: Reserved for future use (will #UD)
vvvv: a register specifier (in 1’s complement form) or 1111 if unused.
L: Vector Length
0: scalar or 128-bit vector
1: 256-bit vector
pp: opcode extension providing equivalent functionality of a SIMD prefix
00: None
01: 66
10: F3
11: F2
Figure 2-9. VEX bit fields
The following subsections describe the various fields in two or three-byte VEX prefix.
2.3.5.1
VEX Byte 0, bits[7:0]
VEX Byte 0, bits [7:0] must contain the value 11000101b (C5h) or 11000100b (C4h). The 3-byte VEX uses the C4h
first byte, while the 2-byte VEX uses the C5h first byte.
2.3.5.2
VEX Byte 1, bit [7] - ‘R’
VEX Byte 1, bit [7] contains a bit analogous to a bit inverted REX.R. In protected and compatibility modes the bit
must be set to ‘1’ otherwise the instruction is LES or LDS.
Vol. 2A
2-15
INSTRUCTION FORMAT
This bit is present in both 2- and 3-byte VEX prefixes.
The usage of WRXB bits for legacy instructions is explained in detail section 2.2.1.2 of Intel 64 and IA-32 Architec-
tures Software developer’s manual, Volume 2A.
This bit is stored in bit inverted format.
2.3.5.3
3-byte VEX byte 1, bit[6] - ‘X’
Bit[6] of the 3-byte VEX byte 1 encodes a bit analogous to a bit inverted REX.X. It is an extension of the SIB Index
field in 64-bit modes. In 32-bit modes, this bit must be set to ‘1’ otherwise the instruction is LES or LDS.
This bit is available only in the 3-byte VEX prefix.
This bit is stored in bit inverted format.
2.3.5.4
3-byte VEX byte 1, bit[5] - ‘B’
Bit[5] of the 3-byte VEX byte 1 encodes a bit analogous to a bit inverted REX.B. In 64-bit modes, it is an extension
of the ModR/M r/m field, or the SIB base field. In 32-bit modes, this bit is ignored.
This bit is available only in the 3-byte VEX prefix.
This bit is stored in bit inverted format.
2.3.5.5
3-byte VEX byte 2, bit[7] - ‘W’
Bit[7] of the 3-byte VEX byte 2 is represented by the notation VEX.W. It can provide following functions, depending
on the specific opcode.
• For AVX instructions that have equivalent legacy SSE instructions (typically these SSE instructions have a
general-purpose register operand with its operand size attribute promotable by REX.W), if REX.W promotes
the operand size attribute of the general-purpose register operand in legacy SSE instruction, VEX.W has same
meaning in the corresponding AVX equivalent form. In 32-bit modes for these instructions, VEX.W is silently
ignored.
• For AVX instructions that have equivalent legacy SSE instructions (typically these SSE instructions have oper-
ands with their operand size attribute fixed and not promotable by REX.W), if REX.W is don’t care in legacy
SSE instruction, VEX.W is ignored in the corresponding AVX equivalent form irrespective of mode.
• For new AVX instructions where VEX.W has no defined function (typically these meant the combination of the
opcode byte and VEX.mmmmm did not have any equivalent SSE functions), VEX.W is reserved as zero and
setting to other than zero will cause instruction to #UD.
2.3.5.6
2-byte VEX Byte 1, bits[6:3] and 3-byte VEX Byte 2, bits [6:3]- ‘vvvv’ the Source or Dest
Register Specifier
In 32-bit mode the VEX first byte C4 and C5 alias onto the LES and LDS instructions. To maintain compatibility with
existing programs the VEX 2nd byte, bits [7:6] must be 11b. To achieve this, the VEX payload bits are selected to
place only inverted, 64-bit valid fields (extended register selectors) in these upper bits.
The 2-byte VEX Byte 1, bits [6:3] and the 3-byte VEX, Byte 2, bits [6:3] encode a field (shorthand VEX.vvvv) that
for instructions with 2 or more source registers and an XMM or YMM or memory destination encodes the first source
register specifier stored in inverted (1’s complement) form.
VEX.vvvv is not used by the instructions with one source (except certain shifts, see below) or on instructions with
no XMM or YMM or memory destination. If an instruction does not use VEX.vvvv then it should be set to 1111b
otherwise instruction will #UD.
In 64-bit mode all 4 bits may be used. See Table 2-8 for the encoding of the XMM or YMM registers. In 32-bit and
16-bit modes bit 6 must be 1 (if bit 6 is not 1, the 2-byte VEX version will generate LDS instruction and the 3-byte
VEX version will ignore this bit).
2-16
Vol. 2A
//////////////////////////////////////////