如果你第一次接触 x64最先撞上的不是某个新指令而是一堆看着眼熟、用起来却总是拧巴的寄存器名字。RAX、EAX、AX、AL、AH、R8D、SIL……它们到底是同一个东西还是不同的东西为什么网上代码里一会儿写mov eax一会儿写mov rax混着用还不出错更实际的问题是一个跑了几年的 32 位老程序凭什么在 x64 系统上还能照常工作这篇是“x64”系列的第一篇我把 CPU 本身这层底账理清。不讲操作系统不讲工具链专注寄存器、内存模型、调用约定、指令编码以及最后那个所有人都关心的兼容层问题。读完你再看反汇编、写汇编、排查栈溢出会明显感觉思路顺很多。1. 为什么是 x64 而不是安腾一段被 IT 历史记住的弯路x64 的全名应该叫 x86-64核心思路不是重新发明一套 64 位体系而是在原有 x86 指令集上做“加宽”和“扩容”。不少新同学觉得这是理所当然的设计但当年真实发生过一场整整十年的路线之争。上世纪末想要升级到 64 位几乎是大规模计算的刚需数据库、科学计算、大内存服务器32 位只有 4GB 地址空间的墙已经杵在面前了。当时背景是 RAM 价格开始下降一台机器想配 16GB、32GB 内存的情况越来越多但 32 位处理器即使开了 PAE物理地址扩展单个进程能看到的逻辑地址空间依然被死死摁在 4GB 以内。软件厂商叫苦不迭。Intel 当年的选择是彻底“掀桌”搞一套完全不兼容 x86 的 IA-64安腾寄希望于编译器和软件生态整体迁移。今天来看这个决定赢在理论上输在现实里你没法让所有存量 x86 二进制直接跑起来所有软件都必须重新适配转译执行效率又不行最后只有少数高端服务器领域真正用了它。真正落地的方案来自另一条路在保留原有 x86 指令语义的前提下把通用寄存器从 8 个扩展到 16 个把寻址位数翻到 64 位再让 CPU 运行在一个新的“长模式”long mode下。这种向后兼容的 64 位扩展就是今天所有人都在用的 x64。Intel 在 2004 年不得不放下身段采用这套方案市面上才统一成了 AMD64 与 Intel 64 并存的局面软件层面一般直接叫 x86-64 或简写 x64。为什么要了解这段历史因为“兼容”这两个字贯穿了 x64 所有设计细节。为什么有R8-R15却没有R16-R31为什么调用约定一会儿这一套一会儿那一套为什么 32 位程序还能跑全都是为了在新架构上把老的软件和老的编程习惯尽量无痛地接住。x64 的裸机模式下核心其实就两个运行形态64 位模式运行 64 位用户程序寄存器、地址、操作数都能按 64 位使用这是今天的默认模式。兼容模式运行 32 位程序CPU 指令层面仍然执行旧的 32 位编码但底层内存管理已经交给 64 位内核统一打理。兼容模式的实现方式值得先记住它不靠逐条软件翻译而是靠 CPU 内部本来就存在的“两套规则”切换。也就是说一个 32 位程序在 x64 系统上运行时大部分指令是直接摆在硬件上跑的并不是模拟器。这和第 6 章讲的 WoW64 兼容层思路完全不同。2. 寄存器翻倍的账16 个通用寄存器和它们的小名x64 最直观的变化就是把通用寄存器从 32 位时代的 8 个翻成了 16 个每个还能按 64 位、32 位、16 位、8 位四种宽度来访问。2.1 从 EAX 到 RAX老寄存器的称呼变化在 32 位时代你见到的名字是 EAX、ECX、EDX、EBX、ESP、EBP、ESI、EDI。到了 x64原来的 8 个寄存器前面加个 R变成 RAX、RCX、RDX、RBX、RSP、RBP、RSI、RDI新加的 8 个直接叫 R8、R9……一直到 R15。这里最容易晕的是“同一个寄存器的多个马甲”。以 RAX 为例访问宽度名称说明64 位全部RAX整个 64 位寄存器低 32 位EAX写 EAX 会自动清空 RAX 的高 32 位低 16 位AX只影响低 16 位低 8 位AL最低字节高 8 位AH第 8 到第 15 位旧编码时代遗留EAX是RAX的低 32 位这个说法没问题。但反过来RAX并不只是“EAX 加高 32 位”那么简单因为写EAX时会顺手把高 32 位清零。如果你写了mov eax, 1那么RAX的完整值就是0x00000000_00000001。但如果你写mov ax, 1或mov al, 1高 56 位完全不动寄存器的其他垃圾数据全被保留。这个“32 位操作自动清零高半部分”的规则是从第二代 x64 处理器开始才有的设计目的是减少指令间的依赖。代价也很明显32 位代码和 64 位代码混着写时很容易踩到“为什么结果变成了奇怪的巨大数字”的坑。我的原则是一个函数里尽量统一宽度不要一会儿mov eax一会儿add rax除非你有明确目的。2.2 新寄存器 R8-R15 的“马甲”命名R8 到 R15 这套新寄存器的子寄存器命名就更直白但也更不顺手64 位R8、R9、R10……32 位R8D、R9D……16 位R8W、R9W……8 位R8B、R9B……这里的 D、W、B 分别代表 Doubleword、Word、Byte。举个例子R8D是R8的低 32 位R8W是低 16 位R8B是低 8 位。没有类似R8H的高字节因为新增寄存器的高 8 位不能单独访问。真正让老手也翻车的是另一组名字SIL、DIL、BPL、SPL。这是RSI、RDI、RBP、RSP四个寄存器的低 8 位新名字。写过 32 位汇编的人习惯了只有 AL、BL、CL、DL 这类低字节到了 x64编译器可以自由使用RSI的低字节于是反汇编里会突然出现mov sil, 1这种看着完全不像寄存器的写法。2.3 指令指针和标志寄存器RIP 与 RFLAGS 的特殊性另一个不能按普通寄存器理解的是指令指针 RIP。x86 时代EIP 存的是当前指令地址你不能直接mov读它。x64 延续了这一点但 RIP 却参与了一个新能力RIP 相对寻址。lea rax, [rip offset]这在 x64 里极其常见原因后面第 3 章会展开。只要记住x64 下访问全局变量、做位置无关代码都爱围着 RIP 打转。标志寄存器 RFLAGS 则从 32 位扩展到了 64 位但高 32 位保留未用。日常会碰到的还是 CF、PF、AF、ZF、SF、OF 和 DF 那几个位。DF 位依然控制着cld、rep movsb这类串指令的方向所以编译器生成的字符串拷贝代码里你会看到cld指令频繁出现。3. 平坦地址空间和那 16bit“多余”的地址x64 内存模型32 位时代写汇编绕不开段寄存器。CS、DS、SS、ES每个访存都要经过“段选择子 偏移量”的变换段基址再叠加到线性地址上。逻辑地址、线性地址、物理地址三层概念能把人绕晕。进入 x64 后这套分段机制在长模式下基本“投降”了。64 位程序看到的是一片从 0 开始、几乎平坦的线性地址空间段寄存器大部分时候是摆设。这也是为什么你看现在的反汇编代码里很少看到指令里出现DS:这类段覆盖前缀。但“平坦”不等于“随便用”。x64 的虚拟地址在架构上允许你写 64 位然而 CPU 实际只“认”低 48 位高 16 位必须是符号扩展用户空间0x00000000_00000000到0x00007FFF_FFFFFFFF也就是 128TB。内核空间0xFFFF8000_00000000到0xFFFFFFFF_FFFFFFFF。两者之间的0x00008000_00000000到0xFFFF7FFF_FFFFFFFF是一个巨大的空洞称非规范地址区。如果你在用户态试图访问0xFFFF8000_00000000这个范围的地址CPU 会直接抛异常因为在这个 canonical 规则下它根本不是一个合法的进程地址。这 16 位“多余”的高位将来如果要扩展成 57 位、64 位虚拟地址也只需要调整边界规则物理层不受影响。物理内存方面x64 处理器支持的物理地址位数通常少于虚拟地址位数。桌面级产品常见是 48 位物理地址理论上可以摸到 256TB 内存条级别服务器产品可以到 52 位。这意味着即使你用mov rax, qword ptr [xxx]构造一个看起来很大的地址最终落到内存控制器时仍然要经过页表转换成物理地址。页表结构在长模式下变成了 4 级PML4、PDPTE、PDE、PTE。每一级负责查一段地址位最低粒度默认是 4KB 页。操作系统一般还会启用 2MB 大页降低 TLB 缺失率有些场景直接用 1GB 页比如数据库和虚拟化里的巨大内存映射。这些细节对你写业务代码可能影响不大但一旦做性能分析、搞内存池、排查 TLB miss页表大小就是绕不开的优化点。真正和普通开发强相关的是 x64 引入的NX 位No-eXecute。页表条目里那一比特决定了某块内存是否可以执行代码。操作系统的数据段可读可写但不可执行同一时间防止了经典的堆栈溢出后直接跳转执行 shellcode 的攻击手法。这个机制在 32 位时代也部分存在但 x64 把它变成了默认强制的安全基线。再回到 RIP 相对寻址。为什么 x64 程序里到处都是[rip 0x????]因为编译器需要在不知道代码最终加载到哪个地址的前提下生成一个可以任意搬动的二进制。用绝对地址编译意味着代码只能固定加载在某个地址用 RIP 相对地址代码放在哪里都能正确指到目标。这也是为什么现代操作系统的代码段几乎都是位置无关的。对比之下32 位时代想要实现类似效果得靠动态链接库的重定位表处理一大堆绝对地址修正麻烦得多。4. RSP、参数和栈调用约定怎么从“挤栈上”变成“先走寄存器”函数调用约定是我觉得 x64 教程里最值得单独写一章的东西。它决定了参数怎么传、栈怎么管理、返回地址怎么处理是理解调试器堆栈回溯和实际调用崩溃的基石。4.1 两种主流调用约定Windows 与 System V32 位时代各编译器有一种约定叫cdecl或stdcall参数一股脑往栈上压函数参数越多栈上的拥挤程度就越感人。到了 x64设计者意识到寄存器带宽足够于是把整数参数优先放进通用寄存器寄存器不够了才用栈。但问题是Windows 世界和类 Unix 世界各自选了一种路线约定项Windows x64System V AMD64Linux/macOS整数参数顺序RCX、RDX、R8、R9RDI、RSI、RDX、RCX、R8、R9浮点参数顺序XMM0-XMM3XMM0-XMM7影子空间 shadow space有32 字节无红区 red zone无有128 字节参数不够放怎么办继续压栈第 5 个参数从高地址开始继续压栈第 7 个参数开始入栈可变参数数量标记AL 寄存器记浮点参数个数AL 寄存器记浮点参数个数栈对齐调用前 RSP 需 16 字节对齐调用前 RSP 需 16 字节对齐看到这个表你应该明白了一个 C 函数如果参数超过 4 个在 Windows 和 Linux 下的汇编结果完全不同。第一个参数在 Windows 上是 RCX在 Linux 上是 RDI。跨平台内联汇编或者直接写汇编函数时认错约定是必炸的。4.2 Windows 独有的影子空间到底有什么用很多人第一次看 Windows x64 汇编会被每个函数开头那 32 字节的“多预留”整懵。这段空间叫 shadow space影子空间位于返回地址上方、调用者的栈顶。规范要求调用者哪怕只有两个参数也要在栈上留出 4 个参数的位置。它的用途是被调函数可以把 RCX、RDX、R8、R9 存到这个预留区这样它内部要重新使用这几个寄存器时原参数不会丢失同时也不用自己再去额外扒一块栈内存。简单说这是 Windows 给被调函数提供的“参数停车位”。Linux 的 SysV 约定没有这个要求所以生成的汇编更紧凑代价是被调函数如果需要保存寄存器参数就得自己push或主动在栈帧里留位置。4.3 栈对齐这个隐形炸弹x64 约定了“调用前 RSP 必须 16 字节对齐”。为什么是 16 字节因为 SSE 指令要求内存操作数按 16 字节对齐编译器在函数内部做movaps或movdqa时才能不出异常。而 call 指令本身会压入一个 8 字节的返回地址因此被调函数入口处RSP 的真实值是 16 字节对齐减去 8也就是RSP % 16 8。所以你会看到一个最简单的 C 函数如果它在 Windows 上要调用另一个函数开头经常是sub rsp, 40为什么是 40因为编译器要预留 32 字节影子空间同时还要把 RSP 凑回 16 字节对齐的“调用前状态”。40 的来历是入口时RSP % 16 8减去 40 后变成8 - 40 算出来的偏移正好让下一个 call 前的 RSP 成为 16 的倍数。这个细节在你手写汇编时一定要算清楚否则一 call 就崩而且崩得毫无规律。SysV 那边没有影子空间函数开头通常就直接push rbp mov rbp, rsp sub rsp, 32栈指针最后能不能落在 16 字节边界上取决于 push 和 sub 的组合编译器算得很清楚你人工写的时候也别想当然。顺便提一句 SysV 的红区red zone在RSP往下 128 字节的范围内即使不调整栈指针函数也可以放心使用。这非常适合叶子函数——一个不调用其他函数的函数压根不用sub rsp直接在红区里存局部变量就行。这是个很实用的编译优化但我在 Windows 上写汇编时经常忘掉它导致一个“在 Linux 上跑得好好的函数”在 Windows 上一进就栈溢出。5. MOV, MOV... 不REX 前缀和 x64 的指令编码规则看反汇编的时候你可能会疑惑为什么同样一条mov有时是48 8b c0有时是8b c0这两条一个对应mov rax, rax一个对应mov eax, eax。中间的48就是 x64 最核心的编码扩展手段——REX 前缀。5.1 REX 前缀的四个位REX 前缀本身是一个字节范围是0x40到0x4F。它有四个功能位W第 3 位置 1 表示指令操作数是 64 位。R第 2 位扩展 ModRM 的 reg 字段多出 R8-R15 的一半。X第 1 位扩展 SIB 的 index 字段。B第 0 位扩展 ModRM 的 rm 字段或 opcode 中的寄存器编码。举例来说mov rax, r8的反汇编码可能是49 8b c0其中49就是一个既带 W 位又带 B 位的 REX 前缀。而如果你看到的是48 8b c0通常表示mov rax, rax——虽然正常编译器不会生成这条废话指令。注意一个限制REX 前缀不能和 AH、BH、CH、DH 这四个高 8 位寄存器同时出现在一条指令里。原因很简单REX 的 R 位和 B 位会重新解释原本用来表示这些高位寄存器的 ModRM 编码。你在 64 位模式下写mov ah, 1没问题但如果你同时在指令里用了 REX 前缀就会变成访问?。不同汇编器对这种组合的处理方式不同有些直接报错有些会产生不可预期的编码。保守起见x64 汇编里我很少碰 AH/BH/CH/DH。5.2 被淘汰的指令和新增的指令x64 砍掉了一批“老古董”指令。在长模式下以下这些不再可用AAA、AAS、DAA、DASBCD 运算辅助指令。BOUND数组边界检查。PUSHA、POPA一次性压栈/弹栈很多寄存器的指令。LES、LDS加载远指针到段寄存器段机制在长模式没意义了。单字节的INC/DEC操作码原本0x40-0x4F这一段是给八个 32 位寄存器做单字节inc/dec的x64 把它让给了 REX 前缀现在的inc rax只能走ff c0这种两字节编码。新增的东西也不少。最经典的是MOVSXD它专门用来把 32 位值符号扩展到 64 位movsxd rax, dword ptr [rbx]还有SYSCALL、SYSRET这套新式系统调用指令对应的 32 位时代用的是int 0x80。在 x64 汇编里偶尔还能看到int 0x80但那通常是恶意软件故意走旧路径的痕迹。5.3 一个看反汇编的实用技巧如果你拿到一段反汇编看到大量48、49、4c、41开头的前缀第一反应应当是这是 64 位代码。判断某条指令是不是真的存取 64 位寄存器主要就看 REX.W 是否存在。比如48 8b 05 12 34 56 78拆开是mov rax, qword ptr [rip 0x78123456]如果去掉开头的48就变成mov eax, dword ptr [rip 0x78123456]。有时候你看到一个地址很大以为是什么高地址特殊区域结果一看前缀发现只是编译器在访问某个全局变量地址是相对 RIP 算出来的而不是真实地址。基于这个规则我在阅读反汇编定位 bug 时第一步一定是把函数里的lea、mov、add这些关键指令按“是否带 REX 前缀”分成 64 位和 32 位两组。混着看很容易被一堆eaxrax的魔改搞到脑壳疼。6. 老程序别怕WoW64 与兼容层这盘棋最后一章聊一个普通用户和运维都关心的问题x64 系统到底怎么跑 32 位程序的为什么绝大多数老软件插上就能用个别却会报“不是有效的 Win32 应用程序”6.1 WoW64 是什么WoW64 全称 Windows on Windows 64是 Windows 在 x64 上提供的 32 位兼容环境。名字里的“Windows on Windows”其实很有画面感一个 Windows 跑在另一个 Windows 进程环境里。它并不是虚拟机。一个 32 位程序在 x64 系统上运行时进程本身是 32 位的代码通过 CPU 的兼容模式直接执行。真正特殊的地方在系统调用边界32 位程序的 ntdll 是 WoW64 版本它负责把 32 位参数整理好切换到 64 位模式再调用 64 位内核。内核这边只认识 64 位调用接口所以 WoW64.dll、wow64cpu.dll 这些模块干的是“翻译系统调用接口和数据结构”的活。通俗地讲CPU 跑 32 位指令时硬件是原生支持的不需要翻译但是“调用操作系统服务”这件事没法直接跨位宽所以要有一层代理。这也是为什么微软不提供 32 位版本的内核驱动所有驱动都必须编译成 64 位——内核态没地方给你做兼容。6.2 文件和注册表的重定向如果你在 x64 Windows 上打开命令提示符普通 64 位版访问C:\Windows\System32看到的是 64 位系统文件但是一个 32 位程序访问同一个路径系统会自动把它转向C:\Windows\SysWOW64。反过来32 位程序通常不感知这个转向所以很多老安装程序里的“复制文件到 System32”操作实际落盘时跑到了 SysWOW64。这个机制容易被滥用。做系统维护时如果发现某个 32 位程序写了配置文件却又找不到文件优先检查是不是被重定向到了 SysWOW64 对应目录。注册表也类似32 位程序读取HKLM\Software下的键时会被重定向到HKLM\Software\Wow6432Node。手动改注册表排查问题时得加这个心眼。要注意的是并非所有目录都参与重定向。比如C:\Windows\Sysnative是 64 位程序也无法直接访问的“魔法目录”专门让 32 位程序用它去访问真正的 64 位 System32 文件。这种设计初看很绕实际是微软为了保持老代码兼容性做的妥协。6.3 32 位程序在 x64 下的内存上限很多人以为 32 位程序在 64 位系统里自动获得了 4GB 内存其实没那么简单。默认情况下32 位进程还是只有 2GB 的用户地址空间和 32 位 Windows 上的默认值一致。如果你在可执行文件上设置了 LARGEADDRESSAWARE 标志才可以把用户空间上限提升到接近 4GB。这个标志通常由编译器参数控制老程序如果没有开启就始终只有 2GB 可用。这也是不少大型 32 位游戏、图像处理软件在 x64 系统上仍然发生内存不足的原因之一。解决办法一般是换 64 位版本或者手动修改 PE 头标志位——后者有风险不推荐对不熟悉的软件操作。对比当初安腾时代的 IA-32EL 软件翻译层WoW64 的底层执行效率高得多因为绝大多数 32 位指令都由 CPU 直接执行没有逐条解释的开销。只有系统调用、线程本地存储这类需要“跨世界”的操作才会经过 WoW64 跳转。这也是为什么在 x64 系统上跑 32 位老软件体感速度基本不输当年真正的 32 位系统。关于 WoW64 还有一个隐藏坑如果系统缺少对应的 32 位支持组件或者 CPU 配置被精简过32 位程序启动时会直接报错。排查时先确认系统是否安装了 32 位兼容选项再考虑程序本身的问题。因为方向完全不同前者重装组件即可后者要从依赖库和运行环境入手。写到这里x64 的第一层底账算是理清了。我自己最初从 32 位汇编过渡到 x64 时最不适应的不是寄存器变多而是“一套指令两套规则”——同一份逻辑Windows 和 Linux 上的参数传递、栈布局、编码前缀全都不一样。但只要先在脑海里建立这张大图寄存器怎么分布、地址怎么算、参数怎么传、指令怎么编再回头看具体的汇编代码就会发现那些乱糟糟的数字和前缀其实都能反推出确定的含义。下一篇我打算挑一个具体方向往下钻大概率是沿着调用约定和栈帧展开把函数入口、出口、异常处理那套现场还原讲透。如果你也在从 x86 往 x64 迁移的路上或者正在为看不懂反汇编头疼先把这一篇里的几个图景画出来再往下走会轻松很多。