Intel Diamond Rapids Switches To "Family 19" In Ending Intel Family 6 CPU Era

[phoronix]

Phoronix: Intel Diamond Rapids Switches To "Family 19" In Ending Intel Family 6 CPU Era

Months ago Intel Linux engineers began adapting the Linux kernel to end the assumptions made around "Family 6" for Intel CPUs that had been used since the 90's with the Pentium Pro as the CPU family ID. With Linux 6.12 they finished the Intel CPU family/model ID restructuring and now we have the first patch confirming a post-Family 6 Intel CPU: Diamond Rapids is Family 19...

https://www.phoronix.com/news/Intel-Diamond-Rapids-Family-19

[Serafean]

This brings back memories when Linus ran out of fingers, and decided that after 2.6.39 comes 3.0. Random kernel version parsers failing in funny ways.
Magic numbers changing are always funny.

[bug77]

Meh, still integers. Wake me up when they switch to irrational numbers.

[Jumbotron]

Intel should go ahead and append the name Family 19 with the letters....TSMC

[jeisom]

I am really surprised they skipped 7 all the the way through 18 and went with 19. If they updated it every generation they probably would be around 19 now, so makes sense.

[kylew77]

so I guess we will never get an i786 or i886, i686 was the end of the road and now we have this family 19? Does that mean it is really the i1986?

[NotMine999]

Meh, still integers. Wake me up when they switch to irrational numbers.

Methinks that imaginary numbers might be more appropriate for an Intel product

[QwertyChouskie]

Methinks that imaginary numbers might be more appropriate for an Intel product

Is i386 a valid imaginary number?

[Doug]

I am really surprised they skipped 7 all the the way through 18 and went with 19. If they updated it every generation they probably would be around 19 now, so makes sense.

Pentium 4 was family 15, so who knows what internal scheme are they using

[justinkb]

Pentium 4 is not family 15, Pentium 4 is family 0xF, family IDs are hexadecimal.

Perhaps the internal scheme is being close to AMD, a la browser version matching. AMD has just moved to 0x1A with Zen 5, from 0x19 with Zen 3/4.

Rather interesting that for Intel the highest they've gone is 0x11 with Itanium 2, yet they skip right past 0x12-0x18 to land on 0x19 when the internal decision to choose the next family ID would've been done before AMD released (or publicly plumbed support for) Zen 5 with family ID 0x1A.

The code snippet screenshot shows me 19 passed into the macro, not 0x19. And I checked the macro, it invokes another macro VFM_MAKE that manipulates the passed family bitwise, without doing any ugly hacks to prepend 0x or something to turn that 19 into 0x19. So I think you are wrong here (or that new patch made a big mistake, but I don't think it is that)