Skeleton WebAssembly target

Post by cpeterso » Fri, Jun 19, 2015, 6:50 PM UTC

sunfish wrote: post #16

andybak wrote: post #10

If webassembly is essentially asm.js directly converted to a more compact bytecode format but with the same semantics - and emscripten already provides llvm with a backend that outputs asm.js, then what's significant about this? I had assumed from the original webassembly announcement that this would be a fairly trivial step but I expect I've misunderstood something.

Multiple things are happening in parallel here. On Emscripten's side, we're going to add a feature which translates Emscripten's asm.js output into WebAssembly, so that existing Emscripten users can easily use WebAssembly. This will indeed be a fairly simple step. [0] The new WebAssembly backend is being developed in upstream LLVM from the beginning, and will be targetting WebAssembly directly rather than going throu…

Post by bcheung » Fri, Jun 19, 2015, 6:52 PM UTC

StefanKarpinski wrote: post #11

andybak wrote: post #10

If webassembly is essentially asm.js directly converted to a more compact bytecode format but with the same semantics - and emscripten already provides llvm with a backend that outputs asm.js, then what's significant about this? I had assumed from the original webassembly announcement that this would be a fairly trivial step but I expect I've misunderstood something.

My understanding is that it will only initially mirror asm.js but will eventually become a full-blown, independent bytecode IR that departs from JavaScript semantics (while continuing to support expressing them), allowing other languages to be compiled down to WebAssembly and run in the browser efficiently. Having a bytecode format also eases the considerable burden of parsing JavaScript – which is especially problem…

Post by TazeTSchnitzel » Fri, Jun 19, 2015, 7:08 PM UTC

cpeterso wrote: post #31

sunfish wrote: post #16

Earlier quoted context omitted.

Multiple things are happening in parallel here. On Emscripten's side, we're going to add a feature which translates Emscripten's asm.js output into WebAssembly, so that existing Emscripten users can easily use WebAssembly. This will indeed be a fairly simple step. [0] The new WebAssembly backend is being developed in upstream LLVM from the beginning, and will be targetting WebAssembly directly rather than going throu…

Will there be any advantage to generating asm.js over WebAssembly+polyfill for clients that don't support WebAssembly natively?

Post by TazeTSchnitzel » Fri, Jun 19, 2015, 7:10 PM UTC

cpeterso wrote: post #32

azakai wrote: post #28

Earlier quoted context omitted.

All of those advantages are true, except for performance. We actually don't know which approach will be faster to compile, nor which approach will emit faster code. There are reasons to guess either way. The new backend being begun here is something of an experiment, as LLVM shared backend infrastructure was just not designed for this kind of thing (emitting a high-level AST IR without physical registers, etc.). Ther…

What's the relationship between WebAssembly and Emscripten's Emterpreter? https://blog.mozilla.org/research/2015/02/23/the-emterpreter...

Post by bcheung » Fri, Jun 19, 2015, 7:14 PM UTC

TazeTSchnitzel wrote: post #34

bcheung wrote: post #33

Earlier quoted context omitted.

It's just a binary encoding of the AST. Nothing more, nothing less. It's not quite a bytecode, those are typically for interpreters. Binary encoding would be more accurate. The semantics will be identical to JavaScript but the syntax obviously can be completely different depending on the language.

It's a binary encoding of a WebAssembly AST. It's not JavaScript, though it lives in the same universe.