Cool, great that you can now do this with LDC directly.
There was a way to compile D to WASM before (using the dscripten package), however that was more akin to a collection of loose pieces strung together.
As with Go, a big obstacle for running typical D code in browsers is reliance on a garbage collector, which requires scanning stacks and temporaries for reachable heap object. Though it's possible to overcome in theory with just compiler support, garbage collection in WASM itself seems to be an ongoing discussion.
> There was a way to compile D to WASM before (using the dscripten package), however that was more akin to a collection of loose pieces strung together.
Also carried the large Emcripten runtime. Sure it gives you a lot of things like posix impls, but the unknown triple is very lightweight (at the cost of sys/OS abstractions of course).
> Also carried the large Emcripten runtime. Sure it gives you a lot of things like posix impls
And also, SDL2 + opengl bindings. Which makes it very adapted to compiling the same project for both targets: native and web. For video games, this is a killer feature (e.g try the game in your browser, and if you like it, download the native app (smoother, less input latency)).
I'd wager there's a lot of lower level optimisations - especially for different architectures - that you just can't get with platform agnostic 'assembly'.
I also think its better for everyone if you don't need to load/download, decode, compile and run a full language runtime on every page load. Imagine a JVM running on web assembly: Every page load first has to decode and compile a full many-MB JVM, then the JVM can start booting - without any platform/architecture specific optimizations.
The more stuff that's common for webasm-targeting-languages that we can move into the browser, the less effort wasted overall.
Somebody wake me up when we move beyond reimplementing Java applets and Flash once more. We had nice batteries-included VMs in the browser, and we turned our backs on them and went back to square one. Again, and again, and again. So we could bang rocks together with javascript.
Almost makes me wish VBScript IE had won. We might be writing browser apps in .NET now...
One might be seen as sleeping back then too if they considered proprietary, complicated, insecure behemoths with large, sometimes shitty standard libraries and forced high-level constructs as "nice batteries-included VMs".
I still have to do .stream() and .toList() (or .collect(Collectors.toList())) back and forth in Java all the time just to get reliable access to map/filter lambdas while still having a valid return value.
Yes, the fact that Google Chrome is written in C++ is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.
Yes, the fact that the Linux kernel is written in C is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.
I disagree, I would like WASM impls to offer one that you can optionally leverage for many reasons. Regardless, here is a recent thread that does a good job discussing pros/cons: https://github.com/WebAssembly/gc/issues/36
> Why can't they just let devs embed their own garbage collector? Isn't he role of an assembly language to let the developer do stuff at a low level?
I believe the big obstacle is that the stack is managed by the VM and isn't accessible directly (at least, in the form of one continuous memory region per thread). A likely constraint that led to this was to allow interoperability with the JavaScript stack.
The core issue is that WebAssembly VMs use the host’s native stack for return addresses and local variables, without providing wasm code any way to inspect or manipulate that data. Thus, there’s no way to scan the stack for GC roots, as would be possible in a ‘real’ assembly language. Programs do typically maintain a second, separate, stack, located within wasm-accessible memory, for things like local variables that have their address taken. In theory, you could make the compiler store all locals there across function calls; I think that might be what Go does. But that’s a performance waste. In any case, a manual approach won’t solve the use case of accessing JS/DOM objects from WebAssembly; that requires interoperating with the existing JS garbage collector.
The full stack will never be exposed for safety and verification reasons, though it's possible you could get some sort of read-only stack walk primitive... it might be very slow. The wasm stack intentionally does not live in the heap so that it's impossible-ish for exploits to target the stack.
What if a complicated Javascript object is passed to WASM, and a reference stored in a WASM object? How would the GC trace the reference across the language boundary?
> There was a way to compile D to WASM before (using the dscripten package), however that was more akin to a collection of loose pieces strung together.
Indeed :-)
The toolchain building scripts were a maintainance nightmare ; I'll be happy to drastically simplify them, especially if it means I can now use the vanilla LDC compiler (instead of having to integrate fastcomp and clang-fastcomp (Emscripten's forks of llvm and clang, respectively)).
Yeah, I'd like to see some examples of passing anything other than doubles, for example Arrays, and I'd like to know how GC works after the Array has been passed, and if the Array is passed by reference (instead of being copied), and things like that.
33 comments
[ 4.3 ms ] story [ 86.0 ms ] threadThere was a way to compile D to WASM before (using the dscripten package), however that was more akin to a collection of loose pieces strung together.
As with Go, a big obstacle for running typical D code in browsers is reliance on a garbage collector, which requires scanning stacks and temporaries for reachable heap object. Though it's possible to overcome in theory with just compiler support, garbage collection in WASM itself seems to be an ongoing discussion.
Also carried the large Emcripten runtime. Sure it gives you a lot of things like posix impls, but the unknown triple is very lightweight (at the cost of sys/OS abstractions of course).
And also, SDL2 + opengl bindings. Which makes it very adapted to compiling the same project for both targets: native and web. For video games, this is a killer feature (e.g try the game in your browser, and if you like it, download the native app (smoother, less input latency)).
Why can't they just let devs embed their own garbage collector? Isn't he role of an assembly language to let the developer do stuff at a low level?
I also think its better for everyone if you don't need to load/download, decode, compile and run a full language runtime on every page load. Imagine a JVM running on web assembly: Every page load first has to decode and compile a full many-MB JVM, then the JVM can start booting - without any platform/architecture specific optimizations.
The more stuff that's common for webasm-targeting-languages that we can move into the browser, the less effort wasted overall.
Almost makes me wish VBScript IE had won. We might be writing browser apps in .NET now...
I still have to do .stream() and .toList() (or .collect(Collectors.toList())) back and forth in Java all the time just to get reliable access to map/filter lambdas while still having a valid return value.
Better stop using Chrome now.
Chrome seem to have a bunch of 2018 vulnerabilities that aren't listed here though...
At least not unless you can load it from the same public CDN.
Edit: Actully, I'm not sure you could do that even with the public CDN.
I believe the big obstacle is that the stack is managed by the VM and isn't accessible directly (at least, in the form of one continuous memory region per thread). A likely constraint that led to this was to allow interoperability with the JavaScript stack.
Indeed :-)
The toolchain building scripts were a maintainance nightmare ; I'll be happy to drastically simplify them, especially if it means I can now use the vanilla LDC compiler (instead of having to integrate fastcomp and clang-fastcomp (Emscripten's forks of llvm and clang, respectively)).