Run RISC-V Binaries on AMD Zen-Series CPUs via Microcode Modification
rvspoc.org
rvspoc.org
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.
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.
Some arm CPUs did have a mode that ran Java bytecode natively but it was slower than the jvm.
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.
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.
Fortunately, they aren't betting everything on this approach.