4 ms·

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 compi

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.

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.