Mysterious Intrigue Around an x86 "Corporate Entity Other Than Intel/AMD"

"If x86 opcode/CPUID/MSR allocations are not of your concern, then you can stop reading. -------------------- 8< ------------------- I was asked to relay this to binutils/LKML. As of 2025, the following are in active use by a corporate entity other than Intel/AMD. Any collisions with them should be avoided. - opcode 0Eh in PM64 - x86 PUSH CS that got removed by x86-64 in 2002; not used since - opcode 0Fh,36h and opcode 0Fh,3Eh - there is a historic collision with Cyrix RDSHR, but that is not considered to be an issue - opcode 0Fh,3Ah,E0h...EFh in classic, VEX, EVEX, Map3, and Map7 encodings, without a prefix, or CS/SS/DS/ES/FS/GS, LOCK, REPE/REPNE, or ASIZE/OSIZE/REX (but not REX2!) prefixes - a historic collision with K10M VCVTFXPNTPD2DQ (at MVEX opcode E6h prefix F2) exists but is not considered an issue - opcode 0Fh,1Eh,/0 - a "hinting NOP" group - CPUID range E000_xxxxh - unspecified leaf return values at this particular time - MSR range E000_xxxxh - unspecified values after RESET - unchanged values after INIT I have documented them at www.sandpile.org. -------------------- 8< ------------------- -- C." Posted to the Linux kernel mailing list and GNU Binutils mailing list today is an intriguing message from a longtime x86/x86_64 expert around a "a corporate entity other than Intel/AMD" using some x86 opcodes not used by AMD or Intel processors.Longtime x86 expert Christian Ludloff posted a cryptic message to the LKML and Binutils mailing lists. An anonymous Phoronix reader in turn relayed the interesting occurrence to me. Christian Ludloff has worked for Google, AMD, TI, and others over the years as an x86 architecture expert as well as being known for his sandpile.org x86 CPU information site.The subject for the mailing list posts by Christian Ludloff wasand simply said:These x86 opcodes and CPUs and MSR ranges now "in active use by a corporate entity other than Intel/AMD" makes this rather intriguing... And that it's a "corporate" entity rather than noting a research organization, hobbyist project, etc. And how said corporate entity has the legal ability to even work on a new x86-based implementation is interesting. For Christian Ludloff to be involved does give it additional weight.As pointed out in the Phoronix Forums, it could be Zhaoxin . But as they have contributed GCC patches , Glibc patches, Linux kernel patches, etc, over the years it's not clear why they would go unnamed or have to relay the message via Ludloff rather than their prior direct mailing list posts. For now that's all I know but rather interesting seeing this message from Ludloff today on the public mailing lists.