<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>第 2 章 汇编与调用约定 on Go 语言原本</title><link>http://golang.design/under-the-hood/zh-cn/part1overview/ch02asm/</link><description>Recent content in 第 2 章 汇编与调用约定 on Go 语言原本</description><generator>Hugo</generator><language>zh-cn</language><atom:link href="http://golang.design/under-the-hood/zh-cn/part1overview/ch02asm/index.xml" rel="self" type="application/rss+xml"/><item><title>2.1 Plan 9 汇编语言</title><link>http://golang.design/under-the-hood/zh-cn/part1overview/ch02asm/asm/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>http://golang.design/under-the-hood/zh-cn/part1overview/ch02asm/asm/</guid><description>&lt;h1 id="21-plan-9-汇编语言"&gt;2.1 Plan 9 汇编语言&lt;/h1&gt;
&lt;p&gt;读 Go 运行时的源码，迟早会撞见一种看起来既像汇编、又不太像任何熟悉汇编的代码，那是 Go 的
&lt;strong&gt;Plan 9 风格汇编&lt;/strong&gt;。剖析调度器、栈切换、原子操作时我们会反复回到它：&lt;code&gt;gogo&lt;/code&gt;、&lt;code&gt;mcall&lt;/code&gt;、
&lt;code&gt;morestack&lt;/code&gt;、&lt;code&gt;asyncPreempt&lt;/code&gt; 都是汇编例程。本节解释它是什么、为何存在、以及读懂它需要的几个
关键概念。我们不求让读者会写 Plan 9 汇编，那是另一本书的内容，但求把它变成一份&lt;strong&gt;阅读词汇表&lt;/strong&gt;：
当后文提到某个汇编例程时，读者知道它身处的是怎样一个抽象层，每个符号各指向什么。&lt;/p&gt;
&lt;p&gt;本节示例取自 &lt;code&gt;runtime/asm_amd64.s&lt;/code&gt; 与 &lt;code&gt;internal/runtime/atomic&lt;/code&gt;。这些例程在各版本间相当稳定，
为聚焦设计，我们对个别与本节无关的实验性分支（如 &lt;code&gt;GOEXPERIMENT&lt;/code&gt; 守卫）做了裁剪，完整定义
请对照对应源文件。&lt;/p&gt;
&lt;h2 id="211-为什么-go-要有自己的汇编"&gt;2.1.1 为什么 Go 要有自己的汇编&lt;/h2&gt;
&lt;p&gt;Go 的汇编源自 &lt;strong&gt;Plan 9 操作系统&lt;/strong&gt;的汇编器传统。Plan 9 是贝尔实验室在 Unix 之后的研究型系统，
Go 的几位设计者（Ken Thompson、Rob Pike、Russ Cox）正是从那里走来，把那套工具链的思路一并带进了
Go。它的关键特征是：&lt;strong&gt;它不是某一种 CPU 的原生汇编，而是一种半抽象、跨架构统一的中间汇编&lt;/strong&gt;。
同一套语法、同一批伪指令与伪寄存器，由工具链 &lt;code&gt;cmd/asm&lt;/code&gt; 翻译到 amd64、arm64、riscv64 等各目标
架构的真实指令。这与 GNU as 那种「每个架构一套方言」的设计截然不同。&lt;/p&gt;
&lt;p&gt;这个选择服务于 Go 最初的一个硬目标：&lt;strong&gt;一套工具链、交叉编译开箱即用&lt;/strong&gt;。当汇编层本身就是跨架构的，
为新架构移植运行时就退化成「为这套统一语法补一个后端」，而不是「重学一门汇编再重写一遍运行时」。
代价同样真实：Go 要自己维护汇编器、链接器与目标文件格式（&lt;code&gt;cmd/internal/obj&lt;/code&gt;），多养一整套基础设施。
买到的是对代码生成、调用约定、与运行时协同的&lt;strong&gt;完全掌控&lt;/strong&gt;，这条「自己造而非复用现成件」的取舍，
会在 &lt;a href=".././callconv"&gt;2.2 调用规约&lt;/a&gt; 的自定义 ABI 与 &lt;a href="../../../part2lang/ch06func/func"&gt;6.1&lt;/a&gt; 的函数调用里
再次出现，是理解 Go 运行时的一条主线。&lt;/p&gt;</description></item><item><title>2.2 调用规范</title><link>http://golang.design/under-the-hood/zh-cn/part1overview/ch02asm/callconv/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>http://golang.design/under-the-hood/zh-cn/part1overview/ch02asm/callconv/</guid><description>&lt;h1 id="22-调用规范"&gt;2.2 调用规范&lt;/h1&gt;
&lt;blockquote&gt;
&lt;p&gt;本节内容对标 Go 1.26。文中的寄存器名、栈帧布局与序言代码以 amd64 为例，
其余体系结构（arm64、riscv64 等）结构相同而寄存器名不同，可对照
&lt;code&gt;src/cmd/compile/abi-internal&lt;/code&gt; 的「Architecture specifics」一节。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;一次函数调用，在机器层面要回答一连串具体的问题：参数放哪里，返回值放哪里，谁负责保存哪些
寄存器，栈帧怎样布局，返回地址压在何处。把这些问题的答案固定下来，就是调用规范（calling
convention），它也常被称作 ABI（application binary interface）。ABI 不是某一段代码，而是一份
&lt;strong&gt;契约&lt;/strong&gt;：编译器生成的代码、手写的 Plan 9 汇编（&lt;a href=".././asm"&gt;2.1&lt;/a&gt;）、运行时里的底层例程，三方各自
独立编写，却要在调用的那一刻严丝合缝地对接。契约一旦写定，三方就都按它来摆放数据，谁也不必
知道对方的内部细节。&lt;/p&gt;
&lt;p&gt;&lt;a href="../../../part2lang/ch06func/func"&gt;6.1&lt;/a&gt; 已从语言视角讲过函数调用从栈到寄存器的演进，那里关心的是
「一次 &lt;code&gt;f(a, b)&lt;/code&gt; 在 Go 语义上发生了什么」。这一节补足它在汇编与运行时层面的另一半：同一次调用，
落到机器指令上是如何约定的。两者合起来，函数调用这件事才算讲完整。&lt;/p&gt;
&lt;h2 id="221-两套-abiabi0-与-abiinternal"&gt;2.2.1 两套 ABI：ABI0 与 ABIInternal&lt;/h2&gt;
&lt;p&gt;Go 同时维护着两套调用规范，理解它们的分工是读懂运行时里那些奇怪符号标注的钥匙。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;ABI0&lt;/strong&gt; 是早期的、&lt;strong&gt;基于栈&lt;/strong&gt;的规范：所有参数与返回值一律通过栈内存传递，调用方在自己的栈帧里
按顺序摆好参数，被调用方从固定偏移处取用。它的好处是布局稳定、可预测，人脑能算清每个参数的
偏移。手写汇编因此一律遵循 ABI0，&lt;code&gt;go.dev/doc/asm&lt;/code&gt; 描述的就是这套稳定 ABI。ABI0 还有一个常被
忽略的性质：它是 Go 唯一&lt;strong&gt;承诺稳定&lt;/strong&gt;的 ABI，是汇编与 Go 之间唯一可靠的接缝。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;ABIInternal&lt;/strong&gt; 是 Go 1.17 引入的、&lt;strong&gt;基于寄存器&lt;/strong&gt;的内部规范：尽量把参数与返回值放进寄存器，省去
大量进出栈内存的读写。所有由 Go 源码编译出的函数都走 ABIInternal。它的名字里「Internal」二字是
郑重的警告：这套 ABI &lt;strong&gt;不稳定&lt;/strong&gt;，会随 Go 版本变化，任何外部代码都不应依赖它的细节。换来的是
约 5% 的整体提速，且这份提速对用户代码完全透明，源码一字不改，重新编译即享。&lt;/p&gt;</description></item></channel></rss>