[HN Gopher] Mysterious Intrigue Around an x86 "Corporate Entity ...
___________________________________________________________________
Mysterious Intrigue Around an x86 "Corporate Entity Other Than
Intel/AMD"
Author : unsnap_biceps
Score : 140 points
Date : 2025-10-16 17:36 UTC (5 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| IlikeKitties wrote:
| > Mysterious
|
| https://en.wikipedia.org/wiki/Zhaoxin
| Qem wrote:
| There are others too. See
| https://en.wikipedia.org/wiki/List_of_x86_manufacturers
| senkora wrote:
| 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...
| tssva wrote:
| Zhaoxin is addressed in the article and also why the author
| considers it unlikely they are the "corporate entity" in
| question.
| ok123456 wrote:
| Either Chinese or Russian x86 clones. Diplomatically not named.
| anticodon wrote:
| 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 wrote:
| 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.
| mikece wrote:
| 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 wrote:
| And Cyrix MediaGX (which remained with National Semiconductor
| after the VIA acquisition) became Geode which was eventually
| sold to AMD.
| eigenform wrote:
| 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....
| dzdt wrote:
| 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?
| mschuster91 wrote:
| 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 wrote:
| >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 wrote:
| Do you have an example of such a project? I'd love to do
| this on an FPGA.
| phendrenad2 wrote:
| https://github.com/MiSTer-devel/ao486_MiSTer
|
| Google is your freeeend
| jacquesm wrote:
| 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 wrote:
| 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 wrote:
| 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.
| fluoridation wrote:
| >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.
| astrange wrote:
| 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 wrote:
| On i486?
| elzbardico wrote:
| Patents, licenses. AMD and Intel, AFAIK, have extensive cross-
| licensing agreements.
| aidenn0 wrote:
| 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.
| mook wrote:
| Wasn't Via involved with Zhaoxin? That's still going as far
| as I know, doing something with Zen1 derived things.
| phendrenad2 wrote:
| Who says it is? There's a long list of emulators and hardware
| recreatements that proves it isn't.
| MadnessASAP wrote:
| 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.
| daft_pink wrote:
| Haven't the patents for x86 long expired?
| trenchpilgrim wrote:
| 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 wrote:
| Or you could just limit your compiler to the subset that
| worked a while ago.
| trenchpilgrim wrote:
| Sure, but that limits what code you can use. A lot of
| consumer software won't work without the SSE extensions,
| for example.
| jacquesm wrote:
| You'd expect some kind of fall-back in place for older
| CPUs, no?
| trenchpilgrim wrote:
| No, often any fallback would be unusuably slow anyway.
| gary_0 wrote:
| 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 wrote:
| 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#Microarchit
| ecture_level...
| crote wrote:
| 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 wrote:
| > Considering there are no meaningful patent-free x86
| CPUs in the wild, why should they?
|
| Open core; no ME.
| wmf wrote:
| 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 wrote:
| That's the last thing I would want to do.
| Qem wrote:
| 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 wrote:
| 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 wrote:
| 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?
| trenchpilgrim wrote:
| 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.
| dzaima wrote:
| 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.
| crote wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bluGill wrote:
| 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.
| speed_spread wrote:
| 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 wrote:
| 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 wrote:
| Then you lose cmpxchg16b, which is pretty much required
| for all x86-64 binaries shipping today.
| throwaway81523 wrote:
| What happened with Transmeta?
| wmf wrote:
| I think they were bought by Nvidia and the Denver/Carmel
| ARM cores were based on Transmeta tech.
| monocasa wrote:
| And particularly Nvidia had intended to make an x86 core,
| but the licensing fell through.
| mrpippy wrote:
| Do those only apply to hardware implementations? Apple and
| Microsoft are both shipping x86_64 emulators that support
| SSE/AVX/AVX2
| trenchpilgrim wrote:
| 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 wrote:
| 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.
| monocasa wrote:
| 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.
| AnimalMuppet wrote:
| The original ones, sure.
|
| The ones you need for to be compatible with any Intel
| processor that shipped this side of, say, 2010? No.
| okanat wrote:
| 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.
| overfeed wrote:
| 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.
| sehugg wrote:
| 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 wrote:
| They're just using the encoding for PUSH CS, presumably the
| actual instruction doesn't concern segment registers... I
| hope...
| Teknoman117 wrote:
| 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...
| tyfighter wrote:
| 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 wrote:
| Some of the public x86 ISA extensions were things that
| hyperscalers specifically requested.
| eqvinox wrote:
| 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 wrote:
| I wonder how long he worked on the "at this particular time"
| line before giving up?
| progval wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-16 23:00 UTC)