操作系统底层律动：ABI
在软件系统的繁星之下，无论是高层的 Python/Java 字节码，还是中层的 C++/Rust/Go 高级代码，最终都必须降维映射为一行行裸露的机器指令。在这片由寄存器、内存地址和堆栈构成的代码旷野中，操作系统如何理解函数的入参？如何接收函数的返回值？如何保证栈帧在崩溃时不至失控？
这些在二进制层面强行约定的底层调用规范，统称为 ABI（Application Binary Interface，应用程序二进制接口）。
今天，计算生态不仅跨越了 Linux、Windows 与 macOS 三大操作系统，更经历了从 x86-64 (CISC) 向 ARM64 (RISC) 的重大架构跃迁。这使得市面上形成了 五大主流 ABI 共同割据的局面：
Linux x86-64 (System V AMD64 ABI)
Windows x86-64 (Microsoft x64 Calling Convention)
Linux ARM64 (Standard AAPCS64)
Windows ARM64 / ARM64EC (Microsoft ARM64 ABI)
Mac Apple Silicon (Apple ARM64 Darwin ABI)
本文将全景式地拆解这五大 ABI 的本质差异，揭示同一硬件架构下不同操作系统之间的二进制博弈。
核心指标全景对比大表
一、 ARM64 统一了硬件，但没有统一 ABI
在 x86-64 时代，AMD 制定了 64 位指令集，但微软与 Unix 社区划江而治，导致 Linux 与 Windows 走上了不同的 ABI 道路。
到了 ARM64 时代，ARM 公司虽然推出了官方标准规范 —— AAPCS64 (Procedure Call Standard for the Arm 64-bit Architecture)，希望天下归一，但三大操作系统厂商在实际落地时依然做出了个性化改造：
┌────────────────────────────────────────┐
│ ARM64 (AArch64) 硬件指令集 │
└──────────────────┬─────────────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌──────────────────┐
│ Linux (ARM64) │ │ Windows (ARM64) │ │ Mac Apple Silicon│
├─────────────────┤ ├─────────────────┤ ├──────────────────┤
│ 原生忠实遵循 │ │ 融入微软风格 │ │ 为高级语言重构 │
│ AAPCS64 官方规范 │ │ 引入 ARM64EC │ │ 极奢返回值 + PAC │
└─────────────────┘ └─────────────────┘ └──────────────────┘
1. 传参约定：标准一致，细节分化
在整型（X0~X7）和浮点型（V0~V7）的前 8 个参数传递上，三者遵循了 AAPCS64 的统一标准，摒弃了 Windows 在 x86 下“只用 4 个寄存器”的保守设计。但在返回值和变参处理上产生了巨大分歧：
Linux ARM64 (纯正 AAPCS64)：允许通过
X0~X3返回最多 4 个寄存器大小的结构体。变长参数（...）依然优先装载进X0~X7，这导致va_list的内部实现包含复杂的指针和寄存器保存区（General/FP save area）。Windows ARM64：同样遵循
X0~X3返回 4 个寄存器。但为了适配 Windows 庞大的 API 历史，微软对于包含空结构体、数组包装的 C++ 结构体传参规则做了特殊调整。Mac Apple Silicon：彻底打破 AAPCS64 限制，允许使用 多达 8 个寄存器（
X0~X7） 返回数据。且 Apple 规定变长参数（...）必须全部强行压入栈，牺牲微小的性能换取了极简的va_list逻辑和 Swift/Obj-C 动态调用的安全性。
二、 Windows ARM64 的特有绝杀：ARM64EC 混合 ABI
在 ARM64 阵营中，Windows 面临着比 Linux 和 macOS 更沉重的历史包袱：如何让几十年来为 x86-64 编写的庞大 Windows 软件无缝运行在 ARM 设备（如 Surface, Snapdragon X Elite 笔记本）上？
为解决这个问题，微软在 Windows ARM64 上创造性地引入了一种特殊的 ABI —— ARM64EC (Emulation Compatible)。
【Windows 独创的 ARM64EC ABI】
┌──────────────────────────────────────────────────────────┐
│ 同一个 .exe / .dll 进程 │
├──────────────────────────────┬───────────────────────────┤
│ x86-64 模拟代码 (Binary) │ ARM64 原生代码 (Native) │
└──────────────┬───────────────┴─────────────┬─────────────┘
│ │
└────────► [ Thunk 转换层 ] ◄──┘
(模拟 x86 寄存器映射至 ARM)
彻底解决模拟开销：传统模拟器（如 Wine 或早期 Rosetta）只能“整个进程模拟”或“全局原生”。而 ARM64EC ABI 允许在同一个二进制 DLL 内部，部分函数是 x86-64 汇编，部分函数是原生 ARM64 汇编，两者可以直接互相
call！寄存器强行重映射：为了能与 x86-64 动态库直接交互，ARM64EC 重新调整了 ARM64 的寄存器保存规则，将 ARM64 的
X13~X15等寄存器强行映射为 x86 的RDI/RSI语义。意义：这是 Windows 在 ABI 层面做出的极具实用主义色彩的妥协与创新，使得 Windows ARM64 能够在不牺牲性能的前提下，逐个函数地将老旧 x86 应用重构为原生 ARM 代码。
三、 内存布局与栈帧：Shadow Space 的终结与对齐狂热
x86-64 时代 Windows 引以为傲的“32 字节 Shadow Space（阴影空间）”，在 ARM64 时代彻底划上了句号。
1. 阴影空间的废除
在 Windows ARM64 ABI 中，微软放弃了在栈顶为前 4 个寄存器强制保留 32 字节 Shadow Space 的做法。三大 OS 在 ARM64 架构下全部实现了“0 字节预留”，调用少参或无参函数时不再有无谓的栈空间分配。
2. 栈对齐（Stack Alignment）的极高要求
Linux ARM64 & Windows ARM64：要求栈指针
SP在进行内存寻址时必须保持 16 字节对齐。Mac Apple Silicon：对对齐的要求达到了偏执的程度。在执行
BL（函数调用）指令的瞬间，如果SP没有 16 字节对齐，CPU 将抛出硬件故障。这使得 Apple 的编译器极其频繁地使用STP/LDP（成对寄存器压栈/出栈）指令：代码段
; Mac ARM64 标准函数头：成对压栈并保持 16 字节对齐 stp x29, x30, [sp, #-16]! ; 将 FP(X29) 和 LR(X30) 压栈，SP 减去 16 字节 mov x29, sp ; 设置栈帧指针
四、 硬件级安全：PAC 在三大 OS 中的落地差异
ARMv8.3-A 引入的 PAC (Pointer Authentication Code，指针认证) 是近年来二进制安全领域的重大革新。它利用隐藏在芯片内部的密钥，在指针的高位无效比特中打入数字签名，防止黑客通过“栈溢出”篡改函数返回地址。
但在三大 OS 的 ARM64 ABI 中，PAC 的落地程度完全不同：
Mac Apple Silicon：默认硬性开启（Mandatory）。Apple 从 M1 芯片起就在 ABI 层面强行集成了 PAC。每一个 C/C++/Swift 函数的入口和出口都充斥着
pacia和autia指令。任何未经签名或许可的函数指针改写都会导致程序在硬件层瞬间崩溃。Linux ARM64：可选支持（PAC/BTI）。Linux 内核和现代 GCC/Clang 支持指针认证（PAC）和分支目标识别（BTI），但为了兼容没有 PAC 硬件指令的老旧 ARM64 芯片，Linux 用户态二进制文件通常将 PAC 指令编码为
NOP兼容空间（Hint 指令），由内核动态开启。Windows ARM64：逐渐普及。在搭载 Qualcomm Snapdragon X 系列等现代 ARM64 芯片的 Windows 设备上，编译器（MSVC）开始全面支持 PAC，但由于需照顾大量未升级的第三方驱动与 legacy 代码，其应用严格程度不及 macOS。
五、 五大 ABI 灵魂总结：两条主线与三重信仰
纵观整个计算历史，五大 ABI 的演进可以归结为两条线索与三重信仰：
┌──────────────────────────┐
│ 现代 ABI 演化图谱 │
└─────────────┬────────────┘
│
┌──────────────────────┴──────────────────────┐
▼ ▼
【x86-64 传统阵营 (CISC)】 【ARM64 现代阵营 (RISC)】
寄存器较少，栈操作较多 寄存器极多，全面转向寄存器传参
┌──────────────┬──────────────┐ ┌──────────────┬──────────────┬──────────────┐
│ Linux x86-64 │ Windows x64 │ │ Linux ARM64 │ Win ARM64EC │ Mac ARM64 │
├──────────────┼──────────────┤ ├──────────────┼──────────────┼──────────────┤
│ 极客吞吐优先 │ 规范调试优先 │ │ 忠实遵循 AAPCS │ 混合兼容 x86 │ 软硬协同安全 │
└──────────────┴──────────────┘ └──────────────┴──────────────┴──────────────┘
三重系统哲学：
Linux 的“吞吐信仰”：无论是 x86-64 还是 ARM64，Linux 始终追求极致的计算吞吐。尽一切可能压榨寄存器、提供 Red Zone 免去栈指针修改，不容许任何无意义的内存开销。
Windows 的“工程与兼容信仰”：Windows 视生态兼容为生命。x86-64 上的 Shadow Space 为标准化调试而生；而 ARM64 上的 ARM64EC ABI 则展现了微软在二进制层面强行打通 x86 与 ARM 界限的惊人工程能力。
Mac (Apple Silicon) 的“软硬一体信仰”：Apple 完全掌控从 M 系列芯片到 macOS 的全栈设计。通过将 PAC 硬件安全、8 寄存器极奢返回值、变参强行入栈与 Swift 高级语言特性在 ABI 层面深度绑定，实现了性能、安全与开发体验的集大成。
弄懂这五大 ABI 的差异，不仅能让系统级开发者（C/C++/Rust/Go）在编写高性能库、JIT 编译器或跨平台 Hook 框架时游刃有余，更让我们能够透过冰冷的指令集，窥见不同操作系统巨头在底层构建数字帝国时的雄心与权衡。