CPUID

In the x86 architecture, the CPUID instruction (identified by a codice_1 opcode) 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.
A program can use the codice_1 to determine processor type and whether features such as MMX/SSE are implemented. 
History.
Prior to the general availability of the codice_1 instruction, programmers would write esoteric machine code which exploited minor differences in CPU behavior in order to determine the processor make and model. 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 codice_1 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 codice_1 opcode is 0Fh, A2h (as two bytes, or A20Fh as a single word).
In assembly language, the codice_1 instruction takes no parameters as codice_1 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. codice_1 should be called with codice_9 first, as this will store in the EAX register the highest EAX calling parameter (leaf) that the CPU implements.
To obtain extended function information codice_1 should be called with the most significant bit of EAX set. To determine the highest extended function calling parameter, call codice_1 with codice_12.
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, but later versions of Windows do not need it, so basic leaves greater than 4 can be assumed visible on current Windows systems. , basic valid leaves go up to 14h, but the information returned by some leaves are not disclosed in 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 (largest value that EAX can be set to before calling codice_1) is returned in EAX.
Here is a list of processors and the highest function implemented.
The following are known processor manufacturer ID strings:
The following are ID strings used by open source soft CPU cores:
The following are known ID strings from virtual machines:
For instance, on a GenuineIntel processor values returned in EBX is 0x756e6547, EDX is 0x49656e69 and ECX is 0x6c65746e. The following code is written in GNU Assembler for the x86-64 architecture and displays the vendor ID string as well as the highest calling parameter that the CPU implements.
 .data
s0: .asciz "CPUID: %x\n"
s1: .asciz "Largest basic function number implemented: %i\n"
s2: .asciz "Vendor ID: %.12s\n"
 .text
 .align 32
 .globl main
main:
 pushq %rbp
 movq %rsp,%rbp
 subq $16,%rsp
 movl $1,%eax
 cpuid
 movq $s0,%rdi
 movl %eax,%esi
 xorl %eax,%eax
 call printf
 pushq %rbx // -fPIC
 xorl %eax,%eax
 cpuid
 movl %ebx,0(%rsp)
 movl %edx,4(%rsp)
 movl %ecx,8(%rsp)
 popq %rbx // -fPIC
 movq $s1,%rdi
 movl %eax,%esi
 xorl %eax,%eax
 call printf
 movq $s2,%rdi
 movq %rsp,%rsi
 xorl %eax,%eax
 call printf
 movq %rbp,%rsp
 popq %rbp
// ret
 movl $1,%eax
 int $0x80
EAX=1: Processor Info and Feature Bits.
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. 
The processor info and feature flags are manufacturer specific but usually the Intel values are used by other manufacturers for the sake of compatibility.
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.
EAX=3: Processor Serial Number.
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. AMD does not use these leaves but has alternate ways of doing the core enumeration.
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 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; 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, and also in the sandpile.org page for CPUID, but the Intel code sample for identifying processor topology has the correct interpretation, and the current Intel Software Developer’s Manual has more clear language. The (open source) cross-platform production code 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. 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=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.
EAX=7, ECX=1: Extended Features.
This returns extended feature flags in EAX.
EAX=80000000h: Get Highest Extended Function Implemented.
The highest calling parameter is returned in EAX.
EAX=80000001h: Extended Processor Info and Feature Bits.
This returns extended feature flags in EDX and ECX.
AMD feature flags are as follows:
EAX=80000002h,80000003h,80000004h: Processor Brand String.
These return the processor brand string in EAX, EBX, ECX and EDX. codice_1 must be issued with each parameter in sequence to get the entire 48-byte null-terminated ASCII processor brand string. It is necessary to check whether the feature is present in the CPU by issuing codice_1 with codice_12 first and checking if the returned value is greater or equal to 80000004h.
int main(void) {
   uint32_t brand[12];
   if (!__get_cpuid_max(0x80000004, NULL)) {
 fprintf(stderr, "Feature not implemented.");
 return 2;
   __get_cpuid(0x80000002, brand+0x0, brand+0x1, brand+0x2, brand+0x3);
 __get_cpuid(0x80000003, brand+0x4, brand+0x5, brand+0x6, brand+0x7);
 __get_cpuid(0x80000004, brand+0x8, brand+0x9, brand+0xa, brand+0xb);
   printf("Brand: %s\n", brand);
EAX=80000005h: L1 Cache and TLB Identifiers.
This function contains the processor’s L1 cache and TLB characteristics.
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).
int main(void) {
 uint32_t eax, ebx, ecx, edx;
   if (__get_cpuid(0x80000006, &eax, &ebx, &ecx, &edx)) {
       printf("Line size: %d B, Assoc. Type: %d; Cache Size: %d KB.\n", ecx & 0xff, (ecx » 12) & 0x07, (ecx » 16) & 0xffff);
 return 0;
 } else {
 fputs(stderr, "CPU does not support 0x80000006");
 return 2;
EAX=80000007h: Advanced Power Management Information.
This function provides advanced power management feature identifiers. EDX bit 8 indicates support for invariant TSC.
EAX=80000008h: Virtual and Physical address Sizes.
Returns largest virtual and physical address sizes in EAX.
It could be used by the hypervisor in a virtual machine system to report physical/virtual address sizes possible with the virtual CPU.
EBX is used for features：
ECX provides core count.
EDX provides information specific to RDPRU (the maximum register identifier allowed) in 31-16. The current number as of Zen 2 is 1 for MPERF and APERF.
EAX=8FFFFFFFh: AMD Easter Egg.
Specific to AMD K7 and K8 CPUs, this returns the string "IT'S HAMMER TIME" in EAX, EBX, ECX and EDX, a reference to the MC Hammer song U Can't Touch This.
CPUID usage from high-level languages.
Inline assembly.
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:
/* This works on 32 and 64-bit systems. See Inline assembler#In actual compilers for hints on reading this code. */
int main()
 /* The four registers do not need to be initialized as the processor will write over it. */
 int infotype, a, b, c, d;
 for (infotype = 0; infotype < 5; infotype ++)
 __asm__("cpuid"
           : "=a" (a), "=b" (b), "=c" (c), "=d" (d) // The output variables. EAX -> a and vice versa.
 : "0" (infotype)); // Put the infotype into EAX.
 printf ("InfoType %x\nEAX: %x\nEBX: %x\nECX: %x\nEDX: %x\n", infotype, a, b, c, d);
 return 0;
In MSVC and Borland/Embarcadero C compilers (bcc32) flavored inline assembly, the clobbering information is implicit in the instructions:
int main()
 unsigned int InfoType = 0;
 unsigned int a, b, c, d;
 __asm {
 /* Do the call. */
 mov EAX, InfoType;
 cpuid;
 /* Save results. */
 mov a, EAX;
 mov b, EBX;
 mov c, ECX;
 mov d, EDX;
 printf ("InfoType %x\nEAX: %x\nEBX: %x\nECX: %x\nEDX: %x\n", InfoType, a, b, c, d);
 return 0;
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 codice_17 on systems that have CPUID. The codice_18 is a macro expanding to inline assembly. Typical usage would be:
int
main (void)
 int a, b, c, d;
 __cpuid (0 /* vendor string */, a, b, c, d);
 printf ("EAX: %x\nEBX: %x\nECX: %x\nEDX: %x\n", a, b, c, d);
 return 0;
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 codice_17. 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.
int
main (void)
 int a, b, c, d;
 if (!__get_cpuid (0x81234567 /* nonexistent, but assume it exists */, &a, &b, &c, &d))
 fprintf (stderr, "Warning: CPUID request 0x81234567 not valid!\n");
 printf("EAX: %x\nEBX: %x\nECX: %x\nEDX: %x\n", a, b, c, d);
 return 0;
Notice the ampersands in codice_20 and the conditional statement. If the codice_21 call receives a correct request, it will return a non-zero value, if it fails, zero.
Microsoft Visual C compiler has builtin function codice_22 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:
int main()
 int cpuInfo[4];
 for (int a = 0; a < 5; a++)
 __cpuid(cpuInfo, a);
 std::cout « "The code " « a « " gives " « cpuInfo[0] « ", " « cpuInfo[1] « ", " « cpuInfo[2] « ", " « cpuInfo[3] « '\n';
 return 0;
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.
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:
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 the device identification purposes.