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

・

168 points

・

unsnap_biceps

・

a day ago

98 comments

mikece ・ a day ago

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

  • JonathonW ・ a day ago

    And Cyrix MediaGX (which remained with National Semiconductor after the VIA acquisition) became Geode which was eventually sold to AMD.

  • aleph_minus_one ・ 14 hours ago

    > 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

  • steve1977 ・ 14 hours ago

    Cyrix… that's a name I've not heard in a long time

  • diamond559 ・ a day ago

    VIA has their own license and joint CPU project w/ a Chinese company apparently, could be related to that?

tyfighter ・ a day ago

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.

  • jeffbee ・ a day ago

    Some of the public x86 ISA extensions were things that hyperscalers specifically requested.

    • clausecker ・ a day ago

      Such as?

      • kijiki ・ a day ago
        ・ 2 more

        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.

        • jeffbee ・ 21 hours ago

          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.

  • dboreham ・ a day ago

    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..

    • jeffbee ・ a day ago

      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.

      • aleph_minus_one ・ 14 hours ago

        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

      • dboreham ・ 12 hours ago

        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.

  • renewiltord ・ a day ago

    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

sehugg ・ a day ago

You mean in 2025 someone is getting paid in their job to mess with x86 segment registers? I'd do that stuff for free.

  • eqvinox ・ a day ago

    They're just using the encoding for PUSH CS, presumably the actual instruction doesn't concern segment registers… I hope…

nateb2022 ・ 21 hours ago

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...

eqvinox ・ a day ago

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…

  • syncsynchalt ・ a day ago

    I wonder how long he worked on the "at this particular time" line before giving up?

    • aleph_minus_one ・ 13 hours ago

      My attempt as a non-native English speaker:

        - CPUID range E000_xxxxh - unspecified leaf
    return values as of the day of 2025-10-14
dzdt ・ a day ago

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?

  • aidenn0 ・ a day ago

    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.

  • overfeed ・ a day ago

    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.

  • daft_pink ・ a day ago

    Haven’t the patents for x86 long expired?

    • trenchpilgrim ・ a day ago

      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.

      • jacquesm ・ a day ago
        ・ 23 more

        Or you could just limit your compiler to the subset that worked a while ago.

        • trenchpilgrim ・ a day ago
          ・ 21 more

          Sure, but that limits what code you can use. A lot of consumer software won't work without the SSE extensions, for example.

          • Qem ・ a day ago
            ・ 10 more

            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

            • trenchpilgrim ・ a day ago
              ・ 9 more

              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.

              • Qem ・ a day ago
                ・ 8 more

                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?

                • dzaima ・ a day ago

                  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.

                • trenchpilgrim ・ a day ago

                  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.

                • bluGill ・ a day ago

                  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.

                • crote ・ a day ago
                  ・ 4 more

                  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...

                  • dzaima ・ a day ago

                    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)

                  • astrange ・ a day ago
                    ・ 2 more

                    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.

                    • dzaima ・ a day ago

                      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).

          • jacquesm ・ a day ago
            ・ 8 more

            You'd expect some kind of fall-back in place for older CPUs, no?

            • gary_0 ・ a day ago

              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.

            • wmf ・ a day ago
              ・ 5 more

              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...

              • crote ・ a day ago
                ・ 4 more

                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.

                • jacquesm ・ a day ago

                  > Considering there are no meaningful patent-free x86 CPUs in the wild, why should they?

                  Open core; no ME.

                • wmf ・ a day ago
                  ・ 2 more

                  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.

                  • jacquesm ・ a day ago

                    That's the last thing I would want to do.

            • trenchpilgrim ・ a day ago

              No, often any fallback would be unusuably slow anyway.

          • speed_spread ・ a day ago
            ・ 2 more

            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?

            • dogma1138 ・ a day ago

              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.

        • monocasa ・ a day ago

          Then you lose cmpxchg16b, which is pretty much required for all x86-64 binaries shipping today.

      • mrpippy ・ a day ago
        ・ 6 more

        Do those only apply to hardware implementations? Apple and Microsoft are both shipping x86_64 emulators that support SSE/AVX/AVX2

        • trenchpilgrim ・ a day ago
          ・ 5 more

          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.

          • nomel ・ a day ago
            ・ 3 more

            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.

            • trenchpilgrim ・ a day ago
              ・ 2 more

              Are you willing to fight Intel's lawyers about it, or are you gonna quietly pay them a fee and move on?

              • anthk ・ 16 hours ago

                Then how does QEMU handle that? Or Bochs?

          • monocasa ・ a day ago

            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.

      • throwaway81523 ・ a day ago
        ・ 3 more

        What happened with Transmeta?

        • wmf ・ a day ago
          ・ 2 more

          I think they were bought by Nvidia and the Denver/Carmel ARM cores were based on Transmeta tech.

          • monocasa ・ a day ago

            And particularly Nvidia had intended to make an x86 core, but the licensing fell through.

    • AnimalMuppet ・ a day ago

      The original ones, sure.

      The ones you need for to be compatible with any Intel processor that shipped this side of, say, 2010? No.

  • phendrenad2 ・ a day ago

    Who says it is? There's a long list of emulators and hardware recreatements that proves it isn't.

    • MadnessASAP ・ a day ago

      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.

  • elzbardico ・ a day ago

    Patents, licenses. AMD and Intel, AFAIK, have extensive cross-licensing agreements.

  • mschuster91 ・ a day ago

    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.

    • fluoridation ・ a day ago

      >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.

      • jacquesm ・ a day ago
        ・ 15 more

        Do you have an example of such a project? I'd love to do this on an FPGA.

        • phendrenad2 ・ a day ago
          ・ 14 more

          https://github.com/MiSTer-devel/ao486_MiSTer

          Google is your freeeend

          • jacquesm ・ a day ago
            ・ 13 more

            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.

            • fluoridation ・ a day ago
              ・ 12 more

              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.

              • jacquesm ・ a day ago
                ・ 11 more

                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.

                • bigiain ・ a day ago
                  ・ 2 more

                  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

                  • jacquesm ・ 18 hours ago

                    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.

                • fluoridation ・ a day ago
                  ・ 8 more

                  >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.

                  • jacquesm ・ 18 hours ago

                    > 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.

                  • astrange ・ a day ago
                    ・ 6 more

                    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.

                    • fluoridation ・ a day ago
                      ・ 5 more

                      On i486?

                      • toast0 ・ 18 hours ago
                        ・ 4 more

                        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.

                        • jacquesm ・ 17 hours ago
                          ・ 3 more

                          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.

                          • fluoridation ・ 12 hours ago
                            ・ 2 more

                            What's the goal here, out of curiosity?

                            • jacquesm ・ 12 hours ago

                              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.

  • okanat ・ a day ago

    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.

NobodyNada ・ a day ago

> 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?

snvzz ・ 16 hours ago

Possibly a legacy ISA acceleration feature in an upcoming RISC-V processor.

IlikeKitties ・ a day ago

> Mysterious

https://en.wikipedia.org/wiki/Zhaoxin

  • tssva ・ a day ago

    Zhaoxin is addressed in the article and also why the author considers it unlikely they are the "corporate entity" in question.

  • ok123456 ・ a day ago

    Either Chinese or Russian x86 clones. Diplomatically not named.

    • anticodon ・ a day ago

      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.

      • Tevo ・ a day ago
        ・ 2 more

        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.

        • anticodon ・ 19 hours ago

          It seems there's only software emulation of x86 on Elbrus.