Skeleton WebAssembly target | Hacker News Reader

Skeleton WebAssembly target

reviews.llvm.org

66 pointsespadrine58 comments

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 through asm.js, so it will eventually have several advantages. And when it's ready, Emscripten itself will make use of it (though that won't be the only way it can be used) [1].

[0] https://github.com/WebAssembly/design/blob/master/FAQ.md#wha...

[1] https://github.com/WebAssembly/design/blob/master/FAQ.md#wha...

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

The polyfill is slower.

It really depends on what you mean by "slower". Emscripten already supports the "Emterpreter"[1], which uses a straight bytecode (not AST, like webassembly) version of your asm.js code that can be downloaded and parsed quickly while the much more verbose asm.js code is still downloading and being parsed. So while it does more work, it's responsive sooner.

If fast start up time is the top priority for your app, the polyfill could easily be the best choice (and there are probably more tricks to be done with incremental parsing by feeding the JS engine wasm -> asm.js code in chunks while running an interpreter in the meantime, prioritizing hot functions in the wasm stream).

[1] https://blog.mozilla.org/research/2015/02/23/the-emterpreter...

The polyfill generates essentially the same asm.js code, so it runs at a similar speed. The slowdown is a translation delay at startup.

On the other hand, WebAssembly code is smaller than asm.js code, so it downloads faster, so in some situations the polyfill is actually faster.

Are there any examples of the text format of wasm?

It doesn't yet exist. The specifications haven't been written, these are high-level design documents.

Based on the spec so far, there's a very good chance it'll look _almost exactly like asm.js_

Yes. Like asm.js it will more closely resemble C than assembly language, having expressions and variables.

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 problematic on constrained devices like mobile phones.

There's already ASICs for Lua and other to-simplistic-bytecode out there for low power applications (If I recall correctly anyway with tessel.)

What's to say when these things are settled, we are left with something that handles asynchrony well and it becomes the basis for IoT?

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.

That's exactly what I said. Why did I get downvoted?

Because your comment is misleading or inaccurate. The comment you had replied to was completely correct.

> It's just a binary encoding of the AST. Nothing more, nothing less.

No, it is not a binary encoding of the JavaScript/asm.js AST. It is a binary encoding of the WebAssembly AST.

> It's not quite a bytecode, those are typically for interpreters.

It is a bytecode, by any normal meaning of the term. WebAssembly could be interpreted, or could be AOT compiled.

You're right, I could have been clearer about saying it is a new AST and not a JavaScript/asm.js AST. That is what I meant.

Bytecodes are for instruction sets, not trees though.

From wikipedia, "Bytecode, also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter."

There are no instructions to interpret since there is no instruction set defined. It is possible though that certain browsers may take the AST and create an instruction set for an interpreter or they may compile it to native code but that is entirely browser specific and has nothing to do with WebAssembly.

https://github.com/WebAssembly/design/blob/master/TextFormat...

"Given that the code representation is actually an Abstract Syntax Tree, the syntax would contain nested statements and expressions (instead of the linear list of instructions most assembly languages have)."

> "No, it is not a binary encoding of the JavaScript/asm.js AST. It is a binary encoding of the WebAssembly AST."

From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks.

> "WebAssembly could be interpreted, or could be AOT compiled."

You can do AOT compilation of JS too. The initial benefits of WebAssembly appear to come from in the binary distribution method and in better use of hardware (low-overhead threads, etc...). That said, there's certainly plenty of potential for WebAssembly to leave other restrictions behind.

> From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks.

At least initially it'll be similar to asm.js, yes.

> You can do AOT compilation of JS too.

No, you can't. You don't have all the type information needed.

> "No, you can't. You don't have all the type information needed."

https://github.com/toshok/echojs

"I want to play around with what is essentially profile guided optimization, but with runtime type information. So you get a partially specialized (at least as much as the static compilation can give you) implementation, which then records type information at runtime."

Very advanced optimizations. Emscripten doesn't do that (not yet, but LLVM has PGO).

I've done something similar for PHP before. But what you get is code that essentially embeds a dynamic language runtime into your code in the places where the types aren't known. It's less efficient than JIT compilation.

Did you include a feedback mecanism in your solution ? (like PGO)

This is my basic understanding...

Consider the interpreters written to run JavaScript. They create ASTs in order to run it. WebAssembly should allow you to target the AST layer directly. The JS compatibility is a fallback. In order to have this fallback, the AST will be similar to that which is used for asm.js.

Furthermore, whilst it's sensible to design WebAssembly with compatibility in mind at first, there's no reason why future versions of WebAssembly can't drop support for JS altogether (whether that'll happen or not remains to be seen). So long as WebAssembly v1 supports a JS fallback, then WebAssembly v2 (or whatever it's called) need not, so long as v1 is kept around. We're talking probably a decade away (if at all) but as far as I can see the end goal is a high-performance, language-neutral web, and JS fallback is just a stepping stone towards that goal. I'm sure JS will stick around on the web regardless.

Got some Julia plans or hopes?

Sure – with a first-class LLVM backend for WebAssembly, we could absolutely compile to it, which would mean running fully in the browser, which is something Emscripten can't quite manage at this point. That would certainly be very cool (and useful too). See https://github.com/JuliaLang/julia/issues/9430.

WebAssembly itself doesn't have anything to do with asm.js near as I can tell. It's more the ecosystem surrounding WebAssembly.

I looked through the specs a little bit. What it is, is a binary encoding of the AST with some optimizations thrown in to decrease size (symbol tables instead of using the full tokens).

I'm unclear on why asm.js is even mentioned but I suspect it is a temporary stop gap since those languages using LLVM currently target asm.js. Now, they can just target the AST but it will take some time for the tools to change. In the meanwhile they will look like: C -> AST -> asm.js -> AST -> binary. In the future, it can just look like C -> AST -> AST -> binary.

Why is it significant?

1) Language designers can just target the AST, then pass that to WebAssembly to compile to a binary. There's no need to compile to JavaScript. It saves them a step.

2) Size. They are claiming 20-30% smaller than minimized gzip versions of Javascript. There are optimizations that can be done (at the AST level) that exceed what is possible with generic compression like gzip.

3) Load time. Since it can be decoded straight to the AST, it saves the Javascript parsing step. This results in faster page loads.

4) Non-Javascript tooling support will improve. Javascript will still be the canonical language but other languages will increasingly get first class tooling support.

It will add a new dimension to web development.

Thanks for the explanation. This was very helpful for cutting though the noise.

Emscripten doesn't provide LLVM with a backend it uses a fork of LLVM called Fastcomp and that has a asm.js backend. Also the current backend isn't integrated with LLVM the way normal ISA backends are.

This I believe (can't access page either) will be upstream and integrated with LLVM proper. Providing performance advantages as well as allowing frontends that aren't supported in Fastcomp but are based off upstream LLVM to support WebAssembly.

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.). There are still significant open questions regarding which parts to use there. It will be interesting to see how this develops.

Regardless, a new backend makes sense for the other advantages you mentioned, especially that wasm will grow and add features, and a new wasm backend is the best place for that.

What's the relationship between WebAssembly and Emscripten's Emterpreter?

https://blog.mozilla.org/research/2015/02/23/the-emterpreter...

Emterpreter is just a binary encoding of asm.js to improve startup times. It's a bit of a hack.

WebAssembly is a whole new language.

Will you continue with C++ (especially for tools outside LLVM)?

Do you plan to use something else (like Rust)?

We use a mix of C++, JS and Python outside of LLVM. No plans to change that, but it could, depends on which tools contributors prefer.

vdohaeris, btw ;)

> vdohaeris, btw ;)

:-)

Based on a post from Brendan Eich [0], it looks like WebAssembly was created to get around JS parsing times on mobile devices, and also to get around some quirks of JS.

[0] https://brendaneich.com/2015/06/from-asm-js-to-webassembly/

It would allow languages that use JS as a compile target to skip that intermediate step and output bytecode for the VM, but as I understand it would also allow Javascript to skip that step. Right now every client needs to JIT compile and optimize all code, but if a compiled blob could be sent down instead of minified code, it would be a pretty dramatic shift.

emscripten (fastcomp) is not a proper LLVM backend (i.e., not a tablegen-based one).

From what I have heard, with asm.js, the parser becomes the hotspot. And WebAssembly is a compressed representation of the AST. (Please note that everything I've written could be completely incorrect)

The page is empty ERR_CONNECTION_TIMED_OUT, does anyone sees the actual content ?

I'm not familiar with LLVM enough to be sure I really understand the title (can't access the article at the moment). Basically what that means is that any compiler already using LLVM today would be able to directly target WebAssembly, which would then be executed by capable browser engines, or am I missing/misunderstanding something?

Yes, LLVM has two tiers, a front end, and a back end (someone else correct me if i butcher concepts or names):

The front end basically converts your human readable code to LLVM intermediate byte code (called IR, or intermediate representation). The byte code is independent of a CPU or programming language.

A second stage then turns that IR into x86 code or ARM code, etc. (these are "targets").

In this case, they added a target so it converts the IR into WebAssembly (which is, funny enough, yet another byte code).

You could probably, technically write any language to this but JS has certain behaviors and the JS engine will probably expect those behaviors.

Just a couple of clarifications.

Although the LLVM IR is mostly agnostic to the target, in practice, it's not quite that simple. However, the IR layer does make it substantially easier to move between languages and targets. It's just not free.

Also, my understanding is that WebAssembly isn't a JS thing. The intent is that a VM for the bytecode will be added to the browsers alongside the JS engine. In the short term they'll use the JS engine for it by converting WebAssembly to JS but that's just a band aid to get things moving. If successful, it could mean an eventual break of the tie between the browser and JS.

Interesting times....

Typically the implementation of Web Assembly will reside in the JS engine. There is no good reason not to continue to do in perpetuity, as far as I'm concerned. So, even in the future in which Web Assembly grows extra functionality, this is only a "break" from JS in the sense that x86-64 was a "break" from x86.

> Also, my understanding is that WebAssembly isn't a JS thing.

Not really. WebAssembly is not entirely unlike asm.js. It will live within the same world that JavaScript does.

Ah so I had the gist of it but it's actually even better than I thought, two tiers. Nice. Thank you for an informative answer and I'll be sure to read up on LLVM later today.

Almost. But it isn't quite so simple that any compiler using LLVM could benefit.

For example, if a language uses a feature like GC, but that isn't supported by a target, then that can't work.

Also, the frontend needs to emit code for the new target. That might be as easy as switching it from "x86" to "wasm", but if say a language only knows how to emit 64-bit LLVM IR, that won't work in a 32-bit target machine.

But aside from issues like those, having an LLVM backend for wasm in upstream will make it very easy for suitable LLVM-using projects to target wasm, and that is the goal here.

It looks like an initial, empty LLVM backend placeholder not doing anything useful yet. Might take few months from this moment to get it working.

http://webcache.googleusercontent.com/search?q=cache:http://...

Maybe the first version of emscripten? https://gist.github.com/anonymous/474956

Found it on Alon blog (http://mozakai.blogspot.fr/2010/07/experiments-with-static-j...). A big and humble journey.

Why don't we just distribute ELF binaries, and have them execute in a sandbox?

Because that would not be portable.

The browsers define what is portable. They're choosing to interpret webasm instead of ELF, or JVM bytecode. I guess I don't know why.

If people just want to distibute sandbox-binaries to each other, that's what the JVM was for. And the reason we needed that was because some OS vendors specifically had no interest in interoperability of native binaries, and also (this one really puzzles me) have still failed to implement sane sandboxing of programs in user-space.

ELF is just a container format for ISA-specific binaries. It doesn't solve portability between x86 and ARM, for example.

The JVM lacks integration with the DOM (important when you have, for example, cross-language cycles) and is also not a good target for C and C++ apps due to various missing features (unsigned ints, SIMD, etc). It is also not easily polyfillable.

Won't work on: (1) systems expecting COFF binaries, (2) systems who support ELF but use a different architecture.

For #2, there's several very popular archs to support: x86, x86_64, arm*, mips, x32.

AFAIK ELF doesn't (yet?) support multiple arch-in-a-single-file.

Looks like this link is broken. When I click I got:

This webpage is not available ERR_CONNECTION_TIMED_OUT

Is there any other?

It took me forever to load, but it finally went through. And even then only part of it loaded because lazy loading.

I think the HN effect got it.

Reply on news.ycombinator.com