WebAssembly architecture for Go

In Chrome today, as an example, the C++ based DOM and V8 (Javascript ) objects are using different GCs. Obviously it is a pain point, but the situation of having different GCs for DOM and language objects is not new with Web Assembly.

In Google's Doubleclick for Publishers UI they use Dart apps. The page loads several "apps" compiled to JS, each of which weights more than 2 Mb (even the "changelog" app). Page loads very slowly. So I would expect something similar for Go.

A "hello world" in Rust is ~100 bytes; the more stuff you use, the bigger it gets, as less of the stdlib can be removed. The biggie is an allocator, which adds some size, but you can use things like https://github.com/fitzgen/wee_alloc and it's less than a kilobyte...

Worth noting, gopherjs has been around forever, and is mature:

https://github.com/gopherjs/gopherjs

...and already has a reasonable js interop story, whereas my understanding is that calling the dom api from wasm is not the simplest thing.

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.

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.

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.

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

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.

> WASM has fairly strict stack/frame rules/types, so arbitrary gotos wouldn't work.

kinda funny because golang follows the same idea.

>non-JS WASM backend

...what's a non-js wasm backend?

> Didn't they see the need for it coming?

Wasm exists because it's small and incremental; there's lots of stuff that's needed, but not in the initial spec. As long as it can be added in the future, that's what matters.

I'm assuming it's because they wanted existing js/asm.js JITs to easily accept wasm, and those only see structured control flow.

It's easier to add instructions than to remove our restrict them. Hardware or software exploits to break out of the sandbox are huge concerns. I'm all for introducing new features slowly.

Speculating, but it sounds to me like it's within individual functions. Go's program counter is "[split] into 2 parts: PC_F and PC_B. PC_F is the index of the function to be executed. PC_B is the index of the basic block to be executed."

What you’re saying applies to interpreters, which execute the program opcode by opcode, and (in the case of stack machines) keep an actual stack at runtime. WebAssembly was designed to be the input for (at least mildly) optimizing JIT compilers. Since the stack is required to be at a fixed depth at each instruction, when the compiler reads the instruction, it can map each of the inputs it pops to a single earlier instruction that pushed it[1], and record a reference directly to that in its internal IR. After that it completely forgets about the stack. Later on it’ll do register allocation for the native architecture, so the generated native code makes efficient use of registers.

Or in other words, the “stack machine” is basically just a compact encoding of an AST.

(Note that the native “stack” is an entirely separate thing which does exist at runtime.)

[1] Actually, there can be multiple possible instructions from, e.g., inside the ‘if’ and ‘else’ sides of a prior if-block (which can push values that stay on the stack after the end of the block). But since both sides have to push the same number of values, this is still tractable; it turns into a phi node in SSA representation.

One big advantage of stack machines is that they tend to be better on code size, which very much matters when you're transferring code over the network. I expect other parts of the design make it easier to JIT; the lack of arbitrary gotos probably makes analyzing control flow easier, for example.

Honestly, the defacement is at least as interesting as the original document.

Here is a direct link [1] for easy access; maybe Dang can change the link.

[1] https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0...