计算机体系结构第五次实验——Branch-Target Buffers（BTB）

本次实验的主要目的是加深对Branch-Target Buffers的理解。掌握使用Branch-Target Buffers减少或增加分支带来的延迟的情况。

实验内容：将以下程序段修改为可利用WinMIPS64模拟器运行的程序。假设R3的初始值为R2+40

在使用forwarding的情况下，对比采用BTB与不采用BTB技术时流水线的变化。重点分析两种情况下每次循环的stall周期数，都是由什么原因造成的？重点分析与分支指令相关的stall。采用BTB技术时何时能够减少分支指令带来的暂停？何时会增加暂停？为什么？

实验完成情况：
因为程序段就是之前第三章第一次实验的时候要修改为WinMIPS64模拟器运行的程序，所以这里直接将修改好的文件输入WinMIPS64模拟器中。
这里先附上之前修改好的代码的截图：

在WinMIPS64中执行这个修改好的文件：
首先是正常情况下，使用定向技术：

执行完文件之后，查看执行周期：

这里的分析之前也写过，这里简单复述一下，之后会进行每个循环的分析，这里的延迟对应的分别是每个循环一次的load指令导致的RAW相关带来的stall，一次是分支指令要在ID阶段完成目标地址和转移条件的计算，而要用到前一条指令的结果还没有计算出来带来的stall。程序总计循环了十次，所以有20次的RAW stall。另外因为分支指令这里采用了预测转移失败的方式进行处理，前九次转移成功，所以执行的后续指令被取消，带来了九次的控制相关的stall。

接下来，使用BTB技术：

执行完文件之后，查看执行周期：

这里也是先对程序执行结果进行一个简单的综述，之后再进行每个循环的分析，20次RAW相关导致的暂停和之前没有使用BTB时候是一样的，之后总共有4个周期的stall，前两个周期是第一次分支指令出来，这个时候BTB表内没有内容，那么就是默认继续执行，PC+4地址的指令，但是因为后续发现转移成功，所以之前的下一条指令的IF周期白干了，并且需要一个周期重新取指，把对应的分支指令和对应的目标地址存在BTB表中，所以带来了两个周期的浪费，对应上图中的branch taken stalls，而后的多个循环中，因为都是成功预测到了转移成功，所以没有周期浪费，直到最后一个周期，预测转移但是实际没有，所以又是两个周期的浪费。

接下来，以循环为单位，进行细致分析：
第一个循环：
不采用BTB的情况下，第一个周期分别因为load互锁，和分支指令ID段计算目标地址和转移条件需要的数据没有计算完成，所以有两个RAW相关，因为采用了预测分支转移失败，所以也有一个周期的浪费，即对应的branch taken stalls：

而采用了BTB的情况下，除了两个RAW相关和之前一样，这里一开始BTB表为空，预测不转移，所以这里出现了halt指令，也就是出循环后的指令，而在前面的转移指令转移成功之后，需要取消指令，并且把这条分支指令和对应的目标地址存到BTB表中，所以红箭头所指的就是BTB导致的两个branch taken stalls（中间那个只是RAW暂停的顺延）：

此时BTB表发生了变化（这里不考虑可选域的部分，因为对实验没有关系）：
从一开始的全空：

到现在的：

接下来，第二个循环：
不采用BTB的情况和之前没有区别。

采用BTB的情况下，除了两个RAW相关不变之外，因为此时的BTB表中已经有了对应分支指令地址的选择了，所以当同样的分支指令再次执行的时候，这次默认的就是转移成功，提前获得对应目标地址，所以可以看到这个周期的时候没有控制相关导致的暂停：

因为预测正确了，所以BTB表不会有变化。

然后从第三个循环开始到第九个循环，都是和第二个循环一样的情况，这里就不进行过多的说明了。

到最后的循环的第十个循环的时候：
没有采用BTB的情况，两次RAW相关都一样，然后是转移指令这里，因为这里循环结束转移失败，刚好编译器用的是预测转移失败，所以相当于一个周期没有浪费直接就可以直接之后最后的halt指令：

而采用了BTB的情况，除了两次RAW相关之外，这里还有两个周期的branch misprediction stalls，因为之前的BTB表中是有这个分支指令和对应的目标地址的，所以这里依旧是预测转移成功，但是因为这里转移实际是失败了的，所以需要取消指令，重新取指，并且把BTB表中对应的指令项删除，浪费了两个周期：

此时BTB表的变化：
从之前的：

到现在的全空：

总结：
BTB技术可以再循环执行的过程中减少分支指令带来的暂停，在实验过程中，因为这时分支指令一直在转移，而BTB中又刚好有这条指令对应的目标地址，默认转移成功的情况下可以一个周期都不浪费，减少分支指令带来的暂停，但是在循环刚开始的时候和循环结束的时候会导致暂停周期的增加，因为此时分支指令是否转移出现了变化，BTB方式给出了错误的判断，需要取消指令，重新取指并且修改BTB表，这会导致两个周期的控制相关暂停。

通过实验，我们可以发现：在预测正确的情况下，可以有效减少分支指令带来的暂停，因为这样可以在取指阶段的时候就提前判断出分支指令是否转移，转移的目的地址是哪里，这样就可以在下一个周期直接开始下一个指令的取指，不需要等到ID段计算转移条件和转移地址再取指，所以可以减少分支指令带来的暂停。在预测失败时候增加暂停，这是因为预测失败之后需要重新取指，并且把这个转移地址连同下一个PC送到转移目标缓冲器中。所以不仅没有节省下来之前分支指令的一个周期的暂停，还需要额外的周期进行BTB表修改。