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.
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.
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?
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.
Android 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.
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.
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.
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.
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.
>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.
Famous words.
Transmeta out here snickering that it took people this long to think of this.
there’s a name I haven’t heard of in awhile
Indeed. Linus ROFLing.
The ISA front-end is not strongly coupled and the original zen had a canceled version that used aarch64.
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?
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.
https://en.wikipedia.org/wiki/Jazelle
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.
Android 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.
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.
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.
And that still ultimately proved slower than JIT and AOT sped up JIT.
And it wasn't targeting devices that had enough spare RAM to run a JIT.
No, it would need multiple instruction decoders to switch between, not just swapping microcode. Most instructions are not handled with microcode.
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.
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.
Unrealistic, yet amusing.
Fortunately, they aren't betting everything on this approach.