想象你走进一家高级西餐厅：前厅经理熟练地记录客人需求，后厨大厨用最精妙的手艺完成烹饪。经理不会颠勺，大厨不擅长待客，但餐厅照样高效运转——靠的是一套行云流水的“交接仪式”：经理把点餐单放进上菜窗口，大厨按单出菜，再把成品放回窗口。 这正是C与汇编混合编程的日常。C语言是那位“经理”：可读性好，适合写业务逻辑和算法框架；汇编语言是“大厨”：能精确控制每条指令、每一字节内存，把性能榨干。两者难免要互相“递单子”——C函数调用汇编函数，汇编函数也调用C函数。 试想，如果经理写单子用中文，大厨只认英文，餐厅早就关门了。所以两者之间必须有一份“默契的交接规范”：参数放哪里、返回值放哪里、谁负责收拾工具、栈空间怎么划分。这份规范叫作 ABI（应用二进制接口）。理解它，就理解了两种语言无缝协作的全部秘密。这篇文章就用“餐厅交接仪式”这个画面，带你从零看懂C与汇编的互调用。

岗位关联

掌握C与汇编互调用，是AI推理加速、嵌入式优化、底层框架开发的核心技能，能让你把AI模型运行时的性能瓶颈真正握在自己手里。

目录
  1. 可视化演示
  2. ABI调用约定
  3. 寄存器保存规则
  4. C调用汇编
  5. 汇编调用C
  6. 栈帧与对齐
  7. 全局变量共享
  8. 工程优化策略
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示C与汇编混合编程核心机制：C调汇编模式展示ABI参数传递（x0-x3寄存器）与返回值约定，汇编调C模式展示extern符号导入、链接器跨文件解析与栈帧对齐匹配过程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

C调用汇编与ABI参数传递 C代码通过函数调用汇编，参数通过x0-x7寄存器传递遵循AAPCS ABI 返回值通过x0寄存器传回C调用方 C: r=asm_fn(a,b); ASM: func: ... RET 需匹配栈帧对齐（16字节）和寄存器保存规则（X19-X30需保护）。

ABI调用约定

餐厅后厨有一面墙，墙上有六个标准“上菜窗口”。经理下单时，第一道菜放1号窗口，第二道放2号窗口……大厨只按编号取菜。如果经理把前菜塞进3号窗口，哪怕菜再好吃，大厨也会按规矩从1号窗口取到完全不相干的一道菜。

ABI（应用二进制接口）就是这面“窗口墙”。它规定了函数调用的一切二进制细节：参数放哪些寄存器、返回值放哪里、栈怎么管理。在64位Linux/Unix世界，主流是System V AMD64 ABI。编译器与汇编器各自生成目标文件，只要双方都遵循同一ABI，就能像餐厅窗口一样严丝合缝地配合。

具体到整型参数，前4个参数寄存器依次是RDI、RSI、RDX、RCX，第5、第6个是R8、R9，从第7个起才压入栈。浮点参数走XMM0~XMM7，整型返回值放RAX。汇编里写函数、C里调用，只要按约定摆好参数，彼此无需知晓对方内部实现。

asm_func(a,b,c,d)  →ABI  {RDI←aRSI←bRDX←cRCX←d\displaystyle \text{asm\_func}(a,b,c,d)\;\xrightarrow{\text{ABI}}\;\begin{cases}\text{RDI} \leftarrow a \\\text{RSI} \leftarrow b \\\text{RDX} \leftarrow c \\\text{RCX} \leftarrow d\end{cases}
这段公式表示：C调用汇编函数 asm_func 时，编译器自动把前4个整数参数分别放入 RDI/RSI/RDX/RCX 四个寄存器，汇编函数从这些寄存器中取参数即可。
  1. 函数符号asm_func 是C代码中声明的外部函数，汇编文件中必须存在同名全局符号，ABI 依靠符号和寄存器两个层面完成对接。
    asm_func\displaystyle \text{asm\_func}
  2. 第一参数a 被放入 RDI，这是第一个整数参数寄存器，相当于经理把第一道菜放到1号窗口。
    RDI←a\displaystyle \text{RDI} \leftarrow a
  3. 第二参数b 放入 RSI，第二个整数参数寄存器，对应2号窗口。
    RSI←b\displaystyle \text{RSI} \leftarrow b
  4. 第三参数c 放入 RDX，第三个整数参数寄存器。
    RDX←c\displaystyle \text{RDX} \leftarrow c
  5. 第四参数d 放入 RCX，第四个整数参数寄存器。
    RCX←d\displaystyle \text{RCX} \leftarrow d
  6. 返回值约定函数结束时，汇编把整型结果写入 RAX，C代码再从 RAX 读取，一个完整的“出菜—取菜”闭环就此完成。
    asm_func(a,b,c,d)⇒RAX←返回值\displaystyle \text{asm\_func}(a,b,c,d) \Rightarrow \text{RAX} \leftarrow \text{返回值}

寄存器保存规则

大厨切菜时，常借经理桌上的便签纸记临时数字。经理很聪明：他知道大厨用完便签纸可能随手一扔，所以递出之前，自己会把重要内容抄进兜里。但有一类东西例外——大厨自己的菜刀，用完必须擦净放回刀架，否则下一道菜就没法做。

寄存器也分这两种性格。调用者保存寄存器（caller-saved，如RAX、RCX、RDX、RSI等）是“便签纸”：汇编函数可以随意使用，但C编译器在调用前若还在意这些值，会自行保存。被调用者保存寄存器（callee-saved，包括RBX、RBP、R12~R15）是“菜刀”：一旦汇编函数要借用，就须在入口压栈保存，返回前恢复原值。若大厨用了菜刀不还，主厨继续切菜时就会发现刀具不对——变量悄然改变，程序逻辑错乱且极难排查。

这条规则不是建议，而是ABI的硬性法律。违反它的后果从“局部变量灵异变化”到“函数返回时跳飞到非法地址”都有可能。用反汇编工具查看崩溃现场的调用栈，往往能在寄存器值里找到线索。

callee-saved: RBX,  RBP,  R12∼R15caller-saved: RAX,  RCX,  RDX,  RSI,  RDI,  R8∼R11\displaystyle \text{callee-saved: } RBX,\;RBP,\;R12\sim R15 \qquad \text{caller-saved: } RAX,\;RCX,\;RDX,\;RSI,\;RDI,\;R8\sim R11
被调用者（汇编函数）负责保存 RBX/RBP/R12~R15；调用者（C编译器）负责保存其余寄存器。谁用谁保管，各司其职。
  1. 被调用者保存组RBX、RBP、R12~R15 这组寄存器由被调用的汇编函数负责保存和恢复，相当于大厨的菜刀。
    callee-saved: RBX,  RBP,  R12∼R15\displaystyle \text{callee-saved: } RBX,\;RBP,\;R12\sim R15
  2. 调用者保存组RAX、RCX、RDX、RSI、RDI、R8~R11 由调用方按需自行保存，相当于经理的便签纸。
    caller-saved: RAX,  RCX,  RDX,  RSI,  RDI,  R8∼R11\displaystyle \text{caller-saved: } RAX,\;RCX,\;RDX,\;RSI,\;RDI,\;R8\sim R11
  3. 波浪号语义R12~R15 表示从 R12 到 R15 的连续4个寄存器，在汇编指令中需逐个列全。
    R12,  R13,  R14,  R15\displaystyle R12,\;R13,\;R14,\;R15
  4. 责任分界两组的划分让双方都知道哪些值可放心覆盖、哪些必须保护，避免互相推诿导致现场崩溃。
    RBX∈callee-saved\displaystyle RBX \in \text{callee-saved}

C调用汇编

经理发现招牌菜需要大厨独家手艺，于是写了一张“外包单”：备注“这道菜全部交给大厨做”。大厨也把自己的拿手菜挂上“招牌菜”的牌子。餐厅管理系统只要看到这两个标记，就能把订单准确送进后厨。

C调用汇编函数就是这张“外包单”：C文件里用 extern 声明函数存在，汇编文件里用 .globl 把函数符号导出。extern 的意思是“我知道这道菜存在，后厨有人会做”；.globl 的意思是“我把这道菜挂上公共菜单，谁都能点”。链接器像餐厅调度系统，把所有“点了这道菜”的外部引用和“挂出这道菜”的全局定义一一匹配。

编译命令也很典型：先用 gcc -c 把C文件编译成目标文件（.o），再用汇编器把汇编文件汇编成目标文件，最后用链接器合成可执行文件。链接期间，extern 引用与 .globl 定义在符号表中碰头，替换成同一个函数入口地址。如果只声明不定义，链接器就会报“未定义引用”错误——相当于点了菜单上的菜，后厨却没人会做。

.globl asm_func⏟汇编导出⟺extern int asm_func(int);⏟C声明\displaystyle \underbrace{\text{.globl asm\_func}}_{\text{汇编导出}} \quad \Longleftrightarrow \quad \underbrace{\text{extern int asm\_func(int);}}_{\text{C声明}}
汇编用 .globl 导出函数符号，C 用 extern 声明导入。二者名称一致时，链接器便可将调用绑定到同一个函数地址。
  1. .globl asm_func在汇编文件里用 .globl 把符号标记为全局，链接器才能在其他目标文件中看到它。
    .globl asm_func\displaystyle \text{.globl asm\_func}
  2. extern int asm_func(int)C 文件里声明 extern，告诉编译器“这个函数存在，但定义在别处”。
    extern int asm_func(int);\displaystyle \text{extern int asm\_func(int);}
  3. 等价箭头左右两边通过同名符号在链接期绑定，C代码中的调用最终跳转到汇编指令序列。
    ⟺\displaystyle \Longleftrightarrow
  4. 返回类型匹配int 类型与 ABI 中“整数返回值放 RAX”的约定呼应，双方都从 EAX/RAX 中读写结果。
    int↔RAX\displaystyle \text{int} \leftrightarrow \text{RAX}

汇编调用C

晚市后，大厨需要核算当天食材成本。他不会做账，但知道经理有套现成的算账系统。于是大厨走向经理办公室，按“跨部门协作流程”提交申请：先把要算的账目放到指定位置（寄存器），再按铃请求（call 指令）。经理算完把结果放进“取件箱”（RAX），大厨取走。

汇编调用C函数，本质完全一样。汇编代码里用 extern 声明（或直接引用）C函数名，按 ABI 把参数摆到寄存器或栈上，执行 call 指令；C函数执行完毕返回，返回值位于 RAX（或其低32位EAX）。关键三件事：准备参数、发起调用、提取结果。

一个常见坑是：call 指令会自动把“返回地址”压入栈中，这会改变 RSP 的偏移。因此调用前必须确认栈已按调用约定对齐——否则进入C函数后，编译器一用 SSE 指令访问栈数据就可能崩溃。这个坑在下一节会重点展开。

movl $1,  %edi;call   c_func;movl %eax,  result\displaystyle \text{movl } \$1,\;\%\text{edi} \quad;\quad \text{call } \;\text{c\_func} \quad;\quad \text{movl } \%\text{eax},\; \text{result}
汇编把第一个参数放入 EDI，call 调用C函数，C函数 return 的整数放在 EAX 中，汇编再把 EAX 取出存到自己的变量里。
  1. 参数准备movl $1, %edi 把整数1（第一个参数）放入 EDI——正是 ABI 规定的第一个整数参数寄存器。
    movl $1,  %edi\displaystyle \text{movl } \$1,\;\%\text{edi}
  2. 发起调用call c_func 把返回地址压栈，同时跳转到 C 函数入口。
    call   c_func\displaystyle \text{call } \;\text{c\_func}
  3. 提取返回值movl %eax, result 从 EAX 寄存器取回 C 函数的返回值；EAX 是 RAX 的低32位，C函数返回 int 时写的就是它。
    movl %eax,  result\displaystyle \text{movl } \%\text{eax},\; \text{result}
  4. 每条指令一个动作三条指令用分号分隔，分别对应“下单—按铃—取件”三个跨部门协作步骤。
    指令1;指令2;指令3\displaystyle \text{指令1}; \text{指令2}; \text{指令3}

栈帧与对齐

大厨的灶台不是随便搭的：台面必须符合16厘米的模数，锅碗瓢盆有固定摆放格局。经理来后厨检查时，只需按固定位置找厨具。如果大厨临时把台面加高2厘米，所有固定位置的参照都会失效，经理在惯常位置摸个空。

栈帧（stack frame）就是每次函数调用后，在栈上搭出的“专属灶台”。一个典型栈帧从高地址到低地址依次是：局部变量区、保存的旧RBP、返回地址、调用者现场。x86-64 中 RBP 常被当作帧指针，指向保存的旧RBP位置；局部变量通过 RBP-偏移 寻址，参数通过 RBP+偏移 寻址。C编译器生成的函数都遵循这个布局。

更严格的是对齐规则：System V ABI 要求，在 call 指令执行前，RSP 必须是16字节对齐。因为 C 编译器的 SSE 指令（如 movaps）要求16字节对齐的内存操作数，一旦不对齐，直接段错误。汇编里调用 C 函数前若发现 RSP 不对齐，必须用 push/sub 手动调整，调用后再恢复。这条规则平时看不见，一旦违反，程序像地砖错位一样到处卡壳。

栈帧: [局部变量][保存的RBP][返回地址][调用方现场]call 前: RSP mod 16=0\displaystyle \text{栈帧: } \big[\text{局部变量}\big]\big[\text{保存的RBP}\big]\big[\text{返回地址}\big]\big[\text{调用方现场}\big] \qquad \text{call 前: } \text{RSP}\bmod 16=0
栈帧从上到下四个部分；调用 C 函数之前，RSP 必须16字节对齐，这是 ABI 的强制性要求。
  1. 局部变量区函数私有的临时数据，汇编中通过 RBP 负偏移（-4、-8…）访问，相当于大厨的调料盒。
    [局部变量]\displaystyle [\text{局部变量}]
  2. 保存的RBP函数入口把调用者的 RBP 压栈，返回前再从栈上弹出来恢复，链条不能断。
    [保存的RBP]\displaystyle [\text{保存的RBP}]
  3. 返回地址call 指令自动压入，ret 指令弹出后跳回调用点继续执行。
    [返回地址]\displaystyle [\text{返回地址}]
  4. 调用方现场调用者保存某些寄存器时留下的数据，在被调用者看来位于更高地址处。
    [调用方现场]\displaystyle [\text{调用方现场}]
  5. 对齐约束call 之前 RSP 必须是16的倍数，即 RSP mod 16 = 0。
    RSP mod 16=0\displaystyle \text{RSP}\bmod 16=0

全局变量共享

餐厅前台和后厨共用一块白板，上面记着当天贵客的忌口和包厢号码。经理和大厨都能查看、修改，前提是所有人都知道“这块白板挂在餐厅入口处”。

C与汇编之间的全局变量共享，就是这块“公共白板”。汇编文件里可以用 .comm 定义一块未初始化的全局数据，也可以写在 .data/.bss 段；C文件里用 extern 声明引用。两个文件编译成目标文件后，链接器在符号表中找到同一个名字，把两处的地址解析到同一块内存：汇编里写 count，C 里读 count，看到的是同一个变量。

要注意“跨文件”三个字。若汇编里的符号没有用 .globl（.comm 本身是导出的），会被当作局部符号，链接器不会暴露给C文件。反过来，C 的全局变量默认是全局符号，汇编里直接引用名字即可，但最好在汇编文件头部用 .extern 声明意图，提高可读性并让汇编器知道它是外部符号。

.comm count, 4, 4⏟汇编定义全局⟺extern int count;⏟C引用全局\displaystyle \underbrace{\text{.comm count, 4, 4}}_{\text{汇编定义全局}} \quad\Longleftrightarrow\quad \underbrace{\text{extern int count;}}_{\text{C引用全局}}
.comm 在汇编中定义4字节的全局符号 count，C 用 extern 声明引用同一符号，链接器将二者绑定到同一地址。
  1. .comm count, 4, 4在 BSS 段定义名为 count、大小4字节、4字节对齐的全局符号，不占文件空间但占运行内存。
    .comm count, 4, 4\displaystyle \text{.comm count, 4, 4}
  2. extern int countC 中声明外部全局变量，表示“类型为 int 的变量定义在别处”。
    extern int count;\displaystyle \text{extern int count;}
  3. 等价绑定链接器在符号表里发现 count 同时在两处出现，就把 C 代码的引用重定位到汇编定义的那个地址上。
    ⟺\displaystyle \Longleftrightarrow
  4. 全局可见性.comm 生成的符号默认全局可见，所以 C 文件能找到它；若改用局部标签，链接器则不会暴露。
    global⇒visible\displaystyle \text{global} \Rightarrow \text{visible}

工程优化策略

餐厅有了稳定菜品后，新问题来了：哪些菜必须大厨亲手制作（独立汇编），哪些可以经理站在旁边口头指点（内联汇编），哪些干脆用现成调料包（编译器内建函数）？聪明的餐厅会先看数据——哪道菜点单最多、做得最慢，才值得手工精雕细琢。

工程上选择互调用方案的思路同理。独立汇编（单独 .s 文件）适合整个函数都是性能关键路径、需要精确控制每条指令的场景，例如矩阵乘内层循环、加密算法内核；内联汇编（__asm__）适合在C函数中插入少量特殊指令（如原子操作、屏障指令），但可读性和可移植性差；如果编译器提供内建函数（intrinsics），如 SIMD 指令的头文件封装，优先用它，因为编译器能自动做寄存器分配和指令调度，性能接近手写且代码可维护。

无论选哪种方案，调试都依赖工具链：objdump -d 反汇编目标文件检查指令；gdb 可单步进入汇编、用 info registers 查看寄存器、用 x/ 查看内存；性能剖析用 perf 找到热点函数，再决定是否把 C 改写为汇编。接口设计上，互调用的边界要尽量窄：参数清晰、无隐含状态、封装成独立函数而非散落各处的内联片段，这样后续替换成纯C实现或新平台汇编都更容易。

方案={独立汇编函数整体是热点、需精确控指令内联汇编短小特殊指令、可移植性要求低内建函数可移植性优先、性能接近手写\displaystyle\text{方案} =\begin{cases}\text{独立汇编} & \text{函数整体是热点、需精确控指令}\\\text{内联汇编} & \text{短小特殊指令、可移植性要求低}\\\text{内建函数} & \text{可移植性优先、性能接近手写}\end{cases}
三种方案按“热点范围、指令特殊性、可移植性”三个维度选择，本质是在性能与可维护性之间做权衡。
  1. 独立汇编分支热点覆盖整个函数、需要逐指令控制时，用独立 .s 文件，接口保持简洁。
    独立汇编\displaystyle \text{独立汇编}
  2. 内联汇编分支只差几条特殊指令、且能接受平台绑定时，用 asm 嵌入 C 函数。
    内联汇编\displaystyle \text{内联汇编}
  3. 内建函数分支优先考虑跨平台与可维护性时，用编译器 intrinsics，让编译器做寄存器分配。
    内建函数\displaystyle \text{内建函数}
  4. 大括号枚举三个分支以花括号并列，表示这是“按条件选择其一”的决策表。
    {⋯\displaystyle \begin{cases} \cdots \end{cases}

AI 应用场景

端侧AI算子汇编加速

阶段：模型推理优化（部署阶段）

解决的问题：在摄像头、手机等边缘设备上运行人脸检测或声学模型时，卷积和激活函数是最大热点。C语言编译出的代码未必能充分利用 SIMD 并行能力，导致推理延迟超标。C调用汇编的方式，让关键算子能用 NEON/AVX 指令手写，C代码只做数据搬运和封装，充分压低延迟。

具体案例：某智能门锁的3D人脸识别方案中，开发者用 ARM NEON 汇编重写了3×3卷积的内层循环，通过 extern int conv3x3_neon(...) 暴露给 C++ 推理引擎调用。严格按 ABI 对齐参数与返回值后，单层卷积耗时降低约35%，整网推理从 412ms 降到 301ms。

AI训练框架的CPU内核优化

阶段：训练/推理计算内核开发

解决的问题：PyTorch/TensorFlow 的 CPU 算子若纯用 C++ 编写，编译器生成的代码在寄存器利用上仍有提升空间。对于高频小算子，用汇编实现核心循环、由 C/C++ 函数封装调用，能榨取最后一部分性能。

具体案例：为自研的轻量级深度学习框架编写矩阵乘法内核，用 AVX2 汇编实现 8×8 微内核，C++ 外层负责分块调度，接口只暴露 matmul_avx2(float*, float*, float*, int n)。训练实测 loss 收敛速度提升约18%，且代码改动集中在单个文件内，便于维护。

安全推理中的常数时间实现

阶段：安全计算/隐私保护推理

解决的问题：联邦学习与隐私计算中，密钥交换、加密协议需要“常数时间执行”以防侧信道攻击。C编译器可能生成分支依赖数据的指令序列，而手写汇编能精确保证每条指令的执行时间与数据无关，再用 C 封装对外接口。

具体案例：在某隐私求交产品中，模幂运算用汇编实现常数时间版本，C模块通过固定ABI调用，侧信道检测工具全部通过，整体安全等级达到设计目标。

Python 演示

python71 行
class Registers:    """模拟通用寄存器组"""     def __init__(self):        self.gp = {name: 0 for name in [            "RAX", "RBX", "RCX", "RDX", "RSI", "RDI",            "R8", "R9", "R10", "R11", "R12", "R13",            "R14", "R15", "RBP", "RSP"        ]}        self.stack = []     def push(self, value):        self.stack.append(value)     def pop(self):        return self.stack.pop() if self.stack else 0  ABI_INT_ARG_REGS = ["RDI", "RSI", "RDX", "RCX", "R8", "R9"]ABI_RET_REG = "RAX"CALLER_SAVED = ["RAX", "RCX", "RDX", "RSI", "RDI",                "R8", "R9", "R10", "R11"]CALLEE_SAVED = ["RBX", "RBP", "R12", "R13", "R14", "R15"]  def call_asm(regs, args, asm_fn):    """按ABI规则把参数放入寄存器，并保存调用者现场"""    saved = {name: regs.gp[name] for name in CALLER_SAVED}    for name, val in zip(ABI_INT_ARG_REGS, args):        regs.gp[name] = val    ret = asm_fn(regs)    regs.gp.update(saved)    return ret  def asm_add(regs):    """模拟汇编逻辑: RAX = RDI + RSI"""    regs.gp[ABI_RET_REG] = regs.gp["RDI"] + regs.gp["RSI"]    return regs.gp[ABI_RET_REG]  def asm_safe_add(regs):    """模拟汇编中使用被调用者保存寄存器时的保护"""    saved_rbx = regs.gp["RBX"]    regs.push(saved_rbx)    regs.gp["RBX"] = regs.gp["RDI"] + regs.gp["RSI"]    regs.gp[ABI_RET_REG] = regs.gp["RBX"]    regs.gp["RBX"] = regs.pop()    return regs.gp[ABI_RET_REG]  def c_add(a, b, use_safe=False):    """模拟C代码调用汇编函数 add(a, b)"""    regs = Registers()    asm_fn = asm_safe_add if use_safe else asm_add    return call_asm(regs, [a, b], asm_fn)  def stress_test():    """批量调用验证寄存器现场恢复"""    for i in range(100):        r = c_add(i, i + 1, use_safe=True)        if r != 2 * i + 1:            raise RuntimeError("寄存器现场被破坏")    return "寄存器现场恢复验证通过"  if __name__ == "__main__":    print("asm_add(3, 5) =", c_add(3, 5))    print("asm_safe_add(3, 5) =", c_add(3, 5, use_safe=True))    print(stress_test())
目的：用 Python 模拟 System V ABI 的寄存器传参、调用者保存与被调用者保存，演示 C 与汇编互调用的参数传递和现场恢复机制。
  1. ABI_INT_ARG_REGS = ["RDI", "RSI", "RDX", "RCX", "R8", "R9"]定义 ABI 参数寄存器顺序，相当于餐厅的上菜窗口编号。
  2. CALLER_SAVED = ["RAX", ...]列出调用者保存寄存器集合，模拟经理自己要收好的便签纸。
  3. saved = {name: regs.gp[name] for name in CALLER_SAVED}调用前给调用者保存寄存器拍快照，防止汇编函数把它们改坏。
  4. for name, val in zip(ABI_INT_ARG_REGS, args):按 ABI 顺序把实参逐一装进寄存器窗口，对应“放上菜窗口”动作。
  5. regs.gp.update(saved)调用结束后把快照还原，C 代码的世界恢复原样。
  6. regs.push(saved_rbx)汇编函数保护被调用者保存寄存器 RBX，先压栈收藏好，符合“谁用谁还”的厨房规矩。
  7. regs.gp["RBX"] = regs.pop()返回前弹出旧值，物归原位，保证后续 C 代码拿到的 RBX 与调用前一致。
  8. if r != 2 * i + 1:批量压力测试：任何一次调用若返回值不对，立刻抛出异常，验证现场恢复逻辑没有漏洞。

常见误区

误区“我总觉得函数调用就是把参数一股脑压到栈上，就像把快递全堆在门口。所以写汇编调用C函数时，我把所有参数都 push 到栈里。”

正解System V AMD64 ABI 规定，前6个整数参数走寄存器（RDI/RSI/RDX/RCX/R8/R9），只有第7个开始才压栈。这就像点餐单上第一行永远写桌号，不是所有信息都塞进备注栏。参数放错位置，被调用的C函数从寄存器里取到的是垃圾值，程序会得到错得离谱的结果。

为何常见：很多旧教材先教 32 位 cdecl 调用约定，那里所有参数都压栈。初学者把 32 位经验照搬到 64 位环境，自然就踩进这个坑。

误区“汇编函数是我自己写的，我想用哪个寄存器就用哪个，反正最后把结果放到 RAX 就完事了。”

正解RBX、RBP、R12~R15 等被调用者保存寄存器一旦使用，必须在入口压栈、返回前恢复。大厨可以借用经理的笔，但用完必须物归原位，不然经理抽屉里的文件全乱了——C 代码里的局部变量在汇编返回后会变成神秘数字，甚至导致函数返回地址被破坏。

为何常见：人只关注自己写的汇编逻辑，忽略了它被 C 调用时的上下文环境。编译器生成的 C 代码默认这些寄存器会被汇编保护，不能打破这个信任契约。

误区“我之前学过 Windows 上的 32 位汇编，push 参数再 call 就行，Linux 64 位应该也差不多吧？”

正解32 位 cdecl 约定：参数全压栈、返回值在 EAX；64 位 System V 约定：参数先放寄存器、超过6个才压栈、返回值在 RAX。这就像不同国家餐厅的上菜窗口位置不同，去新餐厅要先看规矩，否则就会端错菜——从错误的寄存器里读到错误的值。

为何常见：先入为主，把旧知识当作普适真理，缺少“ABI 随平台和架构变化”的意识。

误区“C 里写 extern，汇编里写 .globl，名字一样不就行了？还需要管什么其他东西吗？”

正解符号名字对得上只是第一步。参数顺序、返回值约定、栈对齐、寄存器保存规则都必须匹配，链接器只负责把符号绑定在一起，不负责检查调用方式是否正确。就像两个部门对接，名字对上了但对接标准不同，一样会出乱子。

为何常见：把链接器当作万能胶水，忽略了 ABI 这层看不见的协议才是真正的对接标准。

误区“反正栈那么大，16字节对齐不对齐无所谓，少 push 一个参数应该也没事吧。”

正解System V ABI 要求 call 指令执行前 RSP 是16字节对齐。汇编调用 C 库函数（如 printf）时若栈没对齐，某些 SSE 指令在访问未对齐内存时会直接崩溃。这就像厨房地砖必须对齐铺设，否则推车到转角就卡死——平时没事，关键时刻必然掉链子。

为何常见：对齐问题只在特定边界条件触发，平时能跑，换个参数或优化等级就崩，让人摸不着头脑，于是很多人忽视它。

面试题

Q1. 在 System V AMD64 ABI 下，C 函数第 1 个整数参数传递给汇编函数时，放在哪个寄存器？

单选题 · easy

  • A.RDI← 正确答案
  • B.RSI
  • C.RDX
  • D.RAX

答案：A。RDI 是第一个整数参数寄存器，相当于点餐单的第1号填写位。RSI 是第二个，RDX 是第三个，RAX 是返回值寄存器而不是参数寄存器，这与餐厅“1号窗口先上菜”的规矩一一对应。

Q2. 汇编函数若想保证 C 调用方不受影响，下列哪个寄存器被修改后必须自己保存恢复？

单选题 · easy

  • A.RDI
  • B.RBX← 正确答案
  • C.RCX
  • D.RDX

答案：B。RBX 是被调用者保存寄存器，大厨用了经理的菜刀，必须擦干净放回原处。RDI、RCX、RDX 都是调用者保存寄存器，调用方自己会保存，大厨可以随便用而不用担心善后。

Q3. C 代码调用汇编函数时，汇编文件如何让链接器看到函数符号？

单选题 · easy

  • A.使用.globl func← 正确答案
  • B.使用.extern func
  • C.使用.call func
  • D.使用.export func

答案：A。.globl 把函数符号标记为全局导出，链接器才能看到；.extern 用于导入外部符号而非导出；.call 和 .export 不是标准 GAS 导出语法。就像大厨必须把“招牌菜”挂上公共菜单，客人才能点单。

Q4. 64位 System V ABI 下，第 7 个整数参数如何传递？

单选题 · mid

  • A.压入栈传递← 正确答案
  • B.使用R9传递
  • C.使用RDI传递
  • D.存入全局区

答案：A。前6个整数参数依次使用 RDI、RSI、RDX、RCX、R8、R9，从第7个开始压入栈。这就像窗口只有6个，第7道菜只能先放在备餐台上。选 R9 是第六个参数的位置，RDI 是第一个参数的位置。

Q5. 汇编函数调用C函数后，C函数的返回值放在哪个寄存器？

单选题 · mid

  • A.RSP
  • B.RBP
  • C.RAX← 正确答案
  • D.RDI

答案：C。ABI 规定整型返回值统一放在 RAX（32位下是EAX）。RSP 是栈指针，RBP 是帧指针，RDI 是第一个参数寄存器。大厨做完菜永远把成品放到同一个取餐口，取餐的人才知道去哪儿端菜。

Q6. 汇编文件引用C文件中定义的全局变量时，应该使用哪种声明？

单选题 · mid

  • A..extern var← 正确答案
  • B..globl var
  • C..data var
  • D..local var

答案：A。.extern 告诉汇编器“这个符号定义在其他文件”，汇编器生成可重定位引用，由链接器最终解析；.globl 是导出自己定义的符号，.data var 语法不符合GAS指令格式，.local 是导出相反方向。好比大厨记下“这块白板是公共的，我去查看上面的内容”。

Q7. System V ABI 要求 call 指令执行前，栈指针 RSP 满足什么约束？

单选题 · hard

  • A.4字节对齐
  • B.8字节对齐
  • C.16字节对齐← 正确答案
  • D.32字节对齐

答案：C。call 前 RSP 必须保持 16 字节对齐，这是为了满足 SSE 指令（如 movaps）对 16 字节对齐内存操作数的硬性要求。4字节和8字节对齐不够，32字节是更严格的对齐标准但非ABI强制。就像厨房地砖必须按16厘米模数铺，差一厘米推车都会卡住。

Q8. 以下哪些寄存器属于调用者保存寄存器？

多选题 · hard

  • A.RAX寄存器← 正确答案
  • B.RCX寄存器← 正确答案
  • C.RBX寄存器
  • D.RSI寄存器← 正确答案

答案：ABD。RAX、RCX、RSI 都在调用者保存列表里，调用方需要时自己保存；RBX 属于被调用者保存寄存器，由汇编函数负责保护。就像经理的便签纸（调用者保存）要经理自己收好，而大厨的菜刀（被调用者保存）用完后大厨必须放回原处。

Q9. 关于栈帧，下列哪些说法正确？

多选题 · hard

  • A.返回地址在栈帧最上方← 正确答案
  • B.局部变量多以RBP寻址← 正确答案
  • C.汇编无需维护栈平衡
  • D.RSP可随意修改

答案：AB。call 指令压入的返回地址位于栈帧靠上位置，局部变量通常通过 RBP 负偏移访问，这两项表述正确。汇编函数返回前必须恢复栈指针，否则调用链会断裂，所以 C 错；RSP 可以修改但必须保持对齐与平衡，所以 D 错。好比灶台上的锅位固定，乱动台面会让所有参照失效。

Q10. 以下哪些是 C 与汇编互调用的正确做法？

多选题 · extreme

  • A.按ABI规则传递参数← 正确答案
  • B.汇编函数无需保存寄存器
  • C.链接器负责符号绑定← 正确答案
  • D.栈对齐保持16字节← 正确答案

答案：ACD。按 ABI 传递参数、由链接器绑定符号、保持16字节栈对齐都是互调用的基本要求。B 错在过于绝对：被调用者保存寄存器（RBX 等）仍需汇编函数自己保存，而调用者保存寄存器也并非完全不用管，只是责任在调用方。好餐厅的高效来自双方各守一套明确的规矩。