这个任务要求交出三份互相吻合的记录：每次读依赖哪个物理版本，哪些指令在哪个周期发射和发布，以及每一时刻允许软件看见哪个顺序前缀。最终寄存器相同只是其中一项。

沿重命名到精确退休路线，先读物理版本理路物理寄存器重命名Physical register renaming · Explicit register renaming · 物理寄存器文件重命名为每次寄存器写入分配独立物理版本，固定读取的生产者，并按顺序退休回收旧版本以保持精确恢复。，再读标签就绪理路标签就绪与动态发射Tagged ready instruction issue · Age-ordered ready issue · 标签就绪发射根据固定源标签、操作数就绪和执行单元可用性选择最老候选，逐周期区分运算延迟、结果端口仲裁与顺序退休。，最后用ROB顺序退休理路重排序缓冲与顺序退休Reorder buffer retirement · ROB in-order retirement · 重排序缓冲区让结果乱序准备而架构效果只按队首退休，以已提交映射、延迟store与完成记录取消维持可精确恢复的指令前缀。封闭异常边界。

一、声明机器，避免借错指令集语义 ​

逻辑寄存器r0到r5初值为 [0,2,3,4,0,9]，全部可写；内存是整数槽，槽0初值31。运算是精确整数，DIV向下取整，除零同步异常；不是RV32I。没有load、分支、设备、并发或地址转换故障。

取P=11、ROB容量Q=8。ALU处理CONST/ADD，另有MUL、DIV、STORE单元，延迟分别1、6、2、1，均从发射占用至发布。每周期按“退休→发布→发射→重命名”顺序，每步至多一项；发布选最老到期结果，发射选最老的源齐全且所需单元空闲项。

请先写下三个边界：新重命名项不能当周期发射；刚发布结果可以当周期喂已有消费者；刚发布项不能当周期退休。之后所有周期答案都按这个合同推导。

二、交出版本表与13周期正常轨迹 ​

运行：

I0: MUL   r1,r2,r3
I1: ADD   r4,r1,r2
I2: CONST r1,7
I3: ADD   r5,r1,r3
I4: STORE [0],r4

从最小空闲物理编号分配，I0至I3的新目的应为p6、p7、p8、p9，保存旧目的为p1、p4、p6、p5。源分别为 (p2,p3)、(p6,p2)、空、(p8,p3)；I4读p7、不分配目的。

在周期5停一下：p8已经是7，p6仍未就绪；推测r1映到p8，提交r1仍映到p1，I1仍等待p6。这三个结论必须同时成立。若I1去取最新映射，它会误算7+3=10；正确值应为12+3=15。

完整关键时间如下：

发布顺序是2、3、0、1、4；退休顺序是0、1、2、3、4。最后寄存器为 [0,7,3,4,15,11]，内存槽0=15。周期10的STORE已经准备好，但内存仍31，到周期13才写入。

交出旧标签释放账：周期9释放p1，周期10释放p4，周期11释放p6，周期12释放p5。最终两映射均为 [p0,p8,p2,p3,p7,p9]，空闲为 {p1,p4,p5,p6,p10}。请解释为何I2在周期5完成时不能立即释放它保存的旧p6。

三、让年轻故障等到正确报告边界 ​

恢复原初值，改成：

I0: MUL   r1,r2,r3
I1: DIV   r4,r2,r0
I2: CONST r1,99
I3: STORE [0],r3
I4: ADD   r5,r2,r3

DIV和CONST都在周期5到期，但只有一个结果发布槽。DIV较老，先记录除零；CONST留在ALU直到周期6。STORE周期7发布的是准备值4，不能写内存。I4周期7已经到期，先后让给I3与周期8到期的I0，到周期9才发布7。

交付以下证据：

• 周期5发现内部故障时，架构r1仍为2，I0尚RUN，因此不能立即报告并清空
• 周期8发布I0的12，架构r1仍为2；周期9退休后才为12
• 周期10报告 (PC=1,division-by-zero)，取消I1、I2、I3、I4
• 最终寄存器 [0,12,3,4,0,9]、内存槽0=31；年轻99、4、7均没有架构数据效果
• 两映射恢复为 [p0,p6,p2,p3,p4,p5]，空闲集合为 {p1,p7,p8,p9,p10}

把“首次错误报告时刻”与“错误可对软件提交时刻”分别写进账本。若你只输出一个fault周期，就不能判断究竟是发现得早，还是恢复得太早。

四、迁移资源与延迟 ​

正常五条程序在 (P,Q)=(7,1),(7,8),(8,2),(11,8) 下分别需21、19、15、13周期。前端阻塞分别为ROB满13次、无物理位置11次、ROB满7次、零；检查顺序先ROB后free，不重复计同一周期。所有最终数值相同。

另用两个物理位置执行初值r0=3的两次 r0←r0+r0，最终12；这验证先读源、后改目的及退休后的编号复用。再用 DIV(-7,3)核向下取整结果−3，避免把别的指令集的截断约定偷带进来。

最后用初值 [8,2,0] 执行 DIV r0,r1,r2; MUL r1,r1,r1，把MUL延迟改30。它在周期3发射，本来周期33发布；周期5已因较老DIV异常被取消。交付恢复后ROB为空、单元完成记录为空、架构值仍 [8,2,0]。只取消队列里的指令，却保留周期33的写回事件，是不完整恢复。

五、提交失败证书和可重跑结果 ​

下载完整标准库参考器，直接运行 python foundation-renaming-retirement-check.py；加 -O仍执行相同显式检查。输出可与完整结果JSON对照。

五份破坏证据已经实际执行：先改目的再捕获自引用源导致等自身；临发射重新读名字使r4和内存变10；STORE提前写使异常后内存留4；首个年轻异常时报告只得到旧r1=2而非12；I2完成便释放p6触发生命周期错误。前四项分别交出错误状态，第五项交出仍需该标签的生产者和消费者。

公开1600组有限随机程序逐周期比较每个架构状态与顺序已退休前缀，包含不同容量、延迟、寄存器重写、负数及除零。它们不是任意程序正确性的自动证明；一般论证依赖三个正文给出的版本、就绪和前缀不变量。报告还应单列输入程序、物理文件、ROB、日志和测试用顺序快照的存储，不把验证工具的额外内存当作硬件结构所需空间。