This is something I heard through the grape vine years ago, but when you're a very large corporation negotiating CPU purchasing contracts in quantities of millions, you can get customizations that aren't possible outside of gigantic data centers. Things like enabling custom microcode (and development support) for adding new instructions for the benefit of your custom JIT-ed server infrastructure. The corporate entity here is likely a hyperscaler that everyone knows.
I wonder if this is in response to FineIBT trying to figure out what to use as an undefined opcode? Apparently 0xd6 is being reserved as undefined going forward:
By what legal mechanism is it restricted that not any random company can make their own independent implementation of hardware that interoperates with x86 software?
AMD and Intel have a cross-licensing agreement for patents. Via also has one (two? I don't remember if Centaur and Cyrix's licenses were separate), Via's x86 division was basically disbanded in 2021.
There is no reason to assume it's an independent implementation, it very well could be a company partnered with Intel or AMD.
Hypothetically, Sony could ask AMD to support additional custom opcodes for a still-under-development PlayStation 6 processor, and it would be legally kosher.
Every time new extensions get added to x86 new patents and copyrights are issued to cover those extensions. If you want to make a CPU compatible with what a current compiler produces, you need most of those extensions.
There are further versions of SSE (SSE4 is pretty much a hard requirement on Windows) and a follow-on series, AVX. AVX-512 is from 2016 and AVX10 is from 2023.
That makes me wonder if all those vector extensions pilling on top of each other were really that necessary, or if they are mostly a means of keep churning out patents to delay expiration.
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?
SSE3+ & AVX{,2,-512} & co improve on SSE in pretty much the same way that x86-64 improves on x86 - the old thing still works just fine, but the new one is wider, adds new (very useful!) instructions, doesn't copy over others, and (at least partly) uses different encodings.
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.
Predicting what you will want in a few years is tricky at best. Some things that seem like a great idea are not worth it in the real world and so you pay the price for flexibility nobody uses. Some use case you didn't think of comes along that could really be helped with some tweak you didn't anticipate. thus your flexible architecture is both too flexible and not enough at the same time.
the above is a constant problem in engineering projects more than about 6 months old.
No, the newer extensions are different opcodes. It's like extending an API, you can't change old function signatures, you have to add new ones. The new ones are legitimately useful, most video games and media production software use them a lot.
RISC-V uses a length-agnostic approach, so that would've at least bypassed the need for width-expansion upgrades. But it's something you have to take into account from the very start...
And even that only helps with the length problem, and doesn't help with doing new operations.
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)
Some of SSE is required as part of the x86_64 ABI, and also new versions of Windows (infamously, now) add required CPU extensions so software will often base its requirements on that. And SSE4x is ubiquitous enough (99% of PCs) that some software/games will just require it and simply crash if it can't use those instructions.
Considering there are no meaningful patent-free x86 CPUs in the wild, why should they?
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.
Legally, could a CPU manufacturer implement the unencumbered ISA in hardware and have a separate corporate entity provide a low-level software compatibility trap for the missing instructions? The CPU could even have functional equivalent (but ISA-incompatible) instructions to make it almost as fast. Kind of like third-party microcode?
In theory yes, the problem is that even x86 emulation in hardware in order to run x86 code natively without recompiling can drag you into a legal mess which any western company will avoid.
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.
Wait, you can patent an operation? Is it not considered an API? I assumed the Java case would meant you couldn't. I would think it would be limited to the hardware implementation, or maybe some specifics of the alg.
They said that, but my understanding was that they were really trying to scare apple back on to x86-64. It didn't work, and it was pretty specious anyway.
I would suspect that the patents and other IP dont protect against a software implementation of x86-*. Similar to the way copyright doesnt protect against somebody else making a clean room implementation of an API.
No idea what happens around firmware implementations or an FPGA.
There are independent implementations of x86 at least in software - QEMU can do full emulation at the cost of it being dog slow, which is about the only choice for running fully x86 virtual machines on ARM - no aid from Rosetta for anything.
The problem is the hardware magics you need to make x86 actually performant, there's a lot of patents surrounding that area.
>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.
Not quite. That's a board that contains both an FPGA and an ARM, what I meant was a board that just uses the FPGA for everything and an i386 or better core without any auxiliary processors. 100% clean hardware.
Not really sure what you mean by "no auxiliary processors". Even the on the original IBM PC the CPU was not directly in charge of all the devices. That's generally undesirable because it means any IO ties up the CPU. I think that's what they're using the ARM core for, though I've only just heard of this board minutes ago.
That's a bit different. The whole idea I have revolves around a clean computer without any kind of 3rd party hidden tricks. Of course, the original PC already had several auxiliary processors in places that are important, such as drives, keyboard etc. But let's take those for granted. Adding a soft-core FPGA based i486 to a much more powerful ARM system opens up a massive can of worms: that ARM could do just about anything to the poor 486 without it ever being the wiser.
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.
You've probably seen this already, but just in case... You might be interested in Bunny Huang's work on Betrusted and Precursor. He's building a soft-core FPGA based on RiscV instead of i486, but it's a fascinating project:
https://betrusted.io/ - which includes an open source RiscV design that runs on an fpga
>that ARM could do just about anything to the poor 486 without it ever being the wiser.
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.
Usually patents and the risk of being sued out of existence despite having the right to implement clean-room clones.
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.
Didn't one of the Elbrus CPUs have an x86 translation layer in hardware? Trying to get that to execute code at reasonable speeds, Transmeta style, to use as a replacement to western-supplied hardware wherever you have an explicit need for x86 wouldn't sound particularly far-fetched to me, if I didn't know so little about what's going on within Russia.
Did Cyrix cease to exist or is this someone using their x86 license?
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
And Cyrix MediaGX (which remained with National Semiconductor after the VIA acquisition) became Geode which was eventually sold to AMD.
This is something I heard through the grape vine years ago, but when you're a very large corporation negotiating CPU purchasing contracts in quantities of millions, you can get customizations that aren't possible outside of gigantic data centers. Things like enabling custom microcode (and development support) for adding new instructions for the benefit of your custom JIT-ed server infrastructure. The corporate entity here is likely a hyperscaler that everyone knows.
Some of the public x86 ISA extensions were things that hyperscalers specifically requested.
The block alignment of the text in the e-mail (https://sourceware.org/pipermail/binutils/2025-October/14487...) is triggering some serious tilt for me…
If you want more of this: https://www.youtube.com/watch?v=Y65FRxE7uMc . You can skip to 7:45 if the long intro bores you, but it's worth listening to it.
I wonder how long he worked on the "at this particular time" line before giving up?
You mean in 2025 someone is getting paid in their job to mess with x86 segment registers? I'd do that stuff for free.
They're just using the encoding for PUSH CS, presumably the actual instruction doesn't concern segment registers… I hope…
I wonder if this is in response to FineIBT trying to figure out what to use as an undefined opcode? Apparently 0xd6 is being reserved as undefined going forward:
https://lore.kernel.org/lkml/20250814111732.GW4067720@noisy....
By what legal mechanism is it restricted that not any random company can make their own independent implementation of hardware that interoperates with x86 software?
AMD and Intel have a cross-licensing agreement for patents. Via also has one (two? I don't remember if Centaur and Cyrix's licenses were separate), Via's x86 division was basically disbanded in 2021.
Wasn't Via involved with Zhaoxin? That's still going as far as I know, doing something with Zen1 derived things.
There is no reason to assume it's an independent implementation, it very well could be a company partnered with Intel or AMD.
Hypothetically, Sony could ask AMD to support additional custom opcodes for a still-under-development PlayStation 6 processor, and it would be legally kosher.
Haven’t the patents for x86 long expired?
Every time new extensions get added to x86 new patents and copyrights are issued to cover those extensions. If you want to make a CPU compatible with what a current compiler produces, you need most of those extensions.
Or you could just limit your compiler to the subset that worked a while ago.
Sure, but that limits what code you can use. A lot of consumer software won't work without the SSE extensions, for example.
SSE2 was released circa 2000[1]. Assuming a patent lasts for 20 years, it should be expired for several years now.
[1] https://en.wikipedia.org/wiki/SSE2
There are further versions of SSE (SSE4 is pretty much a hard requirement on Windows) and a follow-on series, AVX. AVX-512 is from 2016 and AVX10 is from 2023.
That makes me wonder if all those vector extensions pilling on top of each other were really that necessary, or if they are mostly a means of keep churning out patents to delay expiration.
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?
SSE3+ & AVX{,2,-512} & co improve on SSE in pretty much the same way that x86-64 improves on x86 - the old thing still works just fine, but the new one is wider, adds new (very useful!) instructions, doesn't copy over others, and (at least partly) uses different encodings.
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.
Predicting what you will want in a few years is tricky at best. Some things that seem like a great idea are not worth it in the real world and so you pay the price for flexibility nobody uses. Some use case you didn't think of comes along that could really be helped with some tweak you didn't anticipate. thus your flexible architecture is both too flexible and not enough at the same time.
the above is a constant problem in engineering projects more than about 6 months old.
No, the newer extensions are different opcodes. It's like extending an API, you can't change old function signatures, you have to add new ones. The new ones are legitimately useful, most video games and media production software use them a lot.
RISC-V uses a length-agnostic approach, so that would've at least bypassed the need for width-expansion upgrades. But it's something you have to take into account from the very start...
And even that only helps with the length problem, and doesn't help with doing new operations.
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)
That's not necessarily a good idea. Small vector uses rely on having nearly no overhead to be faster, so they can't use a generic system.
You'd expect some kind of fall-back in place for older CPUs, no?
Some of SSE is required as part of the x86_64 ABI, and also new versions of Windows (infamously, now) add required CPU extensions so software will often base its requirements on that. And SSE4x is ubiquitous enough (99% of PCs) that some software/games will just require it and simply crash if it can't use those instructions.
It looks like many Linux distros require x86-64-v2 from 2008 and they're preparing to move to v3 from 2013. At this rate they'll never support a level with expired patents. https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level...
Considering there are no meaningful patent-free x86 CPUs in the wild, why should they?
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.
> Considering there are no meaningful patent-free x86 CPUs in the wild, why should they?
Open core; no ME.
That's a fair point. I guess a bigger problem is that a patent-free x86 processor couldn't run any supported version of Windows.
That's the last thing I would want to do.
No, often any fallback would be unusuably slow anyway.
Legally, could a CPU manufacturer implement the unencumbered ISA in hardware and have a separate corporate entity provide a low-level software compatibility trap for the missing instructions? The CPU could even have functional equivalent (but ISA-incompatible) instructions to make it almost as fast. Kind of like third-party microcode?
In theory yes, the problem is that even x86 emulation in hardware in order to run x86 code natively without recompiling can drag you into a legal mess which any western company will avoid.
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.
Then you lose cmpxchg16b, which is pretty much required for all x86-64 binaries shipping today.
Do those only apply to hardware implementations? Apple and Microsoft are both shipping x86_64 emulators that support SSE/AVX/AVX2
They both probably have licenses; Intel stated in 2017 they intended to require licenses for emulators: https://www.forbes.com/sites/tiriasresearch/2017/06/16/intel...
Presumably Apple and Mocrosoft both have counter-leverage of requiring app developers to ship native binaries at some point in the future.
Wait, you can patent an operation? Is it not considered an API? I assumed the Java case would meant you couldn't. I would think it would be limited to the hardware implementation, or maybe some specifics of the alg.
They said that, but my understanding was that they were really trying to scare apple back on to x86-64. It didn't work, and it was pretty specious anyway.
What happened with Transmeta?
I think they were bought by Nvidia and the Denver/Carmel ARM cores were based on Transmeta tech.
And particularly Nvidia had intended to make an x86 core, but the licensing fell through.
The original ones, sure.
The ones you need for to be compatible with any Intel processor that shipped this side of, say, 2010? No.
Who says it is? There's a long list of emulators and hardware recreatements that proves it isn't.
I would suspect that the patents and other IP dont protect against a software implementation of x86-*. Similar to the way copyright doesnt protect against somebody else making a clean room implementation of an API.
No idea what happens around firmware implementations or an FPGA.
Patents, licenses. AMD and Intel, AFAIK, have extensive cross-licensing agreements.
There are independent implementations of x86 at least in software - QEMU can do full emulation at the cost of it being dog slow, which is about the only choice for running fully x86 virtual machines on ARM - no aid from Rosetta for anything.
The problem is the hardware magics you need to make x86 actually performant, there's a lot of patents surrounding that area.
>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.
Do you have an example of such a project? I'd love to do this on an FPGA.
https://github.com/MiSTer-devel/ao486_MiSTer
Google is your freeeend
Not quite. That's a board that contains both an FPGA and an ARM, what I meant was a board that just uses the FPGA for everything and an i386 or better core without any auxiliary processors. 100% clean hardware.
But thank you for the link, fascinating project.
Not really sure what you mean by "no auxiliary processors". Even the on the original IBM PC the CPU was not directly in charge of all the devices. That's generally undesirable because it means any IO ties up the CPU. I think that's what they're using the ARM core for, though I've only just heard of this board minutes ago.
That's a bit different. The whole idea I have revolves around a clean computer without any kind of 3rd party hidden tricks. Of course, the original PC already had several auxiliary processors in places that are important, such as drives, keyboard etc. But let's take those for granted. Adding a soft-core FPGA based i486 to a much more powerful ARM system opens up a massive can of worms: that ARM could do just about anything to the poor 486 without it ever being the wiser.
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.
You've probably seen this already, but just in case... You might be interested in Bunny Huang's work on Betrusted and Precursor. He's building a soft-core FPGA based on RiscV instead of i486, but it's a fascinating project:
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
>that ARM could do just about anything to the poor 486 without it ever being the wiser.
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.
You can limit them with IOMMUs. It's reduced to the power of a hostile process.
Well, that's still bad if you're booted off it.
On i486?
Usually patents and the risk of being sued out of existence despite having the right to implement clean-room clones.
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.
There's also this fun company (DM&P): https://www.vortex86.com
Their "Vortex86DX3" is basically a dual-core 1 GHz Pentium II system on a chip...
> Mysterious
https://en.wikipedia.org/wiki/Zhaoxin
Zhaoxin is addressed in the article and also why the author considers it unlikely they are the "corporate entity" in question.
There are others too. See https://en.wikipedia.org/wiki/List_of_x86_manufacturers
Specifically, the AMD-Chinese joint venture seems like one of the more probable choices: https://en.wikipedia.org/wiki/AMD%E2%80%93Chinese_joint_vent...
Either Chinese or Russian x86 clones. Diplomatically not named.
There's only Russian (Soviet) clone of 8086. There was some finished work on cloning 286 but they were never produced in series, since USSR collapsed.
Didn't one of the Elbrus CPUs have an x86 translation layer in hardware? Trying to get that to execute code at reasonable speeds, Transmeta style, to use as a replacement to western-supplied hardware wherever you have an explicit need for x86 wouldn't sound particularly far-fetched to me, if I didn't know so little about what's going on within Russia.