5.4 乱序执行与状态可见性

5.4 乱序执行与状态可见性

本节摘要：乱序执行是"打乱顺序干活、保证结果按序"的分层魔术。本节拆解它的三大机构——寄存器重命名、乱序发射、按序退役——并回答全章最关键的问题：执行顺序都乱了，程序语义凭什么不变。读完你应当能解释重命名如何消灭假依赖、退役队列如何守护精确异常，以及"架构状态"与"投机状态"的边界为什么是安全问题的源头。

打乱顺序为何不乱

5.2 节留了一个悬念：加载停顿时，让远处的指令插队填空。怎么插队？直接让执行顺序偏离程序顺序，就是乱序执行。它的自由度来自一个观察：程序语义只约束"有数据依赖的指令必须按序"，彼此独立的指令先做后做，结果毫无差别。乱序核心因此只需盯住依赖图，其余全部自由。

第一道机构是寄存器重命名。架构寄存器就那三十几个名字，短命变量反复复用名字，制造出大量假依赖——写后读名与写后写（4.2 节的假依赖在此收线）。重命名的思路是把"名字"与"存储位置"分离：内部备一大排物理寄存器，每条写指令领一个新的物理位置，名字到位置的映射表随指令流动态更新。假依赖在重命名后自动消失——两次写同一个架构寄存器，落到两个不同的物理位置，互不妨碍，后面依赖这个名字的指令通过映射表找到正确的那个位置。

第二道机构是乱序发射。译码后的微操作先进重排序缓冲（ROB）排队登记，再进保留站等待操作数：操作数齐了就发射，不管自己在程序顺序里的位置；没齐就在站里盯着旁路网络等结果送达。执行单元按"谁就绪谁先走"的规则满负荷开张，5.2 节的停顿槽被远处的独立指令填得满满当当。

第三道机构是按序退役，也是语义的守护神。ROB 按程序顺序记录每条在途指令，执行完成不等于生效——只有排到队首、且前面的指令全部完成，指令才"退役"：写回架构状态、更新程序计数器、允许对外可见。所有"看起来按序"的承诺都由这一道工序兑现：顺序执行的假象、精确异常（出错指令之前的全部生效、之后的全部作废）、中断现场的干净保存（入口在 7.1 节），全靠按序退役兜底。

一段依赖链的推演

把三大机构放进同一段代码。设有如下序列：

lw   t0, 0(a0)      # 加载：慢，几十个周期后才有结果
add  t1, t0, t2     # 真依赖：等 t0
xor  t3, t4, t5     # 与前两条毫无关系
mul  t6, t3, t7     # 依赖 xor（假依赖：目标寄存器名若被前面用过也无妨，重命名兜底）
sw   t6, 8(a1)      # 依赖 mul
​

乱序核心的处理时间线：lw 进入保留站等内存；xor 不等任何人，立即发射完成；mul 在 xor 完成的下一拍拿到操作数，完成；add 在 t0 到货后发射；sw 等 mul 的结果。全部完成后，ROB 按程序顺序逐条退役。对外观察到的状态变化与逐条串行执行完全一致——但墙钟时间由依赖链的关键路径（lw → add 与 xor → mul → sw）决定，而非五条指令的周期总和。这段推演也解释了优化的一条铁律：缩短依赖链比减少指令数更值钱——把长依赖链拆成两条独立链再汇合，是手写热点代码的常规手艺。

可见性的边界：架构状态与投机状态

乱序执行把状态分成两层。架构状态：退役指令写下的寄存器、内存与程序计数器——外部世界（其他核心、调试器、操作系统）只看得见这层。投机状态：预测路径上尚未退役的指令改动的内部物理寄存器与预取的缓存行——理论上外部永远看不见，猜错了就整体丢弃。

"理论上"三个字是本章留给第 6 章与 7.4 节的接口。投机执行虽不改变架构状态，却会留下微架构痕迹：预测路径上的加载可能把数据搬进缓存，猜错撤销后缓存里多出的那一行并不随之消失。缓存命中与未命中的时间差是可测的——侧信道攻击（如著名的 Spectre 类）正是教唆程序"投机执行一段本不该执行的代码、再用时间差把它的痕迹读出来"。架构语义分毫未破，机密却顺着微架构的缝隙漏了出去。这不是乱序执行的失败，而是"架构状态与微架构状态"这条边界被重新定价：7.4 节的安全扩展（边界防护、指针认证）就是给这条缝隙补的墙。

存储侧还有一个值得记住的细节：写指令通常先落进存储缓冲，等退役后才真正写向缓存——为了不让尚未定案的写污染缓存，也为了让同核后续的读能立即看到自己的写（存储转发）。两个核心同时读写同一地址时的可见顺序，就是 4.4 节获取释放语义与第 6 章内存模型的正式议题。

容易踩的坑

第一坑：把"乱序"误读成"程序行为不可预测"。乱序只发生在微架构层，架构语义被按序退役钉得死死的——单核程序完全不用操心乱序；需要操心的恰是"外部世界看不见投机层"这个假设被侧信道击穿的部分。第二坑：以为重命名让寄存器复用零成本。名字随便用，物理寄存器却要占位到退役——寄存器名复用会拉长物理寄存器的占用时间，极端的循环体内频繁覆写同名寄存器反而无谓消耗重命名资源，编译器分配寄存器时的寿命分析仍在挣钱。第三坑：静态数周期依赖"停顿槽存在"的旧直觉。乱序核心的执行时间近似由依赖链关键路径与资源冲突决定，逐条加周期的手工模型在乱序机器上只能当量级参考——这再次呼应 5.2 节的结论：精确答案来自实测。

退役机制的边界情形

按序退役有两处边界情形值得专门交代。其一是异常的时点：一条指令在执行层早就报了错（比如除零），但异常要等它排到 ROB 队首才正式抛出——所以调试器里看到的崩溃地址永远精确，错误指令之前的写全部生效、之后的一律作废。反直觉的推论：程序可能"执行"了会出错的指令却从未崩溃——如果一条跳转在它退役前把它冲掉了（错误路径上的投机指令触发的异常会被静默丢弃）。异常的"发生"与"生效"是两件事，这个区分在写性能监控与安全代码时都要用上。其二是存储的可见时点：写指令退役了，数据也可能还躺在存储缓冲里没进缓存——同核后续读能透过存储转发看到它，别的核却要等真正写入。这条缝隙正是 6.3 节内存序要立法的地界，本节先标记在案。

常见疑问

问：乱序执行的窗口是不是越大越好？窗口大，填空能力强，但保留站、ROB、重命名表的查询功耗与面积随窗口超线性增长，而且程序本身的并行度撑不起窗口时全是白费——主流核心的窗口停在几百条的量级，就是这个经济账的平衡点。

问：怎么判断我的程序吃没吃到乱序红利？看剖析工具的"执行端口利用率"与"停顿构成"：若端口利用率高、停顿集中在缓存未命中，说明乱序机器已经在尽力遮盖，瓶颈在访存（去第 6 章）；若停顿集中在依赖链空转，说明程序本身并行度不足（去优化代码结构）。乱序不是万能药，剖析数据才是处方单。

本节要点回顾

• 乱序执行盯住依赖图而非程序顺序：独立指令自由推进，依赖链的关键路径决定墙钟时间。
• 三大机构：重命名消灭假依赖（名字与位置分离），保留站按就绪发射，ROB 按序退役。
• 按序退役是语义守护神：顺序假象、精确异常、中断现场全部由此兜底。
• 状态分两层：架构状态对外可见，投机状态理论不可见——侧信道攻击击穿的就是这堵理论墙，补墙工程在 7.4 节。
• 优化铁律：缩短依赖链优于减少指令数；精确性能结论必须实测。