2 ms·
“proposal to move WASM towards a control-flow model friendlier to tail-call optimization, which would bring it more in line with physical hardware.“ perhaps it
by egberts1 4y ago
“proposal to move WASM towards a control-flow model friendlier to tail-call optimization, which would bring it more in line with physical hardware.“
perhaps it is nigh time to bring the CPU hardware closer to the current WASM design.
Might simplify a lot of issues related to pipelining, cache-busting, and Spectre-like mitigations, not to mention crazy varied breakout of legacy microcode to subfunctions (Intel, I am looking at you as well).
But what do I know, I just play with Unicorn engine.
- egberts1 4y agomeanwhile, the new Spectre-BTI variant just now embroils both AMD and Intel on media. Naysayer (downvoters) seems sure that JavaScript engine having this new tailcall would not be impacted. Of course, I would be talking about the generated microcode, not the JavaScript LIR bytecode. https://arstechnica.com/information-technology/2022/07/intel-and-amd-cpus-vulnerable-to-a-new-speculative-execution-attack/ https://arstechnica.com/information-technology/2022/07/intel...
- egberts1 4y agoFor those who specialize in emitting platform-dependent native machine code translated from macrobytecode to MIR to LIR, following paper outlines the pitfalls of tailcall: https://www3.cs.stonybrook.edu/~mikepo/papers/devil.ndss15.pdf https://www3.cs.stonybrook.edu/~mikepo/papers/devil.ndss15.p... Speaking in Firefox-ese, within its JavaScript engine, IonMonkey taking JavaScript bytecode down to Mid-level Intermediate Representation (MIR), then OdinMonkey (TraceMonkey) translates to Low-level Intermediate Representation (LIR), then for WarpMonkey (NanoJIT) to translate into native machine code. OdinMonkey and WarpMonkey should not be handling tailcalls.