Duplicating functionality for extracting cache line size with cpuid

1

I examined the cpuid documentation and discovered 2 different documented ways of getting cache line size:

  1. eax = 0x04, ecx = $cache_level

In this way the cache line size at the $cache_level will be stored at EBX[11:0] bits

  1. eax = 0x80000006

In this way the cache line size will be stored at ECX[7:0] and the leaf does not depend on the cache level.

QUESTION: What is the reason for adding cache line size info to the leaf 0x80000006 and why does not it depend on the cache level? I have a suspicion that "the right" way to get the cache line size is eax = 0x04, ecx = $cache_level.

assembly
x86
x86-64
cpuid
asked on Stack Overflow Sep 20, 2019 by St.Antario

1 Answer

6

Intel and AMD (and VIA and...) are different companies; and (sadly) there's no vendor neutral standardizing body involved, nothing forcing sane cooperation between vendors, and nothing preventing vendors from making a big mess in an attempt to make each other look bad.

When AMD created "CPUID, leaf 0x80000006", they did the easy thing - assumed that the cache line size is the same for all caches, and put that into a field.

However (at least in theory) each different cache could have a different "line size"; so when Intel created "CPUID, leaf 0x00000004" they made it so that (in theory) each different cache can report a different "line size".

The right way is to have a mess that sorts out the vendor's mess. Specifically; for AMD CPU's you'd want to use "CPUID, leaf 0x80000006" if you can; and for Intel CPUs (and VIA CPUs I think) you'd want to use "CPUID, leaf 0x00000004" if you can; and for all cases where you can't (e.g. because the CPU is too old to support the vendor's method) you end up with another big mess (e.g. using heuristics, and/or using "vendor:family:model:stepping" to find information in a static database).

Of course on top of that you have to take into account errata; which means trawling through about a hundred "specification updates" and "BIOS and Kernel Developer Guides" to find out if/where "special case work-arounds" are needed.

Note 1: All of the above isn't too hard if the only thing you care about is cache line size; but the more information you want the worse it gets (e.g. if you care about the size of each cache too, then you should expect about 10 times as much hassle and 10 times the maintenance burden).

Note 2: Ideally, the OS would provide "pre-sanitized CPU info"; so that it only needs to be updated in one place, and so that normal software doesn't need to deal with pointless "vendor differences", errata, missing information or conflated information; and direct use of the CPUID instruction would be prohibited (for convenience, correctness and security reasons). Unfortunately no existing OS provides this.

answered on Stack Overflow Sep 20, 2019 by Brendan • edited Sep 20, 2019 by Brendan

User contributions licensed under CC BY-SA 3.0