芯片乱序执行：异常提交与访存重放如何分工

处理器芯片可以先执行后面的指令，却不能把错误路径上的结果随意交给软件。精确异常约束架构状态的提交，访存重放修复提前读取的错误依赖，二者共同规定了乱序执行可以激进到什么程度。

精确异常首先是一条状态边界。某条指令出错时，软件通常需要看到它之前的指令已经完成，而它之后的指令尚未改变架构可见结果。执行单元发现故障的先后顺序却可能相反：年轻的加载很快遇到页故障，更老的除法仍未结束。若立即进入异常处理，保存下来的寄存器和程序位置就难以对应一条完整执行前缀。因此，重排序缓冲记录指令年龄和异常信息，等待最老的相关指令到达提交边界再统一处理。

这里必须区分执行完成、写回和提交。年轻指令可以把计算结果写入物理寄存器，供后续依赖者使用，但逻辑寄存器所对应的已提交状态仍受控制。出现异常时，硬件清除年轻指令并恢复重命名关系，使软件重新获得一致的架构视图。逐项回滚节省额外快照资源，却增加恢复周期；保留已提交映射可缩短恢复延迟，但需要更多状态和更新逻辑。两种实现的取舍应根据异常频度与时序约束判断，而不是只看正常执行峰值。

存储是这条边界特别敏感的出口。若年轻指令把写入提前发给不可撤销的设备寄存器，之后清空流水线也无法撤回外部动作。以延迟存储可见性的常见设计为例，地址和数据可以提前进入队列，但只有获得提交授权后才允许送往相应内存系统；特殊访存还需遵守专门的排序要求。芯片验证应同时制造不同年龄的异常和写入，检查最老异常的位置、恢复状态及外部写事务，不能仅比较异常处理后的寄存器值。

访存重放解决的则是地址尚未揭晓时的性能选择。较老存储可能因为地址依赖迟迟未完成，较年轻加载若一直等待，会让大量无关访问失去并行机会。处理器可以预测二者不冲突，先发加载；等存储地址计算出来后，再与已经执行的年轻加载核对。若发现读取本应依赖这次存储，而加载取得的是旧内存值，就必须使受影响结果失效并重新执行。这是依赖预测失败，通常不应变成软件可见的访问异常。

判断冲突不能只比较一个粗略地址标签。访问可能只覆盖同一机器字的部分字节，存储地址已知但数据尚未就绪时，也不能凭地址命中就随意转发。完整实现需要匹配字节覆盖关系与指令先后次序，并在多次候选存储中找到正确来源。较短的地址标签有助于提前筛选，却可能产生假冲突，因此最终判定仍需符合实际地址语义。设计必须明确哪些结果可保守等待，哪些能继续推测，避免优化把正确性责任留给模糊的比较条件。

重放代价也并非只有一条加载的延迟。依赖错误数据的后续指令可能已占用多个队列，清除和重新取指会把损失扩散到整个窗口。单纯增大执行窗口，甚至可能增加一次消歧失败时需要丢弃的工作。性能评估应统计失败频率、恢复长度与相关指令链，而非只测无别名数组循环。定向验证则应让存储地址晚到、加载先完成，并交叉覆盖部分重叠和跨边界访问，确认重新执行后获得的是正确版本。

乱序执行的收益取决于推测能否被准确收回。提交逻辑守住软件可见的状态边界，访存重放纠正未确定的地址依赖，只有两条责任清晰，扩大并行窗口才不会扩大错误范围。