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)的结构
    • 寄存器重命名之后的指令会首先读取物理寄存器堆(PhysicalRegister File),然后将读取到的值随着指令一起写入发射队列中。
    • 如果有些寄存器的值还没有被计算出来,则会将寄存器的编号写到发射队列中,以供唤醒(wake-up)的过程使用,它会被标记为当前无法获得(non-available)的状态,这些寄存器都会在之后的时间通过旁路网络(bypassing network)得到它们的值,不需要再访问物理寄存器堆。
    • IQ中,存储指令操作数的地方,称之为payload RAM;
      • 当指令从发射队列中被仲裁电路选中时,就可以直接从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;
  • 非数据捕捉方式
    • 在流水线的发射阶段之后,再读取物理寄存器;
    • 在这样的设计中,被重命名之后的指令不会去读取物理寄存器堆,而是直接将源寄存器的编号放到发射队列中
    • 当指令从发射队列中被选中时,会使用这个源寄存器的编号来读取物理寄存器堆,将读取的值送到FU中去执行。由于在发射队列中不需要存储源操作数的payload RAM了,所以它可以被“瘦身”,也就增加了处理的速度。
  • 两种方式的比较:
    •  捕捉方式,占用的面积会更大一些。而且,在这种方法中,很多源操作数都需要经历两次读和一次写的过程,即从寄存器中读取出来,写到发射队列中,然后再从发射队列中读取出来送到FU中执行,很显然,这会消耗更多的能量,不利于实现低功耗的处理器。
    • 而采用在流水线的发射阶段之后读取寄存器的方式,需要寄存器堆有着更多的读端口,但是在发射队列中不再需要存储源操作数,所以发射队列在面积和速度方面会好一些,源操作数也只需要读取一次就可以了,因此相比于另一种方法,它的功耗会低一些。

压缩式vs非压缩式

  •  压缩的发射队列(Compressing Issue Queue)
    • 每当一条指令被选中而离开发射队列时,会出现一个“空隙”,这条指令上面所有的指令都会下移一格,将刚才那条指令的“空隙”填上。
    • 发射队列当中的这些指令,从上往下看,是按照“最新→最旧”的顺序排列的,新来的指令会从发射队列上面的空闲空间开始写入。
    • 通过这种方式,可以保证空闲的空间都是处于发射队列的上部,此时只需要将重命名之后的指令写到发射队列的上部即可;
    • 这种方式,需要每个entry的内容,都能够移动到其下方的entry中,这就需要再每个entry的前面,加上一个多路选择器;
      • 这种压缩的设计方法,一个比较大的优点就是其选择(select)电路比较简单,为了保证处理器可以最大限度地并行执行指令,一般都从所有准备好的指令中优先选择最旧(oldest)的指令送到 FU 中执行,这也称为 oldest-first 方法
      • 而这种压缩方式的发射队列已经很自然地按照“最新→最旧”的顺序将指令排列好了,因此只需要简单地使用优先级编码器进行选择即可。
      • 发射队列中每条指令发出的请求信号都受到它之前指令的影响,只有比它旧的所有指令都没有被选中时,这条指令才有被选中的资格;
    • 该种方式的特点: 
      • 选择发射entry的延迟与发射队列的容量成正比,发射队列中,可以容纳的指令个数越多,延迟也就越大;
      • 分配(allocate)电路很简单,发射队列的空闲空间总是在上部,因此只需要使用发射队列的写指针,指向第一个空闲的空间即可;
      • 选择(select)电路很简单,因为最新,最旧的顺序已经拍好了,因此使用priory encoder来找到已经准备好的,最旧的指令,即实现了oldest-first功能;
      • 实现起来比较浪费硅片的面积;主要是选择电路和布线资源太多;
      • 功耗大,因为每周期需要进行数据移动,因此功耗很大;
  •  非压缩的发射队列(Non-Compressing Issue Queue) 
    • 在这种方法中,顾名思义,就是每当有指令离开发射队列的时候,发射队列中其他的指令不会进行移动,而是继续停留在原来的位置,此时就没有了“压缩”的过程。
    • 在这种方法中,空闲空间在发射队列中的分布将是没有规律的,它可以位于发射队列中的任何位置,因此发射队列当中的指令将不再有“最新→最旧”的顺序,不能够根据指令的位置来判断指令的新旧。
    • select logic, 从发射队列的最下面的指令开始寻找,直到遇到第一条准备好的指令为止;但是这种选择电路,其实是一种比较随机的选择,因为inst的年龄信息,与其在发生队列中的位置,是没有关系的;
    • 这种基于位置的选择电路实现起来很简单,也不会产生错误,但是由于没有实现 oldest-first 的功能,所以没有办法获得最好的性能。       
    • 该实现方式的特点如下:
      • 采用非压缩的发射队列,优点是其中的指令不再需要每个周期都移动,这样大大减少了功耗,也减少了多路选择器和布线的面积。
      • 要实现 oldest-first 功能的选择电路,就需要使用更复杂的逻辑电路,这会产生更大的延迟;
      • 分配(allocation)电路也变得比较复杂,无法像压缩方法中那样直接将指令写入到发射队列的上部即可,而是需要扫描发射队列中所有的空间,尤其是当每周期需要将几条指令写入时,需要更复杂的电路来实现这个功能。
  • 25
    点赞
  • 22
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值