7 ms·

I'm trying to learn more about this topic and I'm curious if anyone could clarify for me -- The reason Go would need a specific architecture for WebAssembly is

I'm trying to learn more about this topic and I'm curious if anyone could clarify for me -- The reason Go would need a specific architecture for WebAssembly is because Go supports features, like garbage collection, that WebAssembly does not. Is that right? Close? An oversimplification. Way off?

fwip 9y ago
My understanding is that they're treating Web Assembly as just another architecture to compile for - rather than spitting out x86_64 assembly, or ARM assembly, they're emitting Web Assembly.
hobofan 9y ago
Kind of. It's more that Go _requires_ a runtime to support certain features which require Garbage Collection. The requirement of a runtime in turn dictates a different architecture to run on WebAssembly.
deleted 9y ago
[deleted]
nijaru 9y ago
As others have said, Web assembly is an architecture/target for C, C++, rust, etc. that you compile for, and it will be the same for go. The link does talk about GC support. It looks like wasm will have one, but go’s will most likely perform better since it is tailored to go. (edit for clarification) I assume a lot of the planning for this was in the GitHub and mailing list discussions dedicated to go’s wasm support. I’m on mobile but I can link those later.
- swsieber 9y ago
  I was under the impression that WASM does not have one.
  - dragonwriter 9y ago
    IIRC, WASM doesn't have one and, more importantly, has an architecture which makes implementing one on top of WASM efficiently difficult.
  - steveklabnik 9y ago
    Wasm doesn't have one yet, but it's a future extension to to spec. You can, of course, compile your GC in today, and it will work. Wasm's integrated support will mean re-using the existing GC, which means smaller code size. Side note: most people thought this would be a precursor to DOM support, but the new "host bindings" proposal opens up DOM support without needing GC support, and many people believe that now the former will land before the latter.
    - k__ 9y ago
      Are GC implementations transparent for the languages? Can Go simply run with the WASM GC or does it need some specific type of GC?
      - steveklabnik 9y ago
        "the WASM GC" only exists as a proposal, and proposals can change before they land. I don't know enough about it to say, and even if I did, it might be invalid by the time things are actually accepted. See https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc for the current proposal.
        k__ 9y ago
        Sure. But one day, when there are implementations, can every language run with the WASM GC?
      - pjmlp 9y ago
        No if you care about performance. To go the extra mile in GC performance, the compiler and GC implementation have to collaborate, taking advantage of language specific features.
goalieca 9y ago
Follow-up question, why can't LLVM -> Web Assembly solve the problem?
- sitkack 9y ago
  x86 elf -> wasm could solve this problem.
  - kodablah 9y ago
    That would take quite the effort to build, but I bet lifting to LLVM first might work: https://github.com/trailofbits/mcsema https://github.com/trailofbits/mcsema
  - slrz 9y ago
    No, it wouldn't. At that point you already lost lots of information and your only option is to faithfully reproduce the behaviour of the x86 machine. You can still do it, of course and performance isn't even that bad. See Fabrice Bellard's x86 emulator using asm.js. https://bellard.org/jslinux/tech.html https://bellard.org/jslinux/tech.html
    - sitkack 9y ago
      Ok, pick a better ISA, like RISC-V.
- ianburrell 9y ago
  The regular Go compiler doesn't use LLVM. It is derived from Plan9 compiler toolchain. There has been work on a LLVM Go compiler. There is also Gccgo, Go frontend for GCC, that could use GCC WebAssembly backend.
  - earenndil 9y ago
    Could use dragonegg[1] to run gccgo through llvm and then through emscripten. 1: https://dragonegg.llvm.org/ https://dragonegg.llvm.org/
- 9y ago
opencl 9y ago
Garbage collection isn't really a problem because no CPU architecture supports garbage collection- the compiler is generating code to implement the GC regardless. The issue is that WASM doesn't really resemble real CPUs at all. Basically all modern CPUs are register machines, but WASM is a stack machine. Say you have the code C=A+B in your program. The generated assembly for a real machine looks something like this: (R* denote registers and A-C are memory addresses) load A->R1 load B->R2 add R1+R2->R3 store R3->C WASM looks more like this: push A push B add pop C This alone makes the approach to code generation and optimization quite different. WASM does lack some features that you would find in real CPUs, most notably the ability for execution to jump to arbitrary memory locations. They had to work around this to maintain the behavior of goroutines. Functions also live in their own address spaces which necessitates a change to how the program counter works.

fwip 9y ago

My understanding is that they're treating Web Assembly as just another architecture to compile for - rather than spitting out x86_64 assembly, or ARM assembly, they're emitting Web Assembly.

hobofan 9y ago

Kind of. It's more that Go _requires_ a runtime to support certain features which require Garbage Collection. The requirement of a runtime in turn dictates a different architecture to run on WebAssembly.

deleted 9y ago

[deleted]

nijaru 9y ago

As others have said, Web assembly is an architecture/target for C, C++, rust, etc. that you compile for, and it will be the same for go. The link does talk about GC support. It looks like wasm will have one, but go’s will most likely perform better since it is tailored to go. (edit for clarification) I assume a lot of the planning for this was in the GitHub and mailing list discussions dedicated to go’s wasm support. I’m on mobile but I can link those later.

swsieber 9y ago
I was under the impression that WASM does not have one.
- dragonwriter 9y ago
  IIRC, WASM doesn't have one and, more importantly, has an architecture which makes implementing one on top of WASM efficiently difficult.
- steveklabnik 9y ago
  Wasm doesn't have one yet, but it's a future extension to to spec. You can, of course, compile your GC in today, and it will work. Wasm's integrated support will mean re-using the existing GC, which means smaller code size. Side note: most people thought this would be a precursor to DOM support, but the new "host bindings" proposal opens up DOM support without needing GC support, and many people believe that now the former will land before the latter.
  - k__ 9y ago
    Are GC implementations transparent for the languages? Can Go simply run with the WASM GC or does it need some specific type of GC?
    - steveklabnik 9y ago
      "the WASM GC" only exists as a proposal, and proposals can change before they land. I don't know enough about it to say, and even if I did, it might be invalid by the time things are actually accepted. See https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc for the current proposal.
      - k__ 9y ago
        Sure. But one day, when there are implementations, can every language run with the WASM GC?
    - pjmlp 9y ago
      No if you care about performance. To go the extra mile in GC performance, the compiler and GC implementation have to collaborate, taking advantage of language specific features.

goalieca 9y ago

Follow-up question, why can't LLVM -> Web Assembly solve the problem?

sitkack 9y ago
x86 elf -> wasm could solve this problem.
- kodablah 9y ago
  That would take quite the effort to build, but I bet lifting to LLVM first might work: https://github.com/trailofbits/mcsema https://github.com/trailofbits/mcsema
- slrz 9y ago
  No, it wouldn't. At that point you already lost lots of information and your only option is to faithfully reproduce the behaviour of the x86 machine. You can still do it, of course and performance isn't even that bad. See Fabrice Bellard's x86 emulator using asm.js. https://bellard.org/jslinux/tech.html https://bellard.org/jslinux/tech.html
  - sitkack 9y ago
    Ok, pick a better ISA, like RISC-V.
ianburrell 9y ago
The regular Go compiler doesn't use LLVM. It is derived from Plan9 compiler toolchain. There has been work on a LLVM Go compiler. There is also Gccgo, Go frontend for GCC, that could use GCC WebAssembly backend.
- earenndil 9y ago
  Could use dragonegg[1] to run gccgo through llvm and then through emscripten. 1: https://dragonegg.llvm.org/ https://dragonegg.llvm.org/
9y ago

opencl 9y ago

Garbage collection isn't really a problem because no CPU architecture supports garbage collection- the compiler is generating code to implement the GC regardless. The issue is that WASM doesn't really resemble real CPUs at all. Basically all modern CPUs are register machines, but WASM is a stack machine. Say you have the code C=A+B in your program. The generated assembly for a real machine looks something like this: (R* denote registers and A-C are memory addresses) load A->R1 load B->R2 add R1+R2->R3 store R3->C WASM looks more like this: push A push B add pop C This alone makes the approach to code generation and optimization quite different. WASM does lack some features that you would find in real CPUs, most notably the ability for execution to jump to arbitrary memory locations. They had to work around this to maintain the behavior of goroutines. Functions also live in their own address spaces which necessitates a change to how the program counter works.