Intel Next-Gen CPU Cores & Families Unearthed: Douglas Cove For Adams Lake & Sheldonmont For Cooper Forest

[1_rick]

https://wccftech.com/intel-next-gen...as-cove-adams-lake-sheldonmont-cooper-forest/

WCCFTech misread an email on the Linux Kernel mailing list talking about new Intel CPUIDs. In it, the poster writes about a way to redo #defines that will make kernel coding that is specific to various CPU models more readable, and says

New CPUs in other families might look like:

#define INTEL_DOUGLASCOVE IFM(42, 0x01) /* Adams Lake */
#define INTEL_SHELDONMONT IFM(73, 0x01) /* Cooper Forest */

I hadn't clicked the link at first, but I commented over there "it's not even April Fool's Day!" Having actually skimmed the email now, it's obvious that whoever read it and wrote an article about it had no idea what he was reading.

 

[1_rick]

The meat of the email is that Intel's apparently going to finally start reporting new CPUs as something other than Family 6 at some point, and the discussion was about not duplicating the mess of various processor features, as code using Family 6 does.

Intel has been using family 6 almost exclusively for many
years. As a result, Linux has built up infrastructure like
X86_MATCH_INTEL_FAM6_MODEL() to make it easy for model specific code to
use the #defines for each Intel CPU model.

But the reign of family 6 is about to end. Intel will begin using non-zero
values for the extended family field in CPUID(1).EAX. The minimal patch
size approach to handle these would be to clone the FAM6 macros. But
that will get messy as these prolifrate. This approach does not have an
elegant solution if a switch() statement needs to choose between CPUs
from different families.

Dave Hansen suggested that a more general cleanup that provides
CPU #defines that encode all of <vendor, family, model> would make
existing code better, and provide infrastructure that makes it trivial
to incorporate new families.

Big picture view is that code like this:

if (c->x86_vendor == X86_VENDOR_INTEL && c->x86 == 6 && c->x86_model == INTEL_FAM6_ICELAKE_X)

can become:

if (c->x86_vfm == INTEL_ICELAKE_X)

which is:
a) Simpler
b) Faster
c) More resilient (can't forget to check vendor & family along with model)
d) Code style doesn't change for every new family.

Note that "struct cpuinfo_x86" gains a new xf6_vfm field and the ICELAKE
#define loses the "FAM6_" substring and will be initialized with a macro
that does the bit shuffling to fit X86_VENDOR_INTEL and a family and
model into a "u32":

#define INTEL_ICELAKE_X IFM(6, 0x6A) /* Sunny Cove */

New CPUs in other families might look like:

#define INTEL_DOUGLASCOVE IFM(42, 0x01) /* Adams Lake */
#define INTEL_SHELDONMONT IFM(73, 0x01) /* Cooper Forest */

Model specific "if" statements then follow the same pattern
regardless of family:

if (c->x86_vfm == INTEL_DOUGLASCOVE || c->x86_vfm == INTEL_SHELDONMONT) {
}

The email itself is actually kind of interesting and, on the surface, seems to make a lot of sense. But someone at WCCF went off the deep end, not realizing Douglas Cove and Sheldonmont cores were hypothetical examples.