从零理解RISC-V调用约定：为什么t0-t6寄存器敢随便用而s0-s11必须保护？

从零理解RISC-V调用约定：为什么t0-t6寄存器敢随便用而s0-s11必须保护？

刚开始接触RISC-V汇编，很多人都会被那一堆寄存器搞得晕头转向。x0到x31，每个都有名字和编号，更让人困惑的是，为什么有些寄存器（比如t0到t6）在函数里可以随意使用，而另一些（比如s0到s11）却要小心翼翼地在用之前保存、用之后恢复？这背后其实隐藏着RISC-V架构设计者精心安排的一套“社会契约”——函数调用约定（Calling Convention）。理解这套规则，不仅能让你写出正确的汇编代码，更能让你从底层视角看清程序是如何在函数之间优雅地“传递接力棒”的。

想象一下，你正在组织一场大型的多团队接力赛。每个团队（函数）都有自己的工作区域（栈帧）和专用工具（寄存器）。有些工具是公用的，谁用谁负责收拾（t0-t6）；有些工具是团队私有的，必须原样归还（s0-s11）。比赛的顺利进行，依赖于每个团队都遵守一套明确的规则：什么时候可以动用公共资源，什么时候必须保护好自己的家当。RISC-V的调用约定，就是这套确保程序世界秩序井然的规则。本文将带你深入这套规则的核心，用生活化的比喻拆解其本质，并通过可视化的调用树和实际的模拟器实验，让你亲眼看到寄存器值是如何在函数嵌套调用中流动和变化的。

1. 核心概念：调用者与被调用者的“责任划分”

在程序执行过程中，函数调用无处不在。当一个函数（调用者，Caller）决定调用另一个函数（被调用者，Callee）时，它需要暂时交出CPU的控制权。为了保证调用者能在被调用者执行完毕后，无缝衔接地继续自己的工作，双方必须就寄存器的使用达成一致。这就是调用约定（Calling Convention）要解决的核心问题：在函数调用的边界，谁该负责保存和恢复哪些寄存器的值？

RISC-V的ABI（应用程序二进制接口）将32个通用寄存器清晰地分成了两大类，其划分依据正是“责任归属”。

这个表格揭示了一个关键思想：“保存”的责任是主动的，而非自动的。硬件不会自动帮你保存任何寄存器（除了程序计数器PC在跳转指令中的隐式更新）。所谓“调用者保存”，意思是调用者有责任在需要时保存；所谓“被调用者保存”，意思是被调用者有责任在需要时保存。如果一方没有尽到责任，数据就会丢失。

那么，为什么是t0-t6被划为“临时”的、调用者保存的寄存器，而s0-s11被划为“保存”的、被调用者保存的寄存器呢？这源于它们被赋予的典型用途：

• t0-t6(临时寄存器)：顾名思义，用于存放生命周期短暂的中间计算结果。比如计算一个表达式(a+b)*c，编译器可能会用t0存放a+b的结果，再用t1存放乘以c后的结果。这些值通常在本次函数调用内部就消费完了，很少需要跨越函数调用边界去保存。因此，将它们设为调用者保存，给了调用者最大的灵活性：我用完了，你随便用。调用者如果碰巧有值放在t寄存器里且调用后还需要，它自己会记得存起来（通常压入栈中）；如果不需要，就省去了保存/恢复的开销。
• s0-s11(保存寄存器)：用于存放需要在多个函数调用之间持久存在的局部变量或重要状态。例如，一个函数里有个循环计数器i，它的值在循环的每次迭代中都要用到，并且这个循环里还调用了其他函数。为了确保i的值在子函数调用后不被破坏，就必须将它存放在一个“安全”的地方——s寄存器就是为此设计的。由于被调用者承诺会恢复它们，调用者可以放心地将长期值存放在这里，而无需在每次调用子函数前都手动保存。

提示：ra(返回地址寄存器x1) 是一个特例。从“谁污染谁治理”的角度看，是jal或jalr指令“污染”了它（写入新的返回地址）。因此，如果一个函数内部还会调用其他函数（非叶子函数），它就必须在调用前保存好自己的ra（因为子函数的jal指令会覆盖它），这符合“调用者保存”的逻辑。但在ABI描述中，ra常被归为被调用者需要保存的寄存器之一，这是因为它对于函数的正确返回至关重要，非叶子函数必须保存它，这更像一个强制要求。

2. 可视化污染链：函数调用树中的寄存器流动

单纯看规则可能还是有些抽象。让我们通过一个具体的、多层嵌套的函数调用例子，来可视化寄存器值的“污染链”。假设我们有如下C代码片段：

int global_counter = 0; int leaf_func(int x) { int temp = x * 2; // 可能使用t寄存器 return temp + 1; } int middle_func(int a, int b) { int sum = a + b; // 假设用s0存放sum int doubled = leaf_func(sum); // 调用子函数 global_counter++; // 访问全局变量（可能通过gp） return doubled * global_counter; } int main() { int base = 10; int result = middle_func(base, 20); return result; }

我们可以将其调用关系描绘成一棵树：

main (Caller) | | calls middle_func(a=10, b=20) v middle_func (Callee, also Caller) (uses s0 for `sum`) | | calls leaf_func(x=sum) v leaf_func (Callee) (freely uses t0, t1...)

现在，让我们跟踪s0和t0这两个典型寄存器在调用过程中的状态：

1. main调用middle_func前：

   • main作为调用者，它不关心middle_func内部用什么寄存器。它只负责把参数10和20分别放入a0和a1，然后执行call middle_func（相当于jal ra, middle_func）。

2. middle_func刚进入时：

   • middle_func作为被调用者，如果它打算使用s0-s11中的任何一个，它必须首先在栈上为这些寄存器分配空间，并把它们的当前值保存进去。假设它决定用s0来存放局部变量sum，那么它的序言（prologue）代码可能如下：

     middle_func: addi sp, sp, -16 # 在栈上分配空间（假设还需要存ra） sd ra, 8(sp) # 保存返回地址（因为本函数还要调用leaf_func） sd s0, 0(sp) # 保存s0的原始值（被调用者保存责任） # ... 函数体开始

   • 注意，middle_func不需要保存t0-t6。它可以直接使用它们作为临时计算寄存器，因为这是调用者（main）该操心的事。

3. middle_func调用leaf_func前：

   • middle_func现在变成了调用者。它计算sum = a0 + a1，结果放在s0里（因为这是它决定长期保存的值）。
   • 它需要调用leaf_func，参数是s0的值。所以它把s0的值加载到a0中。
   • 关键决策点：middle_func在调用leaf_func之前，需要保存那些它自己还在使用、并且是“调用者保存”类的寄存器吗？查看上表，a0-a7和t0-t6都是调用者保存的。假设middle_func在调用前刚好用t0做了一个中间计算，并且这个结果在leaf_func返回后还需要，那么middle_func就必须手动保存t0（比如压栈）。如果t0里的值后面没用了，那就不用保存。这就是“调用者保存”赋予的灵活性。
   • 对于s0，由于它是被调用者保存的，middle_func可以确信，只要leaf_func遵守约定（如果它用了s0就会保存恢复），那么s0里的sum值在leaf_func返回后依然是完好的。所以middle_func在调用前不需要为了s0做任何额外操作。

4. leaf_func内部：

   • leaf_func是一个简单的“叶子函数”（不调用其他函数）。它可能大量使用t0,t1等临时寄存器进行计算，完全不需要碰s0-s11。
   • 因为它没有调用其他函数，所以它甚至不需要保存ra。
   • 它自由地“污染”t寄存器，计算完毕后将结果放入a0，然后ret。

5. leaf_func返回middle_func后：

   • middle_func检查s0，值应该没变（前提是leaf_func遵守约定没动它）。而t0如果之前没保存，其值已不可预测（被leaf_func污染了）。
   • middle_func继续执行，使用s0中的值进行后续计算。

6. middle_func返回前：

   • 在ret指令之前，middle_func必须履行其作为被调用者的责任：恢复它保存过的s0和ra。

     # ... 函数体结束，准备返回 ld s0, 0(sp) # 恢复s0的原始值 ld ra, 8(sp) # 恢复返回地址 addi sp, sp, 16 # 释放栈空间 ret

   • 这样，当控制流回到main时，main看到的栈指针sp和它保存的寄存器（如果有）都恢复了原样。

通过这个链条，我们可以清晰地看到：

• t寄存器的污染是“单向传递”的：调用链下游的函数可以随意污染它们，污染效果会向上游“扩散”，除非中途有调用者主动拦截（保存）。
• s寄存器的保护是“建立孤岛”的：每个函数如果使用了s寄存器，就为自己建立了一个安全的存储孤岛。只要它遵守规则（保存/恢复），岛内的数据就不会被外界（子函数调用）影响。这使得长期变量的存储非常稳定。

这种设计带来了巨大的效率优势。在典型的程序中，大量的计算都是局部、临时的。使用t寄存器处理这些临时值，避免了大量不必要的栈操作（保存/恢复）。而将需要长期保存的值放在s寄存器中，又使得它们在多次调用中能被高效地访问。

3. 动手实验：用QEMU模拟器观察寄存器变化

理论结合实践，理解才能深刻。我们搭建一个简单的RISC-V实验环境，写一段小的汇编程序，用调试器一步步跟踪，亲眼验证调用约定是如何工作的。我们将使用QEM-User模式进行模拟，并用GDB进行调试。

首先，确保你的系统安装了必要的工具（以Ubuntu为例）：

sudo apt update sudo apt install gcc-riscv64-linux-gnu gdb-multiarch qemu-user

接下来，我们编写一个包含嵌套调用的RISC-V汇编程序，保存为test_call.S：

.text .globl main .type main, @function main: # 序言：main也是函数，需要保存ra（虽然这里最终不返回） addi sp, sp, -16 sd ra, 8(sp) # 初始化一些值到s和t寄存器，以便观察 li s0, 0x1234 # s0: 将被保护的值 li s1, 0x5678 # s1: 另一个被保护的值 li t0, 0xabcd # t0: 临时值，main希望调用后保留（所以需要保存） li t1, 0xef01 # t1: 临时值，main调用后不再需要 # 在调用func_a之前，main作为调用者，需要保存它希望保留的调用者保存寄存器 # 这里我们只关心t0，t1不需要保留 addi sp, sp, -16 sd t0, 0(sp) # 保存t0到栈上 # 准备参数并调用func_a li a0, 100 li a1, 200 call func_a # jal ra, func_a # 调用返回后，恢复之前保存的t0 ld t0, 0(sp) addi sp, sp, 16 # 此时，检查寄存器的值： # s0, s1 应该还是 0x1234, 0x5678 (被func_a保护了) # t0 应该恢复为 0xabcd (被main自己保护了) # t1 可能已被func_a改变 (调用者未保存，被调用者不负责) # 收尾 ld ra, 8(sp) addi sp, sp, 16 li a0, 0 # 返回0 ret .type func_a, @function func_a: # 序言：func_a是非叶子函数（它调用func_b），需要保存ra和它要使用的s寄存器 addi sp, sp, -32 sd ra, 24(sp) sd s0, 16(sp) # 保存s0（虽然本例中func_a可能不用s0，但演示保护） sd s1, 8(sp) # 保存s1 # func_a使用一些t寄存器，并故意修改s0, s1 (这违反了约定！但我们要观察后果) li t2, 0x2222 li t3, 0x3333 # !! 故意破坏性操作 !! li s0, 0xdead # 错误：修改了被调用者应保存的寄存器，且未恢复 li s1, 0xbeef # 错误：同上 # 调用func_b前，func_a作为调用者，如果需要保留t2, t3，应该保存它们 # 这里假设func_b返回后t2, t3不再需要，所以不保存。 # 准备参数调用func_b mv a0, t2 # 随便传个参数 call func_b # func_b返回后，t2, t3可能已被改变（调用者保存寄存器） # s0, s1 已经被我们错误地修改了 # 收尾：恢复寄存器 (但我们错误地没有恢复s0, s1的原始值) ld s1, 8(sp) # 从栈上恢复s1的原始值（覆盖了0xbeef） ld s0, 16(sp) # 从栈上恢复s0的原始值（覆盖了0xdead） ld ra, 24(sp) addi sp, sp, 32 ret .type func_b, @function func_b: # func_b是叶子函数，简单修改一些t寄存器后返回 li t0, 0x9999 li t1, 0x8888 li t2, 0x7777 # 这将覆盖func_a中t2的值！ # func_b不使用任何s寄存器，所以不需要保存它们 ret

编译这个程序：

riscv64-linux-gnu-gcc -static -g -o test_call test_call.S

现在，用QEMU用户模式启动GDB进行调试：

qemu-riscv64 -g 1234 ./test_call & gdb-multiarch ./test_call

在GDB中，连接到QEMU并设置断点：

(gdb) target remote localhost:1234 (gdb) break main (gdb) break func_a (gdb) break func_b (gdb) continue

程序会在main入口停下。我们可以使用info registers命令查看所有寄存器的值。接下来，我们单步执行（stepi或ni），并重点关注以下几个时刻的寄存器状态：

1. 进入main后，调用func_a之前：记录s0,s1,t0,t1的值。
2. 进入func_a后，调用func_b之前：观察s0,s1是否被func_a的序言正确保存？观察t2,t3被赋值为什么。
3. 进入func_b后：观察t0,t1,t2被修改为什么值。
4. 从func_b返回func_a后：观察t2,t3的值是否变成了func_b中设置的值（0x7777等）？这验证了t寄存器是调用者保存的，func_a没有保存它们，所以值被污染。
5. 从func_a返回main后：这是最关键的观察点。
   • s0和s1的值会是多少？根据代码，func_a错误地修改了它们为0xdead和0xbeef，但在返回前又从栈上恢复了旧值（0x1234和0x5678）。所以，只要被调用者遵守约定保存和恢复，s寄存器的值就能在调用中保持不变。即使函数内部曾修改过它们。
   • t0的值会是多少？main在调用前保存了它（0xabcd），调用后恢复了它。所以它应该还是0xabcd。
   • t1的值会是多少？main没有保存它，它可能被func_a或func_b修改过，所以值是不确定的（很可能是0x8888，即func_b最后设置的值）。这体现了调用者保存寄存器的“风险”。

通过这个实验，你可以直观地看到：

• 遵守约定时（如func_a对s0,s1的保存/恢复，main对t0的保存/恢复），数据得以安全传递。
• 不遵守约定时（如func_a内部修改s寄存器但不恢复，或者调用者不保存重要的t寄存器），程序状态就会出错，这是很多底层bug的来源。

4. 栈帧布局：寄存器保存的物理家园

当寄存器需要被保存时，它们去了哪里？答案是：栈（Stack）。每个函数调用都会在栈上分配一块私有的内存区域，称为栈帧（Stack Frame）。被调用者保存的寄存器（s0-s11,ra等）和调用者需要保存的临时寄存器，都存放在这个帧里。

一个典型的RISC-V栈帧布局如下（地址从高向低增长）：

高地址 +-------------------------------+ | 调用者的栈帧 | | ... | +-------------------------------+ | 参数区 (如果超过8个) | <-- 当参数多于8个时，超出的部分放在这里 +-------------------------------+ | 返回地址 (ra) | <-- Callee-saved, 非叶子函数必须保存 +-------------------------------+ | 保存的寄存器 (s0, s1, s2...) | <-- Callee-saved, 按需保存 +-------------------------------+ | 局部变量 | +-------------------------------+ | 调用者保存的临时空间 (t0...) | <-- Caller-saved, 按需保存 +-------------------------------+ | (对齐填充，使sp保持16字节对齐) | +-------------------------------+ | ... | <-- 当前函数的栈帧顶部 +-------------------------------+ | 参数构造区 (为调用子函数准备) | +-------------------------------+ 低地址 <-- 栈指针 (sp) 通常指向这里

让我们用一段真实的序言/尾声代码来理解这个布局是如何实现的：

# 假设函数`foo`需要使用s0, s1, s2三个保存寄存器，并且它需要调用其他函数（所以需要保存ra） # 同时，假设在调用子函数前，foo需要保留t0和t1的值。 foo: # 序言 (Prologue) # 1. 分配栈帧空间：我们需要保存 ra(8字节), s0(8), s1(8), s2(8) = 32字节 # 还需要为调用者保存的t0, t1预留空间：+16字节 # 总共48字节。为了保持16字节对齐，48本身就是对齐的。 addi sp, sp, -48 # 栈向下增长，分配空间 # 2. 保存被调用者保存的寄存器和ra sd ra, 40(sp) # 将返回地址保存在栈帧较高地址（习惯） sd s0, 32(sp) sd s1, 24(sp) sd s2, 16(sp) # 3. (可选) 在调用子函数前，保存调用者保存的寄存器 sd t0, 8(sp) # 假设t0的值后面还需要 sd t1, 0(sp) # 假设t1的值后面还需要 # ... 函数主体代码 ... # 可能在这里使用s0-s2存放长期变量 # 可能在这里修改t0, t1, t2... 做临时计算 # 假设现在需要调用另一个函数`bar` # 准备参数到a0-a7... call bar # bar返回后，恢复之前保存的t0, t1（如果需要的话） ld t1, 0(sp) ld t0, 8(sp) # ... 更多代码 ... # 尾声 (Epilogue) # 1. 恢复被调用者保存的寄存器 ld s2, 16(sp) ld s1, 24(sp) ld s0, 32(sp) ld ra, 40(sp) # 2. 释放栈帧空间 addi sp, sp, 48 # 3. 返回 ret

几点关键观察：

• 分配与释放对称：序言分配多少空间，尾声就释放多少。sp在函数入口和出口应该指向相同的位置。
• 保存与恢复顺序：通常，保存和恢复的顺序是相反的，但这并非强制。关键是地址要对齐。
• 对齐要求：RISC-V ABI要求栈指针sp在函数调用时必须保持16字节对齐。这有助于优化内存访问性能，并满足某些指令（如向量加载/存储）的要求。因此，在分配栈空间时，总大小必须是16的倍数。
• 帧指针（Frame Pointer,s0/fp）：s0寄存器常被用作帧指针（fp）。在复杂的函数中，栈指针sp可能在函数执行期间变化（例如为变长数组分配空间），使用固定的fp指向栈帧开始处，可以简化局部变量和保存寄存器的访问。在上面的例子中，如果使用fp，通常在保存s0后，会执行mv s0, sp，将当前的sp值作为帧指针。

理解栈帧布局对于调试至关重要。在GDB中，你可以使用backtrace（bt）命令查看调用栈，使用info frame查看当前栈帧的详细信息，包括保存的寄存器值和局部变量位置。

5. 高级场景与最佳实践

掌握了基本规则后，我们来看一些更复杂的场景和编写高效、正确汇编代码的最佳实践。

5.1 叶子函数优化

叶子函数（Leaf Function）是指那些不调用任何其他函数的函数。对于叶子函数，调用约定的遵守可以大大简化：

• 无需保存ra：因为叶子函数不会执行jal或call，所以ra寄存器不会被覆盖。它可以直接使用ra中的返回地址跳回调用者。
• 可能无需使用栈：如果叶子函数只使用t临时寄存器和a参数寄存器，并且不需要太多的局部变量空间（或者可以用寄存器完全容纳），那么它可能完全不需要操作栈指针sp。这减少了内存访问，提升了性能。
• 谨慎使用s寄存器：如果叶子函数使用了s寄存器，它仍然必须保存和恢复它们，因为调用者可能依赖这些值。但有时编译器可以通过寄存器分配优化，让叶子函数避免使用s寄存器。

一个极简的叶子函数例子：

leaf_add: # 无栈操作序言！ add a0, a0, a1 # a0 = a0 + a1 ret # 直接使用ra返回

5.2 内联汇编中的寄存器约束

在C代码中嵌入汇编（内联汇编）时，你必须明确告诉编译器你使用了哪些寄存器，以便编译器在生成代码时进行正确的保存和恢复。GCC内联汇编使用约束（Constraints）来指定。

int example(int x, int y) { int result; // 内联汇编，计算 (x*2) + y // 我们使用t0作为临时寄存器，并告知编译器我们“破坏”了它 asm volatile ( "slli t0, %1, 1\n\t" // t0 = x << 1 (即 x*2) "add %0, t0, %2" // result = t0 + y : "=r" (result) // 输出操作数，约束为寄存器 : "r" (x), "r" (y) // 输入操作数 : "t0" // 破坏列表（Clobber list）：告诉编译器我们修改了t0 ); return result; }

在上面的代码中，"t0"出现在破坏列表里。这告诉GCC：这段汇编代码可能会修改t0寄存器的值。GCC在生成调用example函数的代码时，如果发现调用者正在使用t0并且调用后还需要它的值，就会负责在调用前保存t0，在调用后恢复t0。这正是“调用者保存”约定的体现。

如果你在汇编中使用了s0，你也需要将它列入破坏列表。但更重要的是，如果你修改了s0，你必须在汇编代码内部负责保存和恢复它，因为这是“被调用者保存”的约定。内联汇编通常不处理这个，所以使用s寄存器要格外小心，或者避免在内联汇编中使用它们。

5.3 性能考量与寄存器分配策略

编译器在将高级语言编译为汇编时，一个核心任务就是寄存器分配。调用约定直接影响着分配策略：

• 优先使用t寄存器：对于生命周期短、不跨越函数调用的临时值，编译器会优先分配到t0-t6。因为这样通常不需要额外的保存/恢复指令（除非在调用点该值还需要）。
• 将跨调用变量分配到s寄存器：对于在函数内定义、生命周期跨越了函数调用的局部变量（例如循环计数器），编译器会尝试将它们分配到s0-s11。虽然这需要在函数序言/尾声付出保存/恢复的代价，但避免了在每次调用子函数前都进行保存。
• 溢出（Spilling）：当活跃的变量太多，32个通用寄存器不够用时，编译器不得不将一些变量“溢出”到内存（栈上）。这会显著降低性能。良好的寄存器分配算法会尽量最小化溢出次数。
• 调用密集代码：在调用非常频繁的代码路径上，大量使用调用者保存寄存器（t,a）可能导致调用者不得不频繁地保存/恢复它们，增加开销。有时，编译器会进行调用间寄存器分配优化，分析整个调用图，将某些值安排到被调用者保存寄存器中，即使其生命周期不跨调用，以减少调用者的保存压力。

理解这些策略，有助于你在阅读编译器生成的汇编代码时，明白为什么某个变量被放在了特定的寄存器里，也能在手动编写性能关键的汇编代码时做出明智的选择。

5.4 常见陷阱与调试技巧

即使理解了规则，在实际编码和调试中仍会遇到问题。以下是一些常见陷阱和应对技巧：

• 忘记保存ra：对于任何会调用其他函数的非叶子函数，忘记保存ra是致命的。这会导致函数无法正确返回，通常表现为程序跳转到错误地址并崩溃。调试：在GDB中，当程序ret时，用info registers ra检查ra的值是否指向合理的返回地址（通常是调用指令jal的下一条指令）。
• s寄存器未恢复：函数修改了s寄存器，但在返回前没有恢复其原始值。这会导致调用者的状态被破坏，错误可能在此后很久才显现，难以追踪。调试：在函数入口和出口设置断点，比较s寄存器的值。使用watch命令监视特定s寄存器的变化。
• 栈指针不对齐：没有保证sp是16字节对齐的，可能导致某些指令（如ld/sd）触发对齐错误，或者在调用遵循更严格ABI的函数（如某些库函数）时崩溃。调试：在函数入口和每次修改sp后，用p/x $sp打印其值，检查低4位是否为0。
• 错误估计栈帧大小：分配的空间不足以存放所有需要保存的寄存器或局部变量，导致栈数据被覆盖。调试：使用GDB的x命令检查栈内存，看保存的寄存器值是否被意外修改。也可以通过在栈帧边界写入特定模式（如0xdeadbeef）并在函数返回前检查来探测溢出。
• 混淆调用者/被调用者责任：在编写被调用函数时，错误地保存了t寄存器；或者在编写调用代码时，期望被调用函数保护了t寄存器的值。调试：仔细阅读ABI规范，在代码中添加注释明确每个寄存器的用途和保存责任。

掌握RISC-V的调用约定，就像是拿到了底层系统编程的钥匙。它不仅仅是几条需要死记硬背的规则，更是一套体现模块化、责任分离和效率权衡的深刻设计思想。从理解t和s寄存器的不同角色开始，到能在调试器中游刃有余地分析栈帧和寄存器状态，这个过程会让你对程序在硬件上的执行产生前所未有的掌控感。下次当你看到t0在函数间自由穿梭，而s0在嵌套调用中屹立不倒时，你看到的将不再是冰冷的指令，而是一场精心编排的、高效协作的寄存器芭蕾。