Let's see some ID

First of all, let's say a few words about CPUID. This is a processor command that returns processor's "passport." It was first introduced in higher-end 486 and Pentium processors. Its presence is marked by the possibility to overwrite the 21st bit of the flag register. The command has an implicit argument (the passport page in the EAX register) and it returns 16B in the registers EAX, EBX, ECX and EDX. This is what a program needs to determine features and capabilities of a processor. However, there may be exceptions in real life. Below is Nano's table of returned values.

VIA processors also have the 3rd part, starting from the page C0'00'00'00. It describes specific functions (e.g. PadLock instructions) and contains the original "Family, model, stepping" string. In our tests we changed vendor name to "GenuineIntel," and its place in the hierarchy to "6; 17; 0" (EAX=00'01'06'70), even though stepping 0 means it's an engineering sample not intended for sale (which is indicated by the letters "ES" on the second screenshot).

As you can see, not all the supplied information is correct, even if no strings have been changed. Cache and TLB parameters used to be provided by descriptors on page 2 of the 1st part. But one byte is not enough for all possible combinations, that's why caches and TLB are described thoroughly in the 2nd part, and this is the place to search for programs like CPU-Z. For examples, there's no descriptor "L1D: 64KB, 2 ways and 64 line" (like that of modern AMD chips), but all applications show the correct cache parameters for such processors. However, the CPU-Z screenshot shows that this isn't so for VIA Nano (and for all CPUs most likely). It seems that CPU-Z doesn't actually read cache parameters with CPUID, but just obtains those from its database, based on the vendor name and the "Family, model, stepping" string. It's the same substitution as that of Intel dispatchers.

Of course, some manufacturers just don't care to accurately specify parameters of their CPUs. For example, the first AMD Duron processors reported about having 1KB L2. So in order to provide correct data on even the first processor modifications, applications just keep the "correct values" stored in their tables. When a truly unknown CPU is involved, there's sense in reading the data directly by means of CPUID. Otherwise one may try to fool both applications and users. As for Intel, the company openly states in its documentation that if vendor string isn't "GenuineIntel," one shouldn't rely upon the interpretation of other fields the documentation provides, including the list of supported instruction sets. However all other processor manufacturers are encoding CPUID passports in exactly the same way, with the same pages, fields and interpretations.

Write a comment below. No registration needed!