Alpha 21264微处理器寄存器映射检查点实现机制技术问询

你提到的内容很容易让人误解为Alpha 21264为每条在途指令都存储了完整的寄存器映射快照，实际上它采用了分层的恢复机制，在保证恢复效率的同时大幅降低了存储开销，具体实现如下：

可通过保存的映射状态将寄存器映射回滚到最后一条被清空（squashed）指令之前的状态。每一条在途（in-flight）指令的映射状态都会被维护，因此可以轻松完成恢复。

核心优化：不存储全量映射快照，分层处理不同回滚场景 #

Alpha 21264的寄存器重命名基于重排序缓冲（ROB）和寄存器映射表（RMT）实现，针对两类常见的指令清空场景，采用了完全不同的恢复方案：

• 分支预测失败场景（占90%以上的清空场景）：仅为每一条未执行完的分支指令保存完整的寄存器映射检查点。该处理器硬件最多支持同时存在20个未解决的分支，因此只需要存储20份完整的寄存器映射表即可，远低于80份的量级，单份映射表仅需要存储32个逻辑寄存器对应的物理寄存器编号，存储开销极低。遇到分支预测错误时，直接用对应分支的检查点覆盖当前映射表，1个时钟周期即可完成恢复。
• 异常/访存错误等非分支场景：采用ROB反向回滚的方式恢复映射，不需要提前存储全量快照。ROB中每条在途指令都会记录自己修改的寄存器映射的增量信息（也就是该指令分配新物理寄存器之前，对应逻辑寄存器的旧物理寄存器编号），需要回滚时从清空的指令开始倒序遍历ROB，把每条指令对应的旧映射写回寄存器映射表即可。

论文中提到的「每一条在途指令的映射状态都会被维护」，实际指的是每条指令只在ROB中存储自己修改的那一条映射的旧值，而不是完整的映射表：

• 单条在途指令仅需要存储最多2个旧物理寄存器编号（对应指令覆盖的目标寄存器旧映射），单条指令的存储开销仅十几比特，80条指令总增量存储开销不到2K比特，远低于80份全量映射表15K+比特的开销。
• 加上20份分支全量检查点不到4K比特的存储，整体用于检查点恢复的总存储开销不到6K比特，完全在可接受的硬件成本范围内。
• 非分支清空场景的发生概率极低，即使需要最多几十个时钟周期回滚ROB，对整体性能的影响可以忽略不计。

内容的提问来源于stack exchange，提问作者Abhishek Revinipati