6.2 乱序执行与高性能微架构

6.2 乱序执行与高性能微架构

本节摘要：乱序执行把"等待"从关键路径上摘掉：寄存器重命名消灭伪相关，发射队列让就绪的指令先走，重排序缓冲保证结果按程序顺序生效。本节沿一条指令在乱序引擎里的完整旅程讲解三大件的协作，并解释精确异常为何是乱序设计不可妥协的底线。

等待是唯一真正的敌人

顺序流水线的性能模型里，每条指令都要为前面的依赖排队——哪怕缓存未命中要等两三百拍，后面的指令也得陪站。给频率加码、把流水线拉深，都只是在"等待"周围打转；真正的出路是换一种排队方式：依赖没就绪的指令靠边，不相关的指令先走。这就是乱序执行的全部动机。它不把任何单条指令变快，它改变的是"谁来占用执行资源"——等待不再阻塞整条队伍，只阻塞与它相关的那一小段。

乱序有个必须先说清的边界：它只在处理器内部乱，对外的架构状态必须与顺序执行分毫不差。寄存器最终值、内存最终内容、异常行为，全部按程序顺序成立；乱的是中间的执行时序。理解了这个"内乱外顺"的契约，三大件的设计意图就全都顺理成章。

第一站：重命名——把伪相关连根拔起

让指令乱走的第一道障碍不是真依赖，而是伪相关。看这个序列：第二条要用第一条写的 t0，这是真依赖，没办法；但第三条又写 t0、第四条读 t0——第三条与第二条之间本无瓜葛，只因共享一个寄存器名而互相掣肘。真实代码里寄存器名只有三十二个，伪相关比真依赖密集得多，不清理它们，乱序就乱不起来。

寄存器重命名的手法堪称优雅：物理寄存器堆造得远比架构可见的多（几十到几百个），每条指令的目标寄存器在译码时被指派一个全新的物理寄存器，映射表记录"架构名到物理名"的当前对应。上例中第三条写的 t0 被指到另一个物理单元，与第一条写的物理单元互不相干——写写与读后写冲突在改名瞬间凭空消失，剩下的全是真数据流。乱序引擎的并行度上限，就是重命名解放出来的真依赖图。

第二站与第三站：调度与退役

改完名的指令进入发射队列（保留站）等候。每个执行周期，队列扫描全部表项：谁的操作数到齐、谁要的部件空闲，谁就出发——出发顺序与程序顺序无关，只看就绪早晚。长延迟操作（缓存未命中的加载）后面排着一串等待者，它们挂起不动；而队列里任何与该结果无关的指令照常发射。这就是"等待被摘掉"的机械真相：等待者被隔离在数据流图里，不再占用整条流水线。

退役（提交）是乱序世界的收口，重排序缓冲（ROB）主持大局。指令按程序顺序进入 ROB 排队，执行完毕也不算数，必须轮到自己在队首且无异常，才正式写回架构状态、让出位置。这个设计一举三得：最终状态严格按序；分支猜错时，队首之后所有投机执行的指令整体作废、恢复到预测点的状态；异常处理获得"精确"语义——第三章调试现场读到的 mepc 指向的那条指令，恰好是所有更早指令都已生效、所有更晚指令都未生效的边界。乱序引擎跑得再野，架构世界始终有序。

三大件之外，高性能核还叠着几层增效。超标量：取指、译码、重命名、发射全链路按多路并行（每周期四到八条），乱序窗口相应加宽到数百条。存储消歧：加载与存储队列推测处理访存次序——加载先走，发现更早的存储与它地址重叠再回头重跑，命中率换吞吐的经典交易。缓存层级与预取：乱序引擎能用不相关的执行掩盖部分访存延迟，但掩盖幅度取决于窗口大小与预取精度，这也是高性能核对缓存预算近乎贪婪的原因。

工程现场：一次未命中被掩盖的全过程

背景：下面这段代码在顺序核与乱序核上的表现差异，最能说明乱序的价值。

x = load_from_memory(p);      /* 缓存未命中 三百拍 */
y = compute_unrelated(a, b);  /* 与 x 无关 */
z = x + y;                    /* 真依赖 x */
​

操作：顺序核上，加载停摆则全队停摆，compute 指令陪等三百拍，关键路径就是三百拍加本地执行时间。乱序核上，加载进入发射队列等待内存回应；compute 改名、发射、执行、退役一路畅通；z 在数据就绪后立刻补齐。三百拍的等待被 compute 的执行完全覆盖。

结果：同一份代码，乱序核的有效延迟接近于零额外代价（前提是窗口够深、执行资源有余），顺序核则实打实付出三百拍。

解读：这个案例同时暴露乱序的边界：掩盖能力受限于乱序窗口里"有没有足够多的无关工作"可做。线程级并行不足的串行代码、窗口浅的低功耗核，掩盖效果急剧缩水——"乱序万能论"在评估选型时要打折使用。开源生态里恰好有对照样本：顺序实现的 Rocket 与乱序实现的 BOOM 同源于一套生态，前者面积小功耗低，后者用数倍面积换数倍性能，两条路线对应的产品定位截然不同。

变式：把示例里的 compute 换成另一条访存，观察存储消歧机制如何处理两条访存的潜在重叠；再缩小乱序窗口的规格参数，看掩盖能力如何随窗口塌缩——两个变式分别对应访存并行度与窗口深度这两个乱序调优的主轴。

什么时候不选乱序

本节收在选型判断上，毕竟多数读者面对的是"用不用乱序核"而非"造不造"。三条判据够用：负载的指令级并行度（有无充足的无关工作供乱序挖掘）、功耗与面积预算（乱序引擎的三大件是面积大户，能效比小核差出数倍）、实时性要求（乱序的执行时间方差大，硬实时场景常被一票否决）。嵌入式控制选顺序小核，交互与吞吐型负载上乱序核，实时确定性与极致能效之间没有中间派——微架构选型从来是产品定义问题，不是性能参数问题。

还有一条容易被忽视的间接成本：软件验证的复杂度。乱序与投机执行会放大侧信道类安全问题的暴露面，近年多个影响深远的安全事件都源自投机路径的推测加载；安全敏感的产品为此要增加缓解设计与性能复核的环节，这笔账有时足以让一个摇摆中的选型落回顺序阵营。评估乱序核时，把安全审计与验证成本一并计入，得出的结论才是可执行的。

本节要点回顾

• 内乱外顺：执行时序自由，架构状态按序生效，这条契约是所有乱序机制的总纲；
• 重命名是并行度开关：物理寄存器远多于架构名，伪相关在改名瞬间消解；
• 发射队列隔离等待：未就绪者挂起于数据流图，不再阻塞无关指令；
• ROB 是秩序的锚：按序退役、投机作废、精确异常三件事共用同一机制；
• 掩盖有边界：窗口深度与无关工作量决定收益，选型看指令级并行度与实时约束。

乱序引擎复杂昂贵，常规负载未必值得。但如果你的负载里有一段谁都照顾不好的热点——下一节的自定义指令，就是 RISC-V 给你的官方后门。