4 ms·

I'm discussing JS and WASM as two compile targets for your preferred language. No one is "dictating" anything. But JS and WASM are complementary in some importa

I'm discussing JS and WASM as two compile targets for your preferred language. No one is "dictating" anything. But JS and WASM are complementary in some important ways. GC being one.

brabel 3y ago
Are you aware that WASM is going to have a GC soon? It's in phase 3 (Implementation Phase): https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals
flohofwoe 3y ago
Emscripten has shown that Javascript is a terrible compilation target, that's why WASM exists in the first place (Emscripten started with compiling to vanilla JS, which was then 'standardized' into the asm.js subset, and finally ended up in WASM ... each of those steps improved performance, and a Javascript/asm.js backend would never have been accepted into upstream clang, while WASM is "just another ISA").
- 3cats-in-a-coat 3y ago
  I find it frustrating you casually ignored the primary context of the comment/thread you're replying to, namely: suitable targets for GC (garbage collected) languages, not for C and C++, which you surely know are not garbage collected. WASM is a suitable target for Emscripten. But I never said otherwise, and this was not the discussion. Also. WASM is not "just another ISA" at all, as I explained in other comments throughout. For one it has an opaque call stack and no free jumps inside from one code location to another, unlike any other ISA in the world. This means it's terrible for languages which lean heavily into tail calls and coroutines, among other. It's also bad for GC languages as a custom collector can't compete with JS's GC.
  - flohofwoe 3y ago
    I simply don't see that there's a big enough difference between traditional garbage collection, refcounting and manual memory management. Each of those can already be implemented in pure WASM (without the new GC support), just more or less awkwardly. As for "just another ISA", there have been CPUs which had separate call- and data-stacks, with the call-stack living on the CPU and not directly accessible to code. In that sense WASM isn't much different then those esoteric CPUs, yet those also implemented "just another ISA". And even though WASM might not allow free control flow, I yet have to see a noticeable performance difference between WASM and native for this type of "worst case code": https://github.com/floooh/chips/blob/f5b6684ff6e899429544b2133b31d912ebc15f40/chips/z80.h#L1815-L1849 https://github.com/floooh/chips/blob/f5b6684ff6e899429544b21...
    - 3cats-in-a-coat 3y ago
      We can implement everything on an infinite tape read/writer, but the point is performance. I'm trying to find something to say about you calling a CPU "esoteric" due to its ISA, and then calling its ISA specifics "just another ISA". Kind of seems like a 180 in the middle of your sentence. But one way or another TCO and indirect calls are crucial for modern languages and I'm glad eventually it'll be usable in WASM as you pointed out in another comment.
    - chriswarbo 3y ago
      > Each of those can already be implemented in pure WASM (without the new GC support) I'm not super familiar with WASM, but (according to this article/talk) implementing GC in pure WASM doesn't really work cross-module: in particular, there's no way to trace liveness across modules (e.g. if some JS is holding a reference to one of our WASM values), and the least-privilege/capability approach is lost since we have to grant access to all of our memory at once (e.g. if we're storing the heap as one big buffer). > just more or less awkwardly There are hacks and work-arounds, but it's a pretty silly situation when there's already a GC right there for the JS engine. It's important to get the details right when standardising (e.g. to allow future advances, rather than locking-in current techniques), but the current situation of downloading multiple standalone GCs isn't really acceptable.
  - Findecanor 3y ago
    Support for tail calls are in Phase 4 of the standardisation process: the last phase before becoming part of the Webassembly standard. There is already a WASM back-end for Golang, which implements coroutines without tail calls or sparse stacks. BTW. ISAs with opaque call stacks and verified branch targets, respectively do exist, but I dunno if there is hardware that does both. You could use Intel CET for the latter, and enable "Safe Stack" or a flavour of "Control Flow Integrity" instrumentation in LLVM to emulate the former. There are also projects that recompile existing binaries. Google Fuchsia has Safe Stack enabled for all binaries, except for Golang unfortunately.
    - 3cats-in-a-coat 3y ago
      You can implement coroutines on anything but it’s slow.

I'm discussing JS and WASM as two compile targets for your preferred language. No one is "dictating" anything. But JS and WASM are complementary in some important ways. GC being one.

brabel 3y ago

Are you aware that WASM is going to have a GC soon? It's in phase 3 (Implementation Phase): https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals

flohofwoe 3y ago

Emscripten has shown that Javascript is a terrible compilation target, that's why WASM exists in the first place (Emscripten started with compiling to vanilla JS, which was then 'standardized' into the asm.js subset, and finally ended up in WASM ... each of those steps improved performance, and a Javascript/asm.js backend would never have been accepted into upstream clang, while WASM is "just another ISA").

3cats-in-a-coat 3y ago
I find it frustrating you casually ignored the primary context of the comment/thread you're replying to, namely: suitable targets for GC (garbage collected) languages, not for C and C++, which you surely know are not garbage collected. WASM is a suitable target for Emscripten. But I never said otherwise, and this was not the discussion. Also. WASM is not "just another ISA" at all, as I explained in other comments throughout. For one it has an opaque call stack and no free jumps inside from one code location to another, unlike any other ISA in the world. This means it's terrible for languages which lean heavily into tail calls and coroutines, among other. It's also bad for GC languages as a custom collector can't compete with JS's GC.
- flohofwoe 3y ago
  I simply don't see that there's a big enough difference between traditional garbage collection, refcounting and manual memory management. Each of those can already be implemented in pure WASM (without the new GC support), just more or less awkwardly. As for "just another ISA", there have been CPUs which had separate call- and data-stacks, with the call-stack living on the CPU and not directly accessible to code. In that sense WASM isn't much different then those esoteric CPUs, yet those also implemented "just another ISA". And even though WASM might not allow free control flow, I yet have to see a noticeable performance difference between WASM and native for this type of "worst case code": https://github.com/floooh/chips/blob/f5b6684ff6e899429544b2133b31d912ebc15f40/chips/z80.h#L1815-L1849 https://github.com/floooh/chips/blob/f5b6684ff6e899429544b21...
  - 3cats-in-a-coat 3y ago
    We can implement everything on an infinite tape read/writer, but the point is performance. I'm trying to find something to say about you calling a CPU "esoteric" due to its ISA, and then calling its ISA specifics "just another ISA". Kind of seems like a 180 in the middle of your sentence. But one way or another TCO and indirect calls are crucial for modern languages and I'm glad eventually it'll be usable in WASM as you pointed out in another comment.
  - chriswarbo 3y ago
    > Each of those can already be implemented in pure WASM (without the new GC support) I'm not super familiar with WASM, but (according to this article/talk) implementing GC in pure WASM doesn't really work cross-module: in particular, there's no way to trace liveness across modules (e.g. if some JS is holding a reference to one of our WASM values), and the least-privilege/capability approach is lost since we have to grant access to all of our memory at once (e.g. if we're storing the heap as one big buffer). > just more or less awkwardly There are hacks and work-arounds, but it's a pretty silly situation when there's already a GC right there for the JS engine. It's important to get the details right when standardising (e.g. to allow future advances, rather than locking-in current techniques), but the current situation of downloading multiple standalone GCs isn't really acceptable.
- Findecanor 3y ago
  Support for tail calls are in Phase 4 of the standardisation process: the last phase before becoming part of the Webassembly standard. There is already a WASM back-end for Golang, which implements coroutines without tail calls or sparse stacks. BTW. ISAs with opaque call stacks and verified branch targets, respectively do exist, but I dunno if there is hardware that does both. You could use Intel CET for the latter, and enable "Safe Stack" or a flavour of "Control Flow Integrity" instrumentation in LLVM to emulate the former. There are also projects that recompile existing binaries. Google Fuchsia has Safe Stack enabled for all binaries, except for Golang unfortunately.
  - 3cats-in-a-coat 3y ago
    You can implement coroutines on anything but it’s slow.