Skeleton WebAssembly target
reviews.llvm.org
Skeleton WebAssembly target
1–10 of 60 posts
Re: Skeleton WebAssembly target
#2I'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?
Re: Skeleton WebAssembly target
#3I'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 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.
Re: Skeleton WebAssembly target
#4Looks like this link is broken. When I click I got:
This webpage is not available ERR_CONNECTION_TIMED_OUT
Is there any other?
Re: Skeleton WebAssembly target
#5I'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…
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.
Re: Skeleton WebAssembly target
#6I'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?
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.
Re: Skeleton WebAssembly target
#7The page is empty ERR_CONNECTION_TIMED_OUT, does anyone sees the actual content ?
Re: Skeleton WebAssembly target
#8Looks like this link is broken. When I click I got: This webpage is not available ERR_CONNECTION_TIMED_OUT Is there any other?
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.
Re: Skeleton WebAssembly target
#9Re: Skeleton WebAssembly target
#10If 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.