arm64和x64参数传递方式详解：手把手教程

arm64 和 x64 参数传递机制详解：从底层看函数调用的差异与优化

你有没有遇到过这样的情况——同一段 C 代码，在手机上跑得飞快，到了 PC 上却慢了一截？或者调试崩溃日志时，发现寄存器里的值“对不上号”？问题可能就出在函数调用时参数是怎么传的。

别小看这个细节。现代程序每天要执行成千上万次函数调用，而每一次调用背后，CPU 都得按照一套严格的规则来“交割”参数和返回值。这套规则，就是所谓的调用约定（Calling Convention）。

今天我们就深入到汇编层面，手把手拆解arm64（AArch64）和x64（x86-64）这两种主流架构下，参数到底是怎么传递的。你会发现，看似相似的64位世界，底层逻辑其实大相径庭。

为什么参数传递方式如此重要？

很多人写高级语言代码时，根本不用关心参数是怎么传进去的。但一旦进入性能敏感区、做逆向分析、查 core dump，或是写内联汇编，这个问题就会立刻浮出水面。

举个例子：

long result = compute(a, b, c, d, e, f, g);

这段代码在编译后：
-a到f可能进了寄存器；
-g呢？是继续进寄存器，还是被压进了栈？
- 如果你在 GDB 里想看g的值，该查哪个寄存器？还是得去翻栈？

答案取决于你跑的是 arm64 还是 x64。

更关键的是：寄存器访问比内存快几个数量级。如果一个参数能走寄存器，就不该让它落盘（入栈）。这就直接影响了性能。

所以，搞懂参数传递机制，不是为了炫技，而是为了写出真正高效、可调试、跨平台兼容的代码。

arm64 怎么传参数？AAPCS64 规范全解析

ARM 家族自从进入 64 位时代，就制定了统一的标准——AAPCS64（Procedure Call Standard for the ARM 64-bit Architecture）。这是所有基于 arm64 的系统（iOS、Android、Linux on ARM）共同遵守的“宪法”。

寄存器够多，优先用寄存器

arm64 最大的优势之一就是寄存器资源丰富。它为参数传递专门预留了整整 8 个通用寄存器：

超过8个怎么办？第9个及以后的参数，才会被推入栈中，按从左到右顺序存放。

来看一个典型例子：

int func(int a, int b, int c, int d, int e, int f, int g, int h, int i);

这9个参数怎么分配？

• a→ X0
• b→ X1
• …
• h→ X7
• i→ 栈（sp + offset）

也就是说，前8个整型/指针参数全部通过寄存器直达，不需要任何内存操作。

浮点数呢？也有专属通道

对于浮点或向量类型（float/double/SIMD），arm64 使用另一组寄存器：V0～V7。

比如这个函数：

double add_floats(double x, double y, double z);

它的三个参数会分别放入 V0、V1、V2，结果也通常由 V0 返回。

这种整型与浮点分离的设计，避免了类型混淆，也让硬件调度更清晰。

返回值放哪？还是 X0 和 V0

函数执行完，结果往哪放？

• 整型/指针：写回X0
• 浮点型：写回V0

简单直接，毫无歧义。

汇编实战：看看真实指令长什么样

我们写个简单的加法函数：

// int add_three(int a, int b, int c)

对应的 AArch64 汇编代码如下：

add_three: add x0, x0, x1 // a + b，结果存入 x0 add x0, x0, x2 // 再加上 c ret // 函数返回

就这么两行。没有压栈、没有取参，因为参数已经在 X0～X2 里等着了。效率极高。

⚠️ 注意：这里修改了 X0，意味着原参数 a 被覆盖了。如果你需要保留原始参数，就得先备份。

x64 怎么传参数？System V ABI 的规则

x86 架构历史悠久，x64 是它的64位扩展。在 Linux 和 macOS 上，采用的是System V AMD64 ABI，这也是我们重点分析的对象。（Windows 有自己的规则，略有不同，此处暂不展开。）

六大寄存器撑起前六参数

x64 给整型/指针参数分配了6个专用寄存器：

注意命名风格完全不同：不再是连续编号，而是各有“名字”。这些名字其实源自早期 x86 的用途（如%rdi原本用于字符串操作的目标地址），算是历史包袱。

再看这个函数：

long calc(long a, long b, long c, long d, long e, long f, long g);

前六个参数依次进入%rdi～%r9，第七个g就只能进栈了。

浮点参数走 XMM 寄存器

类似地，浮点参数使用%xmm0到%xmm7，共8个。

例如：

double avg(double a, double b, double c);

三个参数分别进入%xmm0,%xmm1,%xmm2。

返回值放哪？整型用 %rax，浮点用 %xmm0

• 整型返回值 →%rax（低32位%eax也可）
• 浮点返回值 →%xmm0

和 arm64 类似，也很直观。

汇编实战：乘法函数怎么实现

我们实现一个简单的乘法函数：

// long multiply(long a, long b)

对应 x64 汇编（AT&T 语法）：

.text .global multiply multiply: movq %rdi, %rax # 把 a 放进 %rax imulq %rsi, %rax # 计算 a * b，结果仍在 %rax ret

可以看到，虽然用了两条指令，但全程没有访问内存，性能依然很高。

不过相比 arm64 多了一个限制：只有6个寄存器可用。这意味着只要参数超过6个，就必须开始用栈。

对比：arm64 vs x64，谁更胜一筹？

我们把两个架构的关键特性拉出来对比一下：

关键差异解读

1. 寄存器数量：arm64 占优

这是最显著的区别。arm64 多出两个参数寄存器，意味着在处理7~8个参数的函数时，仍可完全避免栈访问；而 x64 在第7个参数就开始读写内存了。

一次栈访问可能只是几十个周期，但在高频调用的小函数中，积少成多，性能差距就显现出来了。

这也是为什么苹果 M 系列芯片（基于 arm64）在某些编译器优化良好的场景下表现尤为出色的原因之一——它天生更适合现代 C++ 多参数、高内联的编程模式。

2. 寄存器命名哲学不同

• arm64：统一编号，结构化思维。X0～X7 清晰明了，易于记忆和扩展。
• x64：功能命名，历史继承。%rdi、%rsi 等名称虽有渊源，但对新手不够友好，也不利于自动化工具生成代码。

但这不影响实际使用，毕竟编译器都帮你处理好了。

3. 浮点与向量集成度更高

arm64 的 V 寄存器不仅能装 float/double，还能用于 NEON 向量运算（相当于 x64 的 SSE/AVX）。一套寄存器，多种用途，资源利用率更高。

而 x64 中，SSE 和通用寄存器是分开的，数据搬运成本略高。

4. ABI 生态一致性都很强

尽管来自不同阵营，但 AAPCS64 和 System V ABI 都做到了高度标准化：

• 不管你是用 Clang 还是 GCC；
• 不管目标平台是 iOS、Android 还是 Linux；
• 只要是 arm64 或 x64，调用约定基本一致。

这种一致性极大降低了跨平台开发的复杂度。

实战场景：如何影响你的开发工作？

理解这些底层机制，不只是为了应付面试题。它们实实在在影响着你的日常开发。

场景一：性能优化——控制参数数量

假设你正在设计一个热点函数：

int process_data( int flag, size_t len, void* input, void* output, int mode, int priority, int timeout, int tag );

这个函数有8 个参数。

在 arm64 上：全部走寄存器，极致高效。
在 x64 上：前6个走寄存器，最后两个必须入栈，带来额外开销。

建议做法：尽量将参数控制在6个以内。若实在太多，考虑打包成结构体：

struct process_args { int flag; size_t len; void* input; void* output; int mode; int priority; int timeout; int tag; }; int process_data(const struct process_args* args);

这样只需传一个指针，既节省寄存器，又提升可读性。

场景二：调试崩溃日志

当你看到一段崩溃时的寄存器状态（比如从 crash report 或 GDB 中获取）：

# arm64 x0: 0x000000010a2b3c4d x1: 0x0000000000000005 x2: 0x000000010b4c5d6e # x64 rdi: 0x7fff1a2b3c4d rsi: 0x0000000000000005 rdx: 0x7fff1b3c4d5e

你能立刻判断出：
- 当前函数的前几个参数是什么；
- 是否传入了非法指针或异常值；
- 哪个参数可能导致了空指针解引用。

这就是掌握调用约定带来的调试直觉。

场景三：编写内联汇编

如果你要在代码中嵌入汇编（比如优化 memcpy 或加密算法），就必须严格遵循当前平台的 ABI。

错误示范：

__asm__ volatile ( "add %0, %1, %2" : "=r"(result) : "r"(a), "r"(b) );

你以为%0,%1,%2是参数？不对！在真正的函数调用中，参数已经按 ABI 规则放进特定寄存器了。

正确的做法是知道：在 arm64 上，第一个参数在 X0；在 x64 上，第一个参数在 RDI。

否则，轻则逻辑错乱，重则程序崩溃。

常见误区与避坑指南

❌ 误区一：“参数都是从左往右压栈的”

错！在现代架构中，大多数参数根本不走栈。只有超出寄存器容量的部分才入栈。

而且，即使是入栈，也不是简单“压栈”，而是由调用者一次性准备好参数空间。

❌ 误区二：“X0 和 %rdi 是一样的”

虽然它们都是“第一个参数寄存器”，但不能混用。一个是 arm64 的，一个是 x64 的。交叉编译时尤其要注意。

❌ 误区三：“返回值可以随便放寄存器”

不行。编译器和调用方都默认返回值在固定位置（X0 或 %rax）。如果你写的汇编函数没把结果放对地方，调用方就会拿到垃圾数据。

结语：底层知识是工程师的护城河

arm64 和 x64 表面上都是64位架构，都能跑 Linux、都能运行高性能应用，但深入到底层，你会发现它们的设计哲学截然不同。

• arm64 更现代、更规整，寄存器充足，适合高并发、多参数的现代软件架构；
• x64 更成熟、生态庞大，尽管有些历史包袱，但在桌面和服务器领域依然坚不可摧。

掌握它们的参数传递机制，不只是为了读懂汇编，更是为了建立一种系统级的思维方式：你知道每行代码背后发生了什么，你能预判性能瓶颈，你能快速定位问题。

下次当你写出一个带7个参数的函数时，不妨停下来问一句：

“我在 arm64 上很爽，那 x64 用户会不会吃亏？”

这才是真正专业的开发者该有的自觉。

如果你在项目中遇到过因调用约定导致的 bug，或者做过跨平台汇编优化，欢迎在评论区分享你的经验！