学习笔记——分支预测入门

考试题：

1、《[我要考试]计算机体系结构_威斯康星_博士资格考试_Fall2000_Q2》

资源：

1、中科大_高性能处理器体系结构_L5_分支预测

正文如下：

========

看体系结构，看了流水线，知道流水线流起来之后，就会产生hazard，然后就会对hazard进行分类，找出解决hazard的方法；然后大伙蜂拥而上，发现hazard中，对于branch
hazard这部分带来的性能影响很大，根据量化书中写的，branch带来的性能影响是10%~30%，并且流水级数越长，性能影响越大，这个其实很好理解的。所以大伙就集中精力解决这个问题了。然后出现了各种方法了啊，根据书上写的，以及我的理解，对于分支指令的处理就两大类：静态的和动态的。

所谓的静态分支处理方法，就是不依靠程序执行期间的信息进行处理，静态的方法一般也就如下了哦：

1）出现branch，就冻结流水线——这是傻瓜也能想出的方法；

2）认为branch一定会token；

3）认为branch一定不会token；

4）由于branch的执行，第一步是IF取指令，然后第二部是译码，即ID，在第二阶段ID才能判断出当前指令是否是branch指令，为此可以在ID阶段继续取一条指令，作为分支指令的delay slot，这条指令不管branch是否token，都会执行。

所谓的动态分支处理方法，是指利用程序执行期间的信息，进行处理，所以这儿很明显带来的是硬件开销，因为程序执行期间是不可能由软件协助的，否则性能影响也就太大了吧。相对的，静态分支处理，其实是利用编译器实现的。

然后接下来，我想基于我的学习吧，把这部分好好介绍下。

然后让我十分不解的是：国内现在居然还有很多人在搞分支预测，提出创新，我觉得就是XX（脏话），然后还有著名高校的学生根据分支预测出硕士论文了，就最近2年的事情，我十分不解！这玩意，还能搞出多少创新呢？有考虑过Balance么？哎……

+++++++++++++++++++++++++++++

+++++动态分支预测

+++++++++++++++++++++++++++++

分支预测，有静态的和动态的。这儿把动态的分支预测基础方法理一下。

现在一般的处理器中，对于动态分支预测算法，支持的基本功能是BTB和BHT两个基本逻辑。

BTB——Branch Target Buffer——分支目标缓冲，记录分支的“目标”即跳转地址的缓冲

BHT——Branch Histroy Table——分支历史表，记录分支指令是否token

实际上在现在的处理器中，存在多级分支预测处理逻辑，至于为什么会这样，道理很简单：因为在现在的处理器中，流水线级数越来越长，人家有的已经有20级流水了，所以分支预测失败的后果就很严重，而理想的分支预测是在第一个流水级就能预测出来，然后取到下一条正确的指令，这样不会造成流水级的stall，但实际是不可能的。

所以在设计分支预测的时候，是希望以最快的速度能获取到下一条可能的指令，注意，这儿是指可能的指令。但是体系结构设计的核心是balance，以最快的速度获取指令，需要较少的时钟周期，但带来的是预测准确率的下降；如果希望提高准确率，则是较慢的速度；这怎么办呢？鱼和熊掌不可兼得啊——要快，使得流水线不stall，则准确率下降，而准确率下降有可能导致流水线重新flush；要准确率上升，就要时钟周期计算，流水线就要stall。

所以，大伙采取的方法是利用多级分支预测算法：第一级的分支预测准确率不是那么的高，但马上就能获得结果，这个时候流水线根据第一级的预测结果去取指令，注意，这儿的指令有可能是正确的分支结果，也有可能是错误的，但没关系，反正追求的是快！第二级的分支预测准确率相比第一级高一点，但需要更多的时钟周期，流水线执行到这个时候，就利用第二级的分支结论，决定是否要重新取指令——如果第二级的分支预测结果和第一级不一样，则是重新取指令；如果第二级的分支预测结果和第一级一样，则不重新去指令，继续执行；而到了最后真正计算出分支结果，则是得到100%的准确率，这时候还需要更多的时钟周期。

多级分支预测存在的问题：第二级的分支结果也是“预测”实现的，即这个结果不能保证一定就是正确的，只能保证在统计概率上比第一级准确，因此，有可能出现的就是：第一级预测结果准确率不高，但针对某条具体指令预测结果是对的；第二级预测准确率高，但针对某条具体指令预测结果是错的；这样，流水线还是会根据第二级预测结构重新取指令，虽然这条指令是错误的。

那么，我们应该在什么阶段进行分支预测呢？当然是越快越好！

考虑教学用5级流水线结构，第一级是取指令，这个时候，我们是不知道这条指令是否是分支指令的；第二级是译码，这个时候才能知道某条指令是否是分支指令的。为此，针对分支预测，则最快也才能在第二级才能进行分支预测，而进行预测也需要一个时钟周期的，因此，也就说，在第三级才能得到分支的结论：是否需要跳转。假设分支预测都是准确的，这个时候最少也会在流水线中插入两级stall，而不是一级stall。

为此带来的流水性能损失是不可接受的。大家也就继续想办法：能否再取指令的同时，进行部分译码呢？因为RISC的指令集都比较规整，分支指令的编码方式也比较规整，进行部分译码需要的逻辑不算多，不会过都影响流水线的时钟周期提升。

这个时候可以把上面的BHT以及BTB用上了，不过BTB和BHT是分别用在两个地方的：

BHT——Branch History Table，顾名思义，这是记录分支历史信息的表格，用于判定一条分支指令是否token；这儿记录的是跳转信息，简单点的，可以用1bit位记录，例如1表示跳转，0表示不跳转，而这个表格的索引是指令PC值；考虑在32位系统中，如果要记录完整32位的branch
history，则需要4Gbit的存储器，这超出了系统提供的硬件支持能力；所以一般就用指令的后12位作为BHT表格的索引，这样用4Kbit的一个表格，就可以记录branch history了。当然，通过大伙的不懈努力和分析，发现在BHT中用1bit位记录分支是否跳转还不够准确，用2bit位记录就非常好了，而用3bit或者更多位记录，效果与2bit类似。所以在BHT中，一般就用2bit位记录分支是否跳转：例如11和10表示这条分支会跳转；01和00表示分支不会跳转。这个2bit计数器大伙叫做饱和计数器。

BTB——用于记录一条分支指令的跳转地址，由于这儿存储的是指令地址，例如32位地址，因此，这个表格就不能做到存储BHT那样多的内容了，如果也支持4K条指令，则需要128Kbit的存储空间，这几乎可以赶上一个L1Cache的容量了，所以BTB一般很小，就32项或者64项。由于这个BTB容量小，并且其用于是记录分支指令的跳转地址，因此，如果这条指令不跳转，即其下一条指令就是PC+4，则不会在BTB中记录的。

基于BTB和BHT的分支预测就很简单了：

1）在取指阶段利用PC寻址BTB，如果命中，则说明这是一条跳转指令，利用从BTB中获取到的地址去取icache；

2）由于BTB中保存的内容不够多，因此BHT的准确率更高，这个时候索引BHT表格，如果发现BHT也跳转，则说明这条指令预测是跳转的；如果BHT不跳转，则说明不跳转，这个时候就取消BTB中的指令地址，重新PC+4去取icache；