3 ms·

IR getting converted into an interpreter-oriented bytecode is pretty common. Mono does it for its interpreter and IIRC, Spidermonkey has historically done that

IR getting converted into an interpreter-oriented bytecode is pretty common. Mono does it for its interpreter and IIRC, Spidermonkey has historically done that as well. I'm not sure if V8 has ever interpreted from an IR (maybe now?) but you could view their original 'baseline JIT' model as converting into an interpreter-focused IR, where the IR just happened to be extremely unoptimized x86 assembly. Translating the stack machine into registers was always a core part of the model but it's interesting to me that even interpreters are doing it. The necessity of doing coloring to assign registers efficiently is kind of unfortunate, I feel like the WASM compiler would have been the right place to do this offline.

jashmatthews 7y ago
> The necessity of doing coloring to assign registers efficiently is kind of unfortunate Register based VMs like Lua don't do this. The register allocation is incredibly simple https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_parse.c#L370 https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_parse.c#L3...
- tom_mellior 7y ago
  But that's an allocator to virtual registers that don't try to correspond to (a valid number of) physical CPU registers. Sure it's easy to allocate to a large number of registers. It's harder to do it to a small number, like the project discussed here seems to claim to do.
  - jashmatthews 7y ago
    I could be completely wrong but it looks like what this does is more like stack-caching. One operand, if it's the result of the last instruction, should already be in "virtual r0" which is already in a register. For the other operand of the opcode, it's an infinite set of "registers" at an offset from the stack pointer: https://github.com/wasm3/wasm3/tree/b1462d450ca367e39e4b2eb414f1520f73dfb7ab/source#the-end-result https://github.com/wasm3/wasm3/tree/b1462d450ca367e39e4b2eb4...
    - tom_mellior 7y ago
      You're right. This doesn't use a register machine in the usual sense of the word. It's kind of the software analog to accumulator machines.
saagarjha 7y ago
> The necessity of doing coloring to assign registers efficiently is kind of unfortunate You don't have to do register allocation with coloring; it's just that most implementations do.

jashmatthews 7y ago

> The necessity of doing coloring to assign registers efficiently is kind of unfortunate Register based VMs like Lua don't do this. The register allocation is incredibly simple https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_parse.c#L370 https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_parse.c#L3...

tom_mellior 7y ago
But that's an allocator to virtual registers that don't try to correspond to (a valid number of) physical CPU registers. Sure it's easy to allocate to a large number of registers. It's harder to do it to a small number, like the project discussed here seems to claim to do.
- jashmatthews 7y ago
  I could be completely wrong but it looks like what this does is more like stack-caching. One operand, if it's the result of the last instruction, should already be in "virtual r0" which is already in a register. For the other operand of the opcode, it's an infinite set of "registers" at an offset from the stack pointer: https://github.com/wasm3/wasm3/tree/b1462d450ca367e39e4b2eb414f1520f73dfb7ab/source#the-end-result https://github.com/wasm3/wasm3/tree/b1462d450ca367e39e4b2eb4...
  - tom_mellior 7y ago
    You're right. This doesn't use a register machine in the usual sense of the word. It's kind of the software analog to accumulator machines.

saagarjha 7y ago

> The necessity of doing coloring to assign registers efficiently is kind of unfortunate You don't have to do register allocation with coloring; it's just that most implementations do.