【提交】commit
文章目錄
- 1. 重排序緩存
- 2. 管理處理器狀態
- 2.1 使用ROB管理指令集定義的狀態
- 2.2. 使用物理寄存器管理指令集定義的狀態
- 3. 特殊情況處理
- 3.1 分支預測失敗
- 3.1.1 基于ROB進行重命名的架構中進行狀態恢復
- 3.1.2 在基于同一的PRF進行重命名的架構中進行狀態修復
- 3.2 異常處理
- 3.3 中斷的處理
- 3.4 Store指令處理
- 3.5 指令離開流水線的限制
1. 重排序緩存
本質上是FIFO. 存儲指令的類型，結果，目的寄存器和異常的類型。ROB容量決定了流水線中最多可以同時執行的指令個數。
4-way超標量處理器ROB端口需求：
- 寄存器重命名階段 ：四條指令源操作數ROB需要8個讀端口
- 提交階段：四條指令退休（最少，實際issue width更寬）需要4個讀端口
- 分發階段：寫入ROB四條指令，需要4個寫端口
- 寫回階段：寫入四條指令結果，最少需要4個寫端口
2. 管理處理器狀態
Architecture State 和 Speculative State
2.1 使用ROB管理指令集定義的狀態
ARF也稱為RRF(retire register file)。
一般配合數據捕捉。payload RAM.
不管指令從旁路網絡、ROB還是通用寄存器中取得操作數，最后都需要在進入流水線執行階段之前，從payload RAM中得到操作數，這種方式不關心操作數位置變化。
ROB+非數據捕捉有較高的硬件復雜度。
2.2. 使用物理寄存器管理指令集定義的狀態
使用統一的物理寄存器堆PRF。指令集中定義的所有寄存器堆都混在這個寄存器堆中。
一條指令退休時，這條指令結果仍然占據原來對應的物理寄存器，狀態會標記為Architecture state，等到后續有另外一條指令也寫到同一個目的寄存器，并且這條后續指令退休時，才可以將當前這條指令對應的物理寄存器釋放。
優點：
缺點：
需要額外表格存放那些物理寄存器是空閑的；需要額外表格存放哪些物理寄存器是Architecture state。
3. 特殊情況處理
- 分支預測失敗
- 異常
- store
3.1 分支預測失敗
以寄存器重命名階段為界：
- 前端恢復 front-end recovery：重命名階段之前的指令抹掉，分支預測器中的歷史狀態表（GHR、BHR等）進行恢復，并使用正確的地址取指令。
- 后端恢復 back-end recovery：Issue Queue、Store buffer和ROB錯誤的指令抹掉，將RAT恢復，同時被錯誤指令占據的物理寄存器和ROB的空間也需要被釋放。
當Time(back?endrecovery)<Time(front?endrecovery)+Time(fetch?renaming)Time_{(back-end\ recovery)}<Time_{(front-end\ recovery)}+Time_{(fetch-renaming)}Time(back?end?recovery)?<Time(front?end?recovery)?+Time(fetch?renaming)?此時，流水線不需要暫停。
大部分恢復任務都是對寄存器重命名相關的部件進行的，重命名的方式直接決定了使用何種方法進行狀態恢復。
基于ROB和使用擴展的ARF進行重命名在本質上一樣，因此這里主要總結兩種分支預測失敗時進行狀態恢復的方法。
3.1.1 基于ROB進行重命名的架構中進行狀態恢復
使用ARF對重命名階段使用的RAT進行恢復
只有一條指令從ROB退休時，發現自身時最新的映射關系，才能夠將RAT中對應的內容改為ARF狀態。
流水線抽干 drain out. 分支指令之前的所有指令退休，抹掉流水線的錯誤指令，然后將RAT中的所有內容都標記為ARF狀態。但是分支指令前有load指令D-cache misss時，miss-prediction penalty變大。
3.1.2 在基于同一的PRF進行重命名的架構中進行狀態修復
該架構中，流水線存在兩個重命名映射表。
- 寄存器重命名階段的前端RAT：狀態是推測的，也稱作Speculative RAT.
- 提交階段的后端RAT：Architecture RAT
1. drain out 后使用后端RAT對分支預測失敗時的處理器進行狀態恢復（將后端RAT復制到前端RAT）。
這種方式分支指令前有load指令D-cache misss時，miss-prediction penalty變大。跟ROB狀態恢復方法一樣，都需要等待預測失敗的分支指令退休的時候，才能進行處理器的狀態恢復。這類方法稱作Recovery at Retire.
使用后端的映射表對重命名階段使用的RAT恢復。
2. Checkpoint方法快速狀態恢復。不需要等分支指令退休，而是預測失敗時馬上狀態恢復。
在分支指令及后面的指令對RAT更改之前，將RAT的內容保存起來。預測失敗時，使用這條分支指令編號將錯誤路徑上的指令抹掉，同時使用checkpoint資源將處理器狀態恢復，然后就可以從正確路徑上取指令執行。
對基于SRAM的RAT. 硬件資源昂貴，無法支持個數很多的checkpoint。因此，當分支預測正確率很高時，可以對分支指令預測的正確率進行預測。
當一條分支指令對應的飽和計數器處于飽和狀態，說明它的預測正確率比較高，對這樣的分支指令不分配checkpoint資源。對經常預測錯誤的分支指令才進行checkpoint。
當一條分支指令沒有分配checkpoint最后又分支預測失敗時，可以采用等到這條分支指令退休時，使用Recovery at retire。這種方式較慢，因此也可以通過ROB將RAT恢復。ROB記錄RAT被修改的歷史。當一條指令重命名時，除了將這條指令當前的映射關系寫到ROB之外，還需要將這條指令對應的舊的映射關系也寫道ROB中，ROB記錄每條指令對RAT的修改，因此一條分支指令沒有分配checkpoint時，可以通過ROB將RAT恢復。
對基于CAM結構
6T SRAM cell plus 4 comparison transistors
BL: bit line ML: match line SL: search line
進行checkpoint只需要對RAT中的狀態位保存。需要的硬件資源少。可以支持很多checkpoint。
缺點是電路面積和延遲很大，表格容量正比于物理寄存器個數，PR很多RAT電路面積就很大；而且CAM尋址延遲很大。
3.2 異常處理
精確異常：處理器知道哪條指令發生異常，并且這條發生異常的指令之后所有指令都不允許改變處理器的狀態，好像這些指令從來沒有發生過一樣。對異常處理完后可以精確返回，可以返回發生異常的指令本身（TLB miss），也可以返回到它的下一條指令開始執行（syscall）。
1. recovery at retire 式處理
此時要完成的任務和recovery at retire情形一樣。處理器狀態恢復后，可以跳轉到對應的異常處理程序的入口地址，取新的指令執行。
這種方法好處是，假如異常處于分支預測失敗的路徑上，其實異常是無效的，因此會被抹掉不被處理。
2. WALK方法
從tail pointer開始將對應的舊的映射關系寫到重命名映射表中。
使用統一的PRF進行寄存器重命名方式中，還需要恢復與RAT相關的兩個表格。即：
- Free Register Pool：存儲哪些物理寄存器是空閑狀態。
需要恢復讀指針。每當ROB中讀取一條存在目的寄存器的指令對RAT進行恢復時，就將Free Register Pool的讀指針也變化一格。 - Busy Table：存儲每個物理寄存器的值是否已經被計算出來。
指令將結果寫到PRF時，將Busy Table對應狀態進行修改。在從ROB中讀取指令進行狀態恢復時，每讀取一條指令，就將這條指令的目的寄存器在Busy Table中對應的內容置為無效。這樣即使這條指令將結果已經寫到PRF中，也可以將其變為無效，后續指令不會使用錯誤的值。
對于異常發生時的處理器來說，如果采用ROB進行重命名的架構，使用recovery at retire 方法是合適的；而對于采用統一的PRF進行重命名的架構，使用WALK方法更好（recovery at retired方法對兩個表格的狀態恢復沒那么直接）
3.3 中斷的處理
中斷是異步的，有兩種方式對中斷進行處理。
3.4 Store指令處理
一條store指令在緩存中有三個狀態，即沒有執行完畢（un-complete）、已經執行完畢（complete）和順利離開流水線（retire）。處于retire狀態的內容也成為處理器狀態（architecture state）的一部分。
只有真正完成D-Cache操作的store指令才可以離開store buffer，會造成它實際可用容量降低，因此也可以將退休的store指令存儲在write back buffer。
load指令需要在store buffer和write back buffer這兩個緩存中都進行查找。
非阻塞結構的D-cache?
3.5 指令離開流水線的限制
因為不值得為不經常出現的情況而浪費硬件資源（比如一個周期需要四條branch\load\store退休，需要很多寫端口；釋放資源等），所以需要在提交階段對分支指令、store指令和load指令的個數都進行限制。
每周期也只能處理一條指令的異常。
總結
以上是生活随笔為你收集整理的【提交】commit的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 读书计划与交流的期望
- 下一篇： 云服务器的优缺点