3 ms·

The tools for working with WASM are here: https://github.com/WebAssembly/wabt https://github.com/WebAssembly/wabt The compiler/converters are here: https://git

by geokon 9y ago

The tools for working with WASM are here: https://github.com/WebAssembly/wabt https://github.com/WebAssembly/wabt The compiler/converters are here: https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen Maybe someone who knows more could help me understand better. It looks the toolchain "stack" is some-lang through LLVM to a special WASM LLVM backend which then is converted to WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?). So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right? I don't really get if WASM has memory-managment / garbage-collection by default or it's something optional available to things like Javascript? Or the GC is written in WASM itself...? With LLVM-IR/WASM/SPIR-V it's kinda a shame we have all these standards doing very very similar things - but I kinda get the rational there

imtringued 9y ago
LLVM-IR is not really a standard and it is not backwards compatible across LLVM releases and usually the generated IR is also specific to the target platform. Of course it's still vastly easier recompile already generated IR to a different platform as opposed to writing an emulator but it's not supposed to be used this way. It's simply not possible to compare LLVM-IR to WASM SPIR-V JVM BEAMVM CLR bytecode.
tom_mellior 9y ago
> WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?) Yes. > So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right? Yes. Andreas Rossberg and other chief WASM people are touring conferences with talks called more or less "WebAssembly: Neither Web nor Assembly". It's a misnomer. > I don't really get if WASM has memory-managment / garbage-collection by default It doesn't. I'm not up to date, but last I heard the best that was offered was "at some point there will be APIs available for calling into the browser's runtime to get GC'd objects" or something like that.
- geokon 9y ago
  Gotcha. After reading a bit more it sounds like WASM isn't supposed to really be the common target for all "web-languages". ie. Javascript won't be compiling to WASM any time soon. It's just a parallel mechanism to run code in the browser that's more extendable/flexible (b/c people where writing monsters to have their language compile to Javascript/asm.js)
  - tom_mellior 9y ago
    I think it's a bit of both, and maybe more. For one thing, I think there are historical ties to asm.js (i.e., some of the same people went on to develop WASM), and asm.js should compile nicely to WASM. Once they have GC figured out. For another thing, I think there is the long-term goal of using WASM as a way to migrate away from JavaScript, if desired. Once you can compile all (or most) of your JavaScript logic to WASM, you can start transparently replacing parts of that code with code written in other languages that compile to WASM. If the interfaces remain unchanged, the remaining JavaScript won't notice.

by geokon 9y ago

imtringued 9y ago

LLVM-IR is not really a standard and it is not backwards compatible across LLVM releases and usually the generated IR is also specific to the target platform. Of course it's still vastly easier recompile already generated IR to a different platform as opposed to writing an emulator but it's not supposed to be used this way. It's simply not possible to compare LLVM-IR to WASM SPIR-V JVM BEAMVM CLR bytecode.

tom_mellior 9y ago

> WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?) Yes. > So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right? Yes. Andreas Rossberg and other chief WASM people are touring conferences with talks called more or less "WebAssembly: Neither Web nor Assembly". It's a misnomer. > I don't really get if WASM has memory-managment / garbage-collection by default It doesn't. I'm not up to date, but last I heard the best that was offered was "at some point there will be APIs available for calling into the browser's runtime to get GC'd objects" or something like that.

geokon 9y ago
Gotcha. After reading a bit more it sounds like WASM isn't supposed to really be the common target for all "web-languages". ie. Javascript won't be compiling to WASM any time soon. It's just a parallel mechanism to run code in the browser that's more extendable/flexible (b/c people where writing monsters to have their language compile to Javascript/asm.js)
- tom_mellior 9y ago
  I think it's a bit of both, and maybe more. For one thing, I think there are historical ties to asm.js (i.e., some of the same people went on to develop WASM), and asm.js should compile nicely to WASM. Once they have GC figured out. For another thing, I think there is the long-term goal of using WASM as a way to migrate away from JavaScript, if desired. Once you can compile all (or most) of your JavaScript logic to WASM, you can start transparently replacing parts of that code with code written in other languages that compile to WASM. If the interfaces remain unchanged, the remaining JavaScript won't notice.