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

11–20 of 60 posts

Re: Skeleton WebAssembly target

#11

Post by StefanKarpinski »

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.

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.

Re: Skeleton WebAssembly target

#12

Post by sklogic »

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 (fastcomp) is not a proper LLVM backend (i.e., not a tablegen-based one).

Re: Skeleton WebAssembly target

#13

Post by juliangoldsmith »

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.

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/

Re: Skeleton WebAssembly target

#14

Post by jashkenas »

StefanKarpinski wrote: post #11
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.

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

Got some Julia plans or hopes?

Re: Skeleton WebAssembly target

#15

Post by vcarl »

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.

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.

Re: Skeleton WebAssembly target

#16

Post by sunfish »

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

Re: Skeleton WebAssembly target

#17

Post by cordite »

StefanKarpinski wrote: post #11
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.

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

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?

Re: Skeleton WebAssembly target

#18

Post by lucozade »

atonse wrote: post #3
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?

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

Re: Skeleton WebAssembly target

#20

Post by wyldfire »

nfoz wrote: post #19

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

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.

Post reply on HN