Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Skeleton WebAssembly target

reviews.llvm.org

Post reply on HN
Print view View original

21–30 of 60 posts

Re: Skeleton WebAssembly target

#21

Post by [deleted] »

lucozade wrote: post #18
atonse wrote: post #3

Earlier quoted context omitted.

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 adde…

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 t…

[deleted]

Re: Skeleton WebAssembly target

#22

Post by bobajeff »

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.

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.

Re: Skeleton WebAssembly target

#23

Post by echeese »

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…

Are there any examples of the text format of wasm?

Re: Skeleton WebAssembly target

#25

Post by pcwalton »

lucozade wrote: post #18
atonse wrote: post #3

Earlier quoted context omitted.

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 adde…

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 t…

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.

Re: Skeleton WebAssembly target

#26

Post by nfoz »

pcwalton wrote: post #24
nfoz wrote: post #19

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.

Re: Skeleton WebAssembly target

#27

Post by pcwalton »

nfoz wrote: post #26
pcwalton wrote: post #24

Earlier quoted context omitted.

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 implem…

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.

Re: Skeleton WebAssembly target

#28

Post by azakai »

bobajeff wrote: post #22
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.

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 LL…

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.

Re: Skeleton WebAssembly target

#29

Post by bcheung »

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.

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.

Re: Skeleton WebAssembly target

#30

Post by azakai »

VeejayRampay wrote: post #2

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?

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.

Post reply on HN