Skeleton WebAssembly target

http://reviews.llvm.org/D10569

by espadrine • 11 years ago

66 58 11 years ago

reviews.llvm.org

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?

atonse• 11 years ago

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.

VeejayRampay2• 11 years ago

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.

lucozade• 11 years ago

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....

sklogic2• 11 years ago

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.

azakai3• 11 years ago

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.

crncosta• 11 years ago

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

This webpage is not available ERR_CONNECTION_TIMED_OUT

Is there any other?

amyjess• 11 years ago

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.

RoboSeldon• 11 years ago

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

adelb• 11 years ago

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

andybak• 11 years ago

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.

StefanKarpinski2• 11 years ago

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.

jashkenas• 11 years ago

Got some Julia plans or hopes?

cordite• 11 years ago

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?

bcheung4• 11 years ago

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.

sklogic2• 11 years ago

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

juliangoldsmith• 11 years ago

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/

vcarl• 11 years ago

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.

sunfish2• 11 years ago

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...

echeese• 11 years ago

Are there any examples of the text format of wasm?

cpeterso2• 11 years ago

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

bobajeff• 11 years ago

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.

azakai3• 11 years ago

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.

bcheung4• 11 years ago

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.

spinlock• 11 years ago

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

vmorgulis6• 11 years ago

It will add a new dimension to web development.

serve_yay• 11 years ago

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)

nfoz2• 11 years ago

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

wyldfire• 11 years ago

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.

pcwalton3• 11 years ago

Because that would not be portable.

nfoz2• 11 years ago

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.

vmorgulis6• 11 years ago

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.

Skeleton WebAssembly target

Related Stories