标签:arch idt 操作 分解 block hit 物理 port tps
Re-order Buffer(ROB)是处理器中非常重要的一个模块,它位于renamer与scheduler(RS)之间,并且也是execution unit(EU)的出口。ROB作为指令处理的后端,其主要任务是存储指令经由EU处理后得到的结果,并把该结果按照in-order顺序写回到寄存器文件。
Intel没有给出详细的ROB pipeline,下面的pipeline的描述以及分析主要基于参考资料以及本人的一些推断,不一定准确,仅供参考。
ROB的目的为存储out-of-order的处理结果,并以in-order写回寄存器。不过早期的ROB与现在的ROB相比,虽然目的相同,但是实现却存在较大的区别,并且这部分的区别不仅仅在于ROB本身,还牵扯到out-of-order engine的其它部分。
早期的ROB的实现方式一直延续到Nehalem微处理器,从Sandy Bridge微处理器开始采用新的ROB实现方式。
早期ROB的相关部分的pipeline:
μops流经上述pipeline的过程分为以下几个步骤:
另外,有些μops是不需要经过EU的处理的,这些μops可以直接在ROB内等待retirement。
如上面的描述,μop在source就绪前会在RS内等待,在此期间,就绪的source会被传送到RS,一旦所有的source都就绪,并且相应的EU可用时,μop就会被调度过去执行。
source分为memory operand、register operand、immediate operand,其中需要等待的只有memory以及register相关的source,我们这里讨论的是register operand。
RS的source入口有三个:
in flight与register read在传输数据时都很块,问题在于ROB read。ROB向RS传输source的通道被称为ROB read port,每个read port在一个时钟周期内可以传输一个register operand,在P6上有两个read port,到了Core以及Nehalem时为3个。
以Core微处理器为例,现假设有两条如下的指令,并且edi、esi、esp、ebp都要从ROB获取:
mov [edi + esi], eax mov [esp + ebp], ebx
它们分解成μops:
tmp1 ← edi + esi mov [tmp1], eax tmp2 ← esp + ebp mov [tmp2], ebx
按由于两条指令之间没有依赖关系,所以如果EU可用的话,按理说第一、第三个μop可以同时被调度到不同的ALU(EU)执行。不过由于Core上只有3个read port,因此无法一次性读取四个source,那么就有一个μop需要延迟执行。
从程序上来说,出现这种情况的原因主要是频繁使用了Based Indexed Addressing以及对寄存器写入后间隔较长才去读取。因此避免出现ROB read port stalls的措施也比较简单:不要频繁使用Based Indexed Addressing以及对寄存器的写后读取读操作尽量别间隔太长。
从Sandy Bridge微处理器开始,intel就采用了全新的ROB pipeline,其中ROB不再用于存储执行结果,而是只用于记录μops的状态,如下图所示
EU在处理完μop后直接写回物理寄存器(PRF)并改变ROB中μop的状态,然后RAT就可以根据ROB中的状态调整PRF映射,使得用户层看起来指令在以in-order的方式执行。这种ROB实现方式没有了ROB read port的限制,因此ROB read port stalls的现象不复存在。
Reference:
Intel® 64 and IA-32 Architectures Optimization Reference Manual
Agner Fog - The microarchitecture of Intel, AMD and VIA CPUs
David Kanter - Inside Nehalem: Intel’s Future Processor and System
David Kanter - Intel’s Sandy Bridge Microarchitecture
标签:arch idt 操作 分解 block hit 物理 port tps
原文地址:http://www.cnblogs.com/TaigaCon/p/7604152.html