第 2 章汇编与调用约定 on Go 语言原本

2.1 Plan 9 汇编语言

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

2.1 Plan 9 汇编语言

读 Go 运行时的源码，迟早会撞见一种看起来既像汇编、又不太像任何熟悉汇编的代码，那是 Go 的 Plan 9 风格汇编。剖析调度器、栈切换、原子操作时我们会反复回到它：gogo、mcall、 morestack、asyncPreempt 都是汇编例程。本节解释它是什么、为何存在、以及读懂它需要的几个关键概念。我们不求让读者会写 Plan 9 汇编，那是另一本书的内容，但求把它变成一份阅读词汇表：当后文提到某个汇编例程时，读者知道它身处的是怎样一个抽象层，每个符号各指向什么。

本节示例取自 runtime/asm_amd64.s 与 internal/runtime/atomic。这些例程在各版本间相当稳定，为聚焦设计，我们对个别与本节无关的实验性分支（如 GOEXPERIMENT 守卫）做了裁剪，完整定义请对照对应源文件。

2.1.1 为什么 Go 要有自己的汇编

Go 的汇编源自 Plan 9 操作系统的汇编器传统。Plan 9 是贝尔实验室在 Unix 之后的研究型系统， Go 的几位设计者（Ken Thompson、Rob Pike、Russ Cox）正是从那里走来，把那套工具链的思路一并带进了 Go。它的关键特征是：它不是某一种 CPU 的原生汇编，而是一种半抽象、跨架构统一的中间汇编。同一套语法、同一批伪指令与伪寄存器，由工具链 cmd/asm 翻译到 amd64、arm64、riscv64 等各目标架构的真实指令。这与 GNU as 那种「每个架构一套方言」的设计截然不同。

这个选择服务于 Go 最初的一个硬目标：一套工具链、交叉编译开箱即用。当汇编层本身就是跨架构的，为新架构移植运行时就退化成「为这套统一语法补一个后端」，而不是「重学一门汇编再重写一遍运行时」。代价同样真实：Go 要自己维护汇编器、链接器与目标文件格式（cmd/internal/obj），多养一整套基础设施。买到的是对代码生成、调用约定、与运行时协同的完全掌控，这条「自己造而非复用现成件」的取舍，会在 2.3 调用约定的自定义 ABI 与 6.1 的函数调用里再次出现，是理解 Go 运行时的一条主线。

2.2 汇编中的栈帧与符号

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

2.2 汇编中的栈帧与符号

2.1 给出了 Plan 9 汇编的伪寄存器与寻址语法，那是「怎么写一行汇编」。本节把视线抬高到一段完整例程：一个手写汇编函数如何用 TEXT ·name(SB) 声明自己的符号，如何用 $framesize-argsize 申明栈帧大小，NOSPLIT 又意味着什么。我们用运行时里三段真实例程（Cas、gogo、morestack）把这些约定逐处对上号，读完之后，调度器与栈管理章节里那些汇编符号就从天书变成可读的现场操作。

2.2.1 从 Go 源码到 Plan 9 汇编：CAS 的逐槽对应

把抽象落到实处。运行时的原子比较交换 Cas 在 amd64 上是手写汇编，它的 Go 原型与汇编实现逐字段对得上，是观察「Go 源码如何映射到 Plan 9 汇编」的好样本。Go 这一侧只有声明（函数体在 .s 文件里）：

// internal/runtime/atomic：仅声明，实现在 atomic_amd64.s
//
//	if *ptr == old { *ptr = new; return true } else { return false }
func Cas(ptr *uint32, old, new uint32) bool

对应的 amd64 实现：

2.3 调用约定与寄存器 ABI

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

2.3 调用约定与寄存器 ABI

文中的寄存器名、栈帧布局与序言代码以 amd64 为例，其余体系结构（arm64、riscv64 等）结构相同而寄存器名不同，可对照 src/cmd/compile/abi-internal 的「Architecture specifics」一节。

一次函数调用，在机器层面要回答一连串具体的问题：参数放哪里，返回值放哪里，谁负责保存哪些寄存器，栈帧怎样布局，返回地址压在何处。把这些问题的答案固定下来，就是调用规范（calling convention），它也常被称作 ABI（application binary interface）。ABI 不是某一段代码，而是一份契约：编译器生成的代码、手写的 Plan 9 汇编（2.1）、运行时里的底层例程，三方各自独立编写，却要在调用的那一刻严丝合缝地对接。契约一旦写定，三方就都按它来摆放数据，谁也不必知道对方的内部细节。

6.1 已从语言视角讲过函数调用从栈到寄存器的演进，那里关心的是「一次 f(a, b) 在 Go 语义上发生了什么」。本节与 2.4 参数传递与栈帧布局补足它在汇编与运行时层面的另一半：同一次调用，落到机器指令上是如何约定的。两者合起来，函数调用这件事才算讲完整。

2.3.1 两套 ABI：ABI0 与 ABIInternal

Go 同时维护着两套调用规范，理解它们的分工是读懂运行时里那些奇怪符号标注的钥匙。

ABI0 是早期的、基于栈的规范：所有参数与返回值一律通过栈内存传递，调用方在自己的栈帧里按顺序摆好参数，被调用方从固定偏移处取用。它的好处是布局稳定、可预测，人脑能算清每个参数的偏移。手写汇编因此一律遵循 ABI0，go.dev/doc/asm 描述的就是这套稳定 ABI。ABI0 还有一个常被忽略的性质：它是 Go 唯一承诺稳定的 ABI，是汇编与 Go 之间唯一可靠的接缝。

ABIInternal 是 Go 1.17 引入的、基于寄存器的内部规范：尽量把参数与返回值放进寄存器，省去大量进出栈内存的读写。所有由 Go 源码编译出的函数都走 ABIInternal。它的名字里「Internal」二字是郑重的警告：这套 ABI 不稳定，会随 Go 版本变化，任何外部代码都不应依赖它的细节。换来的是约 5% 的整体提速，且这份提速对用户代码完全透明，源码一字不改，重新编译即享。

2.4 参数传递与栈帧布局

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

2.4 参数传递与栈帧布局

2.3 给出了两套 ABI 的分工与参数分配的递归算法，那是「规则」。本节把规则落到一个具体例子上：一个同时含标量与数组的签名，参数究竟在栈帧里怎样摆放，寄存器参数为何还要在栈上留一格溢出槽，序言里那条几乎人人都付的栈增长检查又是怎么搭上抢占的便车。最后我们回到「为何自定义 ABI」这个总账，把这两节合成一个完整的回答。

2.4.1 一个掺杂栈传与寄存器传的例子

抽象规则不如一个例子来得清楚。取 ABI 规范里那个精心设计的签名，它故意同时含有能进寄存器的标量与必须走栈的数组：

1
2

func f(a1 uint8, a2 [2]uintptr, a3 uint8) (
    r1 struct{ x uintptr; y [2]uintptr }, r2 string)

按 2.3.1 的递归分配，在 amd64（整数寄存器 RAX, RBX, ...）上结果是：

a1、a3 是能进寄存器的标量，分到 RAX、RBX；
a2 是非平凡数组，整个退回栈上；
返回值 r1 含数组，也走栈；r2 是 string，拆成 base 与 len 两部分，回填 RAX、RBX （返回时寄存器重新从头计数，与入参不冲突）。

于是入口时只有 a2 在栈上有初值，栈帧布局如下，其余区域调用时一律不初始化：

flowchart TB
    spill["a3Spill uint8<br/>a1Spill uint8<br/>（寄存器参数的溢出槽，调用方预留，调用时空着）"]
    ret["r1.y [2]uintptr<br/>r1.x uintptr<br/>（栈传返回值）"]
    arg["a2 [2]uintptr<br/>（栈传参数，唯一带初值者）"]
    spill --> ret --> arg
    low["↓ 低地址"]
    arg -.-> low

这个例子把三件事一次说清：标量优先进寄存器，含数组的值整体走栈，而每个寄存器参数仍在栈上留有一格溢出槽待命。把它和 2.3.1 那条「全栈传」的 ABI0 对照，差别一目了然：ABI0 下 a1、a3 连同 a2 全在栈上按序排开，没有寄存器、也无需溢出槽；ABIInternal 把能搬的都搬进了寄存器，省下的正是那几次进出栈内存的读写。

第 2 章 汇编与调用约定 on Go 语言原本

2.1 Plan 9 汇编语言

2.1 Plan 9 汇编语言

2.1.1 为什么 Go 要有自己的汇编

2.2 汇编中的栈帧与符号

2.2 汇编中的栈帧与符号

2.2.1 从 Go 源码到 Plan 9 汇编：CAS 的逐槽对应

2.3 调用约定与寄存器 ABI

2.3 调用约定与寄存器 ABI

2.3.1 两套 ABI：ABI0 与 ABIInternal

2.4 参数传递与栈帧布局

2.4 参数传递与栈帧布局

2.4.1 一个掺杂栈传与寄存器传的例子

第 2 章汇编与调用约定 on Go 语言原本