递归在汇编中的实现：ARM64栈帧与函数调用机制

1. 从"函数调函数"到"函数调自己"：递归对汇编意味着什么

很多人在高级语言里第一次接触递归时，会觉得这东西挺巧妙的——一个函数自己调用自己，像两面镜子对着放，一眼看不到底。可一旦切换到汇编语言，递归就不再是"巧妙"那么简单了，它直接牵扯到计算机体系结构里最核心的一个机制：栈。

先说清楚一个问题：为什么递归在汇编里是个值得单独拿出来讲的话题？因为在高级语言里，编译器替你处理了函数调用的所有脏活累活——参数怎么传、局部变量放哪、返回地址存哪、调用完怎么跳回来。这些在高级语言里是隐形的，你写一个 return fib(n-1) + fib(n-2) 就完事了。但到了汇编层面，这一切都要你自己安排。而递归的特殊之处在于：同一个函数会被多次调用，每一次调用都必须有自己独立的一套"现场"，否则数据就全乱套了。

什么是"独立的现场"？我用一个生活化的例子来解释。假设你是一个柜台办事员，手头有一叠单据要处理。每张单据上都写着一个电话号码，你需要打电话核实信息。当你拿起一张单据拨出电话，对方告诉你"请稍等，我再给你一个号码，你核实完这个再回来继续处理我这张"——这时候你就相当于在一个函数里调用了另一个函数。你得先把当前这张单据压在一边，记住它放在哪，然后去处理新号码。处理完新号码之后，你还得能回到刚才那张单据继续操作。

递归就是特殊情况：新号码那张单据上，写的是同一个柜台的处理流程。每张单据都对应一个"待办状态"，你总是先处理最新的那张，处理完回收它，再回头处理上一张。这种"后到先处理"的顺序，天然和栈的后进先出（LIFO）结构完美对应。所以递归在汇编里的本质，就是用栈来保存每一层函数调用的完整状态。

那么每一层的"完整状态"具体包括什么？最少得有三样东西：

• 返回地址：当前这层函数执行完后，该回到哪个地址继续执行。
• 参数和局部变量：每一层调用都有自己的参数值和中间计算结果，它们不能被其他层干扰。
• 调用者保存的寄存器：如果汇编代码里用了寄存器来存临时数据，而下一层调用也会用这些寄存器，那就必须先把当前值保存好。

这三个东西合在一起，就是计算机体系结构里常说的栈帧（Stack Frame）。理解递归在汇编里的实现，核心就是理解栈帧的建立和销毁。本篇文章我们就以ARM64（AArch64）架构为例，把递归函数的汇编实现从头到尾拆干净，顺便给出x86_64的对比说明。选ARM64做主线的理由有三个：一是当前嵌入式、移动端、Mac全系都在用ARM架构，实用价值高；二是ARM64的寄存器数量多、规则清晰，非常适合教学；三是你随便拿一台树莓派或者用QEMU模拟器就能上手实践，门槛不高。

2. 动手前的关键准备：寄存器约定与栈布局

2.1 ARM64寄存器调用约定：谁负责什么

写汇编程序，第一步不是写代码，而是搞清楚你所在平台的"函数调用规则"。这个规则在计算机行业里叫 ABI（Application Binary Interface），也就是"二进制层面的函数调用契约"。ARM64的ABI规则比较清爽，专门给函数调用划拨了一批寄存器：

• x0-x7：用于传递参数。第一个参数放x0，第二个放x1，依此类推。函数返回值也放在x0里。
• x8：间接结果寄存器，某些系统调用和返回大结构体时会用到，入门阶段可以先不深究。
• x19-x28：被调用者保存寄存器。意思是你调用的函数内部可以用这些寄存器，但返回之前必须把它们恢复原状。如果你在自己的函数里用了它们，你有责任保存和恢复。
• x29：帧指针（Frame Pointer），通常用来指向当前栈帧的底部。
• x30：链接寄存器（Link Register），专门保存函数调用的返回地址。

这些约定里最需要注意的就是 x30。在ARM64里，BL（Branch with Link）指令会做两件事：先把当前指令下一条的地址写入x30，然后跳转到目标地址去执行。也就是说，当你调用一个函数时，返回地址自动落到了x30里。被调用的函数如果需要再调用别人（或者递归调用自己），就必须先把x30里的值保存到栈上，否则一次新的BL指令就会覆盖掉上一个返回地址。

这就是为什么递归在汇编里必须依托栈：你的函数里要再一次调用自己，x30就会被覆盖。如果你不保存上一层调用的返回地址，那么当你的递归到达最深层开始"归"的时候，就根本找不到回家的路了。

2.2 栈的生长方向与栈帧布局

ARM64的栈和绝大多数架构一样，是向下生长的，也就是栈地址从高到低。SP（栈指针）永远指向当前栈的顶部——也就是最低地址处。当你需要占用栈空间时，用一条SUB SP, SP, #N把栈指针往下挪N字节；用完再ADD SP, SP, #N还回去。

一个典型的栈帧长这样：

在ARM64里有个不成文的习惯：每个栈帧的开头（即低地址端）先保存x29和x30，这样栈就形成了一条"链表"——通过x29指向上一层的x29，就能在调试器里一眼看出完整的调用链。这也是为什么调试时你能在GDB里输入bt（backtrace）看到"main 调用了 factorial，factorial 又调用了 factorial……"的完整回溯，本质就是顺着x29链遍历栈。

很多新手学递归的汇编实现，上来就看代码，结果被那一堆STP、LDP、SUB SP搞晕了。我建议你先在纸上画一画栈布局：一个长方形代表栈空间，栈顶在下，栈底在上，SP指针从下往上移动。每一层递归调用压入一个新的栈帧，就像一个盘子摞一个盘子，最上面（最低地址）永远是最新那层。等递归到最深层开始逐层返回时，栈帧按相反顺序一个个弹出销毁。这个"摞盘子"的图景一旦建立起来，后面读汇编代码会顺畅很多。

2.3 为什么不能用寄存器一传到底

有一个很自然的疑问：递归函数每层的参数和局部变量，能不能就用普通寄存器来存？比如算阶乘，每一层调用的n值不同，我每次进来先把n放到x19寄存器里，下一层来了再覆盖，行不行？

答案是不行。原因很简单：当你在第3层递归里计算到一半，程序要跳去执行第4层调用时，第3层的数据只是"暂时不用"，并没有"彻底消失"。等第4层返回后，第3层还要接着用之前那些值继续计算。如果第3层的数据被第4层直接写进了同一个寄存器，那么第4层返回之后，第3层就什么都不剩了。这就好比你工作到一半把文件放在了办公桌上，结果来了个同事，直接拿你的文件擦桌子了。

所以每一层递归的局部数据必须放在各自的栈帧里，这就是"每一层有自己的独立现场"的物理含义。理解这点之后，我们再来看具体的递归函数实现——你将会看到，整个实现的骨架无非就是"进入函数时保存现场，调用自己之前保存该保存的，返回之前恢复现场"这三件事的循环。

3. 实战案例一：阶乘的递归实现（ARM64）

3.1 从高级语言到汇编：翻译思路

阶乘是最经典的递归入门题：fact(n) = n * fact(n-1)，当n <= 1时返回1。先用C语言写一遍：

c复制long fact(long n) {
    if (n <= 1) {
        return 1;
    }
    return n * fact(n - 1);
}

翻译成汇编的思路分三步走：

1. 处理边界条件：判断n是否小于等于1，如果是，直接返回1；否则继续递归步骤。
2. 准备递归调用的参数：把n-1放进x0，调用fact。
3. 收到返回值后计算：递归返回后，x0里是fact(n-1)的值，拿它和本层的n相乘，结果放回x0，然后返回。

听起来简单，但有个关键问题：第3步要用到本层的n，可本层的n存放在哪里？如果直接放在某个寄存器里，那执行第2步的递归调用时，这个寄存器会被内层调用冲掉。所以必须在调用自己之前，先把本层的n存到栈上。

3.2 完整代码逐行拆解

下面是ARM64汇编的完整实现（GAS语法，适用于as汇编器）：

armasm复制    .text
    .globl fact
    .type fact, %function
fact:
    // 保存x29（帧指针）和x30（返回地址）到栈上
    stp x29, x30, [sp, #-16]!
    mov x29, sp

    // 参数n在x0里，先检查边界条件
    cmp x0, #1
    b.le .Lfact_base    // 如果 n <= 1，跳转到基准情形

    // 递归情形：需要保存本层n到栈上
    str x0, [sp, #-16]!    // 把x0（本层n）压栈，同时sp减16

    // 计算 n-1 并递归调用
    sub x0, x0, #1
    bl fact

    // 恢复本层n
    ldr x1, [sp], #16    // 从栈中弹出n，同时sp加16

    // 计算结果：x0 = n * fact(n-1)
    mul x0, x1, x0

    // 恢复x29和x30
    ldp x29, x30, [sp], #16
    ret

.Lfact_base:
    // 基准情形：返回1
    mov x0, #1
    ldp x29, x30, [sp], #16
    ret
    .size fact, .-fact

这段代码不长，但信息密度很大。我逐块解释一下：

第一块：函数序言（Prologue）

armasm复制    stp x29, x30, [sp, #-16]!
    mov x29, sp

STP是ARM64里一个非常实用的指令：一次存两个寄存器到内存。[sp, #-16]!的!表示"先更新sp，再用更新后的sp作为地址"，这叫做前变址寻址。展开来就是：先把sp减16，然后把x29和x30分别存到sp+0和sp+8位置。这样一来，栈上就有了一块属于本函数的栈帧空间，帧指针也在，返回地址也保住了。

mov x29, sp是把帧指针指向当前栈帧的起始位置。这样后面不管是调试还是手工写代码，都可以用x29加上偏移量来访问栈上的数据。

第二块：边界条件判断

armasm复制    cmp x0, #1
    b.le .Lfact_base

CMP做减法但不保存结果，只更新标志位。B.LE（Branch if Less than or Equal）根据标志位判断，如果x0 <= 1就跳转。这就是高级语言里if (n <= 1)的直译。

第三块：保存本层n

armasm复制    str x0, [sp, #-16]!

这里没有用STP，因为只需要保存一个寄存器。str x0, [sp, #-16]!的语义是：先把sp减16，再把x0的值存到sp指向的地址。注意这里其实白占了16字节——实际上只用了8字节来存n，另8字节是空的。这样写是为了保持16字节对齐，ARM64指令集要求SP始终16字节对齐，后续我们细说。

第四块：递归调用

armasm复制    sub x0, x0, #1
    bl fact

SUB x0, x0, #1把x0减1，此时x0里装着递归调用的参数n-1。BL fact调用自身。进入内层函数前，内层函数会再次执行它的序言，把内层的x29、x30压栈。要注意：当我们执行内层调用时，本层的x30（也就是外层函数的返回地址）已经被保存在本层栈帧里了，所以就算内层用BL覆盖了x30，也没关系——等内层返回时，会通过RET跳回这里，而本层返回时，会从自己的栈帧里恢复原来保存的x30。

第五块：恢复和计算

armasm复制    ldr x1, [sp], #16
    mul x0, x1, x0

内层函数返回后，x0里是fact(n-1)的结果。此时本层的n还压在栈上，用LDR x1, [sp], #16把它弹出来放到x1。[sp], #16是后变址寻址：先用sp当前值作为地址取数据，再sp加16还原栈空间。然后MUL x0, x1, x0做乘法，结果覆盖x0。

第六块：函数尾声（Epilogue）

armasm复制    ldp x29, x30, [sp], #16
    ret

LDP一次弹回两个寄存器，x29、x30都被恢复成进入函数之前的值。RET指令用x30里的地址跳转回去。对于基准情形，也一样要恢复x29、x30再返回，只是返回的临时结果直接设成1。

3.3 为什么必须用STP保存x29和x30而不是分开存

写汇编的时候你会注意到，几乎所有ARM64函数序言都是STP x29, x30, [sp, #-16]!这一条指令，极少有人用两条STR分别存。这背后有性能和内存访问两方面的原因。

从指令数量上看，一条STP搞定两个寄存器的存储，比两条STR少一条指令，代码更紧凑。从硬件实现上看，ARM64的存储流水线对连续的16字节对齐存储做了优化，STP在多数微架构上可以单周期完成，并且一次性完成两条存储不会产生额外的总线事务开销。反过来，LDP也是类似。所以在ARM64上，"一对寄存器一起存取"是常态，单独搞反而会被认为是不懂架构的写法。

另外，STP x29, x30这个顺序也不是随便定的。ARM64 ABI规定，栈帧中x29在低地址、x30在高地址。这样安排的深层原因是，通过x29的值，调试器可以在目标内存地址处读取"上一层的x29"，再顺着地址找到更上一层，从而重建整个调用链。如果顺序反了，调试器和栈回溯工具就全乱了。

3.4 为什么栈指针要16字节对齐

我在上面特意写了str x0, [sp, #-16]!而不是str x0, [sp, #-8]!。很多初学者第一反应是：只存一个8字节的long型，减8字节不就行了，减16不是浪费吗？

理论上是够用，但ARM64在架构层面做了一条硬性规定：在任何一条使用SP作为基址的指令中，SP的值必须保持16字节对齐，否则会产生非法指令异常。这条规则的存在是为了配合SIMD（单指令多数据流）的128位加载存储指令——那些指令要求16字节对齐才能获得最佳性能，而编译器为了保证生成的代码能安全使用这些指令，干脆强制所有函数都维护16字节对齐的栈。

所以那句"浪费8字节"在ARM64里根本不是一个选项。记住这个规则，在你手工写汇编的时候能少踩很多坑。

4. 实战案例二：斐波那契数列——多分支递归的栈使用

4.1 为什么选斐波那契当作第二个案例

阶乘是单路径递归——每一层只往下调一次，逻辑相对简单。斐波那契数列就不一样了：fib(n) = fib(n-1) + fib(n-2)，每一层要递归调两次自己，一个函数展开之后像一棵树一样蔓延开。这在汇编里的难点在于：第一次递归调用返回后，拿到的是fib(n-1)的结果，这个结果需要在第二次递归调用期间也继续保留，所以必须把它压到栈里；第二次调用返回后，再把两个结果相加。

这个案例特别能检验你有没有真正理解"每一层调用有独立栈帧"这句话。因为同一个函数会在同一时刻存在多个活跃调用，每个活跃调用都压了一个栈帧，而栈帧里的内容彼此独立、互不干扰。看懂了斐波那契的汇编实现，你对栈的认知基本就到位了。

4.2 完整实现与关键差异点

armasm复制    .text
    .globl fib
    .type fib, %function
fib:
    // 函数序言：保存x29和x30
    stp x29, x30, [sp, #-16]!
    mov x29, sp

    // 边界条件：if (n <= 1) return n
    cmp x0, #1
    b.le .Lfib_base

    // 递归情形：保存本层n和之后要用的寄存器
    str x19, [sp, #-16]!    // 保存x19到栈，腾出x19给本层用
    mov x19, x0            // x19 = n（本层的n在后续递归中要保留）

    // 第一次递归调用 fib(n-1)
    sub x0, x19, #1
    bl fib

    // 把 fib(n-1) 的结果保存到栈上，为第二次递归腾出x0
    str x0, [sp, #-16]!    // 保存fib(n-1)结果

    // 第二次递归调用 fib(n-2)
    sub x0, x19, #2
    bl fib

    // 恢复 fib(n-1) 的结果到x1
    ldr x1, [sp], #16

    // 恢复本层n到x19，然后恢复x19
    // 注意顺序：先恢复x19的原始值，再归还栈空间
    add x0, x0, x1        // x0 = fib(n-2) + fib(n-1)
    ldr x19, [sp], #16    // 恢复x19

    // 函数尾声：恢复x29和x30
    ldp x29, x30, [sp], #16
    ret

.Lfib_base:
    // 基准情形：return n（即返回参数本身）
    // 注意这里不能直接ret，必须先恢复x29和x30
    ldp x29, x30, [sp], #16
    ret
    .size fib, .-fib

这段代码的模式其实和阶乘一脉相承，但多了两个新东西。

第一个新东西是使用x19这种"被调用者保存寄存器"。 我在前面说过，x19是callee-saved寄存器——你的函数如果要使用它，在这个函数被调用期间必须保存原值并在返回前恢复。为什么这里不能直接用x0或者x1来保存本层n？因为x0和x1是caller-saved的，内层函数调用回来之后，它们的内容大概率已经被改掉了，根本不可依赖。而x19是被调用者保存的，内层函数必须保证返回时x19的值和调用前一样，所以在整个递归过程中，x19的安全性是有保障的。这就是ABI设计的意义所在：你不需要在每一层调用里都反复保存x19，只需要在整个函数入口保存一次、函数出口恢复一次即可。

虽然使用了x19，但在递归调用前我们还是要保存它到栈上——这是因为本函数在使用x19之前，x19里装的是外层函数（或者调用者）传下来的值，我们无权破坏。所以函数的序言里没有保存x19，但在真正使用了x19之前，先把它压栈。这段设计的理解如果卡住了，就回到"每一层都要保存现场"这个原则上去想。

第二个新东西是fib(n-1)的中间结果也必须压栈。 第一次bl fib返回后，结果放x0。此时马上要发起第二次递归调用bl fib，而第二次调用会重新往x0里写入新参数n-2，再把返回结果写到x0——所以第一次的结果在x0里根本待不住。解决的办法就是先把第一次的结果压栈，等第二次调用返回后再弹出来相加。

4.3 x86_64下的对照实现

如果你是x86_64平台（绝大多数PC），上面的ARM64代码虽然逻辑清晰，但没法直接在机器上跑。这里给一份x86_64 AT&T语法的对照代码，方便你对比两种架构在函数调用规则上的不同：

asm复制    .globl fib
    .type fib, @function
fib:
    pushq %rbp
    movq %rsp, %rbp
    pushq %rbx
    movl %edi, %ebx        # ebx = n
    cmpl $1, %edi
    jle .Lfib_base
    leal -1(%rdi), %edi    # 参数 = n-1
    call fib
    pushq %rax             # 保存 fib(n-1) 结果到栈
    leal -2(%rbx), %edi    # 参数 = n-2
    call fib
    popq %rcx              # 恢复 fib(n-1) 结果到rcx
    addq %rcx, %rax        # 结果 = fib(n-2) + fib(n-1)
    jmp .Lfib_done
.Lfib_base:
    movl %ebx, %eax        # 返回 n
.Lfib_done:
    popq %rbx
    popq %rbp
    ret
    .size fib, .-fib

两台架构的主要差异点有四条，值得单独记一下：

x86_64的call指令会把返回地址压到栈上，ret再从栈上弹出——所以x86_64天然把返回地址放在了栈帧里，不太需要显式保存。ARM64则使用x30这个专用寄存器，效率更高，但也因此要求每个函数必须自己保存x30。这就是为什么你在ARM64汇编里几乎每个函数都有stp x29, x30的样板代码。两种设计各有考量：x86_64的"自动压栈"给了调试器更简单的栈回溯方式，ARM64的"链接寄存器"减少了内存访问次数、提升了指令流水线效率。

5. 递归汇编的常见崩溃现场与排查技巧

5.1 出现segfault却不知道崩溃在哪

写递归汇编最容易遇到的第一个问题就是：一运行就段错误，GDB定位到崩溃地址，却发现那里的指令本身没有问题。这个时候你要优先怀疑两个东西：栈是不是被写穿了，x30是不是被错误覆盖了。

排查步骤我建议固定这样：

1. gdb ./a.out进入调试器。
2. b fib在函数入口打一个断点。
3. run运行，程序第一次进入fib时中断。
4. bt看调用栈，栈应该只有一层。
5. 继续运行，当递归进行多轮之后，再输入bt，检查栈的层数是否和你预期的递归深度一致。
6. 如果bt输出的是乱七八糟的地址，十有八九是你的某个LDR/STR压栈弹出不对称，把栈顶搞乱了。

一个非常典型的错误是：序言里用stp x29, x30, [sp, #-16]!压入16字节，但尾声里只弹回了8字节——比如误写了ldr x30, [sp], #8就ret。这样SP没有恢复原状，下一次调用或者返回的时候，访问的地址就全偏了，最终导致各种离奇的崩溃。我的建议是：序言和尾声保持严格的镜像对称，你用一条指令压的，就用同一条指令弹回来。 这是最不容易出错的做法。

5.2 无限递归：边界条件写错了

无限递归是最考验耐心的错误。代码本身不崩溃，但程序永远跑不完，最后把栈空间耗光，报一个栈溢出。这个错误通常出在边界条件的比较上。

ARM64里有一个特别容易踩的坑：比较指令用的是b.le还是b.lt。在编写费波那契的基准判断时，如果你写的是cmp x0, #1; b.lt .Lfib_base，那等于说n == 1时会继续递归调用fib(0)和fib(-1)，而不是直接返回——看起来也没什么问题，fib(0)和fib(-1)会继续往下走，直到负数越来越小，永远不会碰到n < 1这个条件，于是无限递归爆发。这种低级错误往往藏得很深，因为单看逻辑也能执行，只是结果不对而已。

一个小技巧：调试这种问题时，给参数设一个小一点的入口值，比如直接传入4或5；然后在每个递归分支的入口打印参数。怎么打印？最简单的方式是在汇编里调用C库的printf（记得把x0当格式化字符串，x1当参数），或者干脆先在入口处修改x0的值然后在GDB里观察。更极端的情况下，直接在入口放一个死循环断点，逐层观察参数的变化规律。

5.3 保存了却没恢复，或者恢复顺序不对

递归汇编里另一类高频bug是寄存器恢复顺序错误。比如你栈上按顺序压了x19、x30、x29，弹栈的顺序就必须反过来：先弹x29，再弹x30，最后弹x19。如果你先弹x19，拿到的就是x29的旧值，数据完全错位。这个错位不会立即导致崩溃，但接下来算出的结果是荒谬的，排查起来极其浪费时间。

一个靠谱的防御性写法是：在写序言的时候，随手注释掉对应的尾声。比如写了stp x29, x30, [sp, #-16]!，就在函数结尾先写好对称的ldp x29, x30, [sp], #16。后面再往序言里加新的压栈，同样先加好对称的弹栈代码。用"对称"两个字维护栈的压弹一致性，亲测有效。

还有一个关于mov x29, sp的细节：x29一旦确定，后面访问栈上保存的数据都应该以x29为基准，而不是以sp为基准。为什么？因为在一个函数内部，sp可能会随着压栈弹栈操作不断变化。如果你用sp加偏移去取数据，用着用着sp变了，偏移就得跟着改；而x29在整个函数生命周期里是不变的，用[x29, #-8]这样的寻址方式，永远不会受到sp变化的影响。这就是帧指针存在的意义。

5.4 优化问题：开了优化之后递归崩了

另一个有趣的现象：同一个递归函数，用-O0编译运行好好，用-O2就被优化坏了。这通常不是编译器的问题，而是你的汇编违反了ABI约定。最常见的情况是：你用了x19但没保存，或者你假设某块栈空间的内容在函数调用之后仍然有效——但实际上编译器做栈复用，已经把你的数据覆盖了。

在写汇编时，请把ABI当成硬性法律来遵守，不要有任何侥幸心理。哪怕你当前写的代码恰好没有冲突，换一个调用场景、换一个优化等级，问题就暴露出来了。我个人的经验是：入门阶段用-O0调试，彻底跑通逻辑后再用-O2验证一遍，两遍都过了才算真的写对。

6. 递归到迭代：从手写栈到避免灾难

6.1 深深深地不妥：栈溢出不是讨论出来的

递归虽然代码优雅，但在汇编层面有一个物理极限：栈空间是有限的。Linux默认的栈大小通常是8MB，每个栈帧就算只占32字节，理论上最多也只有25万层左右。实际运行中，程序还有其它函数调用也占栈空间，一个递归深度达到几十万的函数，大概率直接把栈顶到栈底之间所有空间耗尽。

我记得有一次写一个目录遍历的递归程序，在测试环境跑得好好的，到生产环境数据一多就直接崩溃。排查了半天，问题出在递归深度上——生产环境的目录嵌套层次比测试环境深得多，栈耗尽之前，程序根本没有任何预兆，等到栈溢出时，程序连报错的机会都没有。

这种场景在实际工程里不是"纸上谈兵"：任何需要处理深度嵌套结构的情况，比如遍历JSON树、XML树、文件系统目录树，都可能触到这个极限。这也是为什么在系统编程领域，"把递归改写成迭代"是一项非常重要的基本功。

6.2 用显式栈模拟递归

把递归改迭代的通用思路是：既然递归依赖系统栈来保存每层状态，那我们自己开一块堆内存来做同样的工作。每次进入一层"调用"，就相当于往自定义栈里压入一个结构体，里面保存原本要保存在系统栈上的数据和返回地址；每次"返回"就弹栈恢复状态。

以阶乘为例，用C语言风格的伪代码来展示手写栈版本：

c复制// 用显式栈模拟 fib 的递归过程
long fib_iterative(long n) {
    if (n <= 1) return n;
    
    // 定义"栈帧"结构：保存到第几层、以及这一层的计算结果
    typedef struct {
        long n;
        long value;
        int state;   // 0=刚进入, 1=第一次递归已完成, 2=第二次递归已完成
    } Frame;
    
    Frame stack[1024];
    int top = 0;
    
    stack[top++] = (Frame){n, 0, 0};
    long result = 0;
    
    while (top > 0) {
        Frame* f = &stack[top - 1];
        
        if (f->n <= 1) {
            f->value = f->n;
            top--;  // 弹出这一帧
            if (top > 0) {
                // 把结果交给下一层
                stack[top - 1].value = f->value;
            } else {
                result = f->value;
            }
            continue;
        }
        
        if (f->state == 0) {
            f->state = 1;
            stack[top++] = (Frame){f->n - 1, 0, 0};  // 模拟 fib(n-1)
        } else if (f->state == 1) {
            long v1 = f->value;
            f->state = 2;
            stack[top++] = (Frame){f->n - 2, 0, 0};  // 模拟 fib(n-2)
        } else {
            // 两个递归都完成了
            long v1 = f->value; // 实际此时v1应保存，这里简化
            f->value += v1;
            top--;
            if (top > 0) {
                stack[top - 1].value = f->value;
            } else {
                result = f->value;
            }
        }
    }
    return result;
}

上面的伪代码只是展示了状态机的思路，实际工程里会写得比这个更精练。但你应该看出来了：手写栈的本质，是把"系统隐式帮你维护的调用状态"变成"你显式维护的数据"。好处是栈放在堆上，容量可以动态扩容，不再受系统栈大小的限制；坏处是代码复杂度直线上升，可读性变差，而且完全失去了利用函数调用边界的自然语义。

所以这里有一个工程判断：递归深度浅、逻辑简单的场景，直接用汇编递归完全没问题；递归深度可能很深、或者对性能极其敏感的场景，优先考虑迭代。 不要为了"用递归而用递归"。

6.3 尾递归：一个值得留意的特殊情况

还有一种折中的优化叫尾递归优化（Tail Call Optimization，TCO）。如果递归调用发生在函数的最后一条指令且返回值不需要再参与任何运算，那么编译器可以复用当前栈帧，而不用一层层压栈。比如fact(n, acc) = fact(n-1, n*acc)这种写法就是典型尾递归。

ARM64对尾递归的处理很优雅：尾调用直接用B指令跳转，而不是BL。因为不再需要保存新的返回地址，反正返回地址已经在x30里了，调用者本来就要返回到同一个地址。用B代替BL，跳过去的时候不会修改x30，在跳转之前把当前栈帧清理干净，目标函数会建立自己的新栈帧——这样整个递归过程只有一个栈帧在反复使用，空间复杂度从O(n)降到了O(1)。

如果你打算用汇编写递归，我强烈建议你在理解普通递归之后，专门研究一下尾调用优化。它不仅能让你写出更高性能的代码，也能加深你对"系统如何管理栈"的理解。

7. 从阶乘到真实工程：递归汇编的生存法则

最后我们再从"课本案例"回到"现实世界"。写阶乘、斐波那契的递归，核心是学会"保存现场-递归调用-恢复现场"的骨架。但真实工程里的递归远没有这么简单，我梳理了几条实用的生存法则：

法则一：进入函数先写序言，越早越好。 只要你在函数里不用x19-x28或者不需要保存x30，哪怕只有一行逻辑，都可以先写好stp x29, x30, [sp, #-16]!和mov x29, sp。这样后面每增加一个分支，都不需要回头补序言，也能保证调试时有完整的调用链。

法则二：需要保存的寄存器，在可能被覆盖之前就保存。 判断标准很简单：一个寄存器的值在当前函数后续逻辑中还会用到，而你又马上要调用另一个函数，那就先保存它。宁可多存，不要少存。存多了最多浪费点栈空间，存少了直接数据错乱。

法则三：用注释管理栈帧布局。 在函数头部写清楚当前栈帧的布局图，比如：

armasm复制// Stack layout:
// [sp+16] -> saved x19
// [sp+8]  -> saved x30
// [sp+0]  -> saved x29

当你遇到问题回头看代码时，这个注释能省你大量推算时间。很多人觉得加注释没必要，这是典型的新手思维——汇编代码的注释成本极低，但调试收益极高。

法则四：优先写C的递归，再用反汇编验证。 如果你是刚入门汇编，最有效的学习方式是把C语言写的递归用编译器编译出来，再配合objdump -d或GDB的disassemble /m查看编译器生成的汇编。你不一定完全模仿编译器的做法，但看编译器如何保存和恢复寄存器、如何安排栈帧布局，是最好的实战教材。比你直接手写一堆汇编然后调半天要快得多。

法则五：性能敏感场景别用递归。 递归的每一次函数调用都有固定的开销：压栈、弹栈、跳转、恢复。在现代处理器上，这些开销虽然微小，但在一层层叠加起来之后，性能损失还是相当可观的。处理大量数据的场景，能写成循环就写循环；必须用递归的话，优先考虑尾递归形式或者手写栈迭代。

回头想想，递归在汇编里的本质其实一点都不神秘：它只是"调用函数"这个机制在极端情况下的一种自然产物。如果你能把普通的函数调用汇编看得明明白白——参数怎么传、返回地址怎么保存、栈帧怎么建立销毁——那么递归不过就是"同一个函数重复执行这套流程"而已。我见过不少学汇编的人卡在递归这一节，其实大多不是卡在"递归"，而是卡在"函数调用机制"本身没有彻底吃透。

建议你先别看这篇文章的最后几个章节，回去把调试器打开，亲手写一个简单的非递归函数（比如两个数相加），单步执行，观察BL跳转前后x30、sp的变化。把这一步做实之后，再回来写阶乘和斐波那契，你会发现一切都是水到渠成。汇编的学习没有捷径，最有价值的路径永远是"读代码-改代码-单步调试-撞错-再改"。递归这个知识点，尤其如此。