As you might have heard, a new collaboration between browser vendors was
just announced, WebAssembly (or "wasm" for short), here are some links:

  https://github.com/WebAssembly/design
  https://blog.mozilla.org/luke/2015/06/17/webassembly/

http://blogs.msdn.com/b/mikeholman/archive/2015/06/17/working-on-the-future-of-compile-to-web-applications.aspx
  https://bugs.webkit.org/show_bug.cgi?id=146064
  https://twitter.com/jfbastien/status/611201861245399041
  https://brendaneich.com/2015/06/from-asm-js-to-webassembly

This is basically an effort to standardize what projects like Emscripten
have been emitting (and more). Unlike asm.js, which was just a pure
optimization - i.e. it did not require standardization - WebAssembly is
being developed as a standard. It is, at first, similar to asm.js, and in
fact constructed to be polyfillable to it (see later), so in a sense it can
be seen as a natural evolution of asm.js, moving it towards standardization
and a cleaner, hack-free design.

I see this as the web taking compiling C and C++ seriously, which is
excellent news for all of us here! Things like Math.imul and fround already
showed an interest in assisting compiler output, but WebAssembly takes it
to a new level, basically designing the target in a proper way.

While a fresh start in some ways, WebAssembly will run on JavaScript
engines. In practice, browsers will use their JS engines to run wasm - no
need for new VMs, although new VMs might show up eventually. Also, wasm can
be polyfilled into JS, so it can run on all modern browsers, even before
they support wasm. When a browser does have native support for wasm,
though, then it can provide faster startup, and faster throughput. wasm is
also smaller to download, which is a benefit even with the polyfill.

WebAssembly is still being designed and specced (with us involved, of
course), so it is a work in progress at this point, and it will take some
time before we can benefit from it. But when possible, Emscripten will
support emitting wasm with the flip of a switch, and one day that will be
flipped on by default. Emscripten will also support automatically
integrating the wasm => js polyfill for you. In other words, existing
Emscripten-using projects will be able to benefit from all the advantages
of wasm without you doing anything, getting these improvements will be
almost transparent.

A longer-term development is that there are also efforts to write an LLVM
wasm backend from scratch. This makes sense since wasm is a new thing, and
will grow beyond what asm.js can do today (the docs mention plans to add
things like coroutines, dynamic linking, zero cost exceptions - interesting
and nontrivial features), and a new backend is the best place for that.
This is also a cross-vendor effort, like the wasm spec itself. It will take
a while for the wasm backend to be written and even more for it to mature,
but when it does, it will likely replace Emscripten's current LLVM backend.
This would be the second compiler core upgrade in Emscripten: We began with
a JS core, replaced that with our own asm.js LLVM backend, and this would
replace that with a wasm backend. As with the first core upgrade, and the
other changes mentioned above, this should be mostly transparent to users,
beginning with an optional flag and eventually being turned on by default.
No changes are needed outside of the compiler core for this (in particular,
not in the Emscripten libraries and runtime code, which are where most
Emscripten code is - the compiler core is crucial, but it's relatively
small), so ported projects should just work.

To summarize,

* Browsers are standardizing a new and good format to run compiled C and
C++ code in browsers, called WebAssembly or "wasm". This is exciting!

* asm.js already let us run C and C++ in browsers at near-native speed, and
showed the way for what could be achieved. WebAssembly will improve on that
performance and make it more consistent across browsers.

* Emscripten will of course support compiling code to WebAssembly, and once
it does, you will not need to do anything special to do so, it should "just
work" for your project.

* WebAssembly is still being specced and implemented, and it will take some
time before it is finished and we can benefit from it. In the meanwhile,
you can contribute to both the WebAssembly spec and to Emscripten support
for it, if you are interested.

- Alon

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to