[johnhenry]

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?

[opencl]

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.

[hobofan]

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.

[fwip]

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.

[nijaru]

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]

I was under the impression that WASM does not have one.

[steveklabnik]

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__]

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]

"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 for the current proposal.

[k__]

Sure.

But one day, when there are implementations, can every language run with the WASM GC?

[pjmlp]

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.

[dragonwriter]

IIRC, WASM doesn't have one and, more importantly, has an architecture which makes implementing one on top of WASM efficiently difficult.

[goalieca]

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

[ianburrell]

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]

Could use dragonegg[1] to run gccgo through llvm and then through emscripten.

1: https://dragonegg.llvm.org/

[ecnahc515]

It can, emscripten supports this, however the primary Go compiler doesn't use LLVM so this doesn't help really.

[steveklabnik]

Emscripten does, but LLVM does without emscripten too.

[johnhenry]

This is kind of what I was getting at... other languages seem to have a webasm pipeline that includes LLVM. I wanted to know what what the difference was between go and these languages that require one to use something other than LLVM.

[pjmlp]

Besides the issue of Go main compilers not using LLVM, that would only be about the instructions.

There is no way around porting the runtime as well.

[sitkack]

x86 elf -> wasm could solve this problem.

[slrz]

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

[sitkack]

Ok, pick a better ISA, like RISC-V.

[kodablah]

That would take quite the effort to build, but I bet lifting to LLVM first might work: https://github.com/trailofbits/mcsema