6 ms·

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 t

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.

kodablah 8y ago
> 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).
- Ace17 8y ago
  > 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)).
jokoon 8y ago
Please no, leave that to js. 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?
- ben-schaaf 8y ago
  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.
  - megaman22 8y ago
    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...
    - kodablah 8y ago
      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".
      - crooked-v 8y ago
        > sometimes shitty 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.
        megaman22 8y ago
        Java's shittiness is a problem, but for the mid 2000s, it wasn't extra shitty in comparison. That long stagnation after 1.6 really hurt.
    - kibibu 8y ago
      Flash's demise is 100% Adobe's fault. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash
      - andyonthewings 8y ago
        Yeah, there are 1098 Flash related CVEs, but Google Chrome itself also has 1608 CVEs https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chrome https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chro... Better stop using Chrome now.
- kodablah 8y ago
  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 https://github.com/WebAssembly/gc/issues/36
- CyberShadow 8y ago
  > 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.
- comex 8y ago
  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.
  - nerpderp83 8y ago
    If you and I join forces, we can get the stack exposed in WASM2. Or we can run our WASM on WASM and hope the JIT can handle the inner interpreter.
    - kevingadd 8y ago
      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.
- amelius 8y ago
  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?
Ace17 8y ago
> 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)).

kodablah 8y ago

> 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).

Ace17 8y ago
> 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)).

jokoon 8y ago

Please no, leave that to js. 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?

ben-schaaf 8y ago
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.
- megaman22 8y ago
  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...
  - kodablah 8y ago
    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".
    - crooked-v 8y ago
      > sometimes shitty 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.
      - megaman22 8y ago
        Java's shittiness is a problem, but for the mid 2000s, it wasn't extra shitty in comparison. That long stagnation after 1.6 really hurt.
  - kibibu 8y ago
    Flash's demise is 100% Adobe's fault. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash
    - andyonthewings 8y ago
      Yeah, there are 1098 Flash related CVEs, but Google Chrome itself also has 1608 CVEs https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chrome https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chro... Better stop using Chrome now.
kodablah 8y ago
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 https://github.com/WebAssembly/gc/issues/36
CyberShadow 8y ago
> 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.
comex 8y ago
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.
- nerpderp83 8y ago
  If you and I join forces, we can get the stack exposed in WASM2. Or we can run our WASM on WASM and hope the JIT can handle the inner interpreter.
  - kevingadd 8y ago
    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.
amelius 8y ago
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?

Ace17 8y ago

> 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)).