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.
Because the 68000 offered an unprivileged MOVE from SR the two different CPUs could be told apart by a CPU error condition being triggered.
To obtain extended function information CPUID should be called with the most significant bit of EAX set.
The following example code displays the vendor ID string as well as the highest calling parameter that the CPU implements.
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.
This returns a list of descriptors indicating cache and TLB capabilities in EAX, EBX, ECX and EDX registers.
Note that the processor serial number feature must be enabled in the BIOS setting in order to function.
These two leaves are used to provide information about the cache hierarchy levels available to the processor core on which the CPUID instruction is run.
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.
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 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.
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] from Wildfire Games also implements the correct interpretation of the Intel documentation.
This returns feature information related to the MONITOR and MWAIT instructions in the EAX, EBX, ECX and EDX registers.
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.
This will return the following items in EAX, EBX and ECX (with EDX being reserved): (This offset is 0 for supervisor state-components, since these can only be saved with the XSAVES/XRSTORS instruction, which use compacting.)
Attempting to query an unsupported state-component in this manner results in EAX,EBX,ECX and EDX all being set to 0.
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.
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.
Hypervisors that implement these leaves will normally also set bit 31 of ECX for CPUID leaf 1 to indicate their presence.
PPIN_CTL (C001_02F0) and PPIN (C001_02F1) MSRs are present[171] This leaf returns information about AMD SVM (Secure Virtual Machine) features in EAX, EBX and EDX.
[180]Several AMD CPU models will, for CPUID with EAX=8FFFFFFFh, return an Easter Egg string in EAX, EBX, ECX and EDX.
[187][188] Known Easter Egg strings include: Returns index of highest Centaur leaf in EAX.
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: 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.
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.
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.
For instance, the C# code below prints the processor brand if it supports CPUID instruction: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.