EDIT: That's exactly what it is! 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."
https://lore.kernel.org/lkml/20250814111732.GW4067720@noisy....
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.
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.
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.
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?
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.
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)
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).
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.
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.
Hypothetically, Sony could ask AMD to support additional custom opcodes for a still-under-development PlayStation 6 processor, and it would be legally kosher.
Their "Vortex86DX3" is basically a dual-core 1 GHz Pentium II system on a chip...
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:
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
- CPUID range E000_xxxxh - unspecified leaf
return values as of the day of 2025-10-14> 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...
IlikeKitties•3mo ago
https://en.wikipedia.org/wiki/Zhaoxin
Qem•3mo ago
senkora•3mo ago
tssva•3mo ago
ok123456•3mo ago
anticodon•3mo ago
Tevo•3mo ago
anticodon•3mo ago