This articlemay be too technical for most readers to understand. Pleasehelp improve it tomake it understandable to non-experts, without removing the technical details.(January 2025) (Learn how and when to remove this message)

In thex86 architecture, theCPUID instruction (identified by aCPUIDopcode) is aprocessor supplementary instruction (its name derived from "CPU Identification") allowing software to discover details of the processor. It was introduced byIntel in 1993 with the launch of thePentium andSL-enhanced 486 processors.^[1]

A program can use theCPUID to determine processor type and whether features such asMMX/SSE are implemented.

Prior to the general availability of theCPUID instruction, programmers would write esotericmachine 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.

For example, in theMotorola 68000 series — which never had aCPUID instruction of any kind — certain specific instructions required elevated privileges. These could be used to tell various CPU family members apart. In theMotorola 68010 the instructionMOVE from SR became privileged. Because the68000 offered an unprivilegedMOVE from SR the two different CPUs could be told apart by a CPU error condition being triggered.

While theCPUID 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 x86CPUID instruction.

TheCPUID opcode is0F A2.

Inassembly language, theCPUID instruction takes no parameters asCPUID 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 withEAX = 0 first, as this will store in the EAX register the highest EAX calling parameter (leaf) that the CPU implements.

To obtain extended function informationCPUID should be called with the most significant bit of EAX set. To determine the highest extended function calling parameter, callCPUID withEAX = 80000000h.

CPUID leaves greater than 3 but less than 80000000 are accessible only when themodel-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 callingCPUID.

This returns the CPU's manufacturer ID string – a twelve-characterASCII string stored in EBX, EDX, ECX (in that order). The highest basic calling parameter (the largest value that EAX can be set to before callingCPUID) is returned in EAX.

Here is a list of processors and the highest function implemented.

The following are known processor manufacturer ID strings:

• "AuthenticAMD" – AMD
• "CentaurHauls" – IDT WinChip/Centaur (Including some VIA and Zhaoxin CPUs)
• "CyrixInstead" – Cyrix/earlySTMicroelectronics andIBM
• "GenuineIntel" – Intel
• "GenuineIotel" – Intel (rare)^[7][8]
• "TransmetaCPU" – Transmeta
• "GenuineTMx86" – Transmeta
• "Geode by NSC" – National Semiconductor
• "NexGenDriven" – NexGen
• "RiseRiseRise" – Rise
• "SiS SiS SiS " – SiS
• "UMC UMC UMC " – UMC
• "Vortex86 SoC" – DM&PVortex86
• "  Shanghai  " – Zhaoxin
• "HygonGenuine" – Hygon
• "Genuine  RDC" – RDC Semiconductor Co. Ltd.^[9]
• "E2K MACHINE" – MCST Elbrus^[10]
• "VIA VIA VIA " – VIA^{[citation needed]}
• "AMD ISBETTER" – early engineering samples ofAMD K5 processor^{[11][12][better source needed]}

The following are ID strings used by open sourcesoft CPU cores:

• "GenuineAO486" – ao486 CPU (old)^[13][14]
• "MiSTer AO486" – ao486 CPU (new)^[15][14]
• "GenuineIntel" – v586 core^[16] (this is identical to the Intel ID string)

The following are known ID strings from virtual machines:

• "MicrosoftXTA" – Microsoft x86-to-ARM^[17]
• "GenuineIntel" – Apple Rosetta 2^[18]
• "VirtualApple" – Newer versions of Apple Rosetta 2
• "PowerVM Lx86" – PowerVM Lx86 (x86 emulator for IBMPOWER5/POWER6 processors)^[19]
• "Neko Project" – Neko Project II (PC-98 emulator) (used when the CPU to emulate is set to "Neko Processor II")^[20][21]

For instance, on aGenuineIntel processor, values returned in EBX is0x756e6547, EDX is0x49656e69 and ECX is0x6c65746e. 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 theWRMSR 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 theGenuineIntel ID string.^[22] Processors that are known to possess such MSRs include:

This returns the CPU'sstepping, model, and family information in register EAX (also called thesignature of a CPU), feature flags in registers EDX and ECX, and additional feature info in register EBX.^[30]

• Stepping ID is a product revision number assigned due to fixederrata 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.

As of October 2023, the following x86 processor family IDs are known:^[32]

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.

This returns a list of descriptors indicating cache andTLB capabilities in EAX, EBX, ECX and EDX registers.

On processors that support this leaf, callingCPUID with EAX=2 will cause the bottom byte of EAX to be set to01h^[a] and the remaining 15 bytes 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, andFEh 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) returns80000000h in EDX - this should be interpreted to mean that EDX contains no valid information, not that it contains a descriptor for 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 4 KBpage, 4K/2Mp for TLBs where each entry can describe either one 4 KB page or one 2 MB 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-wayset-associative, FA = fully-associative)

This returns the processor's serial number. The processor serial number was introduced on IntelPentium 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 theBIOS setting in order to function.

These two leaves are used to provide information about thecache hierarchy levels available to the processor core on which theCPUID instruction is run. Leaf4 is used on Intel processors and leaf8000'001Dh is used on AMD processors - they both return data in EAX, EBX, ECX and EDX, using the same data format except that leaf4 returns a few additional fields that are considered "reserved" for leaf8000'001Dh. They both provide CPU cache information in a series of sub-leaves selected by ECX - to get information about all the cache levels, it is necessary to invokeCPUID repeatedly, with EAX=4 or8000'001Dh and ECX set to increasing values starting from 0 (0,1,2,...) until a sub-leaf not describing any caches (EAX[4:0]=0) is found. The sub-leaves that do return cache information may appear in any order, but all of them will appear before the first sub-leaf not describing any caches.

In the below table, fields that are defined for leaf4 but not for leaf8000'001Dh are highlighted with yellow cell coloring and a(#4) item.

For any caches that are valid and not fully-associative, the value returned in ECX is the number of sets in the cache minus 1. (For fully-associative caches, ECX should be treated as if it return the value 0.)For any given cache described by a sub-leaf ofCPUID leaf4 or8000'001Dh, the total cache size in bytes can be computed as:

CacheSize = (EBX[11:0]+1) * (EBX[21:12]+1) * (EBX[31:22]+1) * (ECX+1)

For example, on IntelCrystalwell CPUs, executing CPUID with EAX=4 and ECX=4 will cause the processor to return the following size information for its level-4 cache in EBX and ECX:EBX=03C0F03F andECX=00001FFF - this should be taken to mean that this cache has a cache line size of 64 bytes (EBX[11:0]+1), has 16 cache lines per tag (EBX[21:12]+1), is 16-way set-associative (EBX[31:22]+1) with 8192 sets (ECX+1), for a total size of 64*16*16*8192=134217728 bytes, or 128 binary megabytes.

These two leaves are used for processor topology (thread, core, package) and cache hierarchy enumeration in Intel multi-core (and hyperthreaded) processors.^[89] As of 2013^[update] AMD does not use these leaves but has alternate ways of doing the core enumeration.^[90]

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 thex2APIC 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-coreWestmere processor capable ofhyperthreading (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 bitsreserved 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;^[91] 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,^[92] and also in the sandpile.org page for CPUID,^[93] but the Intel code sample for identifying processor topology^[89] has the correct interpretation, and the current Intel Software Developer's Manual has a more clear language. The (open source) cross-platform production code^[94] fromWildfire 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.^[95] 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.

This returns feature information related to theMONITOR andMWAIT instructions in the EAX, EBX, ECX and EDX registers.

This returns feature bits in the EAX register and additional information in the EBX, ECX and EDX registers.

This returns extended feature flags in EBX, ECX, and EDX. Returns the maximum ECX value for EAX=7 in EAX.

This returns extended feature flags in all four registers.

This returns extended feature flags in EDX.

EAX, EBX and ECX are reserved.

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 ofcontext 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 ofstate-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. TheEAX=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 theXCR0 control register, while the supervisor-state items are enabled by setting their associated bits in theIA32_XSS (0DA0h) MSR - the indicated state items then become the state-components that can be saved and restored with theXSAVE/XRSTOR family of instructions.

The XSAVE mechanism can handle up to 63 state-components in this manner. State-components 0 and 1 (x87 andSSE, respectively) have fixed offsets and sizes - for state-components 2 to 62, their sizes, offsets and a few additional flags can be queried by executingCPUID withEAX=0Dh andECX set to the index of the state-component. This will return the following items in EAX, EBX and ECX (with EDX being reserved):

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 ofCPUID leaf0Dh are used to provide feature information:

As of July 2023, the XSAVE state-components that have been architecturally defined are:

This leaf provides information about the supported capabilities of the IntelSoftware 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.

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 theENCLS[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 theXCR0 control register. The other bits are given in EAX and EBX, as follows:

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.

This sub-leaf provides feature information for IntelProcessor 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.

These two leaves provide information about various frequencies in the CPU in EAX, EBX and ECX (EDX is reserved in both leaves).

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 byTSCFreq = ECX*(EBX/EAX).

On some processors (e.g. IntelSkylake), CPUID_15h_ECX is zero but CPUID_16h_EAX is present and not zero. On all known processors where this is the case,^[120] the TSC frequency is equal to the Processor Base Frequency, and the Core Crystal Clock Frequency in Hz can be computed asCoreCrystalFreq = (CPUID_16h_EAX * 10000000) * (CPUID_15h_EAX/CPUID_15h_EBX).

On processors that enumerate the TSC/Core Crystal Clock ratio in CPUID leaf 15h, theAPIC timer frequency will be the Core Crystal Clock frequency divided by the divisor specified by the APIC's Divide Configuration Register.^[121]

This leaf is present in systems where an x86 CPUIP core is implemented in an SoC (System on chip) from another vendor - whereas the other leaves ofCPUID provide information about the x86 CPU core, this leaf provides information about the SoC. This leaf takes a sub-leaf index in ECX.

Sub-leaf 0 returns a maximum sub-leaf index in EAX (at least 3), and SoC identification information in EBX/ECX/EDX:

Sub-leaves 1 to 3 return a 48-byte SoC vendor brand string inUTF-8 format. Sub-leaf 1 returns the first 16 bytes in EAX,EBX,ECX,EDX (in that order); sub-leaf 2 returns the next 16 bytes and sub-leaf 3 returns the last 16 bytes. The string is allowed but not required to benull-terminated.

This leaf provides feature information for Intel Key Locker in EAX, EBX and ECX. EDX is reserved.

WhenECX=0, the highest supported "palette" subleaf is enumerated in EAX. WhenECX≥1, information on paletten is returned.

This leaf returns information on theTMUL (tile multiplier) unit.

This leaf returns feature flags on theTMUL (tile multiplier) unit.

When Intel TDX (Trust Domain Extensions) is active, attempts to execute theCPUID instruction by a TD (Trust Domain) guest will be intercepted by the TDX module.This module will, whenCPUID is invoked withEAX=21h andECX=0 (leaf21h, sub-leaf 0), return the index of the highest supported sub-leaf for leaf21h inEAX and a TDX module vendor ID string as a 12-byte ASCII string in EBX,EDX,ECX (in that order). Intel's own module implementation returns the vendor ID string"IntelTDX    " (with four trailing spaces)^[123] - for this module, additional feature information is not available throughCPUID and must instead be obtained through the TDX-specificTDCALL instruction.

This leaf is reserved in hardware and will (on processors whose highest basic leaf is21h or higher) return 0 in EAX/EBX/ECX/EDX when run directly on the CPU.

This returns a maximum supported sub-leaf in EAX and AVX10 feature information in EBX.^[112] (ECX and EDX are reserved.)

Subleaf 1 is reserved for AVX10 features not bound to a version. None are currently defined.

The highest function is returned in EAX.This leaf is only present onXeon Phi processors.^[124]

This function returns feature flags.

When theCPUID instruction is executed underIntel VT-x or AMD-v virtualization, it will be intercepted by the hypervisor, enabling the hypervisor to returnCPUID feature flags that differ from those of the underlying hardware.CPUID leaves40000000h to4FFFFFFFh 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 leaf40000000h, 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 leaf40000001h, the hypervisor may return an interface identification signature in EAX - e.g. hypervisors that wish to advertise that they areHyper-V compatible may return0x31237648—"Hv#1" in EAX.^[125][126] The formats of leaves40000001h 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 of100h leaves per interface. For example, whenQEMU is configured to provide bothHyper-V andKVM interfaces, it will provide Hyper-V information starting from CPUID leaf40000000h and KVM information starting from leaf40000100h.^[127][128]

Some hypervisors that are known to return a hypervisor ID string in leaf40000000h include:

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.

This returns extended feature flags in EDX and ECX.

Many of the bits inEDX (bits 0 through 9, 12 through 17, 23, and 24) are duplicates ofEDX from theEAX=1 leaf - these bits are highlighted in light yellow. (These duplicated bits are present on AMD but not Intel CPUs.)

AMD feature flags are as follows:^[147][148]

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.^[159] It is necessary to check whether the feature is present in the CPU by issuingCPUID withEAX = 80000000h first and checking if the returned value is not less than80000004h.

The string is specified in Intel/AMD documentation to benull-terminated, however this is not always the case (e.g. DM&PVortex86DX3 and AMDRyzen 7 6800HS are known to return non-null-terminated brand strings in leaves80000002h-80000004h^[160][161]), and software should not rely on it.

#include<stdio.h>#include<string.h>#include<cpuid.h>intmain(){unsignedintregs[12];charstr[sizeof(regs)+1];__cpuid(0x80000000,regs[0],regs[1],regs[2],regs[3]);if(regs[0]<0x80000004)return1;__cpuid(0x80000002,regs[0],regs[1],regs[2],regs[3]);__cpuid(0x80000003,regs[4],regs[5],regs[6],regs[7]);__cpuid(0x80000004,regs[8],regs[9],regs[10],regs[11]);memcpy(str,regs,sizeof(regs));str[sizeof(regs)]='\0';printf("%s\n",str);return0;}

On AMD processors, from180nm Athlon onwards (AuthenticAMD Family 6 Model 2 and later), it is possible to modify the processor brand string returned by CPUID leaves80000002h-80000004h by using theWRMSR instruction to write a 48-byte replacement string to MSRsC0010030h-C0010035h.^[156][162] This can also be done on AMD Geode GX/LX, albeit using MSRs300Ah-300Fh.^[163]

In some cases, determining the CPU vendor requires examining not just the Vendor ID in CPUID leaf 0 and the CPU signature in leaf 1, but also the Processor Brand String in leaves80000002h-80000004h. Known cases include:

• Montage Jintide CPUs can be distinguished from the Intel Xeon CPU models they're based on by the presence of the substringMontage in the brand string of the Montage CPUs (e.g. Montage Jintide C2460^[164] and Intel Xeon Platinum 8160^[165] - both of which identify themselves asGenuineIntel Family 6 Model 55h Stepping 4 - can be distinguished in this manner.)
• CentaurHauls Family 6 CPUs may be either VIA or Zhaoxin CPUs - these can be distinguished by the presence of the substringZHAOXIN in the brand string of the Zhaoxin CPUs (e.g. Zhaoxin KaiXian ZX-C+ C4580^[166] and VIA Eden X4 C4250^[167] - both of which identify themselves asCentaurHauls Family 6 Model 0Fh Stepping 0Eh - can be distinguished in this manner.)

This provides information about the processor's level-1 cache andTLB characteristics in EAX, EBX, ECX and EDX as follows:^[a]

• EAX: information about L1 hugepage TLBs (TLBs that hold entries corresponding to 2M/4M pages)^[b]
• 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

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).

#include<stdio.h>#include<cpuid.h>intmain(){unsignedinteax,ebx,ecx,edx;unsignedintlsize,assoc,cache;__cpuid(0x80000006,eax,ebx,ecx,edx);lsize=ecx&0xff;assoc=(ecx>>12)&0x07;cache=(ecx>>16)&0xffff;printf("Line size: %d B, Assoc. type: %d, Cache size: %d KB.\n",lsize,assoc,cache);return0;}

This function provides information about power management, power reporting and RAS (Reliability, availability and serviceability) capabilities of the CPU.