3 ms·
> I don't think this is a good assessment. It's not so much an assessment as one of the main stated goals of the project. The initial point of WebAssembly is
by bzbarsky 10y ago
> I don't think this is a good assessment.
It's not so much an assessment as one of the main stated goals of the project. The initial point of WebAssembly is to do what asm.js does but with a smaller on-the-wire size and much less processing overhead to get from the on-the-wire format to executable code. And more cross-vendor buy-in, so the results are more reliable.
> an in-memory representation is produced (probably LLVM IR),
It's not LLVM IR in either Firefox or Chrome, fwiw. In the case of Firefox, it's the IR that Ion (the "fastest" tier of the JIT) uses. I expect this to be a pretty common approach across browsers, actually; it lets you leverage your existing code generation infrastructure.
Safari actually tried using using LLVM for this sort of thing. They stopped. See https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler... for details.
> This task is comparable in complexity to a JavaScript interpreter with a JIT compiler.
Not really. Once you've got the IR you just use your existing codepaths for it; the IR generation from webasm is a much simpler task than IR generation from JS, complete with runtime instrumentation and whatnot.