[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.

https://en.wikipedia.org/wiki/Jazelle

[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.

[grishka]

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.

[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.

[AstralStorm]

And that still ultimately proved slower than JIT and AOT sped up JIT.

[monocasa]

And it wasn't targeting devices that had enough spare RAM to run a JIT.

[wtallis]

No, it would need multiple instruction decoders to switch between, not just swapping microcode. Most instructions are not handled with microcode.