Mysterious Intrigue Around an X86 "corporate Entity Other Than Intel/amd"
Posted3 months agoActive3 months ago
phoronix.comTechstoryHigh profile
calmmixed
Debate
70/100
X86 ArchitectureCPU DesignInstruction Set Extensions
Key topics
X86 Architecture
CPU Design
Instruction Set Extensions
A mysterious corporate entity, other than Intel or AMD, is using certain x86 opcodes, sparking discussion about the identity of this entity and the implications for x86 compatibility and future development.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
20m
Peak period
29
0-2h
Avg / period
10
Comment distribution90 data points
Loading chart...
Based on 90 loaded comments
Key moments
- 01Story posted
Oct 16, 2025 at 1:36 PM EDT
3 months ago
Step 01 - 02First comment
Oct 16, 2025 at 1:56 PM EDT
20m after posting
Step 02 - 03Peak activity
29 comments in 0-2h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 17, 2025 at 8:44 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45608285Type: storyLast synced: 11/20/2025, 7:45:36 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://en.wikipedia.org/wiki/Zhaoxin
EDIT: That's exactly what it is! They are a joint venture with VIA which acquired most of Cyrix in 1999:
https://en.wikipedia.org/wiki/VIA_Technologies
FYI: Zhaoxin (兆芯) [1] is a Joint Venture between VIA Technologies (威盛電子) and the Shanghai Municipal Government. Zhaoxin is mentioned in the article:
"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."
[1] https://en.wikipedia.org/wiki/Zhaoxin
The problem is the hardware magics you need to make x86 actually performant, there's a lot of patents surrounding that area.
Those aren't even patented, they're straight up trade secrets. The relevant IPs concern the ISAs alone. Without doing anything too crazy you could implement x86 on your own silicon and make something that's slower than mainstream processors, but still usable for some things; certainly better than emulation in software, that's for sure.
Google is your freeeend
But thank you for the link, fascinating project.
Anyway, this project may be useful (I've been digging around in it some more since making the previous comment) because the FPGA itself is fairly common and the i486 bits and pieces could probably be recycled in something much simpler.
Any device with DMA has that same issue, though. You could plug in a hard drive that takes control of the CPU by writing new instructions when certain conditions are met. Even if it doesn't have DMA, it could fulfill a request with crafted data. You can't defend against an adversary in your own machine.
Well, that's still bad if you're booted off it.
Not if you import large chunks of unknown hardware. But if you built the whole thing from scratch you could. And FPGA's with adversarial blocks in them (or a toolchain that would corrupt your own bitstream) are probably possible but I don't see these as realistic attacks against a one-off.
https://betrusted.io/ - which includes an open source RiscV design that runs on an fpga
https://www.crowdsupply.com/sutajio-kosagi/precursor - an FPGA-based open hardware implementation you can buy and experiment with
No idea what happens around firmware implementations or an FPGA.
It's just the default optimization level for those distros. If patent-free x86 CPUs become relevant, compiling another set of binaries would be trivial. Until then it doesn't make any sense to kneecap the >99% of x86 deployments by deliberately refusing to use faster and more efficient instructions.
Open core; no ME.
[1] https://en.wikipedia.org/wiki/SSE2
Is it possible to just improve the original SSE extensions in a logical backward compatible way? Similar to what AMD did to x86, widening it to x86-64, dooming Intel efforts to push the incompatible Itanium architecture?
For SIMD, baseline x86-64 (i.e. SSE + SSE2) didn't have dynamic shuffles & shifts & blend, float floor/ceil, integer conversions & min/max & 64-bit comparisons & 32-bit mul, just to name things useful for even very boring SIMD; then in AVX2 we also get gather/masked load/store, FMA, and in AVX-512 we get a bunch of neat mask stuff, integer narrowing & rotates, compress.
(much of those things RVV has in its base extension, but RISC-V already has a good number of extensions on top of base RVV for things like like float16/bfloat16, expanded bitwise stuff (Zvbb - rotates/popcount/lzcnt/widening shift), clmul, and a bunch of crypto things; and presumably in a decade there'll be a bunch more things that people will want in their CPUs that'll have no choice but to be new extensions)
And an important thing to remember is that there is and never as a single "x86" before x86-64; both Intel and AMD added new instructions as was seen useful in new generations. AVX & co just continue the pattern that's been going on for four decades.
the above is a constant problem in engineering projects more than about 6 months old.
NVIDIA got pinched for this over a decade ago.
I’m not entirely sure how Qualcomm and Apple didn’t.
But overall the more you try to make an x86 enabled alternative viable the more likely you’ll get served with papers and even if you’ll win it would take a decade and cost 100’s of millions to fight.
Presumably Apple and Mocrosoft both have counter-leverage of requiring app developers to ship native binaries at some point in the future.
The ones you need for to be compatible with any Intel processor that shipped this side of, say, 2010? No.
Hypothetically, Sony could ask AMD to support additional custom opcodes for a still-under-development PlayStation 6 processor, and it would be legally kosher.
Patents use sly language and legalese spagetti. If your implementation looks similar, you may lose the right to manufacture certain parts or the entire thing. The law is deliberately vague and you are at the whims of the judge.
https://vaibhavsagar.com/blog/2019/09/08/popcount/
The author of the article believes that while popcnt was indeed used for cryptographical analysis in the 60s, but the fact that popcnt disappeared from instruction sets is seen as evidence that this usage became a lot less important over time. So the author considers the reason for the reappearance of popcnt that there simply exist lots of other useful applications of popcnt that become evident over these decades.
A German article about the same topic:
https://nickyreinert.medium.com/ne-49-popcount-ea62aa304f88
Note that the first "data center" I know of was built at Bletchley Park in the 1940s.
And every homelabber has had one of the 7B13 or 9654-variant processors
Their "Vortex86DX3" is basically a dual-core 1 GHz Pentium II system on a chip...
> As of 2025, the following are in active use by a corporate entity other than Intel/AMD.
> Any collisions with them should be avoided.
What's the purpose of sending this email to these mailing lists -- who cares about assigning x86 instruction opcodes other than Intel and AMD? Do Linux and binutils need to know about unused x86 opcodes in some way? And even if they did...why do unaffiliated open-source projects need to care about a nonstandard architecture extension from a company so secretive about it they won't even name themselves?
Opcodes 0Fh,3Ah,E0h...EFh combined with VEX/EVEX encoding suggests wide (256/512-bit) vector SIMD, possibly for matrix multiplication, tensor operations, or arbitrary neural network activation functions.
[0]: https://nvidianews.nvidia.com/news/nvidia-and-intel-to-devel...
https://lore.kernel.org/lkml/20250814111732.GW4067720@noisy....
6 more comments available on Hacker News