题目重点：执行完成不等于架构状态已提交，错误路径要能取消。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练乱序CPU、rename寄存器、ROB按程序顺序提交；具体ISA和ROB条目布局未固定。
- store何时进入buffer/全局可见受内存模型约束，不能把“提交”自动当跨核立即可见。
解题路线
- dispatch为指令分配ROB和物理目标寄存器；执行可乱序完成，把结果/异常标记写回对应条目。head ready且无异常时才顺序提交，使架构状态对应程序前缀。
- 异常在年轻指令执行时被发现也不能先暴露：等它到head确认之前指令已提交，停止提交并flush年轻指令，恢复rename映射/资源。分支mispredict similarly取消更年轻投机状态并从正确PC重取。
- retirement width、ROB容量、长延迟head与资源回收会限制吞吐。增加ROB可能提升隐藏延迟，也增加唤醒/搜索/功耗；报告IPC与占用/阻塞原因，不仅平均执行延迟。
手动走一遍
I1 cache miss未完成、I2算术已完成：I2仍不能越过I1提交。I2除零先执行，I1尚未完成；先等I1正常提交再呈现I2异常，I3即使已执行也不可留下架构副作用。
规模与取舍
N条ROB常见状态O(N)，每cycle提交最多W条；功能正确性按程序顺序前缀，不等于host模拟器每步O(1)就真实cycle单周期。
易错点与追问
容易失分的边界
- 把ROB直接等同寄存器重命名表，职责不同。
- 错路径store如果提前改变外部内存，flush寄存器不能撤销它。
继续深挖
- mispredict后物理寄存器free list与rename checkpoint怎样恢复？
- head长期阻塞时如何区分ROB满和执行端口瓶颈？
技术参考
- gem5 O3CPU提交与Squash：技术语义参考，具体题目按本文约定。
