前言
上一章讲到了可以通过ScoreBoard 去检测各种各样的冲突。可是呢,解决这些冲突的方法依然是停顿等待冲突解决。但是我们肯定是希望不停顿以提升效率,这时候就有必要要研究一下各种冲突造成的原因,来寻求解决。
冲突产生的原因
- Structural:就是功能单元被占用了,硬件不可能无中生有,只能通过等待来解决
- RAW:和上面一样,需要的数据不可能凭空产生
- WAR/WAW:产生的原因是因为原来的值被错误覆盖,要解决这个问题似乎只能靠增加储存空间。乍一看好像挺无解的,毕竟寄存器的数量不可能凭空增加。但是我们回忆一下,决定寄存器的数量的是指令集架构,但是我们可以让微架构拥有更多的寄存器来缓解这两种冲突。
寄存器重命名
简单来说就是机器在硬件上修改指令源寄存器和目的寄存器的名字以保证前后指令不会因为覆盖而出错。
在这里有两种不同的实现方法:
- 使用集中式的大Register file,真正的通过修改指令中寄存器的索引名,来达到重命名的机制。
- 使用分布式的reservation station 直接储存寄存器的值,哪里需要操作数直接将所需操作数备份到reservation station里就行。这个方法正是大名鼎鼎的Tomasulo 算法里使用的技巧,也是最早的寄存器重命名的形式。
这里我们将使用第一种方法讲解,后