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

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

　　下一時刻如果是這樣：

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

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

　　正確地處理應(yīng)該是這樣：

　　[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
　　...

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

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

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

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

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

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

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

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

　　正是由于分支指令對性能的極大損害，現(xiàn)代的CPU常常費盡心思地進行分支預(yù)測(branch prediction)，期望盡量猜中分支指令執(zhí)行的結(jié)果，盡可能減少極端的長空泡。

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

　　你可以想象早期的CPU面對分支語句有多么無力。更加不幸的是，最愛用分支語句的程序恰恰是必不可少的：編譯器!傳說GCC中就有超過4000個if語句。

　　下面再從電路的層面上說說pipleline這件事：

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

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