從4004到core i7：處理器的進(jìn)化史（3）-4-第一次加速

　　假設我們的帶流水線(xiàn)CPU恰好就有5個(gè)環(huán)節分別完成以上的5個(gè)步驟，那么在上面的代碼中，某時(shí)刻：

　　[ID] mov reg2,reg1
　　[OC] mov reg1,1
　　[EX] nop
　　[WB] nop

　　下一時(shí)刻如果是這樣：

　　[OC] mov reg2,reg1
　　[EX] mov reg1,1
　　[WB] nop

　　就會(huì )產(chǎn)生錯誤：在OC環(huán)節進(jìn)行的是寄存器讀，我們本來(lái)應該讀到reg1=1，但是上面的情況中由于reg1=1沒(méi)有WB，我們讀到了reg=0!

　　正確地處理應該是這樣：

　　[ID] mov reg2,reg1
　　[OC]nop
　　[EX] mov reg1,1
　　[WB] nop

　　----------------------------

　　[ID] mov reg2,reg1
　　[OC]nop
　　[EX] nop
　　[WB] mov reg1,1

　　-----------------------------

　　[OC] mov reg2,reg1
　　[EX] nop
　　[WB] nop

　　----------------------------

　　[EX] mov reg2,reg1
　　[WB]nop
　　...

　　上面的情況叫做數據依賴(lài)(data dependency)，是降低流水線(xiàn)性能的主要原因。我們對數據依賴(lài)的解決辦法很簡(jiǎn)單：

　　對流水線(xiàn)中的指令更改的寄存器、內存都做記錄。在OC環(huán)節進(jìn)行審查，如果該指令讀取的寄存器、內存沒(méi)有掛起的更改(沒(méi)有還沒(méi)有WB的更改)，就執行讀取，否則便要等待直到最近的一條更改讀取的指令的WB執行之后才能執行。

　　對于內存的更改的實(shí)際情況要更復雜些，在這個(gè)帖子中先不講，留到后面和超標量網(wǎng)絡(luò )一起敘述。

　　在上面的等待過(guò)程中，我們在流水線(xiàn)中插入了一些nop指令，這種現象叫做空泡(bubble)。不難想象，在某些有著(zhù)20多級流水線(xiàn)的CPU中的bubble常常長(cháng)達十幾個(gè)環(huán)節。

　　數據依賴(lài)產(chǎn)生的最嚴重的空泡莫過(guò)于分支(branch)。你可能經(jīng)常在C源代碼中這樣寫(xiě)：

　　if(sel==1)
　　{
　　proc1();
　　}
　　else
　　{
　　proc2();
　　}

　　放到上面的5級流水線(xiàn)中考慮時(shí)，我們驚訝地發(fā)現：

　　sel==1這一判斷(CMP指令)的結果(常常是狀態(tài)寄存器的ZF位)要到WB的時(shí)候才能知曉，但它影響的卻是PC(程序指針)的值，也就是說(shuō)產(chǎn)生數據依賴(lài)的是IF階段!分支指令可能產(chǎn)生長(cháng)達5個(gè)環(huán)節的空泡!

　　正是由于分支指令對性能的極大損害，現代的CPU常常費盡心思地進(jìn)行分支預測(branch prediction)，期望盡量猜中分支指令執行的結果，盡可能減少極端的長(cháng)空泡。

　　不幸的是，分支是任何語(yǔ)言必不可少，甚至是最有用的部分：一個(gè)只能順序向下執行的程序有什么用呢?

　　你可以想象早期的CPU面對分支語(yǔ)句有多么無(wú)力。更加不幸的是，最?lèi)?ài)用分支語(yǔ)句的程序恰恰是必不可少的：編譯器!傳說(shuō)GCC中就有超過(guò)4000個(gè)if語(yǔ)句。

　　下面再從電路的層面上說(shuō)說(shuō)pipleline這件事：

　　CPU的執行引擎(execution engine)可以被看成一個(gè)巨大的邏輯電路。它有一個(gè)傳輸延時(shí)t_pd,logic，即它從輸入(IF開(kāi)始)到輸出(WB結束)的耗時(shí)。

　　在尋找最高時(shí)鐘頻率，即最小時(shí)鐘周期間隔時(shí)，自然有：