Geoff Chappell - Software Analyst
Executing the cpuid instruction with 1 in eax nowdays produces meaningful output in all four of the possible registers. The processor identification signature in eax is presumably original. It is what the processor loads into edx as an initial state. That cpuid gives easy access to this signature long after the processor’s initialisation may mean that this signature is the CPU ID that gives cpuid its name. The feature flags in edx are original too, or very nearly. The feature flags in ecx certainly weren’t defined until much later, but both are now more or less fully defined by Intel and AMD, though not all are yet used by Windows. The miscellaneous information in ebx is presently left for another time.
Strictly speaking, cpuid leaf 1 is like any other in that it should be treated as unsupported unless the maximum leaf that’s returned in eax from cpuid leaf 0 is at least 1. Against this is that it’s nearly unthinkable that any cpuid implementation doesn’t extend to leaf 1. The original Windows kernel, for version 3.10, did not bother checking. Nearly unthinkable, however, is not completely unthinkable. With one important exception, versions 3.50 to 6.2 of the 32-bit kernel all check. A processor whose cpuid does not have leaf 1 is treated the same as any old processor that doesn’t have the instruction at all. Whether this was just that a Microsoft programmer took “strictly speaking” seriously or that some processor actually did implement cpuid with a leaf 0 but no leaf 1 is not known.
Versions 6.3 and higher of the x86 kernel take as granted that cpuid is available and has leaf 1. All x64 versions do too, this much cpuid functionality being assured just from have a 64-bit instruction set. For the 32-bit instruction set, the assurance is instead provided by the loader, WINLOAD.EXE, if only for the boot processor. Starting with version 6.2, the loader fails its initialisation almost immediately if the boot processor doesn’t have at least cpuid leaf 1.