9 ms·

Skeleton WebAssembly target

66 points by espadrine 11y ago

VeejayRampay 11y ago
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 11y 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.
  - VeejayRampay 11y 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 11y 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....
    - deleted 11y ago
      [deleted]
    - pcwalton 11y ago
      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.
    - TazeTSchnitzel 11y ago
      > 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.
- sklogic 11y 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.
- azakai 11y 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 11y 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 11y 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 11y ago
The page is empty ERR_CONNECTION_TIMED_OUT, does anyone sees the actual content ?
adelb 11y ago
http://webcache.googleusercontent.com/search?q=cache:http://reviews.llvm.org/D10569 http://webcache.googleusercontent.com/search?q=cache:http://...
andybak 11y 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.
- serve_yay 11y 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)
- StefanKarpinski 11y 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 11y ago
    Got some Julia plans or hopes?
    - StefanKarpinski 11y ago
      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 https://github.com/JuliaLang/julia/issues/9430.
  - cordite 11y 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?
nfoz 11y ago
Why don't we just distribute ELF binaries, and have them execute in a sandbox?
- wyldfire 11y 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.
- pcwalton 11y ago
  Because that would not be portable.
  - nfoz 11y 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.
    - pcwalton 11y ago
      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.
vmorgulis 11y ago
Maybe the first version of emscripten? https://gist.github.com/anonymous/474956 https://gist.github.com/anonymous/474956 Found it on Alon blog (http://mozakai.blogspot.fr/2010/07/experiments-with-static-javascript-as.html http://mozakai.blogspot.fr/2010/07/experiments-with-static-j...). A big and humble journey.

66 points by espadrine 11y ago

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 11y 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.
- VeejayRampay 11y 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 11y 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....
  - deleted 11y ago
    [deleted]
  - pcwalton 11y ago
    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.
  - TazeTSchnitzel 11y ago
    > 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.
sklogic 11y 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.
azakai 11y 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 11y 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 11y 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 11y ago

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

adelb 11y ago

http://webcache.googleusercontent.com/search?q=cache:http://reviews.llvm.org/D10569 http://webcache.googleusercontent.com/search?q=cache:http://...

andybak 11y 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.

serve_yay 11y 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)
StefanKarpinski 11y 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 11y ago
  Got some Julia plans or hopes?
  - StefanKarpinski 11y ago
    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 https://github.com/JuliaLang/julia/issues/9430.
- cordite 11y 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?

nfoz 11y ago

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

wyldfire 11y 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.
pcwalton 11y ago
Because that would not be portable.
- nfoz 11y 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.
  - pcwalton 11y ago
    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.

vmorgulis 11y ago

Maybe the first version of emscripten? https://gist.github.com/anonymous/474956 https://gist.github.com/anonymous/474956 Found it on Alon blog (http://mozakai.blogspot.fr/2010/07/experiments-with-static-javascript-as.html http://mozakai.blogspot.fr/2010/07/experiments-with-static-j...). A big and humble journey.