WebAssembly

[Alon Zakai]

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

[Morgaine Fowle]

This sounds like the death of human runnable code on the web, and the end of machine-to-machine interoperability that JS-as-target has given us. Building a bunch of dev tools for a bytecode language is a shocking prospect. This is a major major change, and I worry that the relative thin-ness, the human-ness of the web is a thing that's made it great, that's made it a preferred platform, and that this puts a very serious kink in that.

Emscripten has been great because it's targeted JS, and enriched it. But with languages just focusing on a VM underneath, I worry the tech will recede into various factional camps, with no interest in aiding the greater web. I'm happy we have good new tech under development, this sounds like an interesting effort, but it also opens very scary ends where the web becomes as banal as every other native platform, as isolated and by itself, with as little interest in enriching the greater whole as we see with everything else not-Web, or without major embedding points (which I'd classify as enriching, but in a single-serving capacity). Today's a major win for machine to machine, but I worry that we're closing the door on people.

Fair us all well. Expecting a report on devtools situations in this brave brave new world soon, regards, yours,
rektide

[Morgaine Fowle]

(Brendan has pointed me at https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webassembly-support-view-source-on-the-web . I still have a lot of fear regarding the commonality of the systems we write, that interoperability and readability will suffer as I wrote above, but it's renewing to read, and it's important to note that there is an intent to try to keep some of what is so good about JS-as-target)

[Pepijn Van Eeckhoudt]

> On 17 Jun 2015, at 19:36, Morgaine Fowle <rek...@gmail.com> wrote:
>
> This sounds like the death of human runnable code on the web, and the end of machine-to-machine interoperability that JS-as-target has given us. Building a bunch of dev tools for a bytecode language is a shocking prospect. This is a major major change, and I worry that the relative thin-ness, the human-ness of the web is a thing that's made it great, that's made it a preferred platform, and that this puts a very serious kink in that.

Not sure what you mean by ‘human runnable’; perhaps ‘human readable’. Assuming that’s what you mean, have you tried reading the asm.js code that Emscripten outputs with optimisations enabled. I wouldn’t call that human readable, nor runnable for that matter. asm.js is as readable as assembly language code and wasm will probably be as readable as machine code. Since one of the design goals is to be polyfillable it will be possible to disassemble back to asm.js and then you’re back to where we are today.
In other words, don’t panic and bring a towel ;)

Best regards,

Pepijn

[Alon Zakai]

I think it is a valid concern to worry about code on the web remaining human-readable, and in fact we are being very careful about that, see this FAQ entry:

https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webassembly-support-view-source-on-the-web

WebAssembly will allow View Source, just like JS currently does. It will actually provide some benefits over the current situation:

1. Minified JS is currently almost impossible to read. Some browsers clean up whitespace for you, which helps a lot, but it isn't standardized. The WebAssembly text format will be standardized, and means all browsers will show a readable and consistent view source on wasm content.

2. asm.js is currently hard to read due to all the extra | 0 and + coercions, etc. The WebAssembly text format will be much cleaner, and much more readable.

Note also that WebAssembly is an AST format. It has a binary version, but still encodes an AST, just like asm.js. So a human-friendly AST is being kept.

Overall, WebAssembly is like asm.js, only better. It will not make things worse on human readability etc., it will only improve things there.

- 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 emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pepijn Van Eeckhoudt]

Hi Alon,

On 17 Jun 2015, at 20:12, Alon Zakai <alon...@gmail.com> wrote:

I think it is a valid concern to worry about code on the web remaining human-readable, and in fact we are being very careful about that, see this FAQ entry:

I didn’t mean to say that this isn’t a valid concern, just that it’s not that much different from what Emscripten is doing today already.

2. asm.js is currently hard to read due to all the extra | 0 and + coercions, etc. The WebAssembly text format will be much cleaner, and much more readable.

That’s true, but even if you take out all the ‘| 0’s you’re left with code that is at a significantly lower level than the original C or C++ code it came from. Since struct/class metadata isn’t retained at runtime in C/C++ you’re left with a bunch of loads and stores from/to the heap and local stack variables. It’s useful to be able to see this in text form of course, but it’s a challenge to look at this and figure out what the code is supposed to be doing. Based on the AST description it’ll be like reading LLVM assembly or javap output. Retaining expressions as ASTs should make it a bit easier to read compared to stack or register based bytecode of course. Is that about right?

Pepijn

[Alon Zakai]

Sorry, my response was to Morgaine, not you - perhaps I clicked the wrong "reply" button, oops :)

Regarding the last point, on the one hand, yes, asm.js and WebAssembly are lower-level than C. Still, as they are in AST format, they are both far more readable than say x86 machine code. It's an interesting middle ground.

I would say it is better than reading LLVM assembly, because ifs and loops are there. However, as you said, LLVM assembly might have more struct info (if the optimizer did not  remove it). But just overall, LLVM IR is not that human readable, for example

  %waka = select i1 fcmp ult (float fadd (float fmul (float undef, float 1.0), float 2.0), float 3.0), double 4.0, double 5.0

whereas in asm.js and in WebAssembly, that would be

  waka = (undef * 1.0) + 2.0 < 3.0 ? 4.0 : 5.0;

which is pretty much what a human would write. Taking that plus loops and ifs, it's very readable in my opinion, even with struct accesses being raw loads and stores.

- Alon

--

[Floh]

That ship of human-readable code on the web has sailed long ago with Javascript minimization, and it is also not really relevant. Has the quality of web development improved because people can do 'view source'? Hardly ;)

I, for one, welcome our new byte-code overlords :)

Cheers to everyone involved :)

[bobajeff]

Great news. I wonder if this is what you Nacl and Fastcomp guys had in mind in regards upstreaming to LLVM.

[JF Bastien]

Honestly, not really. PNaCl and Fastcomp taught us a lot about building a virtual ISA and LLVM, and from the upstream discussion it looks like the LLVM community likes the WebAssembly approach.

On Jun 18, 2015 6:59 AM, "bobajeff" <bobaj...@gmail.com> wrote:

Great news. I wonder if this is what you Nacl and Fastcomp guys had in mind in regards upstreaming to LLVM.

[Brian Gavin]

This is great news.  

I hope some serious time and thought is put into making better debugging tools for this new technology.  Debugging especially NaCl and to a lesser extent Empscripten are harder and more time consuming then when developing Desktop or Mobile apps using C++.  This problem really increases the length of time needed to develop apps using these technologies.

Brian Gavin

[JF Bastien]

Yes, debuggability is an explicit goal.

--

[Xiaoming Ding]

Absolutely it is a good new !

I have a concern about this readable code : as you know , finally these scripts had to be put on the site and they will run at browsers at client-site. Is it possible to make them completely un-readable so that they can be protected from reverse engineering ?

Regards !

Xiaoming Ding

在 2015年6月18日星期四 UTC+8上午2:12:07，Alon Zakai写道：

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[bobajeff]

With a Hex Viewer, Disassembler and Decompiler most things even Windows EXEs and DLLs are without protection from reverse engineering.

See:
http://www.thefreecountry.com/programming/disassemblers.shtml

[Alon Zakai]

Yes, nothing is safe from reverse engineering. Although, one can write layers of obfuscation on top if they want. WebAssembly would be no different in this than any platform for running code on the client.

--
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 emscripten-disc...@googlegroups.com.

[Alecazam]

I'd really like to see all browsers detect Emscripten and unmangle the stack traces reported.   Also speeding up stack traces (even if only for the Emscripten execution) would go far in tracking memory and other stack-tied recording.  And keep improving source map support, and the ability to split up modules.