5 ms·

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, i

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 1y ago
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 https://en.wikipedia.org/wiki/Jazelle
- mosura 1y ago
  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 1y ago
    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 1y ago
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 1y ago
  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 1y ago
    And that still ultimately proved slower than JIT and AOT sped up JIT.
    - monocasa 1y ago
      And it wasn't targeting devices that had enough spare RAM to run a JIT.
wtallis 1y ago
No, it would need multiple instruction decoders to switch between, not just swapping microcode. Most instructions are not handled with microcode.

throwaway48476 1y ago

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 https://en.wikipedia.org/wiki/Jazelle

mosura 1y ago
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 1y ago
  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 1y ago

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 1y ago
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 1y ago
  And that still ultimately proved slower than JIT and AOT sped up JIT.
  - monocasa 1y ago
    And it wasn't targeting devices that had enough spare RAM to run a JIT.

wtallis 1y ago

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