> They are a joint venture with VIA which acquired most of Cyrix in 1999
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."
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.
Most of the Intel cache partitioning things were driven primarily by Google. The holy grail was to colocate latency-sensitive tasks with bulk background tasks to increase cluster utilization.
I guess technically CAT and RDT are not ISA extensions because they are managed by MSRs. I was thinking of aspects of BMI, but I am sure that large-scale buyers had input into things like vector extensions, PMU features, and the things you mentioned as well.
Historically the large buyer that could do this was NSA. Men in black would show up and tell you to add a bit population count instruction to your CPU..
I think it's doubtful that around the time that POPCNT was added to CPUs the NSA was all that influential. Their big scary data center, which is actually tiny, wasn't built until 2014, while players like Google and Meta had much larger data centers years earlier and were undoubtedly larger buyers of AMD Barcelona / Intel Westmere where POPCNT first emerged.
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.
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.
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.
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.
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)
If the scalable VLEN is the same as the ALU width, which should generally be the target, small vectors would still perform optimally.
Of course if you need less than a VLEN-sized vector you're wasting throughput, but that applies just as much when using 128-bit vectors on AVX-capable hardware, and even worse so on AVX-512-capable (which, while double-pumped or equivalent to some extent on most impls, still has 512-bit-exclusive throughput on most).
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
Yes, I've seen it, in fact that's my major inspiration. I already have some software that I can run on an i486 so RiscV would come with substantial extra development cost.
>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't defend against an adversary in your own machine.
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.
An i486 certainly doesn't have an integrated iommu, and none of the chipsets for 486s had them either (afaik), but that doesn't mean you can't add one if you're building up your system from scratch.
Or you could forego DMA completely if you wanted. Almost all DMA capable devices have some kind of non-DMA route to access the data. It may be slower and it would of course still enable an adversary with access to your hardware to replace the device you boot from with one that has compromised data on it. But at that level it is usually game over anyway. I was thinking of just using an SD card, and if you're really paranoid about this (which I am!) you could glue it into the slot or make it physically impossible to replace it without damage to the case.
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.
> 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?
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.
> They are a joint venture with VIA which acquired most of Cyrix in 1999
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
Cyrix… that's a name I've not heard in a long time
VIA has their own license and joint CPU project w/ a Chinese company apparently, could be related to that?
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.
eg. "custom Intel Xeon 6 processors, available only on AWS." https://aws.amazon.com/blogs/aws/best-performance-and-fastes...
Some of the public x86 ISA extensions were things that hyperscalers specifically requested.
Such as?
Most of the Intel cache partitioning things were driven primarily by Google. The holy grail was to colocate latency-sensitive tasks with bulk background tasks to increase cluster utilization.
I guess technically CAT and RDT are not ISA extensions because they are managed by MSRs. I was thinking of aspects of BMI, but I am sure that large-scale buyers had input into things like vector extensions, PMU features, and the things you mentioned as well.
Historically the large buyer that could do this was NSA. Men in black would show up and tell you to add a bit population count instruction to your CPU..
I think it's doubtful that around the time that POPCNT was added to CPUs the NSA was all that influential. Their big scary data center, which is actually tiny, wasn't built until 2014, while players like Google and Meta had much larger data centers years earlier and were undoubtedly larger buyers of AMD Barcelona / Intel Westmere where POPCNT first emerged.
Here is an article about the popcnt instruction:
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
Oh, when I saw this happen first-hand, it was probably 1986.
Note that the first "data center" I know of was built at Bletchley Park in the 1940s.
Oracle Cloud used to boast this as something they had. Tuned for OracleDB with more cache, different core count.
And every homelabber has had one of the 7B13 or 9654-variant processors
Last month, Nvidia and Intel announced jointly developed 'Intel x86 RTX SOCs' + custom Nvidia data center x86 processors.[0]
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...
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....
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?
My attempt as a non-native English speaker:
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.
no they are different, for AMD zen1 stuff: https://en.wikipedia.org/wiki/AMD%E2%80%93Chinese_joint_vent...
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.
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.
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.
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.
If the scalable VLEN is the same as the ALU width, which should generally be the target, small vectors would still perform optimally.
Of course if you need less than a VLEN-sized vector you're wasting throughput, but that applies just as much when using 128-bit vectors on AVX-capable hardware, and even worse so on AVX-512-capable (which, while double-pumped or equivalent to some extent on most impls, still has 512-bit-exclusive throughput on most).
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.
Are you willing to fight Intel's lawyers about it, or are you gonna quietly pay them a fee and move on?
Then how does QEMU handle that? Or Bochs?
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
Yes, I've seen it, in fact that's my major inspiration. I already have some software that I can run on an i486 so RiscV would come with substantial extra development cost.
>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't defend against an adversary in your own machine.
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.
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?
An i486 certainly doesn't have an integrated iommu, and none of the chipsets for 486s had them either (afaik), but that doesn't mean you can't add one if you're building up your system from scratch.
Or you could forego DMA completely if you wanted. Almost all DMA capable devices have some kind of non-DMA route to access the data. It may be slower and it would of course still enable an adversary with access to your hardware to replace the device you boot from with one that has compromised data on it. But at that level it is usually game over anyway. I was thinking of just using an SD card, and if you're really paranoid about this (which I am!) you could glue it into the slot or make it physically impossible to replace it without damage to the case.
What's the goal here, out of curiosity?
Good question :)
Roughly what Bunny was after, not in laptop format, and running my own, recently revived OS.
Effectively a machine of which I know each and every byte.
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...
> 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.
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?
Possibly a legacy ISA acceleration feature in an upcoming RISC-V processor.
> 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.
It seems there's only software emulation of x86 on Elbrus.