Chapter 2 Assembly and Calling Conventions on Go: Under the Hood

2.1 The Plan 9 Assembly Language

Mon, 01 Jan 0001 00:00:00 +0000

2.1 The Plan 9 Assembly Language

Read the source of the Go runtime long enough, and sooner or later you run into code that looks like assembly yet not quite like any assembly you are familiar with. That is Go’s Plan 9 style assembly. We will keep returning to it as we dissect the scheduler, stack switching, and atomic operations: gogo, mcall, morestack, and asyncPreempt are all assembly routines. This section explains what it is, why it exists, and the few key concepts you need in order to read it. We do not aim to teach the reader to write Plan 9 assembly, which is the subject of another book; we aim to turn it into a reading vocabulary: when a later section mentions some assembly routine, the reader knows what kind of abstraction layer it lives in and what each symbol points to.

2.2 Stack Frames and Symbols in Assembly

Mon, 01 Jan 0001 00:00:00 +0000

2.2 Stack Frames and Symbols in Assembly

2.1 gave the pseudo-registers and addressing syntax of Plan 9 assembly, which is about “how to write one line of assembly”. This section raises our view to a complete routine: how a hand-written assembly function declares its own symbol with TEXT ·name(SB), how it states its stack frame size with $framesize-argsize, and what NOSPLIT means. We will match these conventions point by point against three real routines in the runtime (Cas, gogo, morestack), and once you finish reading, the assembly symbols in the chapters on the scheduler and stack management turn from gibberish into readable, on-the-spot operations.

2.3 Calling Convention and the Register ABI

Mon, 01 Jan 0001 00:00:00 +0000

2.3 Calling Convention and the Register ABI

The register names, stack-frame layout, and prologue code in this text use amd64 as the example. Other architectures (arm64, riscv64, and so on) share the same structure but differ in register names; you can cross-reference the “Architecture specifics” section of src/cmd/compile/abi-internal.

A single function call, at the machine level, has to answer a string of concrete questions: where do the arguments go, where does the return value go, who is responsible for saving which registers, how is the stack frame laid out, where is the return address pushed. Pinning down the answers to these questions is the calling convention, often also called the ABI (application binary interface). The ABI is not a piece of code but a contract: the code generated by the compiler, the hand-written Plan 9 assembly (2.1), and the low-level routines inside the runtime are written independently of one another, yet they have to mesh exactly at the moment of the call. Once the contract is fixed, all three sides arrange their data according to it, and none of them needs to know the internal details of the others.

2.4 Argument Passing and Stack Frame Layout

Mon, 01 Jan 0001 00:00:00 +0000

2.4 Argument Passing and Stack Frame Layout

2.3 laid out the division of labor between the two ABIs and the recursive algorithm for assigning arguments. That was the “rule”. This section grounds the rule in a concrete example: given a signature that mixes scalars and arrays, how exactly are the arguments arranged in the stack frame, why does a register argument still reserve a spill slot on the stack, and how does the stack growth check that nearly every function pays for in its prologue hitch a ride on preemption. Finally we return to the overall question of “why a custom ABI” and combine these two sections into a complete answer.