3 ms·
Run RISC-V Binaries on AMD Zen-Series CPUs via Microcode Modification
- throwaway48476 2y agoThe ISA front-end is not strongly coupled and the original zen had a canceled version that used aarch64.
- voidbert 2y agoSo, 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 2y agoIts 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. https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
- mosura 2y agoThese 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.
- grishka 2y agoAndroid ended up doing AOT (the infamous "optimizing apps" step on boot). The modern versions, iirc, have a hybrid approach, interpreting and JITing for newly installed apps but still AOT compiling while the device is charging.
- dzaima 2y agoDirectly 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 2y agoAt 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.
- AstralStorm 2y agoAnd that still ultimately proved slower than JIT and AOT sped up JIT.
- monocasa 2y agoAnd it wasn't targeting devices that had enough spare RAM to run a JIT.
- wtallis 2y agoNo, it would need multiple instruction decoders to switch between, not just swapping microcode. Most instructions are not handled with microcode.
- deleted 2y ago[deleted]
- rincebrain 2y agoTransmeta out here snickering that it took people this long to think of this.
- comprambler 2y agothere’s a name I haven’t heard of in awhile
- drob518 2y agoIndeed. Linus ROFLing.
- monocasa 2y agoThis 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.
- brucehoult 2y agoFamous words.
- snvzz 2y ago>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.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- jogu 2y agoThis 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.
- snvzz 2y agoUnrealistic, yet amusing. Fortunately, they aren't betting everything on this approach.
- camel-cdr 2y agoI 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.