3 ms·
You are mixing it with asm.js. Asm.js is essentially a 32-bit VM that is very well-suited as a cross-compile target for single-threaded C/C++ code, but to ship
by vesinisa 10y ago
You are mixing it with asm.js. Asm.js is essentially a 32-bit VM that is very well-suited as a cross-compile target for single-threaded C/C++ code, but to ship something more high-level you would have to bundle it with a respective VM implementation.
AFAIK WASM literally aims to be a "universal web bytecode", and they hope to eventually add multi-threading, GC and DOM access. Of course the exact implementation details might differ from e.g. your local Java runtime vis a vis GC and threading timings and such.
But for example in a distant future each browser's JavaScript runtime could be just an interpreter that internally emits WASM. And there should not be any reason why you could not compile most Java / C# code to WASM once threads and GC are added.
- bobajeff 10y agoNo. GC access is a feature that they may possibly add at some undisclosed point in the future. (Just like it was with asm.js via Object Types IIRC) but it's not an explicit design consideration. No where does it say that it's intended to be a universal bytecode.
- vesinisa 10y agoNot exactly sure what is meant with "universal web bytecode", but a binary VM code supported by all major browsers sounds like one. There's a whole Wiki page dedicated to GC: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md Sounds like they aim to implement only GC primitives to allow emulating a wide variety of different VMs.
- bobajeff 10y agoAt some point in the "future [unicorn icon]" sure. But the design today is around the porting of C and C++ apps the web. The feature you're talking about is meant for integrating with the browser. It could allow emulating a variety of VM's but that's not a promise or stated goal.