In the x86 architecture, the CPUID instruction (identified by a CPUIDopcode) is a processor supplementary instruction (its name derived from CPU Identification) allowing software to discover details of the processor. It was introduced by Intel in 1993 with the launch of the Pentium and SL-enhanced 486 processors.[1]
A program can use the CPUID to determine processor type and whether features such as MMX/SSE are implemented.
History
Prior to the general availability of the CPUID instruction, programmers would write esoteric machine code which exploited minor differences in CPU behavior in order to determine the processor make and model.[2][3][4][5] With the introduction of the 80386 processor, EDX on reset indicated the revision but this was only readable after reset and there was no standard way for applications to read the value.
Outside the x86 family, developers are mostly still required to use esoteric processes (involving instruction timing or CPU fault triggers) to determine the variations in CPU design that are present.
In the Motorola 680x0 family — that never had a CPUID instruction of any kind — certain specific instructions required elevated privileges. These could be used to tell various CPU family members apart. In the Motorola 68010 the instruction MOVE from SR became privileged. This notable instruction (and state machine) change allowed the 68010 to meet the Popek and Goldberg virtualization requirements. Because the 68000 offered an unprivileged MOVE from SR the 2 different CPUs could be told apart by a CPU error condition being triggered.
While the CPUID instruction is specific to the x86 architecture, other architectures (like ARM) often provide on-chip registers which can be read in prescribed ways to obtain the same sorts of information provided by the x86 CPUID instruction.
Calling CPUID
The CPUID opcode is 0F A2.
In assembly language, the CPUID instruction takes no parameters as CPUID implicitly uses the EAX register to determine the main category of information returned. In Intel's more recent terminology, this is called the CPUID leaf. CPUID should be called with EAX = 0 first, as this will store in the EAX register the highest EAX calling parameter (leaf) that the CPU implements.
To obtain extended function information CPUID should be called with the most significant bit of EAX set. To determine the highest extended function calling parameter, call CPUID with EAX = 80000000h.
CPUID leaves greater than 3 but less than 80000000 are accessible only when the model-specific registers have IA32_MISC_ENABLE.BOOT_NT4 [bit 22] = 0 (which is so by default). As the name suggests, Windows NT 4.0 until SP6 did not boot properly unless this bit was set,[6] but later versions of Windows do not need it, so basic leaves greater than 4 can be assumed visible on current Windows systems. As of April 2024[update], basic valid leaves go up to 23h, but the information returned by some leaves are not disclosed in the publicly available documentation, i.e. they are "reserved".
Some of the more recently added leaves also have sub-leaves, which are selected via the ECX register before calling CPUID.
EAX=0: Highest Function Parameter and Manufacturer ID
This returns the CPU's manufacturer ID string–a twelve-character ASCII string stored in EBX, EDX, ECX (in that order). The highest basic calling parameter (the largest value that EAX can be set to before calling CPUID) is returned in EAX.
Here is a list of processors and the highest function implemented.
"VirtualApple" – Newer versions of Apple Rosetta 2
For instance, on a GenuineIntel processor values returned in EBX is 0x756e6547, EDX is 0x49656e69 and ECX is 0x6c65746e. The following example code displays the vendor ID string as well as the highest calling parameter that the CPU implements.
.intel_syntaxnoprefix.text.m0:.string"CPUID: %x\n".m1:.string"Largest basic function number implemented: %i\n".m2:.string"Vendor ID: %s\n".globlmainmain:pushr12moveax,1subrsp,16cpuidleardi,.m0[rip]movesi,eaxcallprintfmoveax,0cpuidleardi,.m1[rip]movesi,eaxmovr12d,edxmovebp,ecxcallprintfmov3[rsp],ebxlearsi,3[rsp]leardi,.m2[rip]mov7[rsp],r12dmov11[rsp],ebpcallprintfaddrsp,16popr12ret.section.note.GNU-stack,"",@progbits
On some processors, it is possible to modify the Manufacturer ID string reported by CPUID.(EAX=0) by writing a new ID string to particular MSRs (Model-specific registers) using the WRMSR instruction. This has been used on non-Intel processors to enable features and optimizations that have been disabled in software for CPUs that don't return the GenuineIntel ID string.[19] Processors that are known to possess such MSRs include:
This returns the CPU's stepping, model, and family information in register EAX (also called the signature of a CPU), feature flags in registers EDX and ECX, and additional feature info in register EBX.[26]
CPUID EAX=1: Processor Version Information in EAX
EAX
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Reserved
Extended Family ID
Extended Model ID
Reserved
Processor Type
Family ID
Model
Stepping ID
Stepping ID is a product revision number assigned due to fixed errata or other changes.
The actual processor model is derived from the Model, Extended Model ID and Family ID fields. If the Family ID field is either 6 or 15, the model is equal to the sum of the Extended Model ID field shifted left by 4 bits and the Model field. Otherwise, the model is equal to the value of the Model field.
The actual processor family is derived from the Family ID and Extended Family ID fields. If the Family ID field is equal to 15, the family is equal to the sum of the Extended Family ID and the Family ID fields. Otherwise, the family is equal to the value of the Family ID field.
The meaning of the Processor Type field is given in the table below.
↑ The i386 processor does not support the CPUID instruction - it does however return Family ID 3h in the reset-value of EDX.
↑ Family ID 8h has been reported to have been deliberately avoided for the Pentium 4 processor family due to incompatibility with Windows NT 4.0.[37]
CPUID EAX=1: Additional Information in EBX
Bits
EBX
Valid
7:0
Brand Index
15:8
CLFLUSH line size (Value * 8 = cache line size in bytes)
if CLFLUSH feature flag is set.
CPUID.01.EDX.CLFSH [bit 19]= 1
23:16
Maximum number of addressable IDs for logical processors in this physical package;
The nearest power-of-2 integer that is not smaller than this value is the number of unique initial APIC IDs reserved for addressing different logical processors in a physical package.[lower-alpha 1]
Former use: Number of logical processors per physical processor; two for the Pentium 4 processor with Hyper-Threading Technology.[42]
Local APIC ID: The initial APIC-ID is used to identify the executing logical processor.[lower-alpha 2]
Pentium 4 and subsequent processors.
↑ On CPUs with more than 128 logical processors in a single package (e.g. Intel Xeon Phi 7290[40] and AMD Threadripper Pro 7995WX[41]) the value in bit 23:16 is set to a non-power-of-2 value.
↑ The Local APIC ID can also be identified via the cpuid 0Bh leaf ( CPUID.0Bh.EDX[x2APIC-ID] ). On CPUs with more than 256 logical processors in one package (e.g. Xeon Phi 7290), leaf 0Bh must be used because the APIC ID does not fit into 8 bits.
The processor info and feature flags are manufacturer specific but usually, the Intel values are used by other manufacturers for the sake of compatibility.
↑ On some older processors, executing CPUID with a leaf index (EAX) greater than 0 may leave EBX and ECX unmodified, keeping their old values. For this reason, it is recommended to zero out EBX and ECX before executing CPUID with a leaf index of 1.
Processors noted to exhibit this behavior include Cyrix MII[43] and IDT WinChip 2.[44]
↑ On processors from IDT, Transmeta and Rise (vendor IDs CentaurHauls, GenuineTMx86 and RiseRiseRise), the CMPXCHG8B instruction is always supported, however the feature bit for the instruction might not be set. This is a workaround for a bug in Windows NT.[45]
↑ On early AMD K5 (AuthenticAMD Family 5 Model 0) processors only, EDX bit 9 used to indicate support for PGE instead. This was moved to bit 13 from K5 Model 1 onwards.[46]
↑ Intel AP-485, revisions 006[47] to 008, lists CPUID.(EAX=1):EDX[bit 10] as having the name "MTRR" (albeit described as "Reserved"/"Do not count on their value") - this name was removed in later revisions of AP-485, and the bit has been listed as reserved with no name since then.
↑ On Pentium Pro (GenuineIntel Family 6 Model 1) processors only, EDX bit 11 is invalid - the bit is set, but the SYSENTER and SYSEXIT instructions are not supported on the Pentium Pro.[48]
↑ FCMOV and FCOMI instructions only available if onboard x87 FPU also present (indicated by EDX bit 0).
↑ ECX bit 16 is listed as "Reserved" in public Intel and AMD documentation and is not set in any known processor. However, some versions of the Windows Vista kernel are reported to be checking this bit[49] - if it is set, Vista will recognize it as a "processor channels" feature.
↑ On Intel and Transmeta[23] CPUs that support PSN (Processor Serial Number), the PSN can be disabled by setting bit 21 of MSR 119h (BBL_CR_CTL) to 1. Doing so will remove leaf 3 and cause CPUID.(EAX=1):EDX[bit 18] to return 0.
↑ On non-Itanium x86 processors, support for the No-execute bit is indicated in CPUID.(EAX=8000_0001):EDX[bit 20] instead.
↑ EDX bit 28, if set, indicates that bits 23:16 of CPUID.(EAX=1):EBX are valid. If this bit is not set, then the CPU package contains only 1 logical processor.
In older documentation, this bit is often listed as a "Hyper-threading technology"[53] flag - however, while this flag is a prerequisite for Hyper-Threading support, it does not by itself indicate support for Hyper-Threading and it has been set on many CPUs that do not feature any form of multi-threading technology.[54]
Reserved fields should be masked before using them for processor identification purposes.
EAX=2: Cache and TLB Descriptor information
This returns a list of descriptors indicating cache and TLB capabilities in EAX, EBX, ECX and EDX registers.
On processors that support this leaf, calling CPUID with EAX=2 will cause the bottom byte of EAX to be set to 01h[lower-alpha 1] and the remaining 15bytes of EAX/EBX/ECX/EDX to be filled with 15 descriptors, one byte each. These descriptors provide information about the processor's caches, TLBs and prefetch. This is typically one cache or TLB per descriptor, but some descriptor-values provide other information as well - in particular, 00h is used for an empty descriptor, FFh indicates that the leaf does not contain valid cache information and that leaf 4h should be used instead, and FEh indicates that the leaf does not contain valid TLB information and that leaf 18h should be used instead. The descriptors may appear in any order.
For each of the four registers (EAX,EBX,ECX,EDX), if bit 31 is set, then the register should not be considered to contain valid descriptors (e.g. on Itanium in IA-32 mode, CPUID(EAX=2) returns 80000000h in EDX - this should be interpreted to mean that EDX contains no valid information, not that it contains a 512K L2 cache.)
The table below provides, for known descriptor values, a condensed description of the cache or TLB indicated by that descriptor value (or other information, where that applies). The suffixes used in the table are:
K,M,G: binary kilobyte, megabyte, gigabyte (capacity for caches, page-size for TLBs)
E: entries (for TLBs; e.g. 64E = 64 entries)
p: page-size (e.g. 4Kp for TLBs where each entry describes one 4KB page, 4K/2Mp for TLBs where each entry can describe either one 4KB page or one 2MB hugepage)
L: cache-line size (e.g. 32L = 32-byte cache line size)
S: cache sector size (e.g. 2S means that the cache uses sectors of 2 cache-lines each)
A: associativity (e.g. 6A = 6-way set-associative, FA = fully-associative)
↑ In older Intel documentation, the bottom byte of the value returned in EAX is described as specifying the number of times the CPUID must be called with EAX=2 to get hold of all the cache/TLB descriptors. However, all known processors that implement this leaf return 01h in this byte, and newer Intel documentation (SDM rev 053[58] and later) specifies this byte as having the value 01h.
1 2 3 4 5 6 7 8 9 Descriptors 10h, 15h, 1Ah, 88h, 89h, 8Ah, 90h, 96h, 9Bh are documented for the IA-32 operation mode of Itanium only.[59]
1 2 3 4 Descriptor values 26h,27h,28h and 81h are not listed in Intel documentation and are not used in any known CPU, but have been reported to be recognized by the Windows NT kernel v5.1 (Windows XP) and higher. 81h is also recognized by v5.0 (Windows 2000).[66]
1 2 3 4 5 6 7 Descriptors 39h-3Eh and 73h are listed in rev 36 of Intel AP-485,[60] but have been removed from later Intel documentation even though some of them have been used in Intel CPUs (e.g. 39h in "Willamette-128"-based Celeron processors[61]).
↑ Descriptor 49h indicates a level-3 cache on GenuineIntel Family 0Fh Model 6 (Pentium 4 based Xeon) CPUs, and a level-2 cache on other CPUs.
↑ Intel's CPUID documentation does not specify the associativity of the ITLB indicated by descriptor 4Fh. The processors that use this descriptor (Intel Atom "Bonnell"[62]) are listed elsewhere as having a fully-associative 32-entry ITLB.[63]
1 2 On Cyrix and Geode CPUs (Vendor IDs CyrixInstead and Geode by NSC), descriptors 70h and 80h have a different meaning:[64]
Descriptor 70h indicates a 32-entry shared instruction+data 4-way-set-associative TLB with a 4K page size.
Descriptor 80h indicates a 16KB shared instruction+data L1 cache with 4-way set-associativity and a cache-line size of 16bytes.
↑ Descriptor 76h is listed as an 1MB L2 cache in rev 37 of Intel AP-485,[65] but as an instruction TLB in rev 38 and all later Intel documentation.
1 2 3 Descriptors 77h, 7Eh, 8Dh are documented for the IA-32 operation mode of Itanium 2 only.[67]
↑ Under the IA-32 operation mode of Itanium 2, the L3 cache size is always reported as 3MB regardless of the actual size of the cache.[68]
↑ For descriptor B1h, the TLB capacity is 8 elements when using 2MB pages, but reduced to 4 elements when using 4MB pages.
1 2 The prefetch specified by descriptors F0h and F1h is the recommended stride for memory prefetching with the PREFETCHNTA instruction.[71]
This returns the processor's serial number. The processor serial number was introduced on Intel Pentium III, but due to privacy concerns, this feature is no longer implemented on later models (the PSN feature bit is always cleared). Transmeta's Efficeon and Crusoe processors also provide this feature. AMD CPUs however, do not implement this feature in any CPU models.
For Intel Pentium III CPUs, the serial number is returned in the EDX:ECX registers. For Transmeta Efficeon CPUs, it is returned in the EBX:EAX registers. And for Transmeta Crusoe CPUs, it is returned in the EBX register only.
Note that the processor serial number feature must be enabled in the BIOS setting in order to function.
EAX=4 and EAX=Bh: Intel thread/core and cache topology
These two leaves are used for processor topology (thread, core, package) and cache hierarchy enumeration in Intel multi-core (and hyperthreaded) processors.[72]As of 2013[update] AMD does not use these leaves but has alternate ways of doing the core enumeration.[73]
Unlike most other CPUID leaves, leaf Bh will return different values in EDX depending on which logical processor the CPUID instruction runs; the value returned in EDX is actually the x2APIC id of the logical processor. The x2APIC id space is not continuously mapped to logical processors, however; there can be gaps in the mapping, meaning that some intermediate x2APIC ids don't necessarily correspond to any logical processor. Additional information for mapping the x2APIC ids to cores is provided in the other registers. Although the leaf Bh has sub-leaves (selected by ECX as described further below), the value returned in EDX is only affected by the logical processor on which the instruction is running but not by the subleaf.
The processor(s) topology exposed by leaf Bh is a hierarchical one, but with the strange caveat that the order of (logical) levels in this hierarchy doesn't necessarily correspond to the order in the physical hierarchy (SMT/core/package). However, every logical level can be queried as an ECX subleaf (of the Bh leaf) for its correspondence to a "level type", which can be either SMT, core, or "invalid". The level id space starts at 0 and is continuous, meaning that if a level id is invalid, all higher level ids will also be invalid. The level type is returned in bits 15:08 of ECX, while the number of logical processors at the level queried is returned in EBX. Finally, the connection between these levels and x2APIC ids is returned in EAX[4:0] as the number of bits that the x2APIC id must be shifted in order to obtain a unique id at the next level.
As an example, a dual-core Westmere processor capable of hyperthreading (thus having two cores and four threads in total) could have x2APIC ids 0, 1, 4 and 5 for its four logical processors. Leaf Bh (=EAX), subleaf 0 (=ECX) of CPUID could for instance return 100h in ECX, meaning that level 0 describes the SMT (hyperthreading) layer, and return 2 in EBX because there are two logical processors (SMT units) per physical core. The value returned in EAX for this 0-subleaf should be 1 in this case, because shifting the aforementioned x2APIC ids to the right by one bit gives a unique core number (at the next level of the level id hierarchy) and erases the SMT id bit inside each core. A simpler way to interpret this information is that the last bit (bit number 0) of the x2APIC id identifies the SMT/hyperthreading unit inside each core in our example. Advancing to subleaf 1 (by making another call to CPUID with EAX=Bh and ECX=1) could for instance return 201h in ECX, meaning that this is a core-type level, and 4 in EBX because there are 4 logical processors in the package; EAX returned could be any value greater than 3, because it so happens that bit number 2 is used to identify the core in the x2APIC id. Note that bit number 1 of the x2APIC id is not used in this example. However, EAX returned at this level could well be 4 (and it happens to be so on a Clarkdale Core i3 5x0) because that also gives a unique id at the package level (=0 obviously) when shifting the x2APIC id by 4 bits. Finally, you may wonder what the EAX=4 leaf can tell us that we didn't find out already. In EAX[31:26] it returns the APIC mask bits reserved for a package; that would be 111b in our example because bits 0 to 2 are used for identifying logical processors inside this package, but bit 1 is also reserved although not used as part of the logical processor identification scheme. In other words, APIC ids 0 to 7 are reserved for the package, even though half of these values don't map to a logical processor.
The cache hierarchy of the processor is explored by looking at the sub-leaves of leaf 4. The APIC ids are also used in this hierarchy to convey information about how the different levels of cache are shared by the SMT units and cores. To continue our example, the L2 cache, which is shared by SMT units of the same core but not between physical cores on the Westmere is indicated by EAX[26:14] being set to 1, while the information that the L3 cache is shared by the whole package is indicated by setting those bits to (at least) 111b. The cache details, including cache type, size, and associativity are communicated via the other registers on leaf 4.
Beware that older versions of the Intel app note 485 contain some misleading information, particularly with respect to identifying and counting cores in a multi-core processor;[74] errors from misinterpreting this information have even been incorporated in the Microsoft sample code for using CPUID, even for the 2013 edition of Visual Studio,[75] and also in the sandpile.org page for CPUID,[76] but the Intel code sample for identifying processor topology[72] has the correct interpretation, and the current Intel Software Developer's Manual has a more clear language. The (open source) cross-platform production code[77] from Wildfire Games also implements the correct interpretation of the Intel documentation.
Topology detection examples involving older (pre-2010) Intel processors that lack x2APIC (thus don't implement the EAX=Bh leaf) are given in a 2010 Intel presentation.[78] Beware that using that older detection method on 2010 and newer Intel processors may overestimate the number of cores and logical processors because the old detection method assumes there are no gaps in the APIC id space, and this assumption is violated by some newer processors (starting with the Core i3 5x0 series), but these newer processors also come with an x2APIC, so their topology can be correctly determined using the EAX=Bh leaf method.
EAX=5: MONITOR/MWAIT Features
This returns feature information related to the MONITOR and MWAIT instructions in the EAX, EBX, ECX and EDX registers.
CPUID EAX=5: MONITOR/MWAIT feature information in EAX, EBX, EDX
↑ On Intel Pentium 4 family processors only, bit 2 of EAX is used to indicate OPP (Operating Point Protection)[80] instead of ARAT.
↑ To enable fast (non-serializing) access mode for the IA32_HWP_REQUEST MSR on CPUs that support it, it is necessary to set bit 0 of the FAST_UNCORE_MSRS_CTL(657h) MSR.
CPUID EAX=6: Thermal/power management feature fields in EBX, ECX and EDX
Bit
EBX
ECX
EDX
Bit
0
Number of Interrupt Thresholds in Digital Thermal Sensor
Effective frequency interface supported - IA32_MPERF(0E7h) and IA32_APERF(0E8h) MSRs
Number of Intel Thread Director classes supported by hardware
Size of Hardware Feedback interface structure (in units of 4KB) minus 1
11:8
15:12
(reserved)
15:12
31:16
(reserved)
Index of this logical processor's row in hardware feedback interface structure
31:16
↑ The "ACNT2 Capability" bit is listed in Intel AP-485 rev 038[82] and 039, but not listed in any revision of the Intel SDM. The feature is known to exist in only a few Intel CPUs, e.g. Xeon "Harpertown" stepping E0.[83]
EAX=7, ECX=0: Extended Features
This returns extended feature flags in EBX, ECX, and EDX. Returns the maximum ECX value for EAX=7 in EAX.
CPUID EAX=7,ECX=0: Extended feature bits in EBX, ECX and EDX
Speculation Control, part of Indirect Branch Control (IBC): Indirect Branch Restricted Speculation (IBRS) and Indirect Branch Prediction Barrier (IBPB)[87][88]
If 1, then Control-Flow Enforcement (CET) Supervisor Shadow Stacks (SSS) are guaranteed not to become prematurely busy as long as shadow stack switching does not cause page faults on the stack being switched to.[90][91]
18
19
wrmsrns
WRMSRNS instruction (non-serializing write to MSRs)
(reserved)
(reserved)
avx10
AVX10 Converged Vector ISA (see also leaf 24h)[92]
RDMSRLIST and WRMSRLIST instructions, and the IA32_BARRIER (02Fh) MSR
(reserved)
(reserved)
(reserved)
27
28
(reserved)
(reserved)
(reserved)
(reserved)
28
29
(reserved)
(reserved)
(reserved)
(reserved)
29
30
invd_disable_post_bios_done
If 1, supports INVD instruction execution prevention after BIOS Done.
(reserved)
(reserved)
(reserved)
30
31
(reserved)
(reserved)
(reserved)
(reserved)
31
↑ As of April 2024, the DEDUP bit is listed only in Intel TDX documentation[84] and is not set in any known processor.
↑ Support for the MWAIT instruction may be indicated by either CPUID.(EAX=1).ECX[3] or CPUID.(EAX=7,ECX=1).EDX[23]. (One or both may be set.) The former indicates support for the MONITOR instruction as well, while the latter does not indicate one way or another whether the MONITOR instruction is present. MWAIT without MONITOR may be present in systems that support the "Monitorless MWAIT" feature (which is itself indicated by CPUID.(EAX=5).ECX[3].)
EAX=7, ECX=2: Extended Features
This returns extended feature flags in EDX.
EAX, EBX and ECX are reserved.
CPUID EAX=7,ECX=2: Extended feature bits in EDX
Bit
EDX
Short
Feature
0
psfd
Fast Store Forwarding Predictor disable supported. (SPEC_CTRL (MSR 48h) bit 7)
1
ipred_ctrl
IPRED_DIS controls[94] supported. (SPEC_CTRL bits 3 and 4)
IPRED_DIS prevents instructions at an indirect branch target from speculatively executing until the branch target address is resolved.
2
rrsba_ctrl
RRSBA behavior[95][94] disable supported. (SPEC_CTRL bits 5 and 6)
3
ddpd_u
Data Dependent Prefetcher disable supported. (SPEC_CTRL bit 8)
4
bhi_ctrl
BHI_DIS_S behavior[94] enable supported. (SPEC_CTRL bit 10)
BHI_DIS_S prevents predicted targets of indirect branches executed in ring0/1/2 from being selected based on branch history from branches executed in ring 3.
5
mcdt_no
If set, the processor does not exhibit MXCSR configuration dependent timing.
6
UC-lock disable feature supported.
31:7
(reserved)
EAX=0Dh: XSAVE features and state-components
This leaf is used to enumerate XSAVE features and state-components.
The XSAVE instruction set extension is designed to save/restore CPU extended state (typically for the purpose of context switching) in a manner that can be extended to cover new instruction set extensions without the OS context-switching code needing to understand the specifics of the new extensions. This is done by defining a series of state-components, each with a size and offset within a given save area, and each corresponding to a subset of the state needed for one CPU extension or another. The EAX=0Dh CPUID leaf is used to provide information about which state-components the CPU supports and what their sizes/offsets are, so that the OS can reserve the proper amount of space and set the associated enable-bits.
The state-components can be subdivided into two groups: user-state (state-items that are visible to the application, e.g. AVX-512 vector registers), and supervisor-state (state items that affect the application but are not directly user-visible, e.g. user-mode interrupt configuration). The user-state items are enabled by setting their associated bits in the XCR0 control register, while the supervisor-state items are enabled by setting their associated bits in the IA32_XSS (0DA0h) MSR - the indicated state items then become the state-components that can be saved and restored with the XSAVE/XRSTOR family of instructions.
The XSAVE mechanism can handle up to 63 state-components in this manner. State-components 0 and 1 (x87 and SSE, respectively) have fixed offsets and sizes - for state-components 2 to 62, their sizes, offsets and a few additional flags can be queried by executing CPUID with EAX=0Dh and ECX set to the index of the state-component. This will return the following items in EAX, EBX and ECX (with EDX being reserved):
CPUID EAX=0Dh, ECX≥2: XSAVE state-component information
Bit
EAX
EBX
ECX
Bit
0
Size in bytes of state-component
Offset of state-component from the start of the XSAVE/XRSTOR save area
(This offset is 0 for supervisor state-components, since these can only be saved with the XSAVES/XRSTORS instruction, which use compacting.)
User/supervisor state-component:
0=user-state (enabled through XCR0)
1=supervisor-state (enabled through IA32_XSS)
0
1
64-byte alignment enable when state save compaction is used.
If this bit is set for a state-component, then, when storing state with compaction, padding will be inserted between the preceding state-component and this state-component as needed to provide 64-byte alignment. If this bit is not set, the state-component will be stored directly after the preceding one.
1
31:2
(reserved)
31:2
Attempting to query an unsupported state-component in this manner results in EAX,EBX,ECX and EDX all being set to 0.
Sub-leaves 0 and 1 of CPUID leaf 0Dh are used to provide feature information:
CPUID EAX=0Dh,ECX=0: XSAVE features
EBX
ECX
EDX:EAX
Maximum size (in bytes) of XSAVE save area for the set of state-components currently set in XCR0.
Maximum size (in bytes) of XSAVE save area if all state-components supported by XCR0 on this CPU were enabled at the same time.
64-bit bitmap of state-components supported by XCR0 on this CPU.
CPUID EAX=0Dh,ECX=1: XSAVE extended features
EAX
EBX
EDX:ECX
XSAVE feature flags (see below table)
Size (in bytes) of XSAVE area containing all the state-components currently set in XCR0 and IA32_XSS combined.
64-bit bitmap of state-components supported by IA32_XSS on this CPU.
EAX=0Dh,ECX=1: XSAVE feature flags in EAX
Bit
EAX
Short
Feature
0
xsaveopt
XSAVEOPT instruction: save state-components that have been modified since last XRSTOR
1
xsavec
XSAVEC instruction: save/restore state with compaction
2
xgetbv_ecx1
XGETBV with ECX=1 support
3
xss
XSAVES and XRSTORS instructions and IA32_XSS MSR: save/restore state with compaction, including supervisor state.
4
xfd
XFD (Extended Feature Disable) supported
31:5
(reserved)
As of July 2023, the XSAVE state-components that have been architecturally defined are:
↑ Bit 0 of XCR0 is hardwired to 1, so that the XSAVE instructions will always support save/restore of x87 state.
↑ For the XCR0 and IA32_XSS registers, bit 63 is reserved specifically for bit vector expansion - this precludes the existence of a state-component 63.
EAX=12h: SGX capabilities
This leaf provides information about the supported capabilities of the Intel Software Guard Extensions (SGX) feature. The leaf provides multiple sub-leaves, selected with ECX.
Sub-leaf 0 provides information about supported SGX leaf functions in EAX and maximum supported SGX enclave sizes in EDX; ECX is reserved. EBX provides a bitmap of bits that can be set in the MISCSELECT field in the SECS (SGX Enclave Control Structure) - this field is used to control information written to the MISC region of the SSA (SGX Save State Area) when an AEX (SGX Asynchronous Enclave Exit) occurs.
CPUID EAX=12h,ECX=0: SGX leaf functions, MISCSELECT and maximum-sizes
Bit
EAX
EBX
EDX
Bit
Short
Feature
Short
Feature
Short
Feature
0
sgx1
SGX1 leaf functions
EXINFO
MISCSELECT: report information about page fault and general protection exception that occurred inside enclave
MaxEnclaveSize_Not64
Log2 of maximum enclave size supported in non-64-bit mode
0
1
sgx2
SGX2 leaf functions
CPINFO
MISCSELECT: report information about control protection exception that occurred inside enclave
1
2
(reserved)
(reserved)
2
3
(reserved)
(reserved)
3
4
(reserved)
(reserved)
4
5
oss
ENCLV leaves: EINCVIRTCHILD, EDECVIRTCHILD, and ESETCONTEXT
(reserved)
5
6
ENCLS leaves: ETRACKC, ERDINFO, ELDBC, ELDUC
(reserved)
6
7
ENCLU leaf: EVERIFYREPORT2
(reserved)
7
8
(reserved)
(reserved)
MaxEnclaveSize_64
Log2 of maximum enclave size supported in 64-bit mode
8
9
(reserved)
(reserved)
9
10
ENCLS leaf: EUPDATESVN
(reserved)
10
11
ENCLU leaf: EDECSSA
(reserved)
11
12
(reserved)
(reserved)
12
13
(reserved)
(reserved)
13
14
(reserved)
(reserved)
14
15
(reserved)
(reserved)
15
31:16
(reserved)
(reserved)
(reserved)
31:16
Sub-leaf 1 provides a bitmap of which bits can be set in the 128-bit ATTRIBUTES field of SECS in EDX:ECX:EBX:EAX (this applies to the SECS copy used as input to the ENCLS[ECREATE] leaf function). The top 64 bits (given in EDX:ECX) are a bitmap of which bits can be set in the XFRM (X-feature request mask) - this mask is a bitmask of which CPU state-components (see leaf 0Dh) will be saved to the SSA in case of an AEX; this has the same layout as the XCR0 control register. The other bits are given in EAX and EBX, as follows:
CPUID EAX=12h,ECX=1: SGX settable bits in SECS.ATTRIBUTES
Permit debugger to read and write enclave data using EDBGRD and EDBGWR
1
2
MODE64BIT
64-bit-mode enclave
2
3
(reserved)
3
4
PROVISIONKEY
Provisioning key available from EGETKEY
4
5
EINITTOKEN_KEY
EINIT token key available from EGETKEY
5
6
CET
CET (Control-Flow Enforcement Technology) attributes enable
6
7
KSS
Key Separation and Sharing
7
8
(reserved)
8
9
(reserved)
9
10
AEXNOTIFY
Threads inside enclave may receive AEX notifications[96]
10
31:11
(reserved)
31:11
↑ For the copy of the SECS that exists inside an exclave, bit 0 (INIT) of SECS.ATTRIBUTES is used to indicate that the enclave has been initialized with ENCLS[EINIT]. This bit must be 0 in the SECS copy that is given as input to ENCLS[CREATE].
Sub-leaves 2 and up are used to provide information about which physical memory regions are available for use as EPC (Enclave Page Cache) sections under SGX.
CPUID EAX=12h,ECX≥2: SGX Enclave Page Cache section information
Bits
EAX
EBX
ECX
EDX
Bits
3:0
Sub-leaf type:
0000: Invalid
0001: EPC section
other: reserved
Bits 51:32 of physical base address of EPC section
EPC Section properties:
0000: Invalid
0001: Has confidentiality, integrity and replay protection
0010: Has confidentiality protection only
0011: Has confidentiality and integrity protection
other: reserved
Bits 51:32 of size of EPC section
3:0
11:4
(reserved)
(reserved)
11:4
19:12
Bits 31:12 of physical base address of EPC section
Bits 31:12 of size of EPC section
19:12
31:20
(reserved)
(reserved)
31:20
EAX=14h, ECX=0: Processor Trace
This sub-leaf provides feature information for Intel Processor Trace (also known as Real Time Instruction Trace).
The value returned in EAX is the index of the highest sub-leaf supported for CPUID with EAX=14h. EBX and ECX provide feature flags, EDX is reserved.
CPUID EAX=14h,ECX=0: Processor Trace feature bits in EBX and ECX
↑ The frequency values reported by leaf 16h are the processor's specification frequencies and do not reflect the actual clock speed of the CPU.
If the returned values in EBX and ECX of leaf 15h are both nonzero, then the TSC (Time Stamp Counter) frequency in Hz is given by TSCFreq = ECX*(EBX/EAX).
On some processors (e.g. Intel Skylake), CPUID_15h_ECX is zero but CPUID_16h_EAX is present and not zero. On all known processors where this is the case,[97] the TSC frequency is equal to the Processor Base Frequency, and the Core Crystal Clock Frequency in Hz can be computed as CoreCrystalFreq = (CPUID_16h_EAX * 10000000) * (CPUID_15h_EAX/CPUID_15h_EBX).
On processors that enumerate the TSC/Core Crystal Clock ratio in CPUID leaf 15h, the APIC timer frequency will be the Core Crystal Clock frequency divided by the divisor specified by the APIC's Divide Configuration Register.[98]
EAX=19h: Intel Key Locker features
This leaf provides feature information for Intel Key Locker in EAX, EBX and ECX. EDX is reserved.
CPUID EAX=19h: Key Locker feature bits in EAX, EBX and ECX
↑ As of April 2024, the "Process Restriction" bit is listed only in Intel TDX documentation[84] and is not set in any known processor.
EAX=24h, ECX=0: AVX10 Features
This returns a maximum supported sub-leaf in EAX and AVX10 feature information in EBX.[92] (ECX and EDX are reserved.)
CPUID EAX=24h, ECX=0: AVX10 feature bits in EBX
Bit
EBX
Short
Feature
7:0
AVX10 Converged Vector ISA version (≥1)
15:8
(reserved)
16
avx10-128
128-bit vector support is present
17
avx10-256
256-bit vector support is present
18
avx10-512
512-bit vector support is present
31:19
(reserved)
EAX=24h, ECX=1: Discrete AVX10 Features
Subleaf 1 is reserved for AVX10 features not bound to a version. None are currently defined.
EAX=40000000h-4FFFFFFFh: Reserved for Hypervisor use
When the CPUID instruction is executed under Intel VT-x or AMD-v virtualization, it will be intercepted by the hypervisor, enabling the hypervisor to return CPUID feature flags that differ from those of the underlying hardware. CPUID leaves 40000000h to 4FFFFFFFh are not implemented in hardware, and are reserved for use by hypervisors to provide hypervisor-specific identification and feature information through this interception mechanism.
For leaf 40000000h, the hypervisor is expected to return the index of the highest supported hypervisor CPUID leaf in EAX, and a 12-character hypervisor ID string in EBX,ECX,EDX (in that order). For leaf 40000001h, the hypervisor may return an interface identification signature in EAX - e.g. hypervisors that wish to advertise that they are Hyper-V compatible may return 0x31237648—“Hv#1” in EAX.[99][100] The formats of leaves 40000001h and up to the highest supported leaf are otherwise hypervisor-specific. Hypervisors that implement these leaves will normally also set bit 31 of ECX for CPUID leaf 1 to indicate their presence.
Hypervisors that expose more than one hypervisor interface may provide additional sets of CPUID leaves for the additional interfaces, at a spacing of 100h leaves per interface. For example, when QEMU is configured to provide both Hyper-V and KVM interfaces, it will provide Hyper-V information starting from CPUID leaf 40000000h and KVM information starting from leaf 40000100h.[101][102]
Some hypervisors that are known to return a hypervisor ID string in leaf 40000000h include:
CPUID EAX=40000x00h: 12-character Hypervisor ID string in EBX,ECX,EDX
The QNX hypervisor detection method provided in the official QNX documentation[113] checks only the first 8 characters of the string, as provided in EBX and ECX (including an endianness swap) - EDX is ignored and may take any value.
EAX=80000000h: Get Highest Extended Function Implemented
The highest calling parameter is returned in EAX.
EBX/ECX/EDX return the manufacturer ID string (same as EAX=0) on AMD but not Intel CPUs.
EAX=80000001h: Extended Processor Info and Feature Bits
This returns extended feature flags in EDX and ECX.
Many of the bits in EDX (bits 0 through 9, 12 through 17, 23, and 24) are duplicates of EDX from the EAX=1 leaf - these bits are highlighted in light yellow. (These duplicated bits are present on AMD but not Intel CPUs.)
↑ The use of EDX bit 10 to indicate support for SYSCALL/SYSRET is only valid on AuthenticAMDFamily 5 Model 7 CPUs (AMD K6, 250nm "Little Foot") - for all other processors, EDX bit 11 should be used instead.
These instructions were first introduced on Model 7[122] - the CPUID bit to indicate their support was moved[123] to EDX bit 11 from Model 8 (AMD K6-2) onwards.
↑ On Intel CPUs, the CPUID bit for SYSCALL/SYSRET is only set if the CPUID instruction is executed in 64-bit mode.[124]
Bit 16: Floating-point Conditional Move (FCMOV) supported
Bit 24: 6x86MX Extended MMX instructions supported
↑ EDX bit 19 is used for CPU brand identification on AuthenticAMDFamily 6 processors only - the bit is, combined with processor signature and FSB speed, used to identify processors as either multiprocessor-capable or carrying the Sempron brand name.[129]
↑ ECX bit 25 is listed as StreamPerfMon in revision 3.20 of AMD APM[131] only - it is listed as reserved in later revisions. The bit is set on Excavator and Steamroller CPUs only.
These return the processor brand string in EAX, EBX, ECX and EDX. CPUID must be issued with each parameter in sequence to get the entire 48-byte ASCII processor brand string.[132] It is necessary to check whether the feature is present in the CPU by issuing CPUID with EAX = 80000000h first and checking if the returned value is not less than 80000004h.
The string is specified in Intel/AMD documentation to be null-terminated, however this is not always the case (e.g. DM&P Vortex86DX3 and AMD Ryzen 7 6800HS are known to return non-null-terminated brand strings in leaves 80000002h-80000004h[133][134]), and software should not rely on it.
On AMD processors, from 180nm Athlon onwards (AuthenticAMD Family 6 Model 2 and later), it is possible to modify the processor brand string returned by CPUID leaves 80000002h-80000004h by using the WRMSR instruction to write a 48-byte replacement string to MSRs C0010030h-C0010035h.[129][135]
EAX=80000005h: L1 Cache and TLB Identifiers
This provides information about the processor's level-1 cache and TLB characteristics in EAX, EBX, ECX and EDX as follows:[lower-alpha 1]
EAX: information about L1 hugepage TLBs (TLBs that hold entries corresponding to 2M/4M pages)[lower-alpha 2]
EBX: information about L1 small-page TLBs (TLBs that hold entries corresponding to 4K pages)
ECX: information about L1 data cache
EDX: information about L1 instruction cache
CPUID EAX=80000002h: L1 Cache/TLB information in EAX,EBX,ECX,EDX
↑ On some older Cyrix and Geode CPUs (specifically, CyrixInstead/Geode by NSC Family 5 Model 4 CPUs only), leaf 80000005h exists but has a completely different format, similar to that of leaf 2.[136]
↑ On processors that can only handle small-pages in their TLBs, this leaf will return 0 in EAX. (On such processors, which include e.g. AMD K6 and Transmeta Crusoe, hugepage entries in the page-tables are broken up into 4K pages as needed upon entry into the TLB.) On some processors, e.g. VIA Cyrix III "Samuel",[137] this leaf returns 0x80000005 in EAX. This has the same meaning as EAX=0, i.e. no hugepage TLBs.
1 2 On Transmeta CPUs, the value FFh is used to indicate a 256-entry TLB.
1 2 3 For the associativity fields of leaf 80000005h, the following values are used:
Value
Meaning
0
(reserved)
1
Direct-mapped
2 to FEh
N-way set-associative (field encodes N)
FFh
Fully-associative
EAX=80000006h: Extended L2 Cache Features
Returns details of the L2 cache in ECX, including the line size in bytes (Bits 07 - 00), type of associativity (encoded by a 4 bits field; Bits 15 - 12) and the cache size in KB (Bits 31 - 16).
↑ The LMSLE (Long Mode Segment Limit Enable) feature does not have its own CPUID flag and is detected by checking CPU family and model. It was introduced in AuthenticAMD Family 0Fh Model 14h[141] (90nm Athlon64/Opteron) CPUs and is present in all later AMD CPUs - except the ones with the 'no_efer_lmsle' flag set.
↑ A value of 0 indicates that the "Guest Physical Address Size" is the same as the "Number Of Physical Address Bits", specified in EAX[7:0].
EAX=8000000Ah: Secure Virtual Machine features
This leaf returns information about AMD SVM (Secure Virtual Machine) features in EAX, EBX and EDX.
CPUID EAX=8000000Ah: SVM information in EAX, EBX and ECX
Bits
EAX
EBX
ECX
Bits
7:0
SVM Revision Number
Number of available ASIDs (address space identifiers)
Idle HLT (HLT instruction executed while no virtual interrupt is pending) intercept
31
(reserved)
↑ Early revisions of AMD's "Pacifica" documentation listed EAX bit 8 as an always-zero bit reserved for hypervisor use.[143]
Later AMD documentation, such as #25481 "CPUID specification" rev 2.18[144] and later, only lists the bit as reserved.
In rev 2.30[145] and later, a different bit is listed as reserved for hypervisor use: CPUID.(EAX=1):ECX[bit 31].
↑ EDX bit 9 is briefly listed in some older revisions of AMD's document #25481 "CPUID Specification", and is set only in some AMD Bobcat CPUs.[146]
Rev 2.28 of #25481 lists the bit as "Ssse3Sse5Dis"[147] - in rev 2.34, it is listed as having been removed from the spec at rev 2.32 under the name "SseIsa10Compat".[148]
EAX=8000001Fh: Encrypted Memory Capabilities
CPUID EAX=8000001Fh: Encrypted Memory feature bits in EAX
CPU is not subject to SRSO (Speculative Return Stack Overflow) vulnerability[152]
30
SRSO_USER_KERNEL_NO
CPU is not subject to SRSO vulnerability across user/kernel boundary[152]
31
SRSO_MSR_FIX
SRSO can be mitigated by setting bit 4 of BP_CFG (MSR C001_102E)[152]
CPUID EAX=80000021h: Extended feature information in EBX
Bit
EBX
Short
Feature
11:0
MicrocodePatchSize
The size of the Microcode patch in 16-byte multiples. If 0, the size of the patch is at most 5568 (15C0h) bytes
31:12
(reserved)
EAX=8FFFFFFFh: AMD Easter Egg
Several AMD CPU models will, for CPUID with EAX=8FFFFFFFh, return an Easter Egg string in EAX, EBX, ECX and EDX.[153][154] Known Easter Egg strings include:
On IDT WinChip CPUs (CentaurHauls Family 5), the extended leaves C0000001h-C0000005h do not encode any Centaur-specific functionality but are instead aliases of leaves 80000001h-80000005h.[156]
EAX=C0000001h: Centaur Feature Information
This leaf returns Centaur feature information (mainly VIA PadLock) in EDX.[157][158] (EAX, EBX and ECX are reserved.)
This information is easy to access from other languages as well. For instance, the C code for gcc below prints the first five values, returned by the cpuid:
In MSVC and Borland/Embarcadero C compilers (bcc32) flavored inline assembly, the clobbering information is implicit in the instructions:
#include<stdio.h>intmain(){unsignedinta,b,c,d,i=0;__asm{/* Do the call. */movEAX,i;cpuid;/* Save results. */mova,EAX;movb,EBX;movc,ECX;movd,EDX;}printf("InfoType %x\nEAX: %x\nEBX: %x\nECX: %x\nEDX: %x\n",i,a,b,c,d);return0;}
If either version was written in plain assembly language, the programmer must manually save the results of EAX, EBX, ECX, and EDX elsewhere if they want to keep using the values.
Wrapper functions
GCC also provides a header called <cpuid.h> on systems that have CPUID. The __cpuid is a macro expanding to inline assembly. Typical usage would be:
But if one requested an extended feature not present on this CPU, they would not notice and might get random, unexpected results. Safer version is also provided in <cpuid.h>. It checks for extended features and does some more safety checks. The output values are not passed using reference-like macro parameters, but more conventional pointers.
#include<stdio.h>#include<cpuid.h>intmain(){unsignedinteax,ebx,ecx,edx;/* 0x81234567 is nonexistent, but assume it exists */if(!__get_cpuid(0x81234567,&eax,&ebx,&ecx,&edx)){printf("Warning: CPUID request 0x81234567 not valid!\n");return1;}printf("EAX: %x\nEBX: %x\nECX: %x\nEDX: %x\n",eax,ebx,ecx,edx);return0;}
Notice the ampersands in &a, &b, &c, &d and the conditional statement. If the __get_cpuid call receives a correct request, it will return a non-zero value, if it fails, zero.[160]
Microsoft Visual C compiler has builtin function __cpuid() so the cpuid instruction may be embedded without using inline assembly, which is handy since the x86-64 version of MSVC does not allow inline assembly at all. The same program for MSVC would be:
Many interpreted or compiled scripting languages are capable of using CPUID via an FFI library. One such implementation shows usage of the Ruby FFI module to execute assembly language that includes the CPUID opcode.
.NET 5 and later versions provide the System.Runtime.Intrinsics.X86.X86base.CpuId method. For instance, the C# code below prints the processor brand if it supports CPUID instruction:
usingSystem.Runtime.InteropServices;usingSystem.Runtime.Intrinsics.X86;usingSystem.Text;namespaceX86CPUID{classCPUBrandString{publicstaticvoidMain(string[]args){if(!X86Base.IsSupported){Console.WriteLine("Your CPU does not support CPUID instruction.");}else{Span<int>raw=stackallocint[12];(raw[0],raw[1],raw[2],raw[3])=X86Base.CpuId(unchecked((int)0x80000002),0);(raw[4],raw[5],raw[6],raw[7])=X86Base.CpuId(unchecked((int)0x80000003),0);(raw[8],raw[9],raw[10],raw[11])=X86Base.CpuId(unchecked((int)0x80000004),0);Span<byte>bytes=MemoryMarshal.AsBytes(raw);stringbrand=Encoding.UTF8.GetString(bytes).Trim();Console.WriteLine(brand);}}}}
CPU-specific information outside x86
Some of the non-x86 CPU architectures also provide certain forms of structured information about the processor's abilities, commonly as a set of special registers:
The IBM System z mainframe processors have a Store CPU ID (STIDP) instruction since the 1983 IBM 4381[162] for querying the processor ID.[163]
The IBM System z mainframe processors also have a Store Facilities List Extended (STFLE) instruction which lists the installed hardware features.[163]
The MIPS32/64 architecture defines a mandatory Processor Identification (PrId) and a series of daisy-chained Configuration Registers.[164]
The PowerPC processor has the 32-bit read-only Processor Version Register (PVR) identifying the processor model in use. The instruction requires supervisor access level.[165]
DSP and transputer-like chip families have not taken up the instruction in any noticeable way, in spite of having (in relative terms) as many variations in design. Alternate ways of silicon identification might be present; for example, DSPs from Texas Instruments contain a memory-based register set for each functional unit that starts with identifiers determining the unit type and model, its ASIC design revision and features selected at the design phase, and continues with unit-specific control and data registers. Access to these areas is performed by simply using the existing load and store instructions; thus, for such devices, there is no need for extending the register set for device identification purposes.[citation needed]
See also
CPU-Z, a Windows utility that uses CPUID to identify various system settings
CPU-X, an alternative of CPU-Z for Linux and FreeBSD
/proc/cpuinfo, a text file generated by certain systems containing some of the CPUID information
x86-cpuid.org, a machine-readable CPUID data repository and code generator
Related Research Articles
The Cyrix 6x86 is a line of sixth-generation, 32-bit x86 microprocessors designed and released by Cyrix in 1995. Cyrix, being a fabless company, had the chips manufactured by IBM and SGS-Thomson. The 6x86 was made as a direct competitor to Intel's Pentium microprocessor line, and was pin compatible. During the 6x86's development, the majority of applications performed almost entirely integer operations. The designers foresaw that future applications would most likely maintain this instruction focus. So, to optimize the chip's performance for what they believed to be the most likely application of the CPU, the integer execution resources received most of the transistor budget. This would later prove to be a strategic mistake, as the popularity of the P5 Pentium caused many software developers to hand-optimize code in assembly language, to take advantage of the P5 Pentium's tightly pipelined and lower latency FPU. For example, the highly anticipated first-person shooter Quake used highly optimized assembly code designed almost entirely around the P5 Pentium's FPU. As a result, the P5 Pentium significantly outperformed other CPUs in the game.
The Intel 486, officially named i486 and also known as 80486, is a microprocessor. It is a higher-performance follow-up to the Intel 386. The i486 was introduced in 1989. It represents the fourth generation of binary compatible CPUs following the 8086 of 1978, the Intel 80286 of 1982, and 1985's i386.
x86 is a family of complex instruction set computer (CISC) instruction set architectures initially developed by Intel based on the Intel 8086 microprocessor and its 8088 variant. The 8086 was introduced in 1978 as a fully 16-bit extension of Intel's 8-bit 8080 microprocessor, with memory segmentation as a solution for addressing more memory than can be covered by a plain 16-bit address. The term "x86" came into being because the names of several successors to Intel's 8086 processor end in "86", including the 80186, 80286, 80386 and 80486 processors. Colloquially, their names were "186", "286", "386" and "486".
Transmeta Corporation was an American fabless semiconductor company based in Santa Clara, California. It developed low power x86 compatible microprocessors based on a VLIW core and a software layer called Code Morphing Software.
x86 assembly language is the name for the family of assembly languages which provide some level of backward compatibility with CPUs back to the Intel 8008 microprocessor, which was launched in April 1972. It is used to produce object code for the x86 class of processors.
A translation lookaside buffer (TLB) is a memory cache that stores the recent translations of virtual memory to physical memory. It is used to reduce the time taken to access a user memory location. It can be called an address-translation cache. It is a part of the chip's memory-management unit (MMU). A TLB may reside between the CPU and the CPU cache, between CPU cache and the main memory or between the different levels of the multi-level cache. The majority of desktop, laptop, and server processors include one or more TLBs in the memory-management hardware, and it is nearly always present in any processor that utilizes paged or segmented virtual memory.
The x86 instruction set refers to the set of instructions that x86-compatible microprocessors support. The instructions are usually part of an executable program, often stored as a computer file and executed on the processor.
The GNU Assembler, commonly known as gas or as, is the assembler developed by the GNU Project. It is the default back-end of GCC. It is used to assemble the GNU operating system and the Linux kernel, and various other software. It is a part of the GNU Binutils package.
Geode was a series of x86-compatible system-on-a-chip (SoC) microprocessors and I/O companions produced by AMD, targeted at the embedded computing market.
The Pentium F00F bug is a design flaw in the majority of Intel Pentium, Pentium MMX, and Pentium OverDrive processors. Discovered in 1997, it can result in the processor ceasing to function until the computer is physically rebooted. The bug has been circumvented through operating system updates.
The Intel Core microarchitecture is a multi-core processor microarchitecture launched by Intel in mid-2006. It is a major evolution over the Yonah, the previous iteration of the P6 microarchitecture series which started in 1995 with Pentium Pro. It also replaced the NetBurst microarchitecture, which suffered from high power consumption and heat intensity due to an inefficient pipeline designed for high clock rate. In early 2004 the new version of NetBurst (Prescott) needed very high power to reach the clocks it needed for competitive performance, making it unsuitable for the shift to dual/multi-core CPUs. On May 7, 2004 Intel confirmed the cancellation of the next NetBurst, Tejas and Jayhawk. Intel had been developing Merom, the 64-bit evolution of the Pentium M, since 2001, and decided to expand it to all market segments, replacing NetBurst in desktop computers and servers. It inherited from Pentium M the choice of a short and efficient pipeline, delivering superior performance despite not reaching the high clocks of NetBurst.
The Time Stamp Counter (TSC) is a 64-bit register present on all x86 processors since the Pentium. It counts the number of CPU cycles since its reset. The instruction RDTSC returns the TSC in EDX:EAX. In x86-64 mode, RDTSC also clears the upper 32 bits of RAX and RDX. Its opcode is 0F 31. Pentium competitors such as the Cyrix 6x86 did not always have a TSC and may consider RDTSC an illegal instruction. Cyrix included a Time Stamp Counter in their MII.
A test register, in the Intel 80386 and Intel 80486 processor, was a register used by the processor, usually to do a self-test. Most of these registers were undocumented, and used by specialized software. The test registers were named TR3 to TR7. Regular programs don't usually require these registers to work. With the Pentium, the test registers were replaced by a variety of model-specific registers (MSRs).
In computing, Page Size Extension (PSE) refers to a feature of x86 processors that allows for pages larger than the traditional 4 KiB size. It was introduced in the original Pentium processor, but it was only publicly documented by Intel with the release of the Pentium Pro. The CPUID instruction can be used to identify the availability of PSE on x86 CPUs.
In computing, PSE-36 refers to a feature of x86 processors that extends the physical memory addressing capabilities from 32 bits to 36 bits, allowing addressing to up to 64 GB of memory. Compared to the Physical Address Extension (PAE) method, PSE-36 is a simpler alternative to addressing more than 4 GB of memory. It uses the Page Size Extension (PSE) mode and a modified page directory table to map 4 MB pages into a 64 GB physical address space. PSE-36's downside is that, unlike PAE, it doesn't have 4-KB page granularity above the 4 GB mark.
VIA PadLock is a central processing unit (CPU) instruction set extension to the x86 microprocessor instruction set architecture (ISA) found on processors produced by VIA Technologies and Zhaoxin. Introduced in 2003 with the VIA Centaur CPUs, the additional instructions provide hardware-accelerated random number generation (RNG), Advanced Encryption Standard (AES), SHA-1, SHA256, and Montgomery modular multiplication.
RDRAND is an instruction for returning random numbers from an Intel on-chip hardware random number generator which has been seeded by an on-chip entropy source. It is also known as Intel Secure Key Technology, codenamed Bull Mountain. Intel introduced the feature around 2012, and AMD added support for the instruction in June 2015.
The Alternate Instruction Set (AIS) is a second 32-bit instruction set architecture found in some x86 CPUs made by VIA Technologies. On these VIA C3 processors, the second hidden processor mode is accessed by executing the x86 instruction JMPAI. If AIS mode has been enabled, the processor will perform a JMP EAX and begin executing AIS instructions at the address of the EAX register. Using AIS allows native access to the Centaur Technology-designed RISC core inside the processor.
↑ B-CoolWare, TMi0SDGL x86 CPU/FPU detection library with source code, v2.15, June 2000 - see /SOURCE/REALCODE.ASM for a large collection of pre-CPUID x86 CPU detection routines. Archived on 14 Mar 2023.
↑ Intel, Pentium Processor Family Developer's Manual, 1997, order no. 241428-005, sections 3.4.1.2 (page 91), 17.5.1 (page 489) and appendix A (page 522) provide more detail on how the "processor type" field and the "dual processor" designation work.
↑ "Mechanisms to determine if software is running in a VMware virtual machine". VMware Knowledge Base. VMWare. 2015-05-01. Intel and AMD CPUs have reserved bit 31 of ECX of CPUID leaf 0x1 as the hypervisor present bit. This bit allows hypervisors to indicate their presence to the guest operating system. Hypervisors set this bit and physical CPUs (all existing and future CPUs) set this bit to zero. Guest operating systems can test bit 31 to detect if they are running inside a virtual machine.
↑ Kataria, Alok; Hecht, Dan (2008-10-01). "Hypervisor CPUID Interface Proposal". LKML Archive on lore.kernel.org. Archived from the original on 2019-03-15. Bit 31 of ECX of CPUID leaf 0x1. This bit has been reserved by Intel & AMD for use by hypervisors and indicates the presence of a hypervisor. Virtual CPU's (hypervisors) set this bit to 1 and physical CPU's (all existing and future CPU's) set this bit to zero. This bit can be probed by the guest software to detect whether they are running inside a virtual machine.
↑ "AMD64 Technology AMD64 Architecture Programmer's Manual Volume 2: System Programming"(PDF) (3.41ed.). Advanced Micro Devices, Inc. p.498. 24593. Archived from the original(PDF) on 30 Sep 2023. Retrieved 9 September 2023. 15.2.2 Guest Mode This new processor mode is entered through the VMRUN instruction. When in guest mode, the behavior of some x86 instructions changes to facilitate virtualization. The CPUID function numbers 4000_0000h-4000_00FFh have been reserved for software use. Hypervisors can use these function numbers to provide an interface to pass information from the hypervisor to the guest. This is similar to extracting information about a physical CPU by using CPUID. Hypervisors use the CPUID Fn 400000[FF:00] bit to denote a virtual platform. Feature bit CPUID Fn0000_0001_ECX[31] has been reserved for use by hypervisors to indicate the presence of a hypervisor. Hypervisors set this bit to 1 and physical CPU's set this bit to zero. This bit can be probed by the guest software to detect whether they are running inside a virtual machine.
↑ Intel SDM vol 2A, order no. 253666-053, Jan 2015, p. 244
↑ Intel, Software Developer's Manual, order no. 325462-080, June 2023 - information about prematurely busy shadow stacks provided in Volume 1, section 17.2.3 on page 410; Volume 2A, table 3.8 (CPUID EAX=7,ECX=2) on page 820; Volume 3C, table 25-14 on page 3958 and section 26.4.3 on page 3984.
1 2 AMD, Processor Recognition Application Note, pub.no. 20734, rev. 3.13, december 2005. Section 2.2.2 (p.20) and Section 3 (pages 33 to 40) provide details on how CPUID.(EAX=8000_0001):EDX[bit 19] should be used to identify processors. Section 3 also provides information on AMD's brand name string MSRs. Archived from the original on Jun 26, 2006.
↑ AMD, Family 10h BKDG, document no. 31116, rev 3.62, jan 11, 2013, p. 388 - lists the NodeId bit. Archived on 16 Jan 2019.
Contains some information that can be and was easily misinterpreted though, particularly with respect to processor topology identification.
The big Intel manuals tend to lag behind the Intel ISA document, available at the top of this page, which is updated even for processors not yet publicly available, and thus usually contains more CPUID bits. For example, as of this writing, the ISA book (at revision 19, dated May 2014) documents the CLFLUSHOPT bit in leaf 7, but the big manuals although apparently more up-to-date (at revision 51, dated June 2014) don't mention it.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
