Run RISC-V Binaries on AMD Zen-Series CPUs via Microcode Modification
22 comments
·April 9, 2025monocasa
snvzz
>This is not achievable.
Maybe.
>And even...
Suppose any hardcoded path can be disabled, and decode done purely in microcode.
Performance would be a function of:
- how well the microcode can perform in decoding RISC-V.
- how well the actual execution units map to RISC-V instructions.
And whether this is worth it, ignoring the effort gone into it and the street cred of making something like this work, would be a function of whether or not it can beat a JIT emulator running on the same hardware.
null
brucehoult
Famous words.
rincebrain
Transmeta out here snickering that it took people this long to think of this.
comprambler
there’s a name I haven’t heard of in awhile
drob518
Indeed. Linus ROFLing.
throwaway48476
The ISA front-end is not strongly coupled and the original zen had a canceled version that used aarch64.
voidbert
So, could it be a feasable for a Zen CPU to have multiple microcode banks it switches between, so that it can run code in multiple architectures? For example, in addition to x86, some microcode for running WebAssembly or Java bytecode with native performance and no JIT overhead?
throwaway48476
Its possible but the platform would have to support it, ie UEFI etc.
Some arm CPUs did have a mode that ran Java bytecode natively but it was slower than the jvm.
mosura
These often repeated notions about Jazelle make little sense.
J2ME code for Jazelle based feature phones (with appropriate VMs) was noticeably faster than otherwise, to the point Android raw Java performance did not catch up for a really long time. If you have loads of RAM to JIT later then . . . good, but that didn’t arrive for years after the fact.
dzaima
Directly running wasm/Java bytecode in hardware is just a bad idea unless you somehow have tons of loopless code that'll only be run once; both are stack-based with an unbounded stack size, so each op would have multiple memory loads/stores. At the very least you'd want some rewriting to use multiple registers, at which point a simple JIT/AOT isn't far off.
monocasa
At least for jazelle, R0-R3 were an alias for top of stack, which removed a lot of memory accesses for the stack nature of the ISA.
wtallis
No, it would need multiple instruction decoders to switch between, not just swapping microcode. Most instructions are not handled with microcode.
jogu
This type of contest style recruiting just seems like a way to trick people into writing code for free, and even if you do win the prize money seems laughably small for what they're asking to receive.
camel-cdr
I think a more realistic thing would be adding a few custom OPs to make binary rewriting more performant.
Another interesting thing would be implementing a subset of RVV with AVX512 hardware primitives, although idk if/how they are exposed in micro code, amd you likely would need to use a different instruction encoding.
snvzz
Unrealistic, yet amusing.
Fortunately, they aren't betting everything on this approach.
null
null
This is not achievable.
There isn't enough rewritable microcode to do this even as a super slow hack.
And even if all of the microcode were rewritable, ucode is kind of a fallback pathway on modern x86 cores with the fast path being hardwired decode for x86 instructions.
And even if that weren't the case the microcode decode and jump is itself hardwired for x86 instruction formats.
And even if that weren't the case the microops are very non-RISC being 2 address, etc.