issue queue的实现方式

主要从一下几个点进行考虑:

  • 集中式(Centrallized)或者分布式(Distributed);
  • 压缩式(Compressing)或者非压缩式(Non-compressing);
  • 数据捕捉的方式(Data-capture)或者非数据捕捉方式(Non-data-capture);

上述三种结构都是正交的,可以相互组合;

集中式VS分布式

        在超标量处理器中,为了并行执行指令,一般都有很多的FU,例如有些FU负责整数的加减,有些FU负责存储器访问,有些FU负责乘除法运算等。

  • 如果所有的这些FU都共用一个发射队列,称这种结构为集中式的发射队列(Centralized Issue Queue,CIQ);
    • CIQ因为要负责存储所有FU的指令,所以它的容量需要很大
    • 这种设计有着最大的利用效率,不浪费发射队列中的每一个空间,但是会使选择电路和唤醒电路变得比较复杂,因为需要从数量庞大的指令中选择出几条可以被执行的指令(个数取决于每周期最多可以同时执行的指令个数,这个值通常称为Issue Width)
    • 这些被选中的指令还需要将发射队列中所有相关的指令都进行唤醒,这都增加了选择电路和唤醒电路的面积和延迟。
  • 而如果每个FU都有一个单独的发射队列,称这种结构为分布式的发射队列(Distributed IssueQueue,DIQ)。
    • DIQ的设计方式,为每一个FU都配备一个发射队列,所以每个发射队列的容量可以很少,这样就大大简化了选择电路的设计(每个发射队列都对应一个选择电路)。
    • 但是当一个发射队列已经满了时,即使其他的发射队列中还有空间,也不能够继续向其中写入新的指令,此时就需要将发射阶段之前的所有流水线都暂停,直到这个发射队列中有空闲的空间为止。
    • 即使此时其他 FU 的发射队列中还存在空间,也需要将发射阶段之前的流水线都暂停,这样就造成了发射队列利用效率的低下,而且,由于它的分布比较分散,进行唤醒操作时所需要的布线复杂度也随之上升。
  • 现代处理器的折中方式:使某几个FU共用一个发射队列;

数据捕捉 VS 非数据捕捉 

 对于超标量处理器来说,还需要考虑一个重要的事情,就是在流水线的哪个阶段读取寄存器的值,它直接决定了处理器中其他一些部件的设计。

  • 在流水线的发射阶段之前读取寄存器,这种方法也称为数据捕捉(Data-capture)的结构。
    • issue queue的实现方式_第1张图片
    • 寄存器重命名之后的指令会首先读取物理寄存器堆(PhysicalRegister File),然后将读取到的值随着指令一起写入发射队列中。
    • 如果有些寄存器的值还没有被计算出来,则会将寄存器的编号写到发射队列中,以供唤醒(wake-up)的过程使用,它会被标记为当前无法获得(non-available)的状态,这些寄存器都会在之后的时间通过旁路网络(bypassing network)得到它们的值,不需要再访问物理寄存器堆。
    • IQ中,存储指令操作数的地方,称之为payload RAM;
      • issue queue的实现方式_第2张图片
      • 当指令从发射队列中被仲裁电路选中时,就可以直接从payload RAM中对应的地方将源操作数读取出来,并送到FU中去执行。
      • 被选中的同时,它会将目的寄存器的编号值进行广播
      • 发射队列中其他的指令都会将自身的源寄存器编号和这个广播的编号值进行比较,一旦发现相等的情况,则在payload RAM对应的位置进行标记
      • 当那条被选中的指令在FU中计算完毕时,就会将它的结果写到payload RAM这些对应的位置中,这是通过旁路网络(bypassing network)来实现的
    • 这种方式就像是payload RAM在“捕捉”FU计算的结果,所以称为数据捕捉(data-capture)结构;
      • 其中,issue queue负责比较寄存器的编号值是否相等;
      • payload RAM负责存储源操作数,并捕捉对应FU的结果;
    • 一些概念:
      • machine width:表示每周期实际可以decode和rename的指令个数;
      • issue width: 每周期最多可以在FU中并行执行的指令个数(即发射个数);
      • 假设每条指令2个源操作数,则PRF需要读的物理端口个数为:machine width x 2;
  • 非数据捕捉方式

压缩式vs非压缩式

你可能感兴趣的:(risc-v,risc-v)