• DEC 的 Alpha 21264 是 superscalar CPU 的一個典範，其為 4-way out-of-order superscalar CPU，工作頻率是 466 ~ 667 MHz，benchmark：SPECint95 - 40、SPECfp95 - 86；與同時期其他的處理器 benchmark 對比：

  

• Alpha 21264 的 pipeline 最多同時支持 80 條指令，以及 80 個 checkpoints，因此對於 branch mis-prediction、exception、interrupt，Alpha 21264 都可以快速地恢復 CPU 狀態

• Alpha 21264 的分支預測器實現了基於局部歷史 (Local prediction) 和基於全局歷史 (Global prediction) 兩種預測方式，並根據程式的執行情況，動態選擇預測率最高的方法，這就像是兩種分支預測方式在進行競爭一樣

• 對於 load/store 指令，Alpha 21264 採用了 Speculative Memory Disambiguation 和 Load hit/miss Prediction

• Alpha 21264 採用 7-stage pipeline，比較短的 pipeline 使 branch mis-prediction 發生時的 mis-penalty 比較低，從而提高處理器的效率：

  

• Alpha 21264 所使用的設計理念是領先於那個時代的，包含競爭的分支預測、store/load 指令間的相關性預測，數量豐富的 checkpoints 等，它的設計理念被用到了未來的 AMD 和 Intel CPU 中，直接或間接地影響了現代電腦產業

11.2 - 取指令和分支預測

• Alpha 21264 每個 cycle 可以從 I-Cache 中讀取四條指令進 pipeline，其 I-Cache 的 size 為 64 KB、採用 2-way associative，並使用了 2 個 stages 來讀取 I-Cache：fetch0 和 fetch1
  • fetch0：讀取 I-Cache，但這個 cycle 只能得到 I-Cache 的指令 (i.e. data) 和 tag，無法再做其他的事情
  • fetch1：進行 tag 比對的同時，還會將指令送到 decoder 和 register renaming 相關的元件
    • 在 Alpha 21264 中，這個傳輸需要跨越大半個晶片，比較花時間，這也是 Alpha 21264 使用了 2 個 stages 來讀取 I-Cache 的原因
• Alpha 21264 每個 cycle 都需要向 I-Cache 發送位址來讀取指令，為了盡早察覺到分支指令和分支指令的目標位址，Alpha 21264 透過兩個方法來提昇 instruction fetch 的準確度：
  • line/way 的預測 - 較簡單的分支預測器，可以在 fetch0 就得到結果，但是預測準確度比較低
  • 分支預測 - 較複雜的分支預測器，需使用 2 個 cycles，也就是 fetch1 才能得到結果，但是預測準確度比較高
    • 如果發現 fetch0 的預測結果與 fetch1 的預測結果不符，則會拋棄 fetch0 的預測結果，使用 fetch1 的預測結果來 fetch instruction，但也會因此產生 1 個 cycle 的 bubble
      • i.e. 使用 fetch0 的預測結果讀進來的 instruction 會被 flushed 掉

11.2.1 - line/way 的預測

• Alpha 21264 在 fetch stage，為了可以盡快地從 I-Cache fetch 指令，對 I-Cache 的 instruction fetch 位址也進行了預測，這就是 line/way 預測

  • 這種方法本質上就是將 BTB 放進了 I-Cache 中

• 由於 Alpha 21264 每個 cycle fetch 的四條指令必須是 4 words aligned 的，因此只需要對每條 cache line 中每一組 4 words aligned 的四條指令使用一個 line/way 預測即可：

  

  • 對於一條 64 bytes 的 cache line，需要使用 4 個 line/way 預測 (64 bytes / (4 words * 4 bytes/word) = 4)，每個 line/way 預測包含了以下的資訊：
    • Successor way：
      • 下一個 cycle 要取的 fetch group，位在 I-Cache 的那個 way
        • E.g. 4-way set-associative I-Cache，共需要 2 bits 來表示
    • Successor index：
      • 下一個 cycle 要取的 fetch group，第一條指令在 cache line 中的位置
        • E.g. 一個 64 KB、2-way set-associative cache、cache line 為 64 bytes 的 I-Cache：
          • 需使用 PC[14:6] ⇒ 9 bits (64 KB / 2-way set-associative / 64 byes = 512 bytes) 來找到一條 cache line
          • 需使用 PC[5:2] ⇒ 4 bits (64 bytes / 4 bytes/word ⇒ 16，一條 cache line 中共有 16 個 words) 來找到 cache line 中的某個 word
          • 因此，Successor index 只需儲存 PC[14:2] ⇒ 13 bits 即可
    • Branch position：
      • 此 cycle 所取出的 fetch group 中，如果存在分支指令，則將這條分支指令的下一條指令的位址資訊記錄在 branch position 欄位
      • 之所以不記錄分支指令本身的位址資訊，而是其下一條指令的位址資訊，是因為如果此 cycle 取出的 fetch group 中存在預測會跳轉的分支指令，則它後面的指令都不會進入 pipeline，但分支指令本身是會進入 pipeline 的
        • 因此記錄分支指令的下一條指令的位址資訊更容易找到此 cycle 所取出的 fetch group 中，哪些指令不應該進入 pipeline
        • 當此 cycle 所取出的 fetch group 中不存在分支指令，或是存在預測結果為不跳轉的分支指令時，只需將 branch position 寫入 2’b00，就可以表示 “此 cycle 取出的 fetch group 中的所有指令，都需要進 pipeline” 了
        • 如果預測跳轉的分支指令是這個 fetch group 的最後一條指令，那麼這個 fetch group 中的每條指令也都應該進 pipeline，同樣也只需將 branch position 寫入 2’b00 即可

• 在 Alpha 21264 中，當一個 cache line 從 L2 Cache 讀進 L1 I-Cache 時，這條 cache line 包含的所有預測資訊都會被初始化為“沒有需要跳轉的分支指令”，此時 line/way 的預測資訊會指向下一個 PC 值，i.e. PC + sizeof(fetch group)

  • 一旦在後面的過程中發現這個預測資訊是錯的 (e.g. fetch1 的預測結果與 fetch0 的預測結果不同)，就會修改 cache line 中的所記錄的預測資訊
  • 可以按照之前 2-bit saturating counter 的方式來管理 line/way 的預測值，也就是只有當連續兩次預測失敗時，line/way 的預測值才會改變

• 每個 cycle 都會依據目前 fetch group 的 line/way 的預測器，決定下個 cycle 要 fetch 的指令位址

• 範例：

  

  • 64 KB I-Cache，2-way set-associative，每條 cache line 是 32 bytes (i.e. 32 bytes / 4 bytes/word = 8 words)，每 4 個 words 使用一個 line/way 預測器，因此每條 cache line 都包含了 2 個 line/way 預測器
    • 可以用 PC[14:2] 從 I-Cache 中找到需要的指令
    • Cycle 0：
      • PC = 0x20580354，對應到 way 0；由於每個 cycle fetch 的四條指令必須是 4 words aligned 的，因此只能讀出三條指令
      • Branch position = 2’b00，因此這三條指令都會進 pipeline
        • i.e. A0 ~ A2 會進 pipeline
      • Successor index = 0x360，因此下一個要 fetch 的指令位址：0x20580360
    • Cycle 1：
      • PC = 0x20580360，對應到 way 1；由於是 4-word aligned 的，因此四條指令都可以被讀出
      • Branch prediction = 2’b11，因此最後一條指令不會進 pipeline
        • i.e. A3 ~ A5 會進 pipeline
      • Successor index = 0xa28，因此下一個要 fetch 的指令位址：0x20580a28
    • Cycle 2：
      • PC = 0x20580a28，對應到 way 1；由於每個 cycle fetch 的四條指令必須是 4 words aligned 的，因此只能讀出兩條指令
      • Branch position = 2’b00，因此這兩條指令都會進 pipeline
        • i.e. B0 ~ B1 會進 pipeline
      • Successor index = 0xa30，因此下一個要 fetch 的指令位址：0x20580a30
    • Cycle 3：
      • PC = 0x20580a30，對應到 way 1；由於是 4-word aligned 的，因此四條指令都可以被讀出
      • Branch prediction = 2’b11，因此最後一條指令不會進 pipeline
        • i.e. B2 ~ B4 會進 pipeline

• Line/way 預測方法相當於將 BTB 放到了 I-Cache 中，然後相較於獨立的 BTB：

  • 缺點：
    • 每條 cache line 都要使用固定個數的預測資訊，例如上述範例，每條 cache line 都包含了 2 個 line/way 預測器：32 bytes cache line / (4 words * 4 bytes/word)) = 2
      • 然而很多 cache line 中其實並沒有分支指令，浪費硬體空間
      • 獨立的 BTB 不會有這個問題，因為它只會將預測結果為跳轉的分支指令放進 BTB 中
    • 隨著 cache line size 的增大，所需要的 line/way 預測器的個數也會跟著增多
      • E.g. 64 bytes cache line 需要使用 4 個 line/way 預測器
      • 獨立的 BTB size 都是固定的，不會隨著 cache line size 的變化而改變
    • 每當一條 cache line 被 replace 時，它的 line/way 預測資訊會被預設值所取代
      • 預設值 ⇒ successor index 會指到下一道 PC address
      • 獨立的 BTB 則與 cache replacement 無關

• 在 fetch1 stage 會驗證 fetch0 stage 的預測結果是否正確

  • 將 cache 的 tag (i.e. PC[47:15]) 與 successor index (i.e. PC[14:2]) 合併，就可以組成使用 line/way 預測的 PC address，在 fetch 1 stage，就可以與使用分支預測的預測結果相比，如果 PC address 不同，就代表 line/way 的預測錯誤，就會改使用 fetch1 stage 分支預測的 PC address 重新 fetch 指令
    • 因此會產生 1 個 cycle 的 bubble，也就是 line/way 預測的 mis-penalty
  • Alpha 21264 是使用 VIVT 架構的 I-Cache，因此 PC address 可以直接比對
  • 如果是使用 VIPT 架構的 I-Cache，由於 tag 是 physical address，因此還需要將 fetch1 分支預測的 PC address (VA) 透過 TLB 轉換成 PA 才可以比對 line/way 的預測結果是否正確
    • 因此，使用 line/way 預測時，使用 VIVT 架構的 I-Cache 是比較合理的設計

• Line/way 預測總結：

  

11.2.2 - 分支預測

• 為了獲得準確的分支預測，Alpha 21264 使用的分支預測器是比較複雜的，因此無法在 fetch0 stage 完成，需要使用 2 個 stages，在 fetch1 stage 才可以獲得預測結果

  • 這個結果會和 line/way 的預測結果做比較，如果發現不一致，就以分支預測的結果為主

• Alpha 21264 使用了競爭的分支預測法 (tournament branch prediction)；有些分支指令使用基於全局歷史的預測方法準確度比較高，有些分支指令則是使用基於局部歷史的預測方法準確度比較高，Alpha 21264 則是兩種預測方法都實現了；對於每條分支指令來說，處理器會根據兩種分支預測方法的準確度，動態地替每條分支指令選擇適合的分支預測方法，相當於這兩種分支預測方法彼此在競爭

  

  • 左邊為基於局部歷史的分支預測器：

    • Local history table ⇒ BHT：
      • 大小為 1024 x 10 bits，也就是使用了 10 bits 的 BHR，可以記錄一條分支指令過去 10 次的分支結果，總共可以記錄 1024 條分支指令的歷史記錄
    • Local prediction ⇒ PHT：
      • Alpha 21264 的 local history PHT 共包含了：2^10 = 1024 個 saturating counter，每個 saturating counter 為 3 bits (i.e. 3 bits saturating counter)
        • 共需：1024 x 3 bits

  • 右邊為基於全局歷史的分支預測：

    • Path history ⇒ GHR
      • GHR 為 12 bits，可以記錄過去 12 條分支指令的分支結果
    • global prediction ⇒ PHT：
      • Alpha 21264 的 global history PHT 共包含了：2^12 = 4096 個 saturating counter，每個 saturating counter 為 2 bits (i.e. 2 bits saturating counter)
        • 共需：4096 x 2 bits

  • Alpha 21264 基於局部歷史的分支預測器，採用了 non-speculative 的更新方法

    • 只有當指令 retire 時，才會更新分支預測器的內容 (e.g. BHR、saturating counter… etc)

  • Alpha 21264 基於全局歷史的分支預測器，採用了 speculative 的更新方法

    • 一旦有分支指令得到預測結果，就將這個預測結果更新到 GHR 中
      • i.e. GHR 的狀態有可能是不正確的
    • 為了在 mis-prediction 時恢復 GHR，因此採用了 Checkpoint GHR；在更新 GHR 前，會將目前的 GHR 內容複製到 Checkpoint GHR 中；當發生 mis-prediction 時，就可以透過這個 Checkpoint GHR 來恢復 GHR

    

• 對於 PHT 的 saturating counters 一般都是在分支指令得到確定的結果後才更新 (參考：link)

11.3 - 暫存器重命名

• Alpha 21264 使用了統一的 PRF 來實做暫存器重命名，整個處理器中只有一個 PRF，一個 register 在它整個生命週期只會存在一的地方，不會發生位置的變化

  • Register renaming 消除了 WAW 和 WAR 相關性

  

• Alpha 指令集中有一個特殊的 CMOV (Conditional-move) 指令，格式為：

  1	CMOV Ra, Rb ? Rc # (Ra == 0) ? Rc = Rb : Rc = Rc

  • 這條指令在 register renaming stage，需要讀取三個 source registers：Ra, Rb, Rc

    • 由於 Rc 同時也是 destination register，因此需要分配一個 physical register 來存舊的 Rc 值，並再替 destination register：Rc，分配另一個 physical register

    • 然而，對於 Alpha 的其他指令，都只需要讀取兩個 source registers 即可，因此不值得特別為 CMOV 指令增加 RAT 的 read port

    • CMOV 指令可以拆解為下列兩條指令：

      1 2	CMOV1 Ra, oldRc -> newRc1 CMOV2 newRC1, Rb -> newRc2

      • 透過這樣的方式，可以讓 CMOV 指令的 register renaming 按照一般的指令來處理，只是會需要分配兩個 physical registers
  • Alpha 21264 是一個 4-way superscalar CPU，每個 cycle 可以對四條指令做 register renaming，但如果這四條指令中存在 CMOV 指令，則會導致一個 cycle 內要對五條指令 register renaming

    • Alpha 21264 採用了比較簡單的方法，限制在做 register renaming 時，如果碰到 COMV 指令，則只有 CMOV1 指令以及其之前的指令可以在該 cycle 做 register renaming，CMOV2 以及其之後的指令必須等到下個 cycle 才可以做 register renaming

      

    • 雖然這樣的作法會讓 CPU 的執行效率有所降低，但 CMOV 指令出現的頻率並不高，且這種方法很容易實現，所以是一種可接受的折衷方法

11.4 - 發射

• Alpha 21264 包含了兩個 Issue Queue：Integer Issue Queue 以及 Floating-point Issue Queue，分別用來儲存整數類型的指令和浮點數類型的指令
  • Integer Issue Queue 可以儲存 20 條指令，並被 4 個 Integer FU 共享，每個 cycle 最多可以從 Integer Issue Queue 中選出 4 條整數指令出來執行
  • Floating-point Issue Queue 可以儲存 15 條指令，並被 2 個 Floating-point FU 共享，每個 cycle 可以從 Floating-point Issue Queue 中選出 2 條浮點數指令出來執行
• Alpha 21264 採用了 cluster 架構，將整數執行部份分成了 Cluster0 和 Cluster1 兩個部份，每個 cluster 都有完整的 Integer PRF，因此在處理器中共有兩個一模一樣的 Integer PRF

  • 每個 cluster 內部又被分成了兩個 subcluster，分別為：upper (U) 和 lower (L)

    • 整數部份的 4 個 FU分佈在這幾個 subclusers 中：Cluster0 的 U0、L0 以及 Cluster1 的 U1、L1

    

    • Alpha 21264 並沒有直接實現 4-of-20 的 select 電路，而是：
      • Cluster0 中的 U0 和 U1 共用同一個 select 電路：select0
      • Cluster1 中的 L0 和 L1 共用同一個 select 電路：select1
    • 這樣每個 select 電路只需要實做 2-of-20 的功能即可
• Alpha 21264 採用了 Compressing Issue Queue，使 select 電路可以很容易地實現 oldest-first 的功能，不過會增加 Issue Queue 的複雜度，功耗由於每條指令被 issued 時，都會需要移動大量的指令 (通常 oldest-first 的指令都是在 Issue Queue 的底部)，因此不適合使用在行動裝置上
• Alpha 21264 中，除了 load 指令外，其他類型指令執行所需的 cycles 數都是固定的；Alpha 21264 簡化了 load 指令的 wake-up 機制：當 load 指令發生 D-Cache miss 時，在它的 SW (Speculative Window) 中的所有指令都會從 pipeline 中被 flushed 掉，這些指令會重新在 Issue Queue 中等待被 wake up，然後參與仲裁；對於那些與 load 無關的指令很快就會再次被 select 電路選中，然而那些與 load 指令相關的指令則需要等待 D-Cache miss 被解決
  • 這種方式雖然降低了一點性能，但比較容易實現，因為不用識別 SW 中哪些指令和 load 指令存在相關性 (參考：link)，是一種可以接受的折衷方法
• 為了配合上述的 wake-up 機制，指令在被 select 電路選中後，不能馬上”離開” Issue Queue，而是需要確認這條指令沒有被發生 D-Cache miss 的 load 指令所影響後，才能離開 Issue Queue
  • 因此，一條指令被 select 電路選中後，在 Issue Queue 中需要等待 2 個 cycles，才可以從 Issue Queue 中刪除該指令
    • Cycle n：
      • 指令被 select 電路選中
    • Cycle n + 1：
      • 指令仍會留在 Issue Queue 中，但不會再向 select 電路發出 request 訊號了
    • Cycle n + 2：
      • 如果這條指令所需的 operands 都可獲得 (不論是來自 bypassing network 或是 PRF)，這條指令就可以被正常執行，並從 Issue Queue 中刪除該指令 (代表指令離開 Issue Queue 了)
      • 如果這條指令所需的 operands 來自於前面的 load 指令，且該 load 指令發生了 D-Cache miss，那麼這條指令就沒辦法繼續被執行，需要重新”放回” Issue Queue 中並等待 D-Cache miss 被解決
        • 實際上這條指令並沒有真的離開 Issue Queue (i.e. 還是佔著 Issue Queue 的 entry)，只需修改對應的 status bits 即可
• 浮點數的 load/store 指令也是在整數的 cluster 中被執行的

11.5 - 執行單元

11.5.1 - 整數的執行單元

• Alpha 21264 共有 6 個 FU (4 個 Integer FU，2 個 Floating-point FU)，每個 cycle 可以同時執行六條指令

  • i.e. Alpha 21264 是一個 machine width = 4，issue width = 6 的 superscalar CPU

• Alpha 21264 採用了 non-data-capturing 的架構，在指令被 select 電路選中後，才去讀 PRF

  • Integer PRF 因此需要支持四條指令的讀取，也就是需要 8 個 read ports (假設每條指令有兩個 source registers)，導致執行速度較慢
  • 為了解決這個問題，Alpha 21264 採用了 cluster 架構，將整數執行部份分為了 cluster0 和 cluster1，每個 cluster 都使用了一個完整的 Integer PRF；每個 cluster 內部又被分成了兩個 subcluster：upper (U) 以及 lower (L)
    • 因此，每個 Integer PRF 只需 4 個 read ports，簡化了 PRF 的設計，加快執行速度

• 如果兩條連續的指令是在同一個 cluster 內執行，那麼就可以 back-to-back 的執行；然而如果兩條連續的指令是在不同的 clusters，如果要將一條指令的計算結果透過 bypassing network 傳給另一個 cluster 的指令，就需要跨越 cluster，經過比較長的電路，因此需要獨立使用一個 stage，導致兩條連續的指令之間會間隔一個 cycle，沒辦法 back-to-back 的執行

  • 一個 cluster 中指令執行的計算結果需要間隔一個 cycle 才能寫入另一個 cluster 的 PRF 中

  

  

  • 由於 Alpha 21264 是 out-of-order CPU，因此硬體會盡可能地找到一條不相關的指令插入間隔中，就不會降低處理器的執行效率了

11.5.2 - 浮點數的執行單元

• Alpha 21264 有 2 個 Floating-point FU，每個 cycle 可以執行兩條 floating-point 指令

• 為了盡量減少連線的延遲，每個 cluster 中的 FU 都與自己的 PRF 緊靠在一起，大量地縮短 cluster 內 bypassing network 的電路，保證同一個 cluser 內連續的指令可以 back-to-back 的執行

  

• Alpha 21264 同一個 cluster 內，不同指令的 latency：

  Instruction class	Latency (cycles)
  Simple integer operations	1
  Special instruction	3
  Integer multiply	7
  Integer load	3 (假設 D-Cache hit)
  Floating-point add	4
  Floating-point load	4 (假設 D-Cache hit)
  Floating-point multiply	4
  Floating-point divide	12 (single-precision); 15 (double-precision)
  Floating-point square-root	12 (single-precision); 30 (double-precision)

  • 如果跨 cluster，則需要再增加一個 cycle

11.6 - 記憶體的存取

• Alpha 21264 的訪問記憶體元件採用了兩個特殊的設計：
  • 能夠對 load 指令和 store 指令之間存在的 RAW 相關性進行預測，從而規劃某些 load 指令進入 pipeline 的時間，防止它們提前進入 pipeline 做白工，稱為：Speculative disambiguation
  • 能夠對 load 指令存取 D-Cache 時是否 hit 做預測，從而避免不必要的 wake up，稱為：Load hit/miss Prediction
  • 以上兩種方法本質上都是透過預測的方式來提昇處理器的執行效率，並仍然在現代處理器中被廣泛地使用

11.6.1 - Speculative Disambiguation

• 對於 load 指令和 store 指令來說，它們之間的相關性在 register renaming stage 是無法被解決的，只有到了 execute stage，將指令中的存取位址計算出來後，才可以判斷它們之間是否存在相關性，也就是：Memory Disambiguation

• Alpha 21264 採用了完全 out-of-order 的方式來執行 load 指令和 store 指令，為了最大限度地減少對 pipeline 的負面影響，Alpha 21264 還對 load 指令是否和其之前的 store 指令存在相關性進行了預測

  • 如果預測一條 load 指令和 pipeline 中還沒有 retire 的 store 指令之間不存在 RAW 相應，那麼這條 load 指令就不須等待 store 指令的存取位置被計算出來，可以直接 out-of-order 進入 execute stage 被執行，提高了執行性能

  

  • Alpha 21264 將對 D-Cache 的存取拆分成兩個不同的 stages (D-Cache1、DCache2)：
    • D-Cache1 stage：讀取 D-Cache，但這個 cycle 沒辦法得到結果
    • D-Cache2 stage：得到 data 和 tag，並比較 tag，以判斷是否 cache hit

• 將 D-Cache 的存取採取了 pipeline 的方式：

  • 缺點：
    • 增加了 load 指令的執行 cycles 數
    • 增加了 load 指令和與其存在相關性的指令所間隔的 cycles 數，產生更多的 bubbles
  • 優點：
    • 可以提高 CPU 的 frequency
    • Out-of-order CPU 會盡可能地找到不相關的指令插入間隔中，因此不會對性能造成太大的負面影響
  • 因此，現代處理器基本上都使用 pipeline 的方式來存取 D-Cache

• 在 D-Cache1 stage 中，由於 load 指令和先前的 store 指令的存取位址都已經被計算出來，因此可以檢查 load 指令是否與先前的 store 指令存在相關性，也就是：disambiguation，可以透過下列的硬體元件來完成：

  1. Load/store Issue Queue：
     • 以 out-of-order 的方式將 load 指令和 store 指令送到 FU 來執行
  2. Load Queue：
     • 依照 program order 的順序儲存著所有 load 指令的存取位址
     • Load 指令在 register renaming stage 就會被寫進 load queue 中 (register renaming stage 還是 in-order 的)
     • 當 load 指令 retire 時，就會將 load 指令在 load queue 中對應的 entry 給釋放
     • 使用 CAM 來實現，以便可以快速的比較 load 指令的存取位址
  3. Store Queue：
     • 依照 program order 的順序儲存著所有 store 指令的存取位址
     • Store 指令在 register renaming stage 就會被寫進 store queue 中 (register renaming stage 還是 in-order 的)
     • 當 store 指令 retire 時，就會將 store 指令在 store queue 中對應的 entry 給釋放
     • 使用 CAM 來實現，以便可以快速的比較 store 指令的存取位址
  4. Wait Table：

     • 一個 1024 x 1 bit 的表格，使用 PC address 作為索引，用來儲存 load 指令的相關性資訊

     • Wait table 中的每個 bit 都稱為：Wait bit，初始值皆為 0，表示所有的 load 指令和其之前的 store 指令之間都不存在相關性，可以 out-of-order execution

     • 當發現了 store/load 違例，也就是發現了一條或多條在 load 指令前的 store 指令，與該 load 指令所存取的記憶體地址相同 (實際上，只要是存取範圍有重疊就存在相關性)，此時就會將該 load 指令在 wait table 中所對應的 wait bit 給設成 1

     • 在 decode stage，每當 decode 出一條 load 指令，就需讀取 wait table，並將 load 指令所對應的 wait bit 一起寫進 Issue Queue 中

       • 如果一條 load 指令的 wait bit 為 1，則該 load 指令必須等到所有在其之前的 store 指令都計算出存取位址後，才可以向 select 電路發出 request 請求仲裁

     • Wait table 每 16,384 個 cycles 就會全部清為 0，以避免 wait table 的內容在經過一段時間的執行後全部變成 1 (這樣所有的 load 指令都無法 out-of-order execute 了)

       • 就算是同一條 load 指令 (i.e. PC address 相同)，也不一定每次執行時都與 store 指令仍然存在相關性

       

• 指令進到 issue stage 後的下一個 cycle，進到 register read stage 並從 PRF 中讀取 operands，然後再到下一個 cycle，進到 address calculation stage 就可以計算指令的存取位址了，將存取位址計算出來後，就可以進到 D-Cache1 stage

• 在 D-Cache1 stage 會檢查 load 指令和 store 指令之間是否存在相關性，因此這個 cycle stage 也被稱為 Disambiguation stage，load 指令和 store 指令的 disambiguation 分別為：

  1. Load Disambiguation：
     • Load 指令會將其存取位址寫到 load queue 對應 entry 中，同時 load 指令還會完成以下兩件事情：
       1. Load 指令會去查詢 store queue，如果發現存在同樣存取位址且年齡比該 load 指令還老的 store 指令，那這條 load 指令就不需要存取 D-Cache 了，直接透過 store queue 就可以得到結果
       2. Load 指令還需要去查詢 load queue，Alpha 21264 要求訪問相同位址的 load 指令必須是 in-order (i.e. program-order) 的，如果不滿足這個規則，在 multi-core 的環境下有可能會發生錯誤

          • 如果發現存在存取位址相同且比該 load 指令還要年輕的 load 指令，就代表發生了 load/load 指令違例：

            

            • Load 指令 X 和 load 指令 Y 執行的中間有可能被其他的 CPU 將該存取位址的值給更動了，因此如果 load 指令的執行順序改變，其結果就會出錯
     • Alpha 21264 定義了各種記憶體存取應該保持的執行順序：

       First Instruction In Pair	Second Instruction in Pair	Reference Order
       Load memory to address X	Load memory to address X	Maintained
       Load memory to address X	Load memory to address Y	Not Maintained
       Store memory to address X	Store memory to address X	Maintained
       Store memory to address X	Store memory to address Y	Maintained
       Load memory to address X	Store memory to address X	Maintained
       Load memory to address X	Store memory to address Y	Not Maintained
       Store memory to address X	Load memory to address X	Maintained
       Store memory to address X	Load memory to address Y	Not Maintained

       • 兩條 load 指令存取同一個位址，order 必須 maintain ⇒ 否則就是 load/load 指令違例
       • Store 指令一定是 in-order 執行，因此兩條 store 指令不論存取位址是否相同，order 都必須 maintain
       • 一條比較年輕的 load 指令，與一條比較老的 store 存取同一個位址，order 必須 maintain ⇒ 否則就是 store/load 指令違例
       • 一條比較年輕的 store 指令，與一條比較老的 load 指令存取同一個位址，order 必須 maintain ⇒ 否則就是 store/load 指令違例
       • 其他狀況，都可以 out-of-order 執行
       • Alpha 21264 中 load 指令和 store 指令是 out-of-order 執行的，因此需要在 disambiguation stage 解決順序性
       • 然而，load 指令在查詢 store queue 時，如果發現存在同樣存取位址且年齡比該 load 指令還老的 store 指令，這種情況不需要 flush pipeline，因為這只代表 load 指令可以直接從 store buffer 中讀取 store 指令的資料 (需等待 store 指令執行完畢)，不需存取 D-Cache，但是 store 指令和 load 指令之間的執行仍然要保持 in-order

         • 但如果 load 指令需要的資料寬度大於 store 指令的資料寬度 (e.g. 32-bit load vs. 8-bit store) 時，代表 load 指令所需要的資料有一部分存在 store queue 中，另外一部份存在 D-Cache 中，load 指令就沒辦法在同一個 cycle 內得到其所需的資料了

           

           • 此時，仍需將 load 指令和與其相關的指令都從 pipeline 中給 flush 掉，並重新從 I-Cache fetch 這些指令
             • 在 Alpha 21264 中，這個過程稱為：replay trap
  2. Store Disambiguation：

     • 在 pipeline 的 disambiguation stage，store 指令會將其計算出來的存取位址寫到 store queue 中對應的 entry 中，並在同一個 cycle 查詢 load queue，如果發現存在同樣存取位址且年齡比該 store 指令還年輕的 load 指令，則代表這條提前執行的 load 指令沒有使用到正確的計算結果，產生了 store/load 指令違例

       

     • 當發生 store/load 指令違例時，最理想的解決方法是只將違例的 load 指令以及所有與其相關的指令從 pipeline 中給 flush 掉 (參考：Selective Replay)；然而這種設計增加了設計的複雜度，因此 Alpha 21264 採用了相對比較簡單的 replay trap 處理方法

       • 當已經離開 issue queue 的 load 指令或 store 指令由於某個原因不能再繼續執行時，這條 load 指令或 store 指令及它之後的所有指令都會從 pipeline 中被 flushed 掉，並恢復 CPU 的狀態 (Alpha 21264 有非常豐富的 checkpoints)，然後重新從 I-Cache fetch 這些指令來執行
       • Alpha 21264 中，load/load 指令違例也是採用 replay trap 的方式來處理

     • 缺點：

       • 降低了處理器的性能，如果經常發生 store/load 指令違例或是 load/load 指令違例，那麼就需要經常的 flush pipeline 中的部份指令，並重新從 I-Cache fetch 這些指令來執行
         • 因此 Alpha 21264 才使用了 wait table 來對 store 和 load 之間的相關性進行預測，這樣可以避免大部分的 store/load 指令違例，降低需要 replay trap 的次數

     • 當發生 store/load 指令違例後，除了進行 replay trap，還需要更新 wait table，將 load 指令在 wait table 所對應的 bit 給設成 1，這樣當下次這條違例的 load 指令再次被執行時，就需要等它之前所有的 store 指令都被 select 電路選中後，才允許這條 load 指令向 select 電路發出 request

       • 這條指令最後在執行時，有可能可以直接從 store queue 取得所需的資料

       

     • Alpha 21264 選擇將這些被 flushed 的指令重新從 fetch stage 開始執行，而不是將違例的 load 指令及與其相關的所有指令重新放回 Issue Queue 中重新仲裁，是因為此時的 Issue Queue 可能已經沒有空間儲存這些指令了

       • 當 Issue Queue 沒有空間儲存這些指令時，這些指令就必須等待；這個等待時間可能會很長，而且需要額外一個硬體元件來儲存這些等待的指令

       • 此外，由於這些指令沒辦法進入 Issue Queue，因此就不能 wake up Issue Queue 中其他的指令

         • 如果此時在 Issue Queue 中的指令正在等待這些指令來 wake up 它們，那麼在 Issue Queue 中的指令也沒辦法離開 Issue Queue，導致 Issue Queue 永遠沒有空間空出來，便會發生 dead lock

         

         • Store 指令在 disambiguation stage 發現在其之後的 load 指令先被執行了，因此發生了 store/load 指令違例
         • 為了避免 dead lock，Alpha 21264 直接將第一組和第二組的全部指令從 pipeline 中給 flush 掉，並使用 checkpoint 來恢復 CPU 的狀態，然後重新從 I-Cache fetch 這些指令來執行

     • Alpha 21264 採用的 replay 方法是基於 I-Cache 的，這種方法會降低處理器的效能，如果想基於 Issue Queue 來 replay，有兩種方式可以採用：

       1. 當指令被 select 電路選中時，不離開 Issue Queue，只要等到指令 retire 時才允許其離開 Issue Queue (參考：Issue Queue Base Replay)

          • 優點：

            • 設計複雜度比較低

          • 缺點：

            • 由於指令被 select 電路選中後，並不會馬上離開 Issue Queue，只有在該條指令確認可以被正確執行後 (i.e. 不需要 replay)，才會允許該條指令離開 Issue Queue；然而實際上由於 D-Cache hit rate 是很高的，且發生 store/load 指令等違例的機率並不高，所以大部分指令被 select 電路選中後，其實並不需要 replay，但這些指令仍佔據著 Issue Queue 的空間，直到確認其不需要 replay 為止，導致 Issue Queue 中實際可用的 entries 數減少
              • 增加 Issue Queue 的空間則會增加 select 和 wake-up 電路的 latency，因此無法無上限地增加

       2. 採用 Replay Queue Based Replay 的方式，增加一個 Replay Queue，用來保存離開 Issue Queue 但還沒 retire 的指令

          • 當發生 store/load 指令違例時，所有要被 replay 的指令只需從 Replay Queue 重新向 select 電路發出 request 即可

            • Intel Pentium 4 採用了這種設計

          • 優點：

            • 提高了 Issue Queue 的使用效率

          • 缺點：

            • Replay Queue 會佔用額外的硬體空間
            • Replay Queue 也需一起參與 select 電路的仲裁和 wake up，因此設計較複雜

11.6.2 - Load hit/miss Prediction

• 在 Alpha 21264 中，load 指令執行的 cycles 數是不固定的，D-Cache hit/miss、D-Cache 中是否有 bank conflict、是否和其他的元件產生 D-Cache read port conflict 等，都會影響 load 指令執行的 cycles 數；但是，如果需要等到 load 指令讀取到資料後才 wake up Issue Queue 中等待的指令，會導致 latency 過長

  • 然而，大部分的情況下 D-Cache 都會是 hit 的，因此可以直接假設 D-Cache 總是 hit 來 wake up Issue Queue 中相關的指令，也就是採用 Speculative wake-up

    

    • Load 指令被 select 電路選中後，需要等待 2 個 cycles 才可以 wake up 相關的指令
    • Cycel 4、cycle 5 和 load 相關的指令就可以被 wake up 了，這兩個 cycles 也稱為：Speculative Window (SW)
      • 在這兩個 cycles 被 select 電路所選中的指令都不能離開 Issue Queue (i.e. 採用 Issue Queue Based Replay 的設計)，不論它們是否真的和 load 指令存在相關性
      • 當發現 load 指令真的是 D-Cache hit 時，這兩條指令就可以離開 Issue Queue
      • 但如果發現 load 指令是 D-Cache miss 時，這兩條指令就必須從 pipeline 中給 flush 掉，並在 Issue Queue 中重新等待被 wake up，然後重新向 select 電路發出 request

• Alpha 21264 中並沒有區分 SW 中哪些指令和 load 指令相關，而是假設全部指令都與 load 指令相關；在發現 D-Cache miss 時會將 SW 中的所有指令從 pipeline 中給 flush 掉，並在 Issue Queue 中重新等待被 wake up，此時會假設 L2 Cache 是 hit 的，因此這些指令可以再次 (在 cycle 6 時) 被 select 電路選中，這會導致 4 個 cycles 的 latency

  

  • 如果 L2 Cache hit，那麼這些指令就可以從 Issue Queue 中離開
  • 如果 L2 Cache miss，那麼這些指令就必須在 Issue Queue 中繼續等待

• 在發現 D-Cache miss 時會需要將 SW 中的所有指令從 pipeline 中給 flush 掉，但這樣就浪費了執行效率，因為這些 cycles 原本可以選擇其他指令來執行

  • 為了盡量避免這種情況發生，Alpha 21264 中對 load 指令是否會 D-Cache hit 也進行了預測，只有那些預測 D-Cache hit 的 load 指令才會以 2 cycles latency 的方式來 wake up 相關的指令，否則就以 4 cycles latency (假設 L2 Cache 是 hit) 的方式來 wake up 相關的指令
  • Alpha 21264 使用了一個 4-bit saturating counter 來預測 load 指令是否會 D-Cache hit
    • 每當 D-Cache hit 時，counter += 1
    • 每當 D-Cache miss 時，counter -= 2
    • 使用 counter 的 MSB 來作為 load 指令的預測值
      • MSB = 1：預測 load 指令會 D-Cache hit
      • MSB = 0：預測 load 指令會 D-Cache miss
  • 在 Independent Window (IW) (i.e. 2 cycles latency 或是 4 cycles latency) 中可以選擇與 load 指令不相關的指令來執行，即使預測 D-Cache miss，這 4 個 cycles latency 由於仍然可以執行其他不相關的指令，因此也不會對 CPU 的性能造成太大的影響

• 對於浮點數 load 指令來說，由於需要 128 bits 的資料，因此需要 2 個 cycles 才可以從 D-Cache 中讀出完整的結果 (64 bits x 2)，因此浮點數 load 指令的 latency 需要增加 1 個 cycle ⇒ 共 3 個 cycles

  

  • 此時 SW 只有 1 個 cycle (從 load 指令等待 3 個 cycles 後開始將相關的指令 wake up，直到執行時發現是否為 D-Cache hit/miss，中間所間隔的 cycles 數)
    • 如果發現 load 指令是 D-Cache hit 時，這條指令就可以離開 Issue Queue
    • 如果發現 load 指令是 D-Cache miss 時，這條指令就必須從 pipeline 中給 flush 掉，並在 Issue Queue 中重新等待被 wake up，然後重新向 select 電路發出 request

• 當發生 D-Cache miss 時，需要從 L2 Cache 讀取資料，浮點數 load 指令 L2 Cache hit 的 latency 同樣需要增加 1 個 cycle ⇒ 共 5 個 cycles

  • i.e. 指令 A 可以在 cycle 7 時再次被 select 電路選中

• 對於浮點數 load 指令來說，由於其 SW 只有 1 個 cycle，且浮點數指令執行所需的 cycles 通常都比較長，當浮點數 load 指令發生 D-Cache miss 時有足夠的時間進行處理，因此浮點數 load 指令並不會使用 saturating counter 來預測其 D-Cache 是否會 hit

11.7 - 退休

• 在 Alpha 21264 中，一條指令要 retire 時發現了 exception，那麼在 pipeline 中的所有指令都會被 flushed 掉，這些被 flushed 的指令所佔據的 physical registers 也會被釋放，並放回 free list 中，RAT 可以透過 checkpoint 來恢復到產生 exception 那道指令之前的狀態
  • Alpha 21264 的 ROB 中每條指令都有一個對應的 checkpoint，80 個 ROB entries 共對應了 80 個 checkpoints，以便快速的恢復 CPU 的狀態
  • Alpha 21264 的 RAT 是使用 CAM 實現的，因此佔用的硬體資源也是很小的
• Alpha 21264 一個 cycle 內最多可以 retire 8 條指令

11.8 - 結論

• Alpha 21264 為了達到很高的 CPU frequency，在很多地方都加了額外的 pipeline stage，例如 對 cache 的存取；然而，這也同時增加了 mis-prediction penalty，並增大了 load latency

  • Out-of-order execution 可以緩解 load latency 增大所引起的問題

• Alpha 21264 使用了複雜的分支預測方法來準確地預測分支指令，為了加快 branch mis-prediction 及 exception 發生時恢復 CPU 狀態的效率，Alpha 21264 為每個 ROB 中的每條指令都分配了一個對應的 checkpoint

• Alpha 21264 使用了 cluster 架構來解決 multi-port PRF 所產生的問題

• Alpha 21264 使用 load hit/miss prediction 和 speculative disambiguation 這兩種預測方法來加快 load/store 指令的執行

• 更深的 pipeline 加上更準確的預測方法，使 Alpha 21264 在運行更快的 CPU frequency 的同時，保持了較高的執行效率

• Alpha 21264 的 pipeline：

  

  • 對於普通的指令，Alpha 21264 使用了 7 stages 的 pipeline
  • 對於 load/store 類型的指令，由於對 D-Cache 的存取也採取了 pipeline 的方式，因此 Alpha 21264 使用了 9 stages 的 pipeline
  • 對於 floating-point 類型的指令，Alpha 21264 使用了 10 stages 的 pipeline

• 事實上，不能依 pipeline 的 stages 個數來判斷一個 CPU 的性能高低，而是還需要考慮 pipeline 的執行效率，而這需要使用更準確的各種預測方法，才能使 pipeline 保持高效率的執行

• 在 out-of-order superscalar CPU 中，為了保持程式執行順序的一致性，一般通常都會在 pipeline 的最後增加一個 commit stage
  • 當指令抵達 commit stage 時，會將這條指令在 ROB 中的 entry 標記為 complete
  • 此時只代表這個指令已經計算完成，不代表可以離開 pipeline (i.e. retire)
• 指令進到 commit stage 並不代表它一定是正確的，有可能這條指令處在 mis-prediction 或是 exception 的路徑上，最後需要從 pipeline 中被 flushed 掉
  • 只有當這條指令之前的指令都已經 retire 了，且這條指令已經是 complete 的狀態，才可以 retire 並離開 pipeline
• 在一條指令 retire 前，它的狀態都是 speculative 的，只有當這條指令真的 retire 後，才可以將它的狀態更新到 CPU 的 architecture state
• 對一個 N-way 的 superscalar，因為每個 cycle 最少可以 fetch N 條指令進 pipeline 中，pipeline 至少也需要 retire N 條指令，才能確保 pipeline 不會被堵塞

10.2 - ROB

10.2.1 - 一般架構

• ROB 本質上是一個 FIFO，ROB 中儲存了指令的相關訊息，例如：一條指令的類型、結果、destination register 和 exception 的類型等

  

  • Complete：
    • 一條指令是否執行完畢
  • Areg：
    • 指令的 architecture destination register 編號
  • Preg：
    • 指令的 physical destination register 編號
  • OPreg：
    • 指令的 architecture destination register 被 renamed 成 Preg 前，舊的 Preg 編號
      • 當需要恢復 CPU 的狀態時 (e.g. mis-prediction、exception)，需要透過這個映射關係來恢復 RAT
  • PC：
    • 指令的 PC 值，當發生 interrupt 或 exception 時，需要保存指令的 PC 值，以便可以重新執行指令
      • E.g. RISC-V 的 $mepc、$sepc 會保存發生 interrupt 或 exception 指令的 PC 值，就可以從 PC 獲得
  • Exception：
    • 發生 exception 時的 exception 類型
    • 當指令 retire 並需要處理 exception 時，會依據 Exception 的資訊來做對應的處理
  • Type：
    • 指令的類型
    • 當指令 retire 時，不同類型的指令會有不同的處理
      • 例如：
        • Store 指令要寫 D-Cache
        • 分支指令要釋放 checkpoint 資源

• 一個 ROB 的範例 (不包含 source registers 的部份)，假設採用使用統一的 PRF 來實做暫存器重命名：

  

  • i1 (除法) 和 i2 (依賴 i1) 的執行時間會很長，i3 和 i4 會提前被執行完成，但是 i3 和 i4 的結果在 i1 和 i2 retire 前不能更新到 CPU 的 architecture state

  

  • (a)：指令 i1 ~ i3 完成 register renaming，但指令都還沒完成，因此 Complete 都是 Not ready
    • i1 和 i3 的 architecture destination registers 都是 r1，可以透過 register renaming 解決 WAW 相關性
  • (b)：指令 i4 進到 ROB；指令 i3 和 i4 執行完成，Complete 更新為 Ready，但由於還不是最舊的指令，因此無法 retire
  • (c)：指令 i1 執行完畢，且由於其為最舊的指令，因此可以 retire，ROB entry 會被釋放 (ROB Head index++)，physical register：p8 同樣也會被釋放

10.2.2 - 端口需求

• 對於 4-way superscalar CPU，ROB 中每個 cycle 至少可以 retire 4 條指令；需要對 ROB 中從 head pointer 開始連續 4 條指令的 Complete 訊號進行判斷，如果某個指令的 Complete 訊號為 0，那麼在它後面的所有指令都不用允許在這個 cycle 被 retired：

  

  • 對於 4-way superscalar CPU，除了 en0 ~ en3 (4 個 read ports) 外，其他的 pipeline stages 也會存取 ROB，因此需要更多的 read ports 和 write ports
  • 使用 ROB 來實做暫存器重命名對於 ROB 的 ports 需求是最多的：
    • 在 register renaming stage，需要從 ROB 中讀取 4 條指令的 source registers，假設每條指令有 2 個 source registers，那麼就需要 4 * 2 = 8 個 read ports
    • 在 dispatch stage，需要向 ROB 寫入 4 條指令 (需將 register renamed 後的指令寫入 ROB)，因此需要 4 個 write ports
    • 在 write-back stage，需要向 ROB 寫入”至少” 4 條指令的計算結果 (issue width 是有可能 ≥ machine width 的)，因此需要至少 4 個 write ports
    • 因此，對於 4-way superscalar CPU，ROB 至少需要 12 個 read ports 以及 8 個 write ports；然而這種 multi-port 的 FIFO 很難優化其硬體面積及 latency，這也是使用 ROB 來實做暫存器重命名所面臨的最大問題

10.3 - 管理處理器的狀態

• Superscalar CPU 內部有兩個狀態：
  • Architecture state (指令集定義的狀態)
  • Speculative state
• 一條指令只有在 retire 時才會更新處理器的 architecture state，在此之前，指令只能更新處理器的 speculative state
• 在 superscalar CPU 中，根據架構的不同，會用不同的方法來管理 architecture state，包含：
  • 使用 ROB 管理 architecture state
    • Intel P6 架構、Intel Core 架構採用此方法
  • 使用 physical register 管理 architecture state
    • Intel Pentium 4、Alpha 21264、MIPS R10000 採用此方法

10.3.1 - 使用 ROB 管理指令集定義的狀態

• 對於使用 ROB 來實做暫存器重命名來說，一條指令在 retire 之前，都會使用 ROB 來保存指令的結果；當指令 retire 時，就可以用這條指令的計算結果來更新 CPU 的 architecture state，此時會將這條指令的計算結果從 ROB 中搬到 architecture registers

  • 在這種架構中，architecture registers 是真實存在的；由於 architecture registers 儲存了所有 retired 指令所對應的 destination registers 的值，因此這種方法的 ARF 也被稱為 RRF (Retire Register File)：

  

• 在 ROB 中所記錄的所有指令的計算結果都是 speculative state

  • 當一條指令退休時，會將這條指令的計算結果從 ROB 搬到 ARF/RRF 中，同時也會將這條指令所佔用的 ROB entry 給釋放掉

• 使用 ROB 來實做暫存器重命名通常都會搭配 data-capture 的 issue 方式 (參考：link)

  • 當指令在做 register renaming 時會讀 RAT
    • 如果發現這個指令的 source registers 的值已經被先前的指令給計算出來了，那麼就可以直接從 ROB (如果計算結果的指令尚未 retire) 或是 architecture registers (如果計算結果的指令已經 retire) 讀取這個值，然後寫到 payload RAM 中
    • 如果發現這個指令的 source registers 的值還沒被先前的指令給計算出來，就將 source registers 在 ROB 中的位址寫到 payload RAM 中，並等待 bypassing network 將計算結果 bypass 至 payload RAM，此時這個指令就可以被 wake up (已進入 issue stage) 並在被 select 電路選中後，從 payload RAM 獲得所需的計算結果

  

  • 指令 A 會將其計算結果在 write-back stage 寫進 ROB，並透過 bypassing network 將計算結果寫進 paylad RAM；此時也會 wake up 正在 Issue Queue 中等待的指令 B
  • 指令 B 在做 register renaming 時發現 source registers 的值還沒被指令 A 給計算出來，因此只能先將 source registers 在 ROB 中的位址寫到 payload RAM 中；等到指令 A 將其結果計算出來並 wake up 指令 B，指令 B 在被 select 電路選中後就可以讀取 payload RAM 獲得其所需的 source registers 的值並進入 execute stage
  • 指令 C 和指令 D 在做 register renaming 時發現 source registers 的值已經被指令 A 給計算出來了，由於指令 A 還沒有 retire，因此其計算結果仍儲存在 ROB 中，因此需要讀取 ROB 獲得其所需的 source registers 的值，並寫到 payload RAM 中
  • 指令 E 在做 register renaming 時發現 source registers 的值已經被指令 A 給計算出來了，由於指令 A 已經 retire 了，因此可以直接讀取 ARF 來獲得其所需的 source registers 的值，並寫到 payload RAM 中
  • 由於都是從 payload RAM 獲得 source registers 的值，因此不必操心其值是存在 ROB 或 ARF 中

• 如果使用 ROB 來實做暫存器重命名但搭配 non-data-capture 的 issue 方式：

  • Non-data-capture issue 方式在指令被 select 電路選中後，需要直接從需要的位置讀取 source registers 的值，這個位置資訊是在 register renaming 時透過讀取 RAT 時一起被寫入 Issue Queue 中的，但當指令被 wake up 時，有可能 source registers 的值還存在 ROB 中，也有可能已經被搬進 ARF 了，這個位置變更的資訊，需要一併通知 Issue Queue 中的指令，因此 Issue Queue 需要增加額外的 write ports 以及 bypassing network，增加了設計的複雜度

    

    • 指令 A 會將其計算結果在 write-back stage 寫進 ROB
    • 指令 B 和指令 C 都可以從 ROB 中讀取指令 A 的計算結果
    • 由於指令 A retire 時會將計算結果從 ROB 搬至 ARF，因此指令 D 得從 ARF 讀取指令 A 的計算結果
      • 在這中間需要有額外的 write ports 以及 bypassing network 通知在 Issue Queue 中的指令 D，指令 A 計算結果存放的位置被更新了

10.3.2 - 使用物理暫存器管理指令集定義的狀態

• 使用統一的 PRF 來實做暫存器重命名在一條指令做 register renaming 時，architecture register 的計算結果會一直被存在 PRF 中

• 使用 ROB 來實做暫存器重命名：

  • 優點：

    • Register renaming 流程簡單，在指令寫入 ROB 時，將 architecture register 和 physical register 的映射關係一併記錄到 ROB 即可，不須增加複雜的硬體控制邏輯電路

  • 缺點：

    • 暫存器的值需要被搬移 (ROB → ARF)，功耗較大

    • 由於暫存器的值有可能存在 ROB 或是 ARF，當指令 retire 時，需要額外的電路同步所有有使用到該暫存器的指令來告知該暫存器已經從 ROB 搬移到 ARF，功耗較大

    • 很多指令並不會更新 destination register，因此也就不用對 destination register 做 renaming，但每條指令仍然會佔用 ROB entry 中 destination register 的 physical register renaming 的空間，無法省略，浪費硬體空間

    • 對於一條指令而言，它既可以從 ROB 中讀取 operands，也可以從 ARF 中讀取 operands，所以 ROB 和 ARF 最壞的情況就是一個 cycle 內，所有的指令都需要同時讀取 ROB 或 ARF，會增加 ROB 和 ARF 的 read ports 所需的數量

      • 例如：4-way issue CPU，指令最多需要 2 個 source registers，那麼 ROB 和 ARF 都需要準備 2 x 4 = 8 個 read ports，對硬體面積和延遲造成負面的影響
      • 如果 CPU 有支援 multiple destination registers 的指令，那麼同樣也會對 ROB 和 ARF 的 write ports 數量造成影響

• 使用統一的 PRF 來實做暫存器重命名：

  • 優點：

    • 暫存器的值只需寫入一次，不需要再被搬移，功耗較小
    • 暫存器的值只會存在一個地方，不需要

  • 缺點：

    • 需要使用一個 free list 以及兩個 RAT，因此需要使用複雜的硬體控制邏輯電路

10.4 - 特殊情況的處理

• 由於 out-of-order CPU 採用了很多種的預測方式來執行指令，因此並不是 pipeline 中所有的指令都可以 retire
  • 分支指令和發生了異常的指令，都需要將其後面的指令從 pipeline 中給 flush 掉，並恢復處理器的狀態，然後從指定的位址開始重新 fetch 指令來執行
  • 此外，在 commit stage 還需要對 store 指令做特別的處理
    • Store 指令只有在指令 retire 時才可以更新 D-Cache 的內容，如果在這期間發生了 D-Cache miss，store 指令會 block 所有其後面的指令 retire (retire 是 in-order 的)，因此需要對 store 指令做特別的處理
• 在 commit stage 還會對其他的指令有一些特殊的限制，以減少其對處理器中其他的元件造成影響

10.4.1 - 分支預測失敗的處理

• 當發生 branch mis-prediction 時，除了需要從 pipeline 中 flush 掉分支指令後面的指令，還需要恢復這些指令對處理器的修改，包含：

  • RAT
  • ARF
  • PRF
  • PC
  • … etc

• 當發生 branch mis-prediction 時，處理器的狀態恢復可以以 register renaming 為分界，分為兩個獨立的任務：

  • Front-end recovery
    • 較簡單
    • 需將 register renaming stage 前的指令給全部 flush 掉
    • 需將 GHR、BHR 等 branch predictor 的 history tables 給恢復
    • 使用正確的位址重新 fetch 指令
  • Back-end recovery
    • 需將處理器所有的內部元件給恢復，包含：
      • Issue Queue
      • Store buffer
      • RAT
        • 將錯誤指令對 RAT 的修改給恢復
      • PRF
        • 將錯誤指令佔用的 physical registers 給釋放
      • ROB
        • 將錯誤指令佔用的 ROB entries 給釋放
      • … etc

  

  • Front-end recovery 和 back-end recovery 可以同步進行
  • Front-end recovery 通常可以很快完成，處理器此時就可以從正確的位址開始 fetch 指令
    • 這些新 fetch 的指令可以一直執行到 register renaming stage
      • 如果 back-end recovery 在這些指令準備離開 register renaming stage 前已經完成，此時就不需要 stall pipeline
        • i.e. Time (backe-end recovery) < Time (front-end recovery) + Time (fetch → renaming)
      • 反之，pipeline 就必須 stall，直到 back-end recovery 完成，這些新 fetch 的指令才可以離開 register renaming stage

• 當發生 branch mis-prediction 時，大部分的恢復任務都是對 register renaming 相關的元件做恢復，因為大部分在 mis-prediction 路徑上的指令，都會經過這個 stage 並修改了 RAT 及相關的元件

• 除此之外，pipeline 中其他的元件也必須被恢復，包含 Issue Queue、ROB 和 store buffer 等，不過這些元件的恢復相對比較容易

• Register renaming 的實做方式直接決定了要如何恢復 register rename 元件的狀態：

  • 使用 ROB 來實做暫存器重命名

    • 每當一條指令 retire 時，其計算結果會從 ROB 移至 ARF，因此一個 register 在其生命週期內，有兩個位置可以存放它的值 (ROB 和 ARF)

      

      • RAT 中記錄了 registers 的映射關係 (存在 ROB 或 ARF 中)

      • 一條 retired 的指令將 destination register 的值從 ROB 搬到 ARF 後，不一定代表後續的指令就一定需要從 ARF 讀取這個 destination register 的值：

        1 2 3

        指令 A：add $r1, $r2, $r3 指令 B：add $r1, $r1, $r4 指令 C：add $r1, $r1, $r5

        • 經過 register renamed 後，只有指令 C 的 destination register：$r1 的映射關係才會被寫進 RAT 中，因此即使指令 A 已經 retired 並將 destination register 的值從 ROB 搬到 ARF，後續的指令在使用 $r1 時，仍會使用指令 C 的結果
        • 只有一條 retire 的指令發現自己的 destination register 是最新的映射狀態，才能將其 destination register 在 RAT 中的映射關係從 ROB 改成 ARF

      • 一條 retire 的指令要如何檢查自身的 destination register 是否是最新的映射關係呢?

        • 在這條指令要 retire 時，可以使用其 destination register 編號來讀取 RAT，讀出這個 architecture register 所對應的 ROB index，如果發現這個 ROB index 與現在要 retire 的指令在 ROB 中所佔據的位址是一樣的，就表示這條 retire 的指令就是最新的映射關係了
          • 如果不一樣，就代表有其他的指令更新了 RAT 中該 register 的映射關係，因此這條要 retire 的指令就不是最新的映射關係了

    • 當發生 branch mis-prediction 時，會先停止 fetch 新的指令，而在發生 mis-prediction 的分支指令前的指令，會被繼續執行 (i.e. pipeline 會被 drain out)；等到這條分支指令和其前面的指令都 retire 後，此時 ARF 的 registers 內容就都會是正確的了，剩餘在 pipeline 中的指令，都是在 mis-prediction 的錯誤路徑上，因此可以直接將 pipeline 給 flush，並將 RAT 中所有的映射關係都改映射到 ARF，這樣就完成了 RAT 的恢復，並可以開始從新的位址 fetch 指令

    • 優點：

      • Register renaming 容易實現
      • 當發生 branch mis-prediction 時，處理器的狀態恢復也相對容易

    • 缺點：

      • 如果分支指令之前有 load/store 指令發生 D-Cache miss，則這條分支指令需要等一段時間才能 retire，mis-prediction penalty 會增加

  • 擴充 ARF 來實做暫存器重命名

    • 與上述使用 ROB 來實做暫存器重命名雷同

  • 使用統一的 PRF 來實做暫存器重命名

    • 使用統一的 PRF 來實做暫存器重命名使用了兩個 RAT：Speculative RAT 及 Architecture RAT
      • Architecture RAT 的內容永遠是正確的
    • 當發生 branch mis-prediction 時，會先停止 fetch 新的指令，而在發生 mis-prediction 的分支指令前的指令，會被繼續執行 (i.e. pipeline 會被 drain out)；等到這條分支指令和其前面的指令都 retire 後，剩餘在 pipeline 中的指令，都是在 mis-prediction 的錯誤路徑上，因此可以直接將 pipeline 給 flush，並將 architecture RAT 的內容全部複製到 speculative RAT，這樣就完成了 RAT 的恢復，並可以開始從新的位址 fetch 指令

    

    • 缺點：
      • 如果分支指令之前有 load/store 指令發生 D-Cache miss，則這條分支指令需要等一段時間才能 retire，mis-prediction penalty 會增加

  • 上述兩種在指令 retire 時恢復 CPU 狀態的方法，也被稱為：Recovery at Retire

  • 使用 checkpoint 的方式，就可以在發生 branch mis-prediction 時 (e.g. execute stage)，馬上恢復 RAT 的狀態

    • 在每條分支指令改變處理器的狀態前，都將處理器的狀態 (e.g. RAT) 給存下來 (i.e. checkpoint)，當發生 branch mis-prediction 時，除了將 pipeline 中分支指令之後的指令給全部 flush 掉外，同時使用 checkpoint 來恢復處理器的狀態，然後就可以開始從新的位址 fetch 指令
    • 優點：
      • 處理器狀態恢復的速度比較快
      • 對於基於 CAM 的重命名映射表，由於每個 checkpoint 只需保存 valid bits，因此可以支援很多個 checkpoints，在 pipeline 中也就可以同時存在多條分支指令
    • 缺點：
      • 對於基於 SRAM 的重命名映射表，由於每個 checkpoint 都需要保存完整的 RAT，因此限制了 checkpoints 的數量，也就限制了 pipeline 中同時可以存在的分支指令的數量
      • 對於基於 CAM 的重命名映射表，使用 CAM 的電路面積和延遲會很大
        • 使用 CAM 實做的 RAT，RAT entries 的個數跟 physical registers 的個數成正本；當 physical registers 的數量增多時，RAT 的面積也會一併增大

  • 除此之外，也可以對哪些分支指令需要做 checkpoint 進行預測，因為大部分的分支指令的預測準確度很高，因此實際上不需要使用那麼多的 checkpoints

    • 可以同樣透過 2-bit saturating counter 來實現，當一條分支指令的預測準確率很高時，其 2-bit saturating counter 會處於飽和的狀態，這樣就不用替這條分支指令分配 checkpoint 了
    • 但當預測錯誤時：
      • 同樣等待分支指令和其前面的指令都 retire，並 flush pipeline 後，用上述的方式恢復 RAT 並重新從新的位址 fetch 指令
      • 也可以透過 ROB 來恢復 RAT：
        • ROB 中記錄著 RAT 被修改的歷史，每當一條指令被 register renamed 後，除了需要將 register 新的映射關係寫進 RAT 外，也需要將舊的映射關係寫進 ROB 中 (參考：link)
        • 因此當一條分支指令沒有被分配 checkpoint 時，可以透過 ROB 來恢復 RAT
    • 優點：
      • 需要的 checkpoints 硬體比較少，因此硬體面積也比較小
    • 缺點：
      • 在分支指令沒有被分配 checkpoint 並發生預測錯誤時，RAT 的恢復速度會比較慢

10.4.2 - 異常的處理

• 處理器的 exceptions 必須依照程式的執行順序來處理，一個比較早觸發的 exception 不代表它就一定會比比較晚觸發的 exception 早處理

  

  • 依照程式的執行順序，Page Fault Exception (由第一條指令觸發) 需要比 Undefined Instruction Exception (由第二條指令觸發) 先被處理，縱使 Page Fault Exception 比 Undefined Instruction Exception 晚觸發

• 一條指令的 exception 要被處理，必須先保證在它之前的指令的 exception 都已經被處理了，如果發現一條指令在準備要 retire 時發現其 ROB 中被標記有 pending 的 exception，那這條指令就不能 retire，需要先處理 exception

  

• 在 superscalar CPU 中，為了支持 precise exception，當發現要 retire 的指令有 pending 的 exception 時，在跳到 exception handler 前，必須先將 pipeline 中這條指令之後的所有指令都 flush 掉，並恢復 CPU 的狀態

  

• Exception 的 CPU 狀態恢復與 Recovery at Retire 相似，待 CPU 狀態恢復後，就可以跳到 exception handler 並 fetch 新的指令來執行

• 使用 Recovery at Retire 來恢復 exception 的其中一個好處是，很多的 exceptions 其實是不用被處理的，比如在 mis-prediction 路徑上的指令所觸發的 exceptions，只在指令 retire 時才處理 exception 可以簡化設計和避免不必要的處理

• 除了 Recovery at Retire 外，還可以在處理 exception 時，透過 ROB 中所記錄的舊的 physical registers (Preg) 的映射關係來恢復 RAT，也就是先前介紹的 WALK 方式

  

• 使用統一的 PRF 來實做暫存器重命名除了 RAT 外，還有 free list - 用來記錄 free 狀態的 physical registers；當 exception 發生時，除了 RAT 要恢復外，free list 也需要一併被恢復：

  • Free list 使用 FIFO 來實做，每當有指令做 register renaming 時，就會從 free list 讀出 free 狀態的 physical registers，此時只需移動 free list 的 read pointer 即可，free list entry 的內容無須改變；當有一條指令 retire 時並將其所使用的 physical register 釋放時，只需將該 physical register 寫入 free list 中，並移動 write pointer 即可
    • 因此要恢復 free list，只需每次在 ROB 讀取一條指令來恢復 RAT 時，同時也移動一次 read pointer，這樣當所有被 flushed 的指令對處理器的修改都恢復時，free list 也一併恢復完成了

• 使用統一的 PRF 來實做暫存器重命名的架構在處理 exception 時，採用 ROB 的方式來恢復狀態是比較合適的；相反地，採用 Recovery at Retire 的方式雖然可以利用 architecture RAT 來恢復 speculatvie RAT，但是對 free list 的恢復就沒有那麼直接了，有可能需要透過 architecture RAT 中所記錄的 physical registers 映射關係來恢復 free list，增加處理 exception 的 latency，降低執行效率

• 結論：

  • 當處理 exception 時：
    • 使用統一的 PRF 來實做暫存器重命名：比較適合使用 Recovery at Retire 方式來恢復 CPU 狀態
    • 使用 ROB 來實做暫存器重命名：比較適合使用 WALK 方式 (i.e. 透過 ROB) 來恢復 CPU 狀態

• 相較於 branch mis-prediction，exception 的發生頻率是更低的，因此對 exception 的處理可以慢一點，透過 WALK 方式 (i.e. 透過 ROB) 來恢復 CPU 狀態也是非常常見的 (e.g. MIPS R10000)

10.4.3 - 中斷的處理

• Exception 是同步的，interrupt 是非同步的，因此不能按照處理 exception 的方式來處理 interrupt
• 一般來說，有兩種方式處理 interrupt：
  1. 馬上處理：
     • 當 interrupt 發生時，flush 掉 pipeline 中所有的指令，並將 pipeline 中最老的指令的 PC 值以及其他的 status registers (e.g. ARM CSPR、SPSR) 給保存下來，恢復 CPU 的狀態後，跳到對應的 interrupt handler
     • 當從中斷返回時，使用當初所記下來的 PC 值重新 fetch 指令，也就是將先前被 flushed 掉的指令重新 fetch 進 pipeline
     • 優點：
       • Interrupt response latency 最低，可以很快的響應中斷，如果對 interrupt 響應時間有嚴格要求的，可以採用此設計
     • 缺點：
       • 原本執行到一半的指令因為 interrupt 的關係被 flushed 掉，相當於這些指令白作工，且這些指令在中斷返回後還是需要重新被執行，浪費了一些效率
  2. 延遲處理：
     • 當 interrupt 發生時，停止 fetch 新的指令，但要等到所有在 pipeline 中的指令都 retire 後，才會處理 interrupt
       • 由於 pipeline 中所有的指令都 retire 了，CPU 的狀態一定是正確的，因此不需要恢復 CPU 的狀態
     • 缺點：
       • 如果這些等待 retire 的指令中間發生了 D-Cache miss，需要很長的時間才能解決，導致 interrupt response latency 變長
       • 如果這些等待 retire 的指令中間發生了 branch mis-prediction，需要恢復 CPU 的狀態，也會消耗一定的時間，導致 interrupt response latency 變長
       • 如果這些等待 retire 的指令中間發生了 exception，那麼應該先處理 interrupt 或是 exception?
         • 一般來說都是先處理 interrupt
           • 因為很多類型的 exception 處理都需要花費很長的時間，像是：D-Cache miss、TLB miss 或是 page fault… 等，會導致 interrupt response latency 變長

10.4.4 - Store 指令的處理

• Store 指令只有在 retire 時，才可以將資料寫到 D-Cache 中，在此之前，即使 store 指令已經計算完畢，也只會將結果先暫時存在 store buffer 中，直到 store 指令 retire 時，才會將 store buffer 中對應的內容寫到 D-Cache 中
  • 在 store 指令被 dispatch 時，就會在 store buffer 中佔據一個 entry 了
• 在使用 store buffer 後，所有的 load 指令除了讀取 D-Cache 外，也需要檢查 store buffer 中是否有存取位址相等且比這條 load 指令還老的 store 指令
  • 如果有發現，那 load 指令的資料就是來自 store buffer 中對應的 store 指令
• Store 指令要成功的將資料寫入 D-Cache 後，才可以 retire 並離開 pipeline，但如果發生了 D-Cache miss，就需要等待很長的時間才可以 retire，然而，這會導致後續的指令即使已經執行完成，也無法 retire (retire 必須是 in-order 的，只要前面指令的 ROB entry 還尚未被釋放，這條指令就無法 retire)，造成處理器性能的降低

  • 要解決這個問題，最簡單的就是在 store buffer 中的每個 entry 增加一個 state bit，用來標記一條 store 指令是否具備 retire 的條件：un-complete、complete 和 retire

    • 當一條 store 指令被 dispatched 時，會在對應的 store buffer entry 中，標記這條 store 指令是 un-complete 的
    • 當這條 store 指令的存取位址已經被計算出來並讀取到其所需的 store 的 register 資料，且尚未變成 pipeline 中最老的指令，就標記這條 store 指令是 complete 的
    • 當這條 store 指令變成 pipeline 中最老的指令，就標記這條 store 指令是 retire 的；此時就可以將這條 store 指令所佔據的 ROB entry 給釋放，讓後面的指令繼續執行；Store buffer 的 entry 則要等到 store 指令資料真的寫進 D-Cache 中後，才會被釋放
      • 要注意的是，此時 store buffer 標記為 retire 的 entry，也會變成 CPU architecture state 的一部分
        • 也就是程式在讀取記憶體資料時，也要檢查 store buffer 中是否有相同位址且標記為 retire 的 store 指令的資料

  • 由於一旦 store buffer 滿了以後，就無法再處理新的 store 指令；採用上述的方法，會降低 store buffer 可用的空間，不過由於這樣的設計實做相對簡單，因此算是可以接受的折衷方法

  • 如果不想造成 store buffer 實際可用空間的降低，可以將 retire 的 store 指令存在另外一塊write back buffer 中，write back buffer 中 store 指令的值會再被寫入 D-Cache 中；Store 指令寫入 write back buffer 中後，store buffer 中對應的 entry 以及 ROB 中對應的 entry 就可以被釋放了

    

    • 要注意的是，此時 write back buffer，也會變成 CPU architecture state 的一部分，因此 load 指令會需要同時在 store buffer 和 write back buffer 中尋找是否有位址相同的 store 指令，因此會增加設計的複雜度
    • 同樣的，一旦 write back buffer 中沒有空間了，就沒辦法再 retire store 指令了
    • Store 指令是 in-order 寫入 write back buffer 中的，因此在 store 指令寫入 write back buffer 時，還需要檢查是否存在相同位址的 store 指令，如果有的話，就必須將該 store 指令標記為 invalid，這樣 load 指令在讀取 write back buffer 時，才可以讀到最新的資料
    • P.S. 其實這就類似擴充了 store buffer 的容量，除了 write back buffer 中可能不需要儲存這麼多 store 指令相關的資訊，所需的硬體空間可能比較小外，不確定採用這樣方式具體的好處有多少?

10.4.5 - 指令離開流水線的限制

• 對於一個 4-way 的 superscalar CPU，在沒有發生 branch mis-prediciton、interrupt 以及 exception，且 ROB 中最老的四條指令都已經是可以 retire 的情況下，這四條指令理論上是可以在同一個 cycle 一起 retire 的；然而，這也代表：

  • D-Cache 或 write back buffer 需要 4 個 write ports
  • 假設這四條指令都是分支指令，那麼需要在 1 個 cycle 內，將這些分支指令的資訊寫回 branch predictor，也就需要 branch predictor 中的所有元件 (BTB、PHT… 等)，都需要 4 個 write ports；除此之外，每個 cycle 也需要能 release 4 個 checkpoints 的資源
  • 如果有對 load 指令和 store 指令做 load/store 相關性的預測，假設這四條指令都是 load 指令，那麼就需要能在 1 個 cycle 內將 load 指令的資訊，寫回相關的預測器中，這些預測器也就需要 4 個 write ports

• 然而，上述的情況其實發生的機率非常小，為了滿足這些情境而增加硬體設計的複雜度是非常划不來的，因此在 superscalar CPU 中，可以對上述的情境加以限制：

  • 例如：限制每個 cycle 最多只能 retire 一條分支指令，如果同時有超過一條的分支指令準備 retire，第二條以及其後的分支指令都只不允許在當個 cycle retire，這樣就不需要這麼多 write ports 了

• 在 commit stage 需要對分支指令、store 指令和 load 指令的個數進行限制：

  

  • ROB 本質是個 FIFO，在 commit stage 會讀取 ROB 中最老的四條指令，根據它們的 complete 訊號來判斷哪些指令可以在這個 cycle retire，然後再透過 Branch、Store、Load 檢查電路產生 masks，將多餘的指令給 mask 掉，進而得到這個 cycle 有哪些指令可以退休了
    • mask：
      • 1：代表第一條 [branch|store|load] 指令，或是非 [branch|store|load] 指令，可以 retire
      • 0：代表第二條 (或第三條… etc) [branch|store|load] 指令，不可以 retire
    • 例如：
      • br_mask = 2’b1110
      • st_mask = 2’b1111
      • ld_mask = 2’b1111
      • 代表這個 cycle 中，這四條指令不存在多餘一條的 store 和 load 指令，但存在多餘一條的分支指令
        • 第四條指令就是多餘的分支指令
      • (br_mask & st_mask & ld_mask) = 2’b1110 => 代表這個 cycle 可以 retire 前三條指令
        • 實際上指令能不能 retire，還需考慮其他的條件，像是是否有發生 branch mis-prediction，或是是否有指令發生 exception… etc

• 每個 cycle 只能處理一個 exception，同樣可以用上述的方式來找到第一個被標記有 pending exception 的指令，並 mask 在其之後的指令

• 指令在 commit stage retire 後，需要根據最終 retire 指令的個數，更新 ROB 的 read pointer

  • i.e. 釋放 ROB entries

• FU 的個數決定了每個 cycle 最大可以同時執行的指令個數，也就是 issue width
• Execute stage 另一個重要的部份就是 bypassing network，其負責將 FU 的運算結果送到其他需要它的地方，像是 physical register file (PRF)、其他 FU 的輸入端、store buffer 等
  • 隨著每個 cycle 可以同時執行的指令個數的增多，bypassing network 變得越來越複雜，已經是處理器中速度提昇的一個關鍵部份
• 在不使用 bypassing network 的情況下，指令的 operands 值可以來自於 PRF (for non-data-capture)，或是 payload RAM (for data-capture)，每個 FU 都是透過 select 電路將 PRF 或是 payload RAM 串連起來的
  • 每個 select 電路和 PRF (或是 payload RAM) 的 read ports 是一一對應的，每個 FU 和 PRF (或是 payload RAM) 的 read ports 也是一一對應的
  • 因此，PRF 總共需要的 read ports 個數與 issue width 是直接相關的；如果對處理器追求更大的 issue width，就代表著 PRF 需要更多的 read ports，反而會限制了處理器的執行速度，現代處理器多會採用 cluster 架構來解決這個矛盾
    • Payload RAM 由於需要與 Issue Queue 綁定在一起，使用 distributed Issue Queue 可以減少 payload RAM read ports 的需求

9.2 - FU 的類型

9.2.1 - ALU

• ALU (Arithmetic and Logic Unit) 通常負責：整數加減法、shift、簡單的乘除法、資料搬移 (e.g. mov、byte-swap 指令)、分支指令目標位址的計算、記憶體存取位址的計算
• 很多處理器在 ALU 中也實現了比較簡單的乘法功能，用來支持乘法指令
  • 不過為了追求比較高的處理效能，高性能處理器通常選擇將乘法器單獨使用一個 FU 來實現，並在這個 FU 中實現乘累加的功能
  • 有些處理器基於功耗和成本的考量，會將整數類型的乘法交由浮點數運算的 FU 來運算
    • 整數轉成浮點數 → 浮點數乘法 → 浮點數轉為整數
    • 指令的 latency 會變長，但較省面積和功耗，Intel Atom CPU 就採用了此設計

9.2.2 - AGU

• AGU (Address Generate Unit) 用來計算記憶體存取位址，如 load/store 指令
  • 在一般 pipeline 處理器中，記憶體的存取位址都是交由 ALU 來計算，但是在 superscalar CPU 中，由於需要同時執行多條的指令，記憶體存取指令的執行效率直接影響了處理器的性能，所以通常會單獨使用一個 FU 來計算其位址

9.2.3 - BRU

• BRU (Branch Unit) 負責處理 control flow 類型的指令，如 branch、jump、call 和 return 類型的指令，BRU 負責將這些指令所攜帶的目標位址計算出來，並根據一定的條件決定是否使用這些位址；同時，在這個 FU 中還會對分支預測與否正確進行檢查，一旦發現 mis-prediction，就需要啟動相對硬的恢復機制
• ARM 和 PowerPC 等處理器在指令中的編碼加上了 condition code，根據 condition code 來決定指令是否執行

  • 優點：

    • 不須使用分支指令，因此可以降低分支指令使用的頻率，也就降低了分支預測錯誤的風險，可以獲得更好的執行性能

  • 缺點：

    • Condition code 佔據了指令 encoding 的一部分，例如 ARM 使用了 4 bits 的 condition code (NCZV)，扣除掉 opcode、immediate… etc，最後只剩 4 bits 可以用來 encode registers，因此 ARM 指令集支援的 registers 個數只有 16 個 ($r0 ~ $r15)
    • 使用更多的 registers 可以降低指令存取記憶體的頻率，增加處理器的執行效率
    • 當 pipeline 中存在很多條件不符合，因此不會被執行的條件指令，就會造成 pipeline 中存在著大量無效的指令，反而降低了處理器的執行效率

  • 此外，條件執行指令也會對 register renaming 帶來額外的麻煩：

    

    • 如果 ADDEQ 指令會被執行，但 SUBNE 指令不會被執行，那麼 ADD 指令應該使用 P6 而非 P7

    • 最簡單的方法就是 stall pipeline：一旦在 register renaming 的時候碰到條件執行指令，就 stall pipeline，直到這條指令的執行條件被計算出來，就可以決定後續的 register rename 的結果

      • 缺點：效能非常差

    • 另外一個方法就是對條件執行指令也進行預測：可以先假設所有條件執行指令都會被執行，等到後續指令的執行條件被計算出來，並發現預測錯誤時，再恢復執行前的狀態：

      • 將在這條條件執行指令之後的指令從 pipeline 中 flush
      • 恢復這些指令對 RAT 的修改
      • 重新將這些指令 fetch 進 pipeline，重新做 register renaming 時就會使用正確的結果
      • 缺點：
        • 條件指令相較於分支指令，比較沒有固定的 pattern (i.e. 執行 or 不執行)，因此 mis-prediction 的機率會高得多，效率不高

    • (Intel x86) 硬體插入額外的 select-uOP 指令：

      

      • select-uOP 指令可以針對兩個條件執行指令的結果做選擇，所以需要兩個條件執行指令才可以使用
      • 需要編譯器的搭配，手寫 assembly 的時候也需要特別的處理硬體才會插入 select-uOP 指令
      • 例如：
        • ADDEQ 指令會執行：P8 = P6
        • SUBNE 指令會執行：P8 = P7
        • P.S. ADDEQ 指令和 SUBNE 指令都不會被執行的時候???

    • 硬體在每個條件指令後面都插入一條 select-uOP 指令：

      

      • 不用侷限於一定要兩個條件指令才能使用
      • 缺點：
        • 指令變多，執行效能會降低
      • 也可以先每兩條條件指令插入一條 select-uOP 指令，直到最後只剩一條條件執行指令時，再額外插入一條 select-uOP 指令

  • ARM 以 s 結尾的指令，在執行完畢後，也會修改 CPSR，CPSR 就相當於這條指令的另一個 destination register；所有在這條指令之後的條件執行指令，都會將 CPSR 視為其中一個的 source register (i.e. 相當於使用該指令的 destination register)

    • 因此，CPSR 也可以當作一個普通的 register，也可以對其做 register renaming
    • 不過由於 CPSR 的寬度小於一般的暫存器，因此一般會為 CPSR 使用一個獨立的 PRF
    • 由此可見，使用 CPSR 增加了 register renaming 的複雜度，功耗也會有所增加，各有利弊
• 對於實現分支預測的處理器來說，BRU 還必須負責檢查分支預測是否正確；如果發現 mis-prediction，就必須依照先前介紹分支預測失敗狀態恢復的方法 (參考：4.4 - 分支預測失敗時的恢復)，恢復 pipeline 的狀態

9.2.4 - 其他 FU

• 處理器中還包含其他很多類型的 FU：
  • 浮點數運算 FU
  • SIMD 類型指令的 FU

9.3 - 旁路網路

• 一條指令可以在 execute stage 才需要 operands，且在 execute stage 末端就可以得到它的結果，因此只需在 FU 的輸入端和 FU 的輸出端之間搭建一個通路，就可以提前將 FU 的計算結果送到所有 FU 的輸入端

  • 處理器內部也有其他的元件需要 FU 的計算結果：PRF、payload RAM 等，因此也需要將 FU 的計算結果送到這些地方
  • 這個通路就稱為：Bypassing network

• 在處理器中，為了能夠 back-to-back 的執行指令，bypassing network 都是必須的：

  

  • 指令 A 的計算結果，需要提前在 EX stage 末端，bypass 計算結果給指令 B

• 在 superscalar CPU 中，指令在被 select 電路選中的那個 stage，wake up pipeline 中相關的指令，仍舊可以 back-to-back 的執行指令：

  

  • 指令 A 在 Select stage wake up 指令 B，並提前在 Execute stage 末端，bypass 計算結果給指令 B

• 一個更真實的 superscalar CPU，有可能會切分更細的 pipeline stages：

  • Source operands 從 PRF 讀出來，需要經過一段很長的線路，才能抵達 FU 的輸入端，而且 FU 的輸入端還有大量的 multiplexer，用來選擇從不同的 bypassing network 或 PRF 的輸出中選擇合適的 operands
    • 為了降低對 CPU cycle time 的影響，source operands 從 PRF 讀出來後，還需要經過一個 Source Drive stage (≥ 1 個 cycle)，才能抵達 FU 的輸入端
  • FU 計算完後，也需要經過複雜的 bypassing network，才能抵達 FU 或是 PRF 的輸入端
    • 為了降低對 CPU cycle time 的影響，FU 的結果被計算出來後，還需要經過一個 Result Drive stage (≥ 1 個 cycle)，才能 FU 或 PRF 的輸入端

  

9.3.1 - 簡單設計的旁路網路

• 當 FU 的個數比較少，對 CPU 頻率的要求不高時，bypassing network 可以採用比較簡單的設計

  

  • FU 的 operands 直接來自於 PRF
  • FU 的計算結果也直接寫入 PRF
  • 一個 FU 想使用另一個 FU 的計算結果只能直接從 PRF 讀取

  

  • FU 的 operands 可以來自於 PRF、自身 FU 的結果、其他 FU 的結果
    • 每個 FU 都需要一個 3-to-1 的 multiplexer 來選擇 operands 來源
  • FU 的計算結果會透過 bypassing network，寫入 PRF 或是 FU 的輸入端

• 很多 FU 都有多個功能，也就是有多個計算單元；然而，由於 FU 所支援的指令的 latency 不一定都相同，如加減法指令只需 1 個 cycle 即可完成，乘法指令需要 32 個 cycles 才能完成，此時如果使用採用正常的執行，就可能出現一個 FU 中兩個以上計算單元的結果在同一個 cycle 被計算出，並搶用 FU 的 bypassing network，造成衝突

  

  • 最簡單的解法可以採用類似 8.5.3 - 推測喚醒的方法，先假設不會發生衝突，等到一條指令到達 FU 中被執行之前，檢查目前 FU 是否可以被使用，例如：

    • 一個 FU 在上個 cycle 執行了 latency = 3 的指令，那麼這個 cycle 就沒辦法執行 latency = 2 的指令了

    • 如果這個 cycle 不幸到達 FU 的指令的 latency = 2，那就必須將這條指令重新放回 Issue Queue 中參與仲裁

    • 缺點：

      • 浪費了原本可以執行其他指令的機會，如果可以事先得知無法執行 latency = 2 的指令，那 select 電路就可以選擇其他 latency ≠ 2 的指令來執行

        

    • 因此，select 電路在進行仲裁時，應該要將某些 latency 的指令給排除，那就可以在不降低性能的情況下解決 bypassing network 衝突的問題

    • 例如：

      • 假設一個 FU 可以執行三種類型的指令，也就是該 FU 有三種計算單元，其對應的 latency 分別為：1 個 cycle、2 個 cycles、3 個 cycles，那麼：
        • 當這個 cycle 執行 latency = 3 的指令時：
          • 下個 cycle 不允許執行 latency = 2 的指令
          • 下下個 cycle 不允許執行 latency = 1 的指令
        • 當這個 cycle 執行 latency = 2 的指令時：
          • 下個 cycle 不允許執行 latency = 1 的指令
        • 當這個 cycle 執行 latency = 1 的指令時，沒有限制
        • 對於 latency = 3 的指令，沒有限制 (假設 FU 是 pipeline 的)

• Select 電路在仲裁時，需要考慮指令所對應的 FU 是否可以被使用，不會產生 bypassing network 衝突

• 從簡化設計的考量，最好使一個 FU 所執行所有類型的指令的 latency 都是相同的，就不用引入上述的判斷電路

9.3.2 - 複雜設計的旁路網路

• 真實的 superscalar CPU 中，execute stage 有可能會切分更細的 pipeline stages：Source Drive stage 以及 Result Drive stage，這也導致了 bypassing network 需要做對應的變化：

  

  • 指令 B 只能在 Execute stage 從指令 A 的 Result drive stage 獲得 operands

  • 指令 C 可以在 Source drive stage 從指令 A 的 Result drive stage 獲得 operands

  • 指令 C 也可以在 Execute stage 從指令 A 的 Write back stage 獲得 operands

  • 指令 D 可以在 Source drive stage 從指令 A 的 Write back stage 獲得 operands

  • 指令 E 在 RF read stage 讀去 PRF 時，就可以得到指令 A 寫入 PRF 的結果了，因此不需要透過 bypassing network

    • 假設 PRF write 可以在前半個 cycle 完成，PRF read 可以在後半個 cycle 完成

• 在複雜的 pipeline 中加入 bypassing network，會使設計的複雜度變大，對 CPU cycle time 造成一定的影響

  

  • 相較於先前簡單的設計，只增加了 Source Drive 和 Result Drive stages，不使用 bypassing network 並不會增加設計的複雜度

  

  • 相較於先前簡單的設計，增加了 Source Drive 和 Result Drive stages 會導致在使用 bypassing network 時，設計的複雜度大幅度的增加

• 每新增一個新的 pipeline stage，bypassing network 的複雜度會大幅地增加，因此無法無上限的新增 pipeline stage

9.4 - 操作數的選擇

• FU 的輸入端來源包括：PRF、bypassing network、還有指令的 immediate value；而這些來源是透過 multiplexer 來選擇的，需要有對應的訊號來控制這個 multiplexer，決定要選擇的來源

• 所有的 physical register 可以保存在一個表格：Scoreboard 中，scoreboard 記錄了一個 physical register 生命週期經過的地方：

  

  • 真實的 scoreboard 原本圖片所示來得複雜
  • scoreboard 中對於每個 physical register，都記錄了：
    • FU #：這個 physical register 會在哪個 FU 被計算出來
      • 當需要透過 bypassing network 取得 physical register 的值時，需要知道它來自於哪個 FU，以控制 multiplexer 選擇對應的值
      • 當一條指令被 select 電路選中時，就會將這條指令的 destination register 在哪個 FU 中執行的資訊記錄到 scoreboard 中
    • R：表示這個 physical register 已經被 FU 計算出來並寫進 PRF 中
      • 只需使用一個 bit 即可：
        • 0：這個 physical register 還沒被寫進 PRF 中，需要透過 bypassing network 來取得值
        • 1：這個 physical register 已經被寫進 PRF 中了，可以直接讀取 PRF 來取得值

• 在 pipeline 中加入 scoreboard 會對 pipeline 的性能造成一定的影響：

  

  • 指令 A 在 select stage 會將 $r1 的 physical register 在哪個 FU 中執行的資訊寫進 scoreboard 的 FU # 中
  • 指令 A 在 write-back stage 除了會將 FU 的結果寫入 PRF，也會將 $r1 的 physical register 在 scoreboard 中的 R 設成 1
  • 指令 B 在 execute stage 時，可以讀取 scoreboard，得知其所需的 $r1 需透過 bypassing network 來取得
  • 指令 C 在 execute stage 時，可以讀去 scoreboard，得知其所需的 $r1 可以直接讀取 PRF 來取得

• Scoreboard 的讀取如果放在 execute stage，會對 CPU 的 cycle time 造成一定的影響

  

  • 當 CPU 頻率的需求比較高時，這種作法可能就無法滿足要求

  • 如果需要提高 CPU 的頻率，可以將 scoreboard 的讀取放到 RF read stage，使 scoreboard 的讀取和 PRF 的讀取可以同時進行，”隱藏” scoreboard 的讀取時間：

    

    • 然而，這樣會導致新的問題：

      

      • 指令 C 原本可以在 execute stage 直接讀取 PRF 獲得 $r1 的值，但由於指令 C 讀取 scoreboard 時，指令 A 尚未完成 scoreboard R bit 的更新，因此會讓指令 C 錯誤地認為 $r1 必須透過 bypassing network 才能獲得

    • 可以在讀取和寫入 scoreboard 的地方加入新的邏輯：

      • 當寫入 scoreboard 所使用的 physical register 編號和讀取 scoreboard 的 physical register 編號相同時，就將 multiplexer 設為從 PRF 中獲得 operands

• 補充：

  • 實際上的 scoreboard 範例：

    1 2 3

    MUL F2, F0, F4 ; F2 = F0 * F4 ADD F6, F2, F8 ; F6 = F2 + F8 SUB F10, F6, F12 ; F10 = F6 - F12

    1 2 3 4 5 6 7

    +------+-------+-----+-----+-----+-----+-------+-------+-----+-----+ | FU | Busy | Op | Fi | Fj | Fk | Qj | Qk | Rj | Rk | +------+-------+-----+-----+-----+-----+-------+-------+-----+-----+ | MUL1 | Y | MUL | F2 | F0 | F4 | - | - | T | T | | ADD1 | Y | ADD | F6 | F2 | F8 | MUL1 | - | F | T | | ADD2 | Y | SUB | F10 | F6 | F12 | ADD1 | - | F | T | +------+-------+-----+-----+-----+-----+-------+-------+-----+-----+

    • FU：FU 的名稱
    • Busy：FU 是否正在忙
    • Op：這個 FU 正在執行的 operation
    • Fi：這個 FU 要寫的 destination register
    • Fj, Fk：FU 所需的 source registers
    • Qj, Qk：如果 Fj/Fk 尚未 ready，哪個 FU 會提供它
    • Rj, Rk：來源是否 ready

  • 現代處理器，scoreboard 幾乎已經被 Tomasulo (Issue Queue + Register Renaming + Bypassing Network) 給取代了

9.5 - Cluster

• 現在處理器隨著 pipeline stages 級數的提高，會導致硬體的設計越來越複雜，例如需要更多的 read/write ports、PRF，更複雜的 bypassing network，不僅增加了硬體的面積，也增加了硬體的功耗，限制了 CPU 的頻率，需要採用 Cluster 架構來解決這個問題

9.5.1 - Cluster Issue Queue

• 除了 Issue Queue 外，由於 register file 與 Issue Queue 彼此是緊密相關的，因此 register file 同時也會採用 cluster 架構

• 8.1.1 - 集中式 (Centralized) vs. 分佈式 (Distributed) 介紹的 distributed Issue Queue 就是將 Issue Queue 採用了 cluster 架構

  

  • 每個 cluster Issue Queue 都對應一個 payload RAM (採用 data-capture 架構) 和 FU
  • 優點：
    • 減少每個 Issue Queues 的 ports 數
    • 每個 Issue Queue 對應的 select 電路只需從少量的指令中做仲裁，因此可以加快 select 電路的速度
    • 由於 Issue Queue 的容量較小，因此 wake up 指令的速度也比較快
    • Payload RAM 也可以採用 cluster 架構，因此每個 payload RAM 的容量也會比較小，而且也不需要支援這麼多的 read/write ports
  • 缺點：
    • 被 select 電路選中的指令如果要 wake up 的指令存在另外的 Issue Queue 中，那麼需要走比較長的 wake up 電路

      • 對頻率有要求的 CPU，跨 cluster 的 wake up 有可能會需要額外新增一個 pipeline stage

      • 當兩條存在相關性的指令存在不同 cluster 的 Issue Queue 時，有可能就會有 bubble，無法 back-to-back 的執行指令

      • 例如：一個 2-way issue 的 CPU，執行指令 A ~ E，假設指令 A ~ E 的 dependency 如下：

        

        • 如果指令 A、B、E 被分配到同一個 cluster，指令 C、D 被分配到另外一個 cluster，共需 5 個 cycles 才能執行完畢：

          

          • 指令 A 需要多 1 個 cycle 才能 wake up 指令 C
          • 指令 B 需要多 1 個 cycle 才能 wake up 指令 D
          • 指令 D 需要多 1 個 cycle 才能 wake up 指令 E

        • 如果指令 A、C 被分配到同一個 cluster，指令 B、D、E 被分配到另一個 cluster，只需 3 個 cycles 才能執行完畢：

          

          • 指令 A 可以 back-to-back wake up 指令 C
          • 指令 B 可以 back-to-back wake up 指令 D
          • 指令 D 可以 back-to-back wake up 指令 E

        • 因此想使處理器有比較高的執行效率，指令 allocation 的演算法就必須有適當的設計

• 對於採用 non-data-capture 架構的 CPU 來說，指令在被 select 電路選中後，會先去讀 PRF，因此就需要 PRF 支援 multiple read ports，因此也會增大硬體面積，執行效率也會比較慢，因此，也可以對 PRF 採用 cluster 架構

  

  • 每個 cluster 都有”完整”的 PRF：每個 FU 在更新自己 cluster 內部 PRF 的同時，也同時需要更新其他 clusters 的 PRF
  • 每個 FU 都只能在自己的 cluster 內使用 bypassing network
  • 優點：
    • 減少 PRF 所需的 read ports
      • 4 個 FU → 每個 cluster 2 個 FU，因此 read ports 可以減少，進而減少硬體面積
      • 但無法減少 write ports，因為 FU 仍需要更新其他 clusters 的 PRF
    • 減少 bypassing network 的複雜度
  • 缺點：
    • Bypassing network 無法跨 cluster，當兩個存在相關性的連續指令處於不同的 clusters 時，後面的指令需要等到前面的指令更新完 PRF 後，才能從 PRF 中讀取 operands
      • 雖然硬體可以嘗試找其他不相關的指令到這兩條指令中間來執行，但當 pipeline 較深的時候，硬體可能沒辦法找到這麼多不相關的指令，引進較多的 bubbles

9.5.2 - Cluster Bypassing Network

• 為了減少 bypassing network 的複雜度，也可以讓 bypassing network 採用 cluster 的架構

  

  • 採用 cluster 架構的 bypassing network 後，每個 FU 就沒辦法將其計算結果送到其他 clusters 的 FU
    • 當兩條相關的指令都使用同一個 FU 時，還是可以透過 bypassing network，back-to-back 的執行
      • 跨 cluster 只能透過 PRF 來傳遞 operands
    • 但當兩條相關的指令使用不同 clusters 的 FU 時，就沒辦法 back-to-back 的執行了
  • 由於 bypassing network 的複雜度降低了，因此 pipeline 中的 Source Drive stage 和 Result Drive stage 就可以被移除了

    • 雖然跨 cluster 只能透過 PRF 來傳遞 operands，但由於 pipeline 少了 Source Driver stage 以及 Result Driver stage，因此一條指令的執行效率是有被提高的，兩條跨 cluster 的指令只需間隔 1 個 cycle 即可

      

      • Out-of-order CPU 可以找一條不相關的指令插到這個 cycle 中來執行
        • 然而，隨著 CPU 同時可以執行的指令數越來越多，PRF 的 ports 數量也會隨著增加，加上 CPU 的頻率的提高 (i.e. cycle time 的減少)，有可能會導致 PRF 沒辦法在同一個 cycle 中做 write & read，兩條相關的指令就需要間隔更多的 cycles，Out-of-order CPU 有可能沒辦法找到這麼多條不相關的指令插到這幾個 cycles 中來執行，影響到 CPU 的執行效率
      • In-order CPU 由於沒辦法調度不相干的指令來執行，只能產生 bubbles，因此通常 in-order CPU 都會採用”完全”的 bypassing network，而非採用 cluster 架構的 bypassing network
        • 例如：Intel Atom 就有複雜的 bypassing network

• 對於 Cluster Issue Queue 和 cluster bypassing network，當兩條相關的指令分處於不同的 cluster 時，都會需要 delay 1 個 cycle，但這兩個 delays 其實並不會被累加：

  

  • 指令 A 需要 delay 1 個 cycle 才能 wake up 指令 B
  • 由於已經 delay 1 個 cycle 才 wake up 指令 B，指令 A bypass 其 FU 的計算結果的 delay 剛好被隱藏起來了；當指令 B 進到 execute stage 時，指令 B 的 FU 剛好可以接收到來自指令 A 的 FU 的計算結果，不需要額外的 delay
  • 總共只需要 delay 1 個 cycle 即可

9.6 - 記憶體指令的加速

9.6.1 - Memory Disambiguation

• 暫存器的相關性 (RAW、WAW、WAR)，都是可以在 register renaming stage 被解決；然而，針對記憶體存取的相關性 (i.e. load、store 指令)，由於記憶體存取位址是在 execute stage 才被計算出來的，才可以得知兩條記憶體存取的指令，是否存在相關性
  • 記憶體存取指令間也存在 RAW、WAW、WAR 相關性：

• 記憶體存取的 WAW、WAR 是沒辦法像暫存器可以用 register renaming 來消除的，因此記憶體存取的 RAW、WAW、WAR 都是真的相關性，需要特別處理

• 為了降低設計難度，大部分的處理器：

  • Store 指令都是 in-order 的，可以避免 WAW 相關性
  • Load 指令則有不同的實現方式：
    • 完全 in-order：
      • Load 指令和 store 指令都完全依照程式的順序來執行
    • 部份 out-of-order：
      • In-order 的 store 指令將程式劃分成了不同的 blocks，當一條 store 指令的存取位址被計算出來後，這條 store 指令和它後面的 store 指令之間的 load 指令可以以 out-of-order 的方式來執行：
      • 這種設計可以降低 RAW 相關性的檢查難度
    • 完全 out-of-order：
      • Load 指令不受 store 指令的限制，只要 load 指令的 operands 都準備好了，它就可以被送到 FU 中執行
      • 這種設計 WAR 和 RAW 相關性都必須在 pipeline 中被處理

• 完全 in-order：

  • Load 指令和 store 指令都是嚴格得照程式的執行順序來執行，為最保守的一種方法
  • 由於 load 指令通常處於相關性的頂端，這種方法沒辦法使 load 指令盡可能地提前被執行，導致所有相關的指令都必須等待 load 指令才能被執行，性能較差
  • 在 superscalar CPU 中基本上不會採用此方法

• 部份 out-of-order：

  • Store 指令仍是 in-order 執行，但兩條 store 指令之間的所有 load 指令都可以以 out-of-order 的方式來執行

  • 可以使 load 指令盡可能地提早被執行

  • 當一條 store 指令的存取位址被計算出來後，在它之後進入到的所有 load 指令就可以判斷 RAW 的相關性了，每條 load 指令的存取位址被計算出來後，需要和前面所有已經執行的 store 指令的存取位址進行比較

  • 因此，需要使用 store buffer 來儲存還沒 retire 的 store 指令，如果 load 指令在 store buffer 中發現了相同存取位址的 store 指令，則說明了存在 RAW 的相關性，此時 load 指令就可以直接從 store buffer 拿到 store 指令的值；如果在 store buffer 中沒有找到相同存取位址的 store 指令，那 load 指令就必須去存取 D-Cache 或是 memory 來取得值

  • 實際上，當 store 指令被 select 電路選中後，就可以 wake up 後面的 load 指令了，無須等到 store 指令的存取位址真的被計算出來；當 load 指令的存取位址被計算出來時，其前面 store 指令的存取位址一定也早就被計算出來了

    • 然而除了比較存取位址外，還需要比較指令的先後順序，例如：

      

      • 即使 store 指令 E 和 store 指令 A 的存取位址相同，load 指令 B、C、D 也不會跟 store 指令 E 有 RAW 相關性，如果只比對 store buffer 中的存取位址，有可能就會判斷錯誤 (如果 load 指令 B、C、D 執行時，store 指令 E 已經存入 store buffer 中了)
        • RAW 相關性檢查只需檢查 load 指令之前的 store 指令即可，因此需要對 load 指令和 store 指令前後順序進行編號
      • 可以在 decode stage 替每條 load 指令和 store 指令進行編號，這個編號的 bits 寬度由 pipeline 中最多可容納的 load 指令和 store 指令的個數來決定
        • 編號的比較方法可以參考 ROB 編號的比較方式
        • 由於 ROB 中儲存了所有的指令，使用 ROB 編號作為 load 指令和 store 指令的編號會變得非常的稀疏，浪費比較器的 bits 寬，增加硬體面積，不過在真實處理器中也有採用

    • P.S. 一條 load 指令是有可能會與多條 store 指令存在 RAW 相關性的

      • 例如：兩條 store 指令各 store 1 byte 的資料，但另外一條 load 指令 load 的 4 bytes 資料中，其中 2 bytes 是從這兩條 stores 而來，此時這條 load 指令就與這兩條 store 指令存在 RAW 相關性
      • 因此不能單單只比較位址，還需比較存取的資料範圍
        • i.e. addr + size

  • 另外一種設計方法，可以限制後面的 store 指令只有在前面所有的 load 指令全部都被 select 電路選中後，才允許該 store 指令向 select 電路發出 request

    • 這樣每一條 load 指令在比對 store buffer 時，只會遇到在自己老的 store 指令，而不會遇到比自己年輕的 store 指令，就不需要比對指令的先後順序，簡化 RAW 相關性的檢查
    • 例如上例中，store 指令 E 只能在 load 指令 B、C、D 都被 select 電路選中後，才會向 select 電路發出 request

  • 然而這種部份 out-of-order 的設計，仍然無法最大限度的同步執行指令：

    

    • Load 指令 F 與 store 指令 B 沒有相關性，但卻沒辦法在 store 指令 B 之前被執行

• 完全 out-of-order：

  • Store 指令仍是 in-order 執行，但只要 load 指令的 operands 都準備好了，就可以向 select 電路發出 request
  • 可以採用 load 指令和 store 指令共用同一個 Issue Queue，每個 cycle 只 issue 一條 load 指令或 store 指令的設計，或是每個 cycle 同時 issue 一條 load 指令和 store 指令的設計
    • Load 指令和 store 指令在一般程式中佔的比例比較大，所以最好每個 cycle 都盡可能的增加每個 cycle 可以同時執行的 load 指令和 store 指令的個數
    • 不過由於 load 指令和 store 指令的處理過程不同，即使使用同一個 Issue Queue，仍需要使用互相獨立的 select 電路

      • 對於 store 指令的 select 電路來說：

        • 當指令被寫入 Issue Queue 中時，需根據指令的年齡資訊，找到最舊的那條 store 指令來 issue；如果還沒有準備好，則必須一直等待 ⇒ In-order

      • 對於 load 指令的 select 電路來說：

        • 只需要比對準備好的 load 指令的年齡資訊即可，找到最舊，且準備好的 load 指令來 issue ⇒ Out-of-order
  • 也可以採用 load 指令和 store 指令各自使用獨立的 Issue Queue 的設計
    • Store 指令的 Issue Queue 可以直接使用 FIFO 來實做，select 電路不用比較年齡資訊，只需判斷 FIFO 中最舊的那條 store 指令是否準備好就好

• Store/load 指令違例：

  

  • 第二條 load 指令被提前到 store 指令之前被執行，結果發現 store 指令與第二條 load 指令的存取位址相同，彼此之間存在 RAW 相關性，因此必須恢復 pipeline 的狀態
    • 除此之外，不僅第二條 load 指令的結果有錯，所有與這條 load 指令有直接關係或間接關係的指令，都需要從 pipeline 中被 flushed 掉，恢復 pipeline 的狀態，並重新參與仲裁並執行，因此會影響處理器的執行效能
  • 需要採用 load/store 相關性的預測，來預測哪些 load 指令和前面的 store 指令存在 RAW 相關性而不能提前被執行：
    • 透過 load/store 相關性的預測，一旦發現一條 load 指令和它前面的 store 指令存在 RAW 相關性，就將其記錄下來，之後再遇到這條 load 指令時，就不提前執行，而且需要從 store buffer 中獲取 load 指令所需要的值
      • 額外好處：只有那些與 store 指令存在 RAW 相關性的 load 指令，才需要存取 store buffer，因此可以減少 store buffer 所需的 ports 數及比較電路的個數，並降低設計的複雜度和功耗
    • P.S. 預測失敗並不需要恢復 pipeline 的狀態， 因為 load 指令只是比較晚被執行而已

9.6.2 - Non-blocking Cache

• I-Cache 由於 fetch 指令需要照 program order，不能簡單地使用 non-blocking cache，因此 non-blocking cache 主要會用在 D-Cache

  • 然而對於使用了 branch prediction 的 CPU 來說，是可以根據當前指令的位址來對下一條指令的位址做預測的；當使用一個 PC address 讀取 I-Cache 發生 I-Cache miss，且同時預測這個 PC address 所的指令是一條分支指令時，如果不採用 non-blocking I-Cache，那 CPU 就得等這條分支指令從 I-Cache 讀出來後，才可以繼續使用預測的 PC address 來 fetch 下一條指令，此時再次發生 I-Cache miss 的機率是很高的：

    

    • 有可能連續發生兩次 miss penalties

  • 如果使用 non-blocking I-Cache，就可以隱藏一部分的 miss penalty，提高處理器的執行效率：

    

    • Non-blocking I-Cache 不用等到所預測的分支指令從 I-Cache 讀出來後，才開始 fetch 下一條指令 (有可能又會再發生一次 I-Cache miss)

  • 然而，由於指令的特性，就算後面的指令比前面一個指令先被 fetched 進來，也沒辦法先執行後面的指令；因此通常不用使用太大的 MSHR

• 對於 load 指令來說 (假設 L1 D-Cache 下一級就是記憶體)：

  • 如果需要的資料不在 D-Cache 中，就會發生 D-Cache miss，需要從下一級的記憶體中讀取data block (一條 cache line 的 size)，並找到一條 cache line 將該 data block 寫入
    • 如果被寫入的 cache line 是 dirty 的，那在寫入之前，還需要先將 dirty 的 cache line flush 回記憶體後，才可以將讀到的 data block 寫入 cache line

• 對於 store 指令來說 (假設 L1 D-Cache 下一級就是記憶體)：

  • 如果 store 的位址不在 D-Cache 中，對於 “write back + write allocate” 類型的 D-Cache 來說，首先需要從記憶體中找到這個位址對應的 data block，讀出來後與 store 指令的資料合併，並找到一條 cache line 將合併後的資料寫入
    • 如果被替換的 cache line 是 dirty 的，那在寫入之前，還需要先將 dirty 的 cache line flush 回記憶體後，才可以將合併後的資料寫入 cache line

• 不管是 load 指令還是 store 指令，當發生 D-Cache miss 時，D-Cache 和記憶體都是需要交換資料的，通常需要好幾個 cycles 才能完成；如果在這幾個 cycles 內，又發生了 D-Cache miss，該如何處理?

  • 最簡單的方法就是在發生 D-Cache miss 並未被解決前，鎖定 D-Cache 和記憶體之間的 bus，只處理目前發生 D-Cache miss 的指令

    • 缺點：

      • D-Cache miss 通常處理的時間都比較長，如果這段時間 block 了 load 指令和 store 指令的執行，在一般情況下，load 指令都是處於相關性的最頂端，這樣的 block 就會大大降低處理器可以同步執行指令的數量，降低處理效能

      • 這種 cache 設計方法稱為：Blocking Cache

        

  • 如果在發生 D-Cache miss 時，不用 block load 指令和 store 指令的執行，這種 cache 的設計方法稱為：Non-blocking Cache

    

    • Non-blocking cache 可以在一定程度上掩蓋 D-Cache miss 所佔用的時間 (Miss Penalty)
    • 採用 non-blocking cache 後，load 指令和 store 指令 D-Cache miss 被處理完的時間有可能就跟原始的程式執行順序不一樣了
    • 為了支援 non-blocking cache，必須將產生 D-Cache miss 的 load 指令和 store 指令給記錄起來，用來保存這些資訊的硬體稱為：MSHR (Miss Status/information Holding Register)

• D-Cache miss 可以分為兩種：

  • Primary miss：
    • 對於一位址來說，存取 D-Cache 時第一次發生的 miss 稱為：primary miss
  • Secondary miss：
    • 對於一位址來說，primary miss 還沒被處理完前，後續的 load 指令或 store 指令再次存取了同一條 cache line 並發生 D-Cache miss，此時的 miss 便稱為：secondary miss

• MSHR 和 Load/store Table 的架構如下：

  

  • MSHR：
    • MSHR 記錄了所有發生 primary miss 的指令
    • V：
      • Valid bit，用來表示此 MSHR entry 是否被佔用
      • 當發生 primary miss 時，會將該指令存進一 MSHR entry 和 Load/store Table entry，並將 V 設成 1
      • 當從下一級的記憶體讀回資料後，就會將對應的 MSHR entry 和 Load/store Table entry 清掉，並將 V 設成 0
    • Block address：
      • 發生 primary miss 位址的 cache line address
        • 例如：
          • Cache line = 64 bytes ⇒ 需要 6 bits 來選擇所存取的資料位址是在哪個 byte
          • 假設存取位址是 32 bits ⇒ Block address = 32 - 6 = 26 bits
      • 每條 load 指令或是 store 指令發生 D-Cache miss 時，都會查詢 MSHR 是否有同一條 cache line 正在被讀取的過程中，這需要比較 MSHR 每個 V = 1 的 entries
        • 如果有發現同一條 cache line 正在被讀取的過程，那麼就不需要再發一次 request
      • P.S. DDR3 SDRAM 的 burst size 為 64 bytes，因此處理器通常也會將 cache line size 設為 64 bytes
    • Issued：
      • 表示發生 primary miss 的 load 指令或是 store 指令是否已經開始處理，i.e. 是否已經開始從下一級的記憶體讀取 data block
        • 由於 bus 寬度有限，每個 MSHR entry 並不一定會馬上被處理，因此需要透過 Issued bit 來表示此 primary miss 是否已經在處理的過程中
  • Load/store Table：
    • 發生 primary miss 或是 secondary miss 的 load 指令或是 store 指令都會被記錄到 Load/store Table 中
    • V：
      • Valid bit，用來表示此 Load/store Table entry 是否被佔用
    • MSHR entry：
      • 發生 miss 的 load 指令或 store 指令所對應的 MSHR entry
        • 不同的 load 指令或 store 指令有可能會存取到同一條 cache line，此時 MSHR entry 只會有一個，但 Load/store Table 會記錄所有發生 miss 的指令，以確保在 data block 讀回來後，可以在 Load/store Table 中找到哪些 load 指令和 store 指令屬於這條 cache line
    • Dest. register：
      • 對於 load 指令，Dest. register 欄位記錄 load 指令的 destination register 編號 (physical register)
      • 對於 store 指令，Dest. register 欄位記錄 store 指令在 store buffer 中的編號
        • Store 指令在 retire 前會將其資訊記錄在 store buffer 中，當 store 指令變成 pipeline 中最老的指令時，需要將其資料寫進 D-Cache 中，如果此時發生了 D-cache miss，store buffer 中對應的 entry 就不會馬上被釋放，需要等到 D-Cache miss 解決並將合併後的資料寫進 D-Cache 後，才可以釋放 store buffer 中的 entry
    • Type：
      • 記錄指令的類型，如：Load word、Load half word、Load byte、Store word、Store half word、Store byte
    • Offset：
      • Load 指令或 store 指令所存取的位址在 data block 中的 offset
        • 例如：64 bytes 共需要 6 bits 來找出 data block 中所對應的 byte(s)

• 當 load 指令或 store 指令發生 D-Cache miss 時，會先搜尋 MSHR 中是否有對應的 entry

  • 如果沒有的話，代表是 primary miss，需將該指令寫入 MSHR 及 Load/store Table 中，並開始處理 D-Cache miss
  • 如果有的話，代表同樣的 D-Cache miss 已經在被處理了 (Issued = 1)，或是即將要被處理了 (Issued = 0)，此時只需將指令寫入 Load/store Table 中即可

• 如果 MSHR 或 Load/store Table 滿了，那就無法再處理任何的 load 指令或 store 指令，此時得暫停 pipeline 繼續處理 load 指令或 store 指令，直到有 D-Cache miss 被處理完畢，並釋放 MSHR 和 Load/store Table entries

• 當一個 D-Cache miss 被解決後，會釋放一個 MSHR entry，以及一或多個 Load/store Table entries

  • 對於 load 指令，在 refill 完 cache line 後，load 指令所需的資料會被送到對應的 destination register
  • 對於 store 指令，store buffer 中的資料會與讀回來的 data block 合併，並寫回 D-Cache 中；Store buffer 中對應的 entry 也會被釋放

• 在現實處理器中，基於硬體面積和功耗的考量，MSHR 和 Load/store Table 容量通常不會很大，一般多為 4 ~ 8 個 entries，也就是同時可以處理 4 ~ 8 個 D-Cache misses

• 對於 out-of-order CPU，由於採用了 branch prediction 及 out-of-order execution，發生 D-Cache miss 的指令有可能是處在 mis-prediction 路徑上的，除了需要 flush 這些指令外，也需要一種機制能夠選擇性的放棄正在被處理的 D-Cache miss，以及將 mis-prediction 指令所對應的 MSHR 和 Load/store Table entries 給釋放，此外，如果已經從下一級記憶體讀取出 data block，該 data block 也不能寫回 D-Cache

9.6.3 - 關鍵字優先

• 當執行一條 load 指令或 store 指令而發生 D-Cache miss 時，會將這條指令所需的整條 data block (e.g .64 bytes) 都從下一級的記憶體讀出來並寫進 D-Cache 中，如果考慮到 prefetching，還需要將相鄰的下一個 data block 也一起讀出來，而且這些 data blocks 的讀取過程是照順序的

  

• 如果等到所有的數據都寫進 D-Cache 後才將所需的資料送給 CPU，可能就會讓 CPU 等待一段時間；為了加快執行速度，可以對 D-Cache 下一級的記憶體進行”改造”，使資料的讀取順序發生改變：

  

  • 如果 load 指令或 store 指令所需的資料在 data block 中的第 6 個 word，那麼可以從第 6 個 word 開始讀取記憶體，當讀到 data block 的尾端時，再從頭開始將第 0 ~ 第 5 個 words 給讀出來
  • 當記憶體第一個讀取的 word (i.e. 第 6 個 word) 返回時，CPU 就可以得到所需的資料並繼續執行，D-Cache 會繼續完成剩餘資料的 refill
  • 下一級的記憶體需要額外增加硬體才能支援這種特性，會一定程度上增加硬體的面積及功耗

• 這種方式稱為：關鍵字優先 (Critical Word First)

9.6.4 - 提前開始

• Critical Word First 由於需要改變資料讀取的順序，因此需要額外增加硬體才能支援此特性；如果不想增加硬體成本，可以改採用提前開始 (Early Restart) 的方法

  • 這種方法不會改變硬體讀取資料的順序，因此不需要增加額外的硬體，當發生 D-Cache miss 的指令所需要的資料被讀出來後，CPU 就可以馬上繼續執行

    

    • 當指令所需的第 6 個 word 被讀取出來後，就可以讓 CPU 繼續執行了，D-cache 會繼續完成剩餘資料的讀取
    • 由於沒有改變資料讀取的順序，因此若是所需的資料位於 data block 比較後面的位置時，這種方法就沒有比較明顯的優勢

8.5.1 - 單週期指令的喚醒

• Wake up 是指被 select 電路選中的指令將其執行完後，將其 destination register 和 Issue Queue 中所有的 source registers 編號做比較，並將相同編號的 source registers 標記為 ready 的過程

  • 因為需要將被選中指令的 destination register 編號需要傳遞到 Issue Queue 中的所有 entries，當 Issue Queue 容量比較大，或是 Issue Queue 的個數比較多時，這個編號就需要走很長的路徑

• 一般情況下，select 電路的個數等同於 issue width

• 以下是 Issue width = 4 的 wake-up 電路 (只包含一個 Issue Queue 的 entry，且所有 select 電路共用同一個 Issue Queue)：

  

  • SrcL /SrcR：第一、第二個 source register 的編號
  • ValL / ValR：指令是否存在第一、第二個 source register
  • RdyL / RdyR：第一、第二個 source register 是否準備好
  • Dest：Destination register 的編號
  • Issued：指令是否已經被 issued 出去
    • 當指令準備好，並被 select 電路選中時，此時該指令不一定會馬上被 issued 出去 (e.g. 一條指令使用了 load 指令的結果，即使其被 select 電路選中，也不可以馬上離開 Issue Queue)，因此需要透過 Issued 記錄該指令是否已經被 issued 了
      • 如果已經被 issued，select 電路就不會重複選到該指令
  • 當指令準備好時，就會向 select 電路送 request 訊號，請求被仲裁
  • Select 電路會選擇根據是否選擇了該指令，送出 grant 訊號
    • 四個 select 電路同時間只會有一個 grant 訊號是 valid 的
  • 如果一條指令被 granted，那麼就會將其 Dest 送到 tag bus 上，以便 broadcast 給所有的 Issue Queue entries

• 實務上，為了提供速度，需要減少 Issue Queue 的容量，因此可以使用多個容量較小的 Issue Queue

  • 例如 FU 可以拆分成：
    • 兩個 ALU、一個 Mul/Div、一個 Load/Store ⇒ 共四個 ALU
    • 可以使兩個 ALU 共用同一個 Issue Queue，其他 FU 各自有其獨立的 Issue Queue
  • 雖然每個 FU 仍然需要使用一個 select 電路，且沒辦法減少 wake-up 電路的複雜度，但由於 Issue Queue 的容量變小了，select 電路的 latency 也會因此減少，加快 select 電路的速度，進而減少 select 和 wake-up 兩個 stages 對 CPU cycle time 的影響

• 大部分的 RISC ALU 指令都是 single-cycle 完成的，這種指令可以在 select 電路選中指令時，同個 cycle wake up 其他 Issue Queue 中的指令，被 wake up 的指令在 execute stage 可以透過 bypassing network 獲得被選中指令的執行結果，進而實現 back-to-back 的執行

• Single-cycle 指令的 wake-up 流程：

  1. 被 select 電路選中的指令，其 destination register 會被送到 tag bus 上
  2. 每一條 tag bus 上的值會跟所有 Issue Queue 中所有指令的 source registers 編號做比較，如果相等，則將該 source registers 標記為 ready
  3. 當 Issue Queue 中的指令所有的 registers 都準備好了，並且還沒有被 select 電路選中過，其就可以向對應的 select 電路發出 request 訊號，要求被仲裁
  4. 如果 select 電路選擇了其他優先度更高的指令 (如年齡更老的指令)，則這條指令可以在下一個 cycle 持續向 select 電路發出 request 訊號，要求被仲裁
  5. Issue Queue 中這條指令根據 grant 訊號，當 grant 訊號為 valid 時，將其 destination register 的編號送到對應的 tag bus 上，用來 wake up Issue Queue 中所有相關的 source register；同時這條指令就可以被 issued 至 FU 中執行了

8.5.2 - 多週期指令的喚醒

• 當一條指令無法在 1 個 cycle 內執行完成時，就不能在被 select 電路選中的那個 cycle，wake up Issue Queue 中的其他指令，而需要根據它在 FU 執行的 cycles 數，delay 這個 wake-up
• Wake-up 過程主要分為兩個階段：
  1. 將被選中的指令的 destination register 送到 tag bus 上 broadcast
  2. 將 tag bus 上的值與所有 Issue Queue 中的 source registers 編號做比較
  • 因此如果要 delay wake-up，就是需要 delay 這兩個階段
• 總共有兩種 delay 方法：
  • Delay tag broadcast
  • Delay wake-up
• Delay tag broadcast：

  • 當發現被 select 電路選中的指令執行 cycles 數 > 1，則在被選中的那個 cycle，並不將這條指令的 destination register 編號送到 tag bus 上，而是根據這條指令所需執行的 cycles 數：N，延遲 N - 1 個 cycles 後，才將 destination register 編號送到 tag bus 上

    

    • 乘法指令的執行 cycles 數為 3，因此 delay：3 - 1 = 2 個 cycles 才將其 destination register 編號送到 tag bug 上
    • 但當乘法和其他操作共用一條 tag bus 時，如：Mul/Div FU，乘法和除法會共用同一個 FU 以及同一條 tag bus，則有可能會出現：

      • 當乘法指令的 destination register 編號 delay 了幾個 cycles 後送到 tag bus 上，其他的指令 (e.g. 除法指令)，同時間也要使用這條 tag bus，產生了衝突

        

        • MUL 和 ADD 共用同一個 FU 以及同一條 tag bus，當 MUL 要將其 destination register 編號送到 tag bus 上時，ADD 指令也同時要將其 destination register 編號送到同一條 tag bus 上，產生了衝突
        • 解決方法：

          • 增加這個 FU 所對應的 tag bus 的數量

            • 缺點：
              • 當處理器中有很多這種情況時，會導致需要大量的 bus，增加 wake-up 電路的複雜度，因此在實際設計中是無法使用的

          • 使用一個表格記錄當前 FU 中執行的指令所需的 cycles 數，後續被 select 電路選中的指令，如果從這個表格中發現了衝突，那麼這條被選中的指令就不會馬上被送到 FU 中執行，而是在下個 cycle 繼續參與仲裁

            

            • 指令 A 需要 3 個 cycles 來執行，因此指令 A 在被 select 電路選中後，需要 delay 2 個 cycles 才 wake up 其他的指令
            • 指令 B 需要 2 個 cycles 來執行，因此指令 B 在被 select 電路選中後，需要 delay 1 個 cycle 才 wake up 其他的指令
            • 透過表格可以知道，指令 B 和指令 A 在 cycle 2 會同時使用 tag bus，也就是存在衝突，因此指令 B 是不會被允許在 cycle 2 被選中的，會在下個 cycle 繼續參與仲裁
            • 表格的查詢和 select 電路是同步運行的，因此指令 B 即使被 select 電路選中，也有可能被表格否決掉
              • 優點：
                • 沒有增加電路的延遲
              • 缺點：
                • 指令 B 被否決的那個 cycle，指令 C 因為不會產生 tag bus 衝突，因此原本也是可以被 select 電路選中的，但因為指令 C 比指令 B 來得新，因此 select 電路選擇了指令 B，結果指令 B 被表格給否決，浪費了一個 cycle，造成性能的下降
            • 因此，也可以採用先查詢表格，如果表格否決了該指令，則該指令就不會對 select 電路發出 request 訊號，把機會讓給其他的指令
              • 缺點：
                • 需要先查詢表格，再讓 select 電路仲裁指令，因此 cycle time 會增加
            • 具體要選擇哪種設計，取決於實際設計中的折衷和權衡
• Delay wake-up：

  • 被 select 電路選中的指令同樣會在當個 cycle 就將其 destination register 的編號 broadcast 到 tag bug 上，並和 Issue Queue 中所有的指令的 source registers 做比較；但此時比較結果相同的 source registers 的 ready bit 並不會馬上被設為 valid，而是會依據被 select 電路所選中的指令執行所需的 cycles 數，delay 相對應的 cycles 後，才將 ready bit 設為 valid

  • 優點：

    • 這種方法不需要增加這個 FU 所對應的 tag bus 的數量

    

    • 指令 A 需要 4 個 cycles 來執行，因此指令 A 在被 select 電路選中後，在 Issue Queue 中所有的 R3 source registers (e.g. 指令 B 的 R3) 都需要 delay 3 個 cycles 後，ready bit 才會被設為 valid

  • 其中一種實做 delay wake-up 控制電路的方法：

    

    • 採用 shift register 來實現 delay wake-up
    • 每個指令執行所需的 cycles 數在 decode stage 就可以得知了，可以在指令進入到 Issue Queue 時，將該指令的 DELAY 值一併寫入 Issue Queue 中
    • 當一條指令被 select 電路選中時，除了將其 destination register 的編號 broadcast 到 tag bus 上，同時也會將其 DELAY 值一起 broadcast 到 delay bus 上
      • 一般來說，每個 FU 都會對應一個 delay bus
    • Issue Queue entry 中每個欄位的內容：
      • Freed：
        • 這個 Issue Queue entry 是否為空閒的
        • 當一條指令被寫入此 Issue Queue entry 時，該 Issue Queue entry 就不是空閒的 (Freed = 0)
        • 當該指令被 select 電路選中，且確定沒有問題，可以離開 Issue Queue 時，這個 Issue Queue entry 就會變為空閒的狀態 (Freed = 1)
          • 一條指令被 select 電路選中時，並不一定馬上就會離開 Issue Queue
            • 因為有可能此時 source registers 都還沒準備好 (e.g. 如果等待 load 指令的結果)，但處理器為了加速執行效率，採用了 speculative wake-up 的方式，此時就算該指令被 select 電路選中，也有可能會在之後的時間重新再次參與仲裁
        • 最簡單管理 Issue Queue entry 的方式，就是等一條指令 retire 時，才將該 Issue Queue entry 變為空閒的狀態
          • 缺點：
            • 會導致許多無效的指令佔著 Issue Queue entries，使 Issue Queue 中可用的 entries 數變少，降低了處理器的執行效率
          • 因此現實中的處理器都會採用更高級的方法
      • Issued：
        • 是否被 select 電路選中
          • 0：沒被 select 電路選中，當 source registers 皆 ready 時，向 select 電路發出 request 訊號
          • 1：被 select 電路選中，不再向 select 電路發出 request 訊號
        • 被 select 電路選中的指令，並不一定馬上就會離開 Issue Queue，因此需要將該指令進行標記，使其不再繼續向 select 電路發出 request 訊號
      • SrcL：
        • 指令的第一個 source register 的編號，會與 tag bus 上所有的 destination registers 編號值做比較
      • SrcL_M：
        • 當 tag bus 上的 destination registers 與 SrcL 比較結果相同時，SrcL_M 就會被設為 1 (i.e. match)
        • 當指令收到 select 電路的 grant 訊號時，SrcL_M 會被設為 0
          • 被 select 電路選中的指令，就會將其 destination register 的編號 broadcast 到 tag bus 上，同時也會將其 DELAY 值一起 broadcast 到 delay bus 上
        • SrcL_M 為 SrcL_SHIFT 的 enable 訊號，當 SrcL_M 為 1 時，SrcL_SHIFT 每個 cycle 都會 arithmetic right shift 一位 (i.e. MSB 為 1 時，right shift 也會補 1)
      • SrcL_SHIFT：

        • 當 tag bus 上的 destination registers 與 SrcL 比較結果相同時，被 select 電路選中的指令的 DELAY 值就會被寫入 SrcL_SHIFT 中

          • DELAY 值會被 encoded，如被 select 電路選中的指令執行需要 3 個 cycles，且 DEALY bit width 為 8 bits，那麼 DELAY 值就會被 encoded 為 2’b11111100 (i.e. bit[7:2] 皆被設成 1)

        • 當 SrcL_M 為 1 時，SrcL_SHIFT 每個 cycle 都會 arithmetic right shift 一位

        • 當 SrcL_SHIFT 的 LSB 為 1 時 (i.e. Rdy = 1)，就代表該指令可以被 wake up 了

          • 透過這樣的方式，就可以實現 delay wake-up

        • 當指令收到 select 電路的 grant 訊號時，SrcL_SHIFT 會被清為 0

      • Rdy(_R)：
        • 指令的第一個 source register 是否已經準備完成，其值為 SrcL_SHIFT 的 LSB
      • SrcR、SrcR_M、SrcR_SHIFT、Rdy(_L) 代表指令的第二個 source register，其定義皆與第一個 source register 相同
      • SrcR_imm_valid：
        • 指令的第二個 source register 是否為 immediate value
      • DELAY：
        • 記錄該指令執行時所需的 cycles 數，在 decode stage 就可以得知
        • 當該指令被 select 電路選中時，除了將其 destination register 的編號 broadcast 到 tag bus 上，同時也會將此 DELAY 值一起 broadcast 到 delay bus 上
        • DELAY 值會被 encoded，如該指令執行需要 3 個 cycles，且 DEALY bit width 為 8 bits，那麼 DELAY 值就會被 encoded 為 2’b11111100 (i.e. bit[7:2] 皆被設成 1)
        • DELAY 的 bit width 由 FU 所有支援的指令中，執行所需 cycles 數最長的那個指令來決定
      • ROB_ID：
        • 這條指令在 ROB 中的 index，用來表示該指令的年齡，使 select 電路可以實現 oldest-first 仲裁

8.5.3 - 推測喚醒

• 先前的 wake-up 機制都是建立在指令的執行 cycles 數都是可以預知的前提，才可以替每個指令指定 DELAY 值，但實際上，還有很多指令的執行 cycles 數是沒辦法提前預知的：

  • Load 指令：
    • Load 指令的執行 cycles 數取決於 D-Cache 是否 hit，甚至是 L2 Cache、L3 Cache 和 DRAM 的時間
      • DRAM 由於自身的結構 (e.g. queuing delay)，從其讀取資料所需的時間並不是一個固定的值
  • 在某些處理器中，定義了一些特殊的情況，如：
    • PowerPC 603 CPU，當被乘數的值比較小時，乘法的結果可以提前被計算出來，稱為 early out
    • Intel Core2 CPU 對於除法操作也存在 early out
    • 因此這些指令的執行 cycles 數並不是一個固定的值

• 對於這些執行 cycles 數不固定的指令，一個最簡單的處理方式，就是等這些指令執行完時，才 wake up 其他相關的指令

• 例如，針對 load 指令：

  • 當 load 指令 A 執行完畢後，才 wake up 指令 B，假設 D-Cache hit，那麼指令 B 就需要 delay 5 個 cycles

    • 如果在這之間找不到足夠的指令來執行，就會導致處理器執行效率的下降

    

  • 由於 D-Cache 是否 hit 可以在資料被讀出前得知，因此可以將 pipeline 改為：

    

    • Cal Addr：計算並得到 load address
    • TLB/Tag：得知 D-Cache 是否 hit/miss
      • 在此 cycle 就提前 wake up 相關的指令，減少所需的 delay cycles 數，指令 B 只需 delay 3 個 cycles
    • Data：讀出資料

  • D-Cache hit 的機率應該是很高的，那麼可以進一步的假設 D-Cache 總是 hit，將 pipeline 改為：

    

    • 在 Cal Addr 就 wake up 相關的指令，並在 Bypass stage 就可以夠過 bypassing network 得到 load 指令的結果，指令 B 只需 delay 2 個 cycles

    • 然而，如果 D-Cache miss 了，那麼就沒辦法透過 bypassing network 得到 load 指令的結果，指令 B 也就無法被執行

      • 此外，指令 B 也無法就此停住等待結果，因為指令 B 已經佔用了 FU 了，會導致其他的指令無法被執行

    • 因此，最好的方法就是直接將指令 B 重新放回 Issue Queue 中，並重新參與仲裁，讓 FU 繼續執行其他的指令

      

• 讀取 L1 Cache、L2 Cache、甚至是 L3 Cache 所需要的 cycles 數是固定的 (假設皆為 hit 的情況)，所以可以使用上述 delay wake-up 的方法

• 然而，對於讀取時間不固定的情況，如讀取 DRAM，就只能等到從 DRAM 中讀回資料後，才能 wake up 相關的指令

  • 這種方式會需要比較多的 delay cycles，性能較差
  • 但如果在這之間可以找到足夠的指令來執行，就可以降低性能上的損失

• 針對像 load 指令這種執行所需 cycles 數不確定的指令，如果等到指令的結果被計算出來後，才 wake up 與其相關的指令，會降低處理器的性能，因此需要使用預測的方法來預測指令執行所需的 cycles 數，在指令得到結果之前，就 wake up 相關的指令，這種方法就稱為 speculative wake-up：

  

• 既然是預測，就有可能會預測錯誤，因此就需要恢復預測錯誤前的狀態

  • 對於 load 指令，由於 D-Cache 的 hit rate 是很高的，因此可以假設所有的 load 指令的 D-Cache 都是 hit 的；當 load 指令被 select 指令選中後，就可以依照其最短的執行 cycles 數，wake up 與其相關的指令
  • 當 load 指令真的存取 D-Cache 時，如果此時發現了 D-Cache miss，就代表預測錯誤，需要恢復預測錯誤前的狀態：
    • 被 load 指令 wake up 的 source registers 都必須重新被設為 not ready
    • 對於已經離開 Issue Queue 的指令，還需要將其從 pipeline stage 中給 flush 掉，並重新放回 Issue Queue 中，並等待 load 指令重新 wake up 它們
      • 此時 load 指令可以繼續預測 L2 Cache 是 hit 的，依照 L2 Cache hit 時所需的執行 cycle 數，依照該 cycles 數 wake up 其相關的指令
      • 如果此時預測也失敗，那麼就需要依照同樣的方式，恢復預測錯誤前的狀態

• Load 指令被 select 電路選中後，需要等待 2 個 cycles 才可以 wake up 相關的指令，在這 2 個 cycles，select 電路可以選擇和 load 指令不相關的指令，這 2 個 cycles 稱為 Independent Window (IW)；此外，從 load 指令等待 2 個 cycles 後開始將相關的指令 wake up，直到執行時發現是否為 D-Cache hit/miss，中間共間隔了 2 個 cycles，這 2 個 cycles 稱為 Speculative Window (SW)：

  

  • SW 中的指令不一定和 load 指令存在相關性
    • 如果被 load 指令 wake up 的指令並沒有被 select 電路選中，SW 中的指令就不會使用 load 指令的結果
  • IW 中的指令一定和對應的 load 指令不存在相關性，但仍有可能與其他的 load 指令存在相關性

    • 因為兩道 load 指令，其 IW 和 SW 有可能是重疊的：

      

      • Load 3 指令的 IW 和 Load 1 指令的 SW 重疊
      • 假設在 TLB/Tag stage 就可以得知 D-Cache 是 hit 或 miss，那麼在 cycle 5 的時候，如果 Load 1 指令發生了 D-Cache miss，那麼就需要將與其相關的指令 (i.e. 第四和第五條指令) 從 pipeline 中給 flush 掉，並重新放回 Issue Queue 中，等待重新被 wake up ⇒ 這個過程稱為 replay
        • 因為採用 speculative wake-up，預測失敗時，與其相關的指令是沒辦法獲得該指令的執行結果的，因此需要將與其相關的指令 replay
  • 一條指令被 select 電路選中後，可以選擇：
    1. 直接從 Issue Queue 離開
    2. 繼續停留在 Issue Queue 中，直到被允許時才離開
    • 這兩種設計方式會需要使用不同狀態的恢復方法，產生不同的執行效率和硬體消耗
    • 常用的兩種方法：
      • Issue Queue Based Replay
      • Replay Queue Based Replay

• Issue Queue Based Replay：

  • 採用這種設計，指令被 select 電路選中後，並不會馬上離開 Issue Queue，只有在該條指令確認可以被正確執行後 (i.e. 不需要 replay)，才會允許該條指令離開 Issue Queue

    • 需要在 Issue Queue 中新增一個 issued flag，標記該指令已經被 select 電路選中，但還沒離開 Issue Queue
      • 當 issued flag 為 1 時，就不會繼續向 select 電路發出 request 訊號請求仲裁
    • 當這條指令需要 replay 時，會將 issued flag 清為 0，這樣它就可以繼續向 select 電路發出 request 訊號請求仲裁了

  • 實際上，有很多情況都會需要 replay 指令：

    • Load 指令發生 D-Cache miss

    • 採用 interleaving 架構的 D-Cache 發生了 bank 衝突

    • Store/load 指令的違例

      • 存取相同位址的 store、load 指令，結果 load 指令在 store 指令之前先被執行了
        • i.e. load 指令讀到了 store 指令前的結果

    • Load/load 指令的違例：

      • 存取相同位址的兩條 load 指令，結果後面的 load 指令比前面的 load 指令先被執行了
        • 在某些 multi-core 的處理器中，需要保持原始的程式執行順序

  • 上述的情況都必須將與其相關的指令 replay，此時最簡單的方法就是讓所有的指令被 select 電路選中時，都不要馬上離開 Issue Queue，只有在確定指令可以被正確執行時，才將該指令從 Issue Queue 中移除

  • 什麼時候才能確定指令可以被正確執行呢?

    • 如果是完全 out-of-order 來執行 load 和 store 指令：
      • 即使 load 指令是 D-Cache hit，甚至 load 指令已經執行完畢，但只要 load 指令還沒有 retire，都有可能會發生：
        • store/load 指令違例：
          • load → store 同一個位址，結果 store 指令比 load 指令先被執行了，而導致 load 指令的結果是錯誤的
        • load/load 指令違例：
          • load → load 同一個位址，結果比較年輕的 load 指令比比較老的 load 指令先被執行了
            • 在 multi-core 的環境下，有可能兩條 load 指令之間會有另一個 CPU 的 store 指令寫入了同一個位址，因此兩條 load 指令的執行順序應該要保持 in-order
      • 此時需要將 load 指令和與其相關的指令都 replay (同時把 issued flags 重新設回 0)
        • P.S. store → load 同一個位址，結果 load 指令比 store 指令先被執行了，這種情況並不算是指令違例，因此不需要 replay，因為這只代表 load 指令可以直接從 store buffer 中讀取 store 指令的資料 (需等待 store 指令執行完畢)，不需存取 D-Cache，但是 store 指令和 load 指令之間的執行仍然要保持 in-order
          • 但如果 load 指令需要的資料寬度大於 store 指令的資料寬度 (e.g. 32-bit load vs. 8-bit store) 時，代表 load 指令所需要的資料有一部分存在 store buffer 中，另外一部份存在 D-Cache 中，load 指令就沒辦法在同一個 cycle 內得到其所需的資料了
            • 此時，仍需將 load 指令和與其相關的指令都 replay (同時把 issued flags 重新設回 0)
      • 因此，只有在一條指令 retire 後，才能保證其是正確執行的，此時該指令才可以離開 Issue Queue
    • 如果是完全 in-order 或是 partially out-of-order 來執行 load 和 store 指令，則不會出現上述的違例情況
      • 此時只有 load 指令的 SW 中的指令才有可能需要 replay (load 指令本身不需要 replay)
      • 因此，只需等到 load 指令確定是 D-Cache hit/miss 的結果後，就可以決定 SW 中的指令是否可以離開 Issue Queue 了
        • D-Cache hit ⇒ SW 中的指令不需要 replay ⇒ load 指令和其 SW 中的指令可以離開 Issue Queue
        • D-Cache miss ⇒ SW 中的指令需要 replay ⇒ SW 中的指令無法離開 Issue Queue

  • 優點：

    • 設計複雜度比較低

  • 缺點：

    • 由於指令被 select 電路選中後，並不會馬上離開 Issue Queue，只有在該條指令確認可以被正確執行後 (i.e. 不需要 replay)，才會允許該條指令離開 Issue Queue；然而實際上由於 D-Cache hit rate 是很高的，且發生 store/load 指令等違例的機率並不高，所以大部分指令被 select 電路選中後，其實並不需要 replay，但這些指令仍佔據著 Issue Queue 的空間，直到確認其不需要 replay 為止，導致 Issue Queue 中實際可用的 entries 數減少
      • 增加 Issue Queue 的空間則會增加 select 和 wake-up 電路的 latency，因此無法無上限地增加

  • 由於上述的缺點，針對與 load 指令相關的指令，可以採取適當的折衷：

    • 一旦 load 指令在執行階段得到 D-Cache hit 的結果，就直接釋放與其相關指令 (有被 select 電路選中的指令) 的 Issue Queue entries
      • 優點：
        • 這樣可以最大限度的減少指令對 Issue Queue 的佔用
      • 然而，這樣的折衷方式會導致當發生 store/load 指令違例，或是 load/load 指令違例時，其 replay 的方式會有所不同 (P.S. 只有採用完全 out-of-order 來執行 load 和 store 指令在 D-Cache hit 後還有可能會發生違例)：
        • 由於很多需要 replay 的指令已經離開 Issue Queue 了，此時由於 Issue Queue 中有可能已經沒有多餘的空間了，因此就沒辦法將這些指令重新加回 Issue Queue 中，且有可能會發生 deadlock 的情況
          • 需要被 replay 的指令因為 Issue Queue 中沒有空間，因此無法被 replay，導致那些依賴這些 replay 指令的指令，也無法被 wake up 來釋放 Issue Queue 的空間
        • 因此一旦需要 replay，就必須 flush 掉這些需要被 replay 的指令，並從 I-Cache 中重新讀取這些指令進 pipeline；這樣會損失一些性能，但這就是折衷的方法
    • 但當 load 指令在執行階段得到 D-Cache miss 的結果時，一個比較簡單的方法就是將所有在 load 指令之後被 select 電路選到的指令都重新”放回” Issue Queue 中 (P.S. 只是將 issued flag 重新設回 0，因為這些指令還沒真的離開 Issue Queue)

      • 然而，考量到 IW 的存在，甚至是 SW 中的指令，並不一定都與 load 指令存在相關性，這些原本並不需要 replay 的指令也會一併被 replay

      • 這種方法稱為：Non-Selective Replay

      • 優點：

        • 實做比較簡單

      • 缺點：

        • 由於不用 replay 的指令也 replay 了，因此在一定程度上損失了一些性能

        

        • 假設 LD 指令在 Data stage 得知 D-Cache miss，則需將 LD 指令之後被 select 電路選中的指令，全部從 pipeline 中 flush 掉，並重新”加回” Issue Queue 中等待重新被 wake up
        • 但其實只有 OR 和 SUB 指令跟 LD 是有相關的，其他的指令其實沒有必要一起 replay
    • 改進方法：
      • 由於 IW 中的指令一定是與 load 指令無關的，因此處於 Cal Addr 和 TLB/Tag 這兩個 stages 的指令其實是可以不用 replay 的，只需將 Select 和 RF 這兩個 stages 的指令 replay 即可

  • 如何判斷指令所操作的暫存器是否與 load 指令存在相關性?

    • 相關性分為兩種：
      • 直接相關性
        • 如上例的 OR 指令
      • 間接相關性
        • 如上例的 SUB 指令
          • SUB 指令與 OR 指令相關，OR 指令又與 LD 指令相關
    • 可以使用一個 load-vector 來記錄 pipeline 中所有的 load 指令，每一個 bit 表示一條 load 指令，這個值的寬度等於 pipeline 中最多可以容納的 load 指令個數

      • 每個 architecture register (或是經過 register renaming 後，physical register)，都會分配一個 load-vector

        

        • 假設由左至右：bits[0] → bits[4]
        • 第一條 load 指令佔據 load-vector 一個 bit：R1 ⇒ 2’b10000
        • 第二條 ADD 指令，因為依賴 load 指令的 R1，因此其 load-vector = 第一條 load 指令的 load vector：R1 ⇒ 2’b10000
        • 第三條 load 指令佔據 load-vector 額外一個 bit：bits[1]，且因其也依賴第一條 load 指令的 R1，因此其 load vector 的值等於兩者 OR 後的結果：R3 ⇒ 2’b01000 | 2’b10000 = 2’b11000
        • 第四條 SUB 指令依賴第三條 load 指令的 R3，因此其 load-vector = 第三條 load 指令的 load-vector：R4 ⇒ 2’b11000
        • 第五條 load 指令佔據 load-vector 額外一個 bit：bits[2]：R5 ⇒ 2’b00100
        • 第六條 ADD 指令依賴 SUB 的 R4，以及第五條 load 指令的 R5，因此其 load vector 的值等於兩者 load-vector 值 OR 後的結果：R7 = 2’b11000 | 2’b00100 = 2’b11100

      • 每當 load 指令發生 D-Cache miss 時，就可以透過查詢 Issue Queue 中每個指令的 source registers 的 load-vector，是否有 bit 與 load 指令的 load-vector 重疊，進而得知是否與 load 指令存在相依性

      • 缺點：

        • 如果 pipeline 深度比較深，可以容納的 load 指令數跟著增加，所需的 load-vector 的寬度也會需要跟著增加，增大硬體面積
          • Load-vector 只適合 pipeline 深度不深的 CPU
    • 每條 load 指令可以改用 5 個 bits 的 Load Position Value (LPV) 來記錄 load 指令在 pipeline 中哪個 stage (Select、RF、Cal Addr、TLB/Tag、Data，假設 load 指令在 FU 中執行需要 3 個 cycles)

      • 每當一條 load 被 select 電路選中時，都會將其 LPV 重置為 2’b10000，表示這條 load 指令目前處在 Select stage

        • 在 Select stage，load 指令的 destination register 編號都會與 Issue Queue 中所有指令的 source registers 編號做比較，如果相符，則每個相符的 source register 都會得到該 load 指令的 LPV
        • 每條指令在被 select 電路選中並 wake up 其他指令時，如果被 wake up 的指令的 source registers 與被 select 電路選中指令的 destination register 相同，則被 select 電路選中指令的 destination register 的 LPV 值也會一併被複製給這些被 wake up 的指令的 source registers，以識別哪些指令的 source registers 與 load 指令存在間接相關性
        • 之後的每個 cycle，所有 source registers 的 LPV 都會 right shift 一位，用來追蹤 load 指令在 pipeline 中的 stage
        • 同時，load 指令的 LPV 每個 cycle 也會 right shift 一位，記錄其在 pipeline stage 中哪個 stage

      • 當 load 指令抵達 Data stage，發現 D-Cache miss 時，在 Issue Queue 中那些 LPV 的最低位 (bits[0]) 為 1 的 source registers，都與這條 load 指令存在直接或間接的相關性，需要 replay 並將這些 source registers 在 Issue Queue 中對應的 Rdy bit 設為 0

      • 範例：

        

        • LD 指令被 select，wake up XOR 指令，將 LD 的 LPV：2’b10000 複製給 XOR 指令的 source register：R2

        

        • XOR 指令被 select，wake up ADD 和 SLL 指令，將 XOR 此時的 LPV：2’b00010 複製給 ADD 指令和 SLL 指令的 source register：R3

        

        • ADD 指令和 SLL 指令被 select，ADD 指令 wake up AND 指令，並將其 LPV：2’b00001 複製給 AND 指令的 source register：R4
        • 此外，AND 指令還依賴 LD2 指令，因此也會將 LD2 指令的 LPV：2’b00100 複製給 AND 指令的 source register：R6
        • 此時 LD1 已經進到 Data stage 了 (假設在 Data stage 才可以得知 D-Cache hit 或是 miss 的即果)，所有與 LD1 指令有相關性的 source registers 其 LPV 最低位 (bits[0]) 皆為 1
          • 如果 D-Cache hit，那就繼續執行即可
          • 如果 D-Cache miss，則必須：
            • 將這些相關的 source register 在 Issue Queue entry 中的 Rdy bit 設為 0
            • Replay SW 中與 load 指令相關的指令

      • 優點：

        • LPV 所需的 bits 數不會隨著 pipeline stages 的深度而改變，只會與 load 指令執行所需的 stages 個數有關
        • 相較於 load-vector 的方法，硬體面積比較小，執行速度也比較快

      • 當一個 cycle 可以執行多條的 load 指令時，那麼在 Issue Queue 中每條指令 source register 的 LPV 電路個數就需要做相對應的複製

        • 例如：每個 cycle 可以執行 2 條 load 指令，那麼每個 source register 就需要 2 個 LPV 分別記錄這兩條 load 指令的 LPV
        • 不過由於 D-Cache ports 數的限制，因此每個 cycle 可以執行的 load 指令個數並不會過多，因此此方法並不會對增加太多的硬體面積

      • 此外，LPV 也可以作為 select 電路選擇指令的依據：

        • 如果 LPV 為 0，代表該指令的 source register 沒有與任何 load 指令相關，select 電路可以優先選擇該指令
        • 反之，如果 LPV 不為 0，代表該指令的 source register 與某個 load 指令相關，select 電路可以優先選擇其他沒有相關性的指令

      • 這種只 replay 與 load 指令相關的指令的方法，稱為：Selective Replay

  • Non-Selective Replay 總結：

    • Load 指令在執行階段發現 D-Cache miss 時，就將 SW 中所有指令都 replay，並將 issued flag 清為 0；此外，與 load 指令相關的 source registers 的 Rdy bit 也會被清為 0
      • 由於與 load 指令不相關的指令其 source registers 的 Rdy bit 都仍為 1，因此在下一個 cycle 馬上就可以向 select 電路發出 request 訊號請求仲裁
      • 與 load 指令相關的指令則要等之後再次被 wake up 後才可以重新參加仲裁

  • Selective Replay 總結：

    • 透過 LVM，當 load 指令在執行階段發現 D-Cache miss 時，只將 SW 中與 load 相關的指令 replay

      

      • 只需 replay 與 load 指令相關的 OR 和 SUB 指令

  • 基於 Issue Queue replay 的方法，很多指令在被 select 電路選擇後沒辦法馬上離開 Issue Queue，因此其最大的缺點就是降低了 Issue Queue 中可以使用的空間，降低了處理器的執行效率

• Replay Queue Based Replay：

  • 採用這種設計，指令被 select 電路選中後，會馬上離開 Issue Queue，並存入 Replay Queue 中

    • 當一條指令 retire 時，就可以從 Replay Queue 中移除

    

  • 舉例來說，當 load 指令發生 D-Cache miss 時：

    • 需將與 load 指令相關的指令，從 pipeline 中給 flush 掉
    • 將這些相關的指令從 Replay Queue wake up，且這些指令被 select 電路仲裁的 priority，比其他在 Issue Queue 中的指令來得高，以便這些需要 replay 的指令可以優先重新送入 FU 中執行

  • Replay Queue Based Replay 同樣支援處理：

  • 優點：

    • 提高了 Issue Queue 的使用效率

  • 缺點：

    • Replay Queue 會佔用額外的硬體空間
    • Replay Queue 也需一起參與 select 電路的仲裁和 wake up，因此設計較複雜

• 從 select stage 到 execute stage 所需的 cycles 數越多，需要 replay 的指令也就越多，因此：

  • 對於 data-capture 架構的設計：
    • 由於其 select stage → execute stage 的時間比較短，需要 replay 的指令個數也就比較少
      • 比較適合搭配 Issue Queue Based Replay 的設計
  • 對於 non-data-capture 架構的設計：
    • 由於指令在 issued 後會讀取 physical register file，所以其 select stage → execute stage 的時間比較長，需要 replay 的指令個數也就比較多
      • 採用 Issue Queue Based Replay 的設計會導致 Issue Queue 的可用空間變少
      • 比較適合搭配 Replay Queue Based Replay 的設計

• Issue 就是將符合一定條件的指令從 Issue Queue 中選出來，並送到 FU (Function Unit) 中執行的過程

  • Issue Queue 會依照一定的規則，選擇那些 source registers 都已經準備好的指令，將其送到 FU 中執行，這個過程就稱為：Issue

• Issue Queue 也被稱為 Reservation Station

• 對於 in-order core，指令會按照程式原始順序加進 Issue Queue 中，此時 Issue Queue 就相當於一個 FIFO

• 對於 out-of-order core，只有少數指令，如 store 及分支指令，才會採用 in-order 的方式執行，對其他大部分的指令，都是採用 out-of-order 的方式執行

• 指令到了 Issue Queue 後，只要 Issue Queue 中任一條指令的 operands 都準備好了，且滿足 issue 的條件，就可以將其送到 FU 中執行

• Issue Queue 設計的好壞，會直接影響處理器的 concurrency

• Issue stage 的硬體比較複雜，一般它都在 critical path 上，直接影響 CPU 的 cycle time

  • 因此這個 stage 的設計需要一定的折衷，才能在性能和複雜度之間找到一個可以接受的平衡點

• Issue stage 同時也是 in-order 和 out-of-order 的分界點

  • Issue stage 之前的指令都是 in-order 的
  • Issue stage 之後的指令都是 out-of-order 的，直到到了 commit stage 才會透過 ROB 的資訊來將指令重排回 in-order 的順序

• Issue stage 除了 Issue Queue 外，還有：

  

  • Allocate 電路：用來從 Issue Queue 中找到 free 的 entries，將 register renamed 完的指令加入進 Issue Queue 中
  • Select 電路 (也稱為 Arbiter 電路)：如果在 Issue Queue 中有多條指令已經準備好了，Select 電路會依照一定的規則，選出最適合的指令送到 FU 中去執行
    • Select 電路是 issue stage 中比較關鍵的元件，會直接影響到 CPU 的執行效率
  • Wake-up 電路：當一條指令經過 FU 而得到結果時，會通知給 Issue Queue 中所有等待此結果的指令；這些指令對用的 source operands 會被設為 valid 的狀態，這就稱為 wake-up
    • 如果一條指令所有的 source operands 都已經準備好了，那該指令就處於 ready 狀態，Select 電路就有可能選擇該指令來 issue

8.1.1 - 集中式 (Centralized) vs. 分佈式 (Distributed)

• 在 superscalar CPU 中，為了並行執行指令，一般都會有很多的 FU，如有些 FU 負責 integer 的運算，有些 FU 負責乘法與除法運算，有些 FU 負責 memory access
  • 如果這些 FU 都共用同一個 Issue Queue，那麼這種架構就稱為 Centralized Issue Queue
  • 如果每個 FU 都有一個獨立的 Issue Queue，那麼這種架構就稱為 Distributed Issue Queue
• Centralized Issue Queue 因為要儲存所有 FU 的指令，因此它的容量需要很大
  • 優點：
    • 有最大的利用效率，不會浪費 Issue Queue 中任何的空間
  • 缺點：
    • Select 電路和 Wake-up 電路會比較複雜，因為需要從龐大數量的指令中選擇幾條可以被 issued 的指令；這些被選中的指令執行完後還需要 wake up 所有 Issue Queue 中相關的指令，增加了 Select 電路和 Wake-up 電路的面積和 latency
• Distributed Issue Queue 由於為每個 FU 都配一個 Issue Queue，因此每個 Issue Queue 的空間可以很小
  • 優點：
    • 簡化了 Select 電路的設計 (每個 Issue Queue 都有自己的 Select 電路)
  • 缺點：
    • 但 Issue Queue 使用率較低，當一個 Issue Queue 滿了以後，即使其他 Issue Queue 還有空間，也無法繼續向其寫入新的指令
      • 此時就需要將 pipeline stall，直到這個 Issue Queue 有空出新的空間為止
        • 例如：
          • 一段時間內執行了大量的 add / sub 指令，則可能由於 add / sub 指令 FU 對應的 Issue Queue 已經滿了而無法處理新的 add / sub 指令
            • 這會阻礙新的指令做 register renaming，因為 register renaming stage 仍然是 in-order 的
            • 即使此時別的 FU 的 Issue Queue 仍有空間，也仍需 stall issue stage 之前的 pipeline，降低 Issue Queue 的使用率
    • 由於 Issue Queue 是分散的，因此也會增加 Wake-up 電路的複雜度
• 由於上述兩種設計各有優缺點，因此現代處理器一般都會結合使用上述兩種方法，使某些 FU 共用一個 Issue Queue，某些 FU 有自己獨立的 Issue Queue

8.1.2 - 數據捕捉 (Data-capture) vs. 非數據捕捉 (Non-data-capture)

• 對於 superscalar CPU 而言，還需要考慮在哪個 pipeline stage 讀取 registers 的值

  • 何時讀取 registers 對於整個處理器架構有著直接的影響

• 一般來說，有兩個時間點可以讀取 registers：

  • 在 issue stage 之前讀取 registers：

    • 這種方法也被稱為數據捕捉 (Data-capture) 的架構

    • 被 register renamed 後的指令首先會讀取 physical register file，然後將 source registers 的編號寫進 Issue Queue，讀到的 source registers 的值寫進 payload RAM

      • 如果有 source register 的值在指令寫進 Issue Queue 中時還沒有被計算出來，則該 register 會被標記為 non-available
      • 在之後的 wake-up stage，可以根據 Issue Queue 中所記錄 source registers 編號，透過 bypassing network 取得結果，不需要再讀取 physical register file

    • 在 Issue Queue 中，儲存指令 operands 的元件稱為 payload RAM：

      

      • Payload RAM 儲存了指令 source registers 的值，當指令從 Issue Queue 中被 select 電路選中時，可以直接從 payload RAM 中對應的 entry 將 source registers 的值給讀出來，並送到 FU 中執行
      • 當一條指令從 Issue Queue 中被選中的同時，它會 broadcast 其 destination register 的編號，Issue Queue 中的其他的指令的 source registers 都會被比較，一旦發現相等時，就會在 payload RAM 中進行標記，等到被選中的指令被計算完畢後，就會透過 bypassing network 將其結果寫進 payload RAM 對應的 entries 中
      • Payload RAM 負責”捕捉” FU 計算的結果，因此稱為 data-capture 架構
      • Issue Queue 負責比對 registers 編號是否相等，payload RAM 負責儲存 source registers 的值並捕捉對應 FU 的計算結果

    • 在 superscalar CPU 中，使用 machine width 來表示每個 cycle 實際可以 decode 和 register rename 的指令個數，使用 issue width 來表示每個 cycle 可以被 issued 的指令個數

      • 考慮到由於指令間存在 dependencies，很多時候，沒辦法每個 cycle 都將 machine width 個數的指令 issue 到 FU 中執行，只有使 issue width 大於 machine width，才能最大限度地使用 FU
        • 因此，現代高性能處理器都會採用多個 FU，盡可能增加每個 cycle 可以被 issued 的指令個數

    • Data-capture 架構需要在 issue stage 前讀取 physical register file，因此 physical register file 需要的 read ports 數量 = machine width x 2 (假設每條指令只有兩個 source registers)，是直接與 machine width 相關的：

      

  • 在 issue stage 之後讀取 registers：

    • 這種方法也被稱為非數據捕捉 (Non-data-capture) 的架構

    • 在 non-data-capture 架構中，register renamed 後的指令並不會去讀取 physical register file，而是直接將 source registers 的編號寫進 Issue Queue 中

      • 當指令從 Issue Queue 中被 select 電路選中，會使用 source registers 的編號來讀取 physical register file，將讀到的 source registers 的值一併送到 FU 中執行
      • 由於不需要 payload RAM，因此可以增加執行的速度

    • 由於指令在 issued 後才會讀取 physical register file，因此 physical register file 所需的 read ports 數量 = issue width x 2，是直接與 issue width 相關的，因此所需 physical register file 的 read ports 數量通常比較多

      

• Data-capture 架構：

  • 優點：
    • 需要的 physical register read ports 數量較少
  • 缺點：
    • 需要額外的 payload RAM，硬體面積較大，執行速度較慢
    • source register 需要經過兩次 reads 和一次 write 的過程，功耗較高
      • 如果 source register 的值在指令寫進 Issue Queue 中時已經有被計算出來，那麼就需要將 register 的值從 physical register file 中讀出來，寫進 Issue Queue，然後再從 Issue Queue 中將值讀出來，送到 FU 中

• Non-data-capture 架構：

  • 優點：
    • 在 Issue Queue 中不需要儲存 registers 的值，也不需要使用 payload RAM，硬體面積較小，執行速度較快
    • Source register 只需要經過一次 read 即可，功耗較低
      • 從 physical register file 讀出來送進 FU 中
  • 缺點：
    • Physical register file 需要比較多的 read ports

• 這兩種架構的選擇，決定了 ROB 的實做方式：

  • 當使用 ROB 做 register renaming 時 (i.e. 使用 ROB 當作 PRF)，一般都會配合使用 data-capture 的架構

    • 在一條指令 retire 前，其 architecture register 的計算結果會被存在 ROB 中，register renaming table 的 pointer 會指向 ROB；當這條指令 retire 時，其 architecture register 的計算結果會從 ROB 移到 ARF，RAT 的 pointer 也會一併更新指向 ARF
    • 採用 data-capture 架構在讀取 source register 的值寫進 Issue Queue 時，可以直接透過 RAT 找到對應的 physical register，因此不用考慮位置的變化
    • 反之，採用 non-data-capture 的架構，當指令從 Issue Queue 中被 select 電路選中，要讀取 PRF 來將 source registers 的值送到 FU 中執行時，並沒辦法直接使用 Issue Queue 中記錄的 source register 的編號 (physical register number) 來讀取 ROB 取得 source register 的值 (因為計算結果有可能已經被搬進 ARF 中了），因此需要額外的處理

8.1.3 - 壓縮 vs. 非壓縮

• 根據 Issue Queue 的工作方式，又可將其分為壓縮 (Compressing) 和非壓縮 (Non-compressing) 兩種架構
• Compressing Issue Queue：

  • 每當一條指令被選中並從 Issue Queue 中移除時，會出現一個”空格”，這條指令上面的所有指令都會下移一格，將這條指令的空格給補上：

    

  • 透過這種方式，可以保證 Issue Queue 中的 empty entries 都是在 Issue Queue 中的 tail

    • 當有新的指令寫入時，只需將其寫入 Issue Queue 中的 tail 即可

  • 要實現這樣的架構，需要在每個 Issue Queue 的 entry 前面加上 multiplexer，用來移動一個 entry 的內容

    

  • 優點：

    • Allocation 電路較簡單，Issue Queue 中的 empty entries 都是在 Issue Queue 中的 tail，只需使用 Issue Queue 的 write pointer 即可得知指令寫入 Issue Queue 的位置
    • Select 電路設計比較簡單

      • 通常為了讓處理器可以最大限度的同時執行多條指令，一般都是從所有準備好的指令中，優先選擇最老的指令到 FU 執行，也就是 oldest-first 方法

        • 最老的指令通常會與其他指令之間有更多的 RAW dependencies，因此可以 wake up 更多的指令

        

      • Compressing Issue Queue 中的指令已經是照著 oldest → newest 的順序排好的，因此 select 電路可以很容易依照 oldest-first 的方法選出指令來執行

  • 缺點：

    • Issue Queue 的設計較複雜
      • 需要額外加入 multiplexer 用來移動一個 entry 的內容
    • Select 電路的 latency 與 Issue Queue 的容量成正比， 如果 Issue Queue 容量越大，就會使 select 電路的 latency 越長
      • 雖然可以很容易的找出最老的指令，但因為要跟所有的 Issue Queue entries 比較才能找出要被 issue 的指令，因此 Issue Queue 容量越大，select 電路的 latency 越長
    • 同時間會有多個指令需要被移動，因此功耗也會比較高
• Non-compressing Issue Queue：
  • 每當一條指令被選中並從 Issue Queue 中移除時，Issue Queue 中的其他指令並不會被搬移，而是會停留在原本的位置，i.e. 沒有壓縮的過程
    • 無法根據指令在 Issue Queue 中的位置來決定指令的新舊
  • 實務上沒辦法把所有 Issue Queue 的指令都掃過一遍，找出最老已經準備好的指令；因此可以採用折衷的方式，從 Issue Queue 的 head 開始尋找，直到找到一條已經準備好的指令就直接選擇它
    • 這種 select 電路的實做相對簡單，但由於沒辦法找出 oldest-first 的指令，因此沒辦法獲得最好的效能
  • 優點：
    • 指令不用每個 cycle 都需要移動，功耗較低
    • 少了 multiplexer，硬體面積較小
  • 缺點：
    • 如果真的要實做 oldest-first 的功能，就需要更複雜的 select 電路設計 (參考：8.4 - 仲裁 (Arbitration))，會增加 latency
    • Allocation 電路設計較複雜，需要掃過 Issue Queue 中所有的 entries，才能找到 empty 的 entry 來將指令寫入；尤其 superscalar CPU 每個 cycle 都會寫入多條的指令到 Issue Queue 中，allocation 的電路設計會更為複雜
• Compressing Issue Queue 和 Non-compressing Issue Queue 設計各有優缺點，在現實世界的 superscalar CPU 中都有採用

8.2 - 發射過程的流水線

8.2.1 - 非數據捕捉 (Non-data-capture) 架構的流水線

• 一條在 Issue Queue 中的指令需等到以下條件都成立後，才可以被 issued 到 FU 中執行：

  • 這條指令所有的 source registers 都準備好了
  • 這條指令能從 Issue Queue 中被選中，也就是需要被 select 電路選中才能被 issued
  • 需要能從 registers、payload RAM 或 bypassing network 中獲得 source registers 的值

• 對於一個 source register 來說，如果被寫到 Issue Queue 時，還是 not-ready 的狀態，等到之後的某個時間，它變成 ready 的狀態，這個過程便稱為 Wake-up

  • 需通過 bypassing network 才可以通知到 Issue Queue 中每個 source registers

• Wake-up 的過程：

  • 最簡單的作法：當一條指令在 FU 得到其運算的結果時，將 Issue Queue 中使用到這個計算結果的所有 source registers 都設為 ready 的狀態：

    

    • Issue 被分為了 wake-up 和 select 兩個 stages
      • 在 wake-up stage，Issue Queue 中所有得到計算結果的 source registers 都會被改為 ready 狀態
      • 在 select stage，select 電路會從 Issue Queue 中選擇一條最合適的指令 issue 到 FU 中
    • 然後，這樣 RAW 相關的兩條指令，並沒辦法 back-to-back 的執行，中間間隔了 3 個 cycles，執行效率不佳
    • 這種指令執行完才 wake up 相關的指令的方法便是：Tomasulo

• 為了提高執行效率，可以將 wake-up 的過程提前，以便可以 back-to-back 執行指令：

  

  • 需要透過 bypassing network 才能 back-to-back 執行指令
    • 當指令 B 到 execute stage 時，就可以透過 bypassing network 得到指令 A 的執行結果，便可以被 issued 到 FU 中執行了

• 實際上，指令 A 的 select 和指令 B 的 wake-up 這兩個操作是在同一個 cycle 中接續執行的

  • 只有當 select 電路選出可以 issue 的指令後，才可以對 Issue Queue 中相關的 source registers 進行 wake up，只有兩個操作是在同一個 cycle 內完成，才可以 back-to-back 執行兩條 RAW 的指令：

    

  • 如果 select 和 wake-up 分為 2 個不同的 cycles，那麼就無法 back-to-back 執行兩條 RAW 的指令：

    

    • 指令 A 被選中，但要等到下一個 cycle 才能 wake up 指令B，那麼指令 A 和指令 B 之間的執行就會相差一個 cycle

• Select 電路和 wake-up 電路都是相對比較複雜的，將它們放在同一個 cycle 內執行，肯定會使 cycle time 變長，降低 CPU 的頻率；而將這兩個電路分成兩個不同的 cycles，可以降低 cycle time，提昇 CPU 的頻率，但會降低 CPU 的 IPC

  • 將 select 和 wake-up 分成兩個不同的 cycles，IPC 約會下降 10% ~15%
    • 此外，由於增加了一個 cycle，因此也會帶來其他的負面影響：
      1. Miss-prediction penalty 的增加
      2. Cache 存取 cycles 數的增加
         • Cache 存取的時間是固定的，cycle time 變短，cache 存取需要的 cycles 數就變多了
      3. 增加了一個 cycle，需要更多的硬體資源，功耗變大

• Superscalar CPU 中存在多個 FU，每個 FU 的執行時間都是不同的；即使是同一個 FU，不同指令所需的執行時間也不一定相同

  • 當一條指令的 FU 沒辦法在一個 cycle 內完成，pipeline 的 execute stage 的執行就需要超過一個 cycle，有可能就來不及 bypass 結果給 RAW 的指令

    

    • 指令 A 是乘法指令，在 FU 中需要 2 個 cycles 才能計算出結果，如果仍在指令 A 被 selected 時同時 wake up 指令 B，等到指令 B 進到 execute stage 時，由於指令 A 的結果在那個時候還沒有被計算出來，指令 B 就沒辦法執行

    • 因此，需要將指令 B 的 wake-up delay 一個 cycle，才可以讓指令 B 進到 execute stage 時，透過 bypassing network 得到指令 A 的計算結果

      

• 除此之外，像是 load/store 指令，其 execute 所需要的 cycles 是取決於 D-Cache 或 Store buffer 是否 hit/miss 的，都需要做特別的處理

8.2.2 - 數據捕捉 (Data-capture) 架構的流水線

• Data-capture 跟 non-data-capture 架構最大的差異就是使用了 payload RAM 來儲存所有指令的 source registers 的值，當指令被 issued 時，可以直接得到 source registers 的值，而不須再去讀取 physical register file

  • 相比於 non-data-capture 架構少了 Regfile read 的 stage

• Data-capture 架構同樣需要分為 select 和 wake-up 兩個階段，只不過指令在被 select 電路選中後，不需要再去讀取 physical register，而是可以直接讀取 payload RAM 取得 source registers 的值

  

  • 一條指令被 select 後 (如：指令 A)，同個 cycle 也可以 wake up 其他有 dependency 的指令 (如：指令 B、C)；同時還會去讀取 payload RAM，得到 source registers 的值
    • Payload 和 wake-up 是在同一個 cycle 中發生的
  • 在得到 source registers 的值後，下一個 cycle 就可以進到 execute stage，將指令送到 FU 中執行
  • 被 wake up 的指令 (如：指令 B、C)，可以在其 execute stage 透過 bypassing network 取得其所依賴的指令的計算結果 (如：指令 B)，也可以從 payload RAM 得到計算結果 (如：指令 C)
    • 對於指令 C 來說，在其 execute stage 時，指令 A 已經將其計算結果寫回 payload RAM 了，因此可以直接從 payload RAM 讀取指令 A 的計算結果 (但仍需要將指令 B 的計算結果 bypass 給指令 C)
  • 此設計將 select 和讀取 payload RAM 放到同一個 cycle 內，因此在一個 cycle 內，需要同時讀取 payload RAM，又需要寫入 payload RAM，因此需要使用 multi-port 的設計，讓 cycle time 變得過大
    • 如：*Cycle i+2*，需要將指令 A 的計算結果寫回 payload RAM；指令 C 又需要同時讀取 payload RAM 得到指令 A 的計算結果
  • 同時，當 FU 的個數比較多時，FU 的計算結果也需要透過 bypassing network 來傳遞，因此也會佔用不少的硬體支援和過長的執行時間，因此可以進一步將 pipeline 進行細分

• 以下的設計將 payload RAM 的存取獨立成一個單獨的 pipeline stage，以避免 multi-port payload RAM 影響 CPU 的 cycle time：

  

  • 此外，在 execute stage，FU 得到計算結果後，也不會在同一個 cycle 就 bypass 結果給其他的指令，而是將 bypass 放到下一個 pipeline stage
    • 在 bypass stage 中，會同時將計算結果寫進 payload RAM 以及 bypass 給其他指令
  • 由於指令 C 依賴指令 A 和指令 B 的計算結果，因此需要等到 *Cycle i+1* 才能真的被 wake up

• 有些設計甚至還會將 select 和 wake-up 拆分成兩個不同的 stages，但缺點就是 RAW 相關的指令無法 back-to-back 的被執行

8.3 - 分配 (Allocation)

• Allocation 電路其實是屬於 dispatch stage，而不是 issue stage 的

• 採用 Non-Compressing Issue Queue 設計的 Issue Queue，其 empty entries 的分佈是沒有規律的；對於每個 cycle 可以 decode N 條指令的 superscalar CPU 來說，最理想的狀態就是可以從 Issue Queue 中找到 N 個 empty entries，需要 allocation 電路掃過整個 Issue Queue

  • Allocation 所需要的時間，與 Issue Queue 的容量，以及每個 cycle 要寫入的指令個數成正比

• 可以採用一個 free list 來記錄所有 Issue Queue 中 empty entries 的編號，每個 cycle 都從這個 free list 中讀出 N 個編號，就可以找到對應的 Issue Queue empty entries 了

  • 這個 free list 可以透過 FIFO 來實現
  • 然而，這種方法仍有一定的複雜度，產生的 latency 也不一定會比較小
    • 如果 N 很大，就需要在一個 cycle 內 pop 出 N 個 FIFO entries

• 一種折衷的方法，可以直接將 Issue Queue 分成 N 段，從每段找出一個 empty entry

• 如 N = 4：

  

  • 每段都會有一個獨立的 allocation 電路，這樣一個容量為 12 個 entries 的 Issue Queue，每段只需要從 3 個 entries 中找到 1 個 empty entry 即可
  • 每個獨立的 allocation 電路都可以同時工作，所需查找的 entries 數也很少，因此 latency 很小
  • 缺點：

    • 如果一個段中沒有 empty entry 了，那麼就算其他段有多餘的 empty entry，這個段也沒辦法接收新的指令

    • 更糟糕的是，在 register renaming stage，指令仍然是 in-order 的，因此如果一條指令沒辦法找到 Issue Queue 的 empty entry，其後的指令就算其對應的段仍有 empty entries，也無法被寫入 Issue Queue 中：

      

      • 指令 A 對應的段已經沒有 empty entries 了，無法被寫入 Issue Queue 中；但由於此時仍是 in-order 的，因此會導致縱使指令 B、C、D 的段有 empty entris，一樣無法被寫入 Issue Queue 中

• Allocation、select、wake-up 是 issue stage 中三個主要的步驟，每個步驟都需要做很多的事情，因此 issue stage 是 superscalar CPU 中工作量比較繁忙的 pipeline stage

8.4 - 仲裁 (Arbitration)

8.4.1 - 1-of-M 的仲裁電路

• 前面的章節有提到，Non-compressing Issue Queue 需要特別的處理才能實做 oldest-first 的功能，不能單純的由指令在 Issue Queue 中的位置來判斷
• 越舊的指令，和它存在 dependency 的指令就越多，因此優先 select 最舊的指令，則有機會可以wake up 更多的指令；除此之外，最舊的指令還佔據著處理器的其他資源，如 ROB 和 store buffer… etc，越早執行這些舊的指令，就可以越早釋放這些資源來讓更新的指令使用
• 要識別出 Issue Queue 中哪些指令是最舊的，就需要知道這些指令的年齡，也就是進到 pipeline 的先後順序
  • In-order core 的年齡資訊很容易判斷，在 pipeline 中先執行的指令肯定比後執行的指令來得老
  • Out-of-order core 的年齡資訊必須依靠 ROB 來判斷，可以使用指令在 ROB 中的 index 來判斷指令的年齡先後 (指令是從 ROB index 0 開始寫)

    • ROB 是一個 circular FIFO，因此沒辦法直接拿 ROB 的 index 來判斷，需要做一些處理

      

      • Write pointer 和 read pointer 在同一個 lap 上，可以直接比較 write pointer 和 read pointer 的 index 來識別指令的年齡

      • 但當 write pointer 和 read pointer 不在同一個 lap 上 (i.e. write pointer 比 read pointer 多 wrap 了一次)，那就沒辦法透過直接比較 write pointer 和 read pointer 的 index 來識別指令的年齡

      • 因此需要額外加 1 個 position bit，每次 write 或 read pointer wrap 時，write pointer 或 read pointer 所指到的 position bit 都會被 toggled (0 → 1、1 → 0)

        

        

        • 當 write pointer 指到的 position bit 與 read pointer 所指到的 position bit 相同時 (i.e. write pointer 和 read pointer 在同一個 lap 上)，指令的 ROB index 越小，年齡越老
        • 當 write pointer 指到的 position bit 與 read pointer 所指到的 position bit 不同時 ****(i.e. write pointer 比 read pointer 多 wrap 了一次)，指令的 ROB index 越大，年齡越老

      • 為了記錄年齡資訊，需要將每條指令在 ROB 中的 index (i.e. 年齡) 也一併寫進 Issue Queue 中，這樣在 Issue Queue 中每條指令就有了年齡的資訊，select 電路就可以依據這個資訊，從所有準備好的指令中找到最舊的那個指令

      • 如果 Issue Queue 中有 M 個 entry，這種 select 電路就稱為 1-of-M select 電路

        

        

        • Issue Queue 中每條指令都由 1 個 ready bit 來表示該指令是否已經準備好了：

          • 兩個指令的 ready bits 皆為 1 時：選擇年紀比較大 (i.e. ROB index 比較小) 的指令
          • 只有一個指令的 ready bit 為 1 時：選擇 ready bit 為 1 的那條指令
          • 兩個指令的 ready bits 皆為 0 時：選擇哪條指令都無所謂，因為下一級也不會被選中

        • 實際上，可以將每條指令在 Issue Queue 中的 index 一起加入上述的比較電路，這樣就可以在取得年齡值時，同時取得該指令在 Issue Queue 中的 index，進而找到 Issue Queue 中這個年齡值所對應的指令

          

          • 新增的 multiplexer 是跟原有的同步執行的，因此不會影響到 CPU 的 latency

8.4.2 - N-of-M 的仲裁電路

• 多個 FU 有可能會共用同一個 Issue Queue，因此需要在 1 個 cycle 內為每個 FU 都選出一條指令，也就代表需要使用 N-of-M 的 select 電路

  • N：FU 個數
  • M：Issue Queue 的容量

• 假設一 2-of-M select 電路，如果要遵循 oldest-first 的設計，每個 cycle 需要選出 2 條指令來：

  • 需要兩級的 select 電路，第一級 select 電路選出指令後，將該指令標記，這樣第二級 select 電路在挑選時就會排除第一級 select 電路所選出來的指令
  • 但這樣的實做，其 latency 會是 1-of-M select 電路的兩倍，因此不可能擴展到 N-of-M select 電路

• 因此，要設計一個 N-of-M select 電路，仍然需要使用折衷的方法，在性能、電路面積和速度之間找到一個平衡點：

  

  • 四個 ALU 共用同一個 Issue Queue，假設 Issue Queue 容量為 M，每個 FU 都有一個專屬的 1-of-M select 電路
  • Issue Queue 中的指令會依照指令類型，分配給對應的 FU；如果存在相同功能的 FU，則會按照 round-robin 或是 random 的方式分配指令給這幾個 FU
  • 可以透過 demultiplexer 來實現
    • 因為 Issue Queue 中每個 entry 都有可能會放不同類型指令，因此每個 FU 的 select 電路都會有 M 個輸入，執行完整的 1-of-M select
  • 整個 N-of-M select 電路的 latency 可以降到跟 1-of-M select 電路一樣 (demultiplexer 的 latency 很小，可以忽略)

• 然而，這樣的設計無法實現理想的 N-of-M 功能：

  

  • LOAD、DIV、MUL、SUB、ADD 指令皆 ready，但只有 LOAD、DIV、ADD or SUB or ADD 其中一條指令可以被 issued，因此 4-of-M 的 select 電路，最後只能 issue 三條指令到 FU 中執行

  • 為了解決這樣的問題，可以增加 FU 的數量，如使用兩個相同的 ALU：ALU0 和 ALU1

    • 但會引入新的問題，一條 ALU 指令究竟要分配給哪個 ALU?

  • 可以採用一種 round-robin 的分配方法：

    • 目前 cycle 寫進 Issue Queue 的指令全部 issue 給 ALU0、下一個 cycle 寫進 Issue Queue 的指令改全部 issue 給 ALU1
    • 可以透過一個額外的 1 bit 訊號來標記這個 cycle 指令的 issue 狀態，且這個 1 bit 訊號每個 cycle 都會 toggle (0 → 1；1 → 0)
      • 0：ALU 類型的指令會被 issued 給 ALU0
      • 1：ALU 類型的指令會被 issued 給 ALU1

  • 不過這仍然無法保證嚴格的 oldest-first：

    

    • XOR 和 AND ⇒ 只有 AND 可以被 issued 進 ALU1
    • SUB 和 ADD ⇒ 只有 ADD 可以被 issued 進 ALU0
    • 但 SUB 比 AND 還老，但 AND 卻比 SUB 先被執行

    

    • CMP、SUB 和 ADD ⇒ 只有 AND 可以被 issued 進 ALU0
    • 雖然 ALU1 也可以用來計算，但此時卻沒有任何指令可以被 issued 進 ALU1，形成浪費

• 現代處理器大多一個 cycle 可以執行 4 ~ 6 條指令

• 需要將多個不同類型的指令加以合併使用同一個 FU：

  • 加減法、邏輯運算、移位運算 ⇒ 傳統意義上的 ALU
  • 整數乘法、整數除法
  • 浮點數運算
  • Memory access、Co-processor access

• 實際的設計中，需要對不同的指令集，甚至不同的程式進行分析，才能對 FU 進行合理的分類，得到相對優化的分配結果

• 由於 select 電路的 latency 與 Issue Queue 的容量成正比；當越多的 FU 共用同一個 Issue Queue 時，Issue Queue 的容量也需要相對應的增加，因此就會增加 select 電路的 latency

  • 但如果是想使越少的 FU 共用同一個 Issue Queue，那麼就需要更多數量的 Issue Queue，此時 wake-up 就需要更多的佈線和 comparators，反而增加 wake-up 電路的 latency 和功耗
  • 因此如何配置 Issue Queue 的分配並沒有一個標準答案，需要根據實際的需求並分析

• 程式中不同指令的相關性 (dependency) 可以分類為：

  1. 數據相關性 (data dependency)，包含以下幾種類型：

     • WAW (Write After Write) dependency，i.e. output dependence：

       • 兩條指令都將結果寫到同一個 destination register 中

     • WAR (Write After Read) dependency，i.e. anti-dependence：

       • 一條指令的 destination register 和它前面某條指令的 source register 相同

     • RAW (Read After Write) dependency，i.e. true dependence：

       • 一條指令的 source register 和它前面某條指令的 destination register 相同

     • 只有 RAW 是真的相關性， WAR 和 RAW 可以透過 register renaming 來解決

       

  2. 記憶體數據相關性 (memory data dependency)：

     • Load 和 store 指令之間的相關性，代表 load 和 store 指令都存取到同一個位址
     • 同樣也分為 WAW、WAR、RAW dependencies

  3. 控制相關性 (control dependency)：

     • 由於分支指令所引起的相關性，可以透過分支預測來解決

  4. 結構相關行 (structure dependency)：

     • 指令必須等到 CPU 中某些元件可以使用的時候才可以繼續執行
       • 例如要等到 Issue Queue 和 ROB 中有空閒的 entry，或是 FU 計算資源是有空的

• WAW 和 WAR dependencies 雖然可以透過 register renaming 來解決，但這兩個 dependencies 仍然存在的原因為：

  • 暫存器個數有限，導致在某些地方重複地使用暫存器
    • 需要透過 register renaming 並引進更多的 physical registers 來彌補
  • Loop 的存在，如果 loop body 中重複的向某個暫存器寫值，那麼就會產生大量的 WAW dependencies
    • 雖然可以透過 loop unrolling 的方法來解決這個問題，但由於暫存器的個數有限，在 unloop 到某一個時刻就會把所有的暫存器給用完，此時 WAW dependency 就是不可避免的了
    • 此外，loop unrolling 也會導致程式的 size 變大，佔用更多的記憶體空間，並導致 I-Cache miss rate 的升高
  • Code reuse，如 recursive call；如果 function 中會向某個暫存器寫值，並被 recursively called，那麼就會產生大量的 WAW dependencies
    • 同樣可以採用 inline function 的方式來解決這個問題，但也會碰到跟 loop unrolling 同樣的問題

• CPU 中實際存在的暫存器個數會比指令集定義的通用暫存器的個數還來得多：

  • CPU 內部實際存在的暫存器被稱為物理暫存器 (Physical registers)
  • 指令集定義的暫存器被稱為邏輯暫存器 (Logical registers 或是 Architecture registers)

• CPU 在做 register renaming 時，會動態的將 architecture registers 映射到 physical registers，這樣可以解決 WAW 和 WAR dependencies 的問題：

  

• Register renaming table (RAT)：用來保存已經存在的映射關係，i.e. architecture register → physical register)

  • 可以基於 SRAM 實現
  • 也可以基於 CAM 實現
  • 甚至可以採用 SRAM + CAM 來實現

• Free register list：用來保存目前還沒被映射的 physical registers

  • 在做 register renaming 時，會透過 free register list 來取得目前可以被映射的 physical register 編號

7.2 - 暫存器重命名方式

• Register renaming 有三種實做方式：
  1. 使用 ROB 來實做 register renaming
  2. 擴充 Architecture Register File (ARF) 來實做 register renaming
  3. 使用統一的 Physical Register File (PRF) 來實做 register renaming
• 在實做 register renaming 時，一般都要考慮以下的內容：
  1. 什麼時候佔用一個 physical register? 這個 physical register 來自於哪裡?
  2. 什麼時候要釋放一個 physical register? 這個 physical register 要被釋放到哪裡?
  3. 當發生 mis-prediction 時要如何處理?
  4. 當發生 exception 時要如何處理?

7.2.1 - 使用 ROB 來實做暫存器重命名

• 這種方法把 ROB 當做了 physical registers，在其中儲存了推測的結果，而 ARF 則儲存了正確的結果；使用此種方法，ROB 和 ARF 都可以儲存暫存器的結果，相當於是使用了 ROB 來擴充 ARF

• 當一個指令執行完後，其計算結果會被更新到 ROB 中對應的 entry 中，但是由於有可能會發生 mis-prediction 或是 exception，因此這些暫存器的狀態為推測 (speculative) 的；該條指令在被 retired 前都會一直存在 ROB 中，直到該指令變成 pipeline 中最舊的指令，且沒有發生 mis-prediction 或 exception，才會離開 pipeline，並使用其結果更新 CPU 的狀態 (e.g. 將結果寫到 ARF 中)

  • 這種方式相當於將 PRF 和 ROB 整合了在一起：

    

• 使用此方法可以簡化 register renaming 的流程，只要 ROB 中還有空間，register renaming 就可以持續地進行

• 一個 architecture register 的值有可能會同時存在 ROB 或是 ARF 中

  • E.g. 一條指令 retire 時更新了 $r1，其 architecture register 的計算結果會被記錄在 ARF 中；隨後又有另外一條指令被執行，也同樣更新了 $r1，其 architecture register 的計算結果會被記錄在 ROB 中

    • 因此，需要使用 RAT 來標記每個 architecture register 的計算結果是存在 ROB 或是 ARF 中：

      

      • 在一條指令 retire 前，其 architecture register 的計算結果會被存在 ROB 中，register renaming table 的 pointer 會指向 ROB；當這條指令 retire 時，其 architecture register 的計算結果會從 ROB 移到 ARF，RAT 的 pointer 也會一併更新指向 ARF
  • 因為一個暫存器在它的”生命週期”內會有兩個可以被存放的位置 (ROB 或是 ARF)，這會對指令 operands 的讀取造成影響，因此在實際的 CPU 中，都會搭配 data-capture 的 issue 方式，並採用 payload RAM 來儲存所需的 operands (參考：link)
    • 當一條指令的結果被 FU 計算出來後，會透過 bypassing network 將其結果寫進 payload RAM；Issue Queue 中所有等待這個結果的指令在被 select 電路選中時，就可以直接從 payload RAM 中得到 source registers 的值，而不用關心這些 source registers 的值是存在 ROB 或是 ARF 中

• 使用 ROB 做 register renaming：

  • 優點：

    • 實做容易，設計複雜度不高，且便於管理

  • 缺點：

    • 很多指令並不會更新 destination register，因此也就不用對 destination register 做 renaming，但每條指令仍然會佔用 ROB entry 中 destination register 的 physical register renaming 的空間，無法省略，浪費硬體空間

    • 對於一條指令而言，它既可以從 ROB 中讀取 operands，也可以從 ARF 中讀取 operands，所以 ROB 和 ARF 最壞的情況就是一個 cycle 內，所有的指令都需要同時讀取 ROB 或 ARF，會增加 ROB 和 ARF 的 read ports 所需的數量

      • 例如：4-way issue CPU，指令最多需要 2 個 source registers，那麼 ROB 和 ARF 都需要準備 2 x 4 = 8 個 read ports，對硬體面積和延遲造成負面的影響
      • 如果 CPU 有支援 multiple destination registers 的指令，那麼同樣也會對 ROB 和 ARF 的 write ports 數量造成影響

7.2.2 - 擴充 ARF 來實做暫存器重命名

• 這種方法是基於使用 ROB 來實做暫存器重命名方法的延伸；由於很多指令並沒有 destination register，例如：store 指令、分支指令和比較指令… etc，且這些指令佔了約 25% 的比例，使用 ROB 來實做暫存器重命名方法會造成 ROB 空間的浪費

• 因此，可以使用一個獨立的元件取代 ROB 來儲存 architecture register 對 physical register 的映射關係，這個元件被稱為 PRF (Physical Register File) (可以使用 FIFO 來實做)，它可以被視為 ARF 的擴充

• 在做 register renaming 時，architecture register 的計算結果被存在 PRF 中，等到這條指令 retire 時，才會將該計算結果從 PRF 搬進 ARF

  • 如果 PRF 中沒有空間了，那就必須 stall register renaming 之前的 pipeline stages，直到有指令 retire，PRF 的空間被釋放後，才可以繼續執行

  

• 缺點：

  • Architecture register 的計算結果仍然可能存在 PRF 及 ARF 兩個地方，因此仍然會對後面的指令使用這個暫存器作為 operands 的過程造成影響

7.2.3 - 使用統一的 PRF 來實做暫存器重命名

• 這種方法將上述方法的 ARF 和 PRF 合併，合併後同樣稱為 PRF (Physical Register File)，在其中同時儲存了 speculative 和 retire 的暫存氣值

• 這種統一的 PRF，所有沒有和指令產生映射關係的暫存器都是 free 的，並會使用一個 free list (可以使用 FIFO 來實做) 來記錄目前仍為 free 狀態的 physical registers

  • 在做 register renaming 時，architecture register 的計算結果會一直被存在 PRF 中，因此在 register renaming 的過程並不需要將 architecture register 的計算結果進行搬移，方便後續的指令讀取 operands
  • 這種方法同樣需要使用一個 RAT 來記錄每個 architecture register 對 physical register 的映射關係

  

• Superscalar CPU 在一個 cycle 內可以 retire N 條指令，因此每個 cycle 會有多個 physical registers 的編號會被寫進這個 FIFO 中，因此這個 FIFO 也要支援多個寫入，可以採用 interleaving 的方式來實現，避免 multi-port 的設計

• 當程式讀取暫存器時，由於很多 physical registers 仍處在 speculative 的狀態，是不能夠被程式所看到的，因此只使用一個 RAT 並沒辦法滿足這樣的要求；此時還需要使用另一個 RAT 來記錄所有 retired 的指令和 architecture register 對 physical register 的映射關係

  • 當指令 retire 時，其 architecture registers 對 physical registers 的映射關係就會被寫進這個 RAT
  • 外部透過查詢這個 RAT，就可以找到 architecture register 此時對應的 physical register，避免程式讀取到 CPU 內部一些可能錯誤的狀態

• 當一個 physical register 被佔用時，何時才可以再改為 free 狀態並加回 free list 中?

  • 當一個 physical register 不會再被後面的指令使用時，這個 physical register 就可以改為 free 狀態並加回 free list 中了

    • i.e. 當最後一條使用到這個 physical register 的指令要被 retired 時，就可以將此 physical register 改為 free 狀態

  • 但要在 CPU 中識別這個 physical register 最後一道使用到它的指令並不是一件容易的事情，CPU 可以採用一種很簡單也很保守的方法來辨別：

    • 當一條指令和其後面的指令都寫到同一個 destination register 時，當後面的指令 retire 時，前面指令的映射關係就沒有用處了，此時就可以將前面指令的 physical register 改為 free 狀態，並加回 free list 中

    

    • 例如：指令 (a) 和指令 (b) 都使用到了 $r1，如果有任何指令使用到指令 (a) 的 $p1，那麼這些指令一定是存在指令 (a) 和指令 (b) 之間的，因此當指令 (b) retire 時，代表不會再有任何指令會使用指令 (a) 的 $p1，此時便可以將 $p1 改為 free 狀態，並加回 free list 中了
      • 為了實現此功能，在 ROB 中還需要記錄指令 (如指令 (b)) 的 destination register 之前所對應的 physical register (如指令 (a) 的 $r1 所對應的 physical register - $p1)，以便在指令 retire 時 (如指令 (b))，將其舊的映射關係 ($r1 → $p1) 給釋放掉 (i.e. 將 $p1 改為 free 狀態，並加回 free list 中)

• 總結：

  • 使用 ROB 來實做 register renaming

    • 優點：

      • Register renaming 流程簡單，在指令寫入 ROB 時，將 architecture register 和 physical register 的映射關係一併記錄到 ROB 即可，不須增加複雜的硬體控制邏輯電路

    • 缺點：

      • 暫存器的值需要被搬移 (ROB → ARF)，功耗較大
      • 由於暫存器的值有可能存在 ROB 或是 ARF，當指令 retire 時，需要額外的電路同步所有有使用到該暫存器的指令來告知該暫存器已經從 ROB 搬移到 ARF，功耗較大

  • 擴充 ARF 來實做 register renaming

    • 優點：
      • 如同使用 ROB 來實做 register renaming，只需將 architecture register 和 physical register 的映射關係記錄到 PRF 即可，其中 PRF 可以使用 FIFO 來實做，不須增加複雜的硬體控制邏輯電路
    • 缺點：
      • 暫存器的值需要被搬移 (PRF → ARF)，功耗較大
      • 由於暫存器的值有可能存在 PRF 或是 ARF，當指令 retire 時，需要額外的電路同步所有有使用到該暫存器的指令來告知該暫存器已經從 PRF 搬移到 ARF，功耗較大

  • 使用統一的 PRF 來實做 register renaming

    • 優點：

      • 暫存器的值只需寫入一次，不需要再被搬移，功耗較小
      • 暫存器的值只會存在一個地方，不需要

    • 缺點：

      • 需要使用一個 free list 以及兩個 RAT，因此需要使用複雜的硬體控制邏輯電路

7.3 - 重命名映射表

• (以下皆採用統一的 PRF 來實做 register renaming 的方式)

• RAT 的實做有以下幾種方式：

  • 基於 SRAM 來實做 (sRAT)
  • 基於 CAM 來實做 (cRAT，實際上是基於 SRAM + CAM 來實做的)

• 範例：32 個 architecture registers ($r0 ~ $r31)，64 個 physical registers ($p0 ~ $p63)

  

  • sRAT：
    • 使用 architecture register 來 index，共 32 個
    • 每個 RAT entry 記錄了 architecture register 所對應的 physical register (共 6 bits)
  • cRAT：
    • CAM 是使用內容來 index 的，CAM 會將內容與每個 entry 做比較 (類似 fully-associative cache)，並回傳與內容相符的 entry indexes
    • 因此 cRAT 是透過 architecture register 來 index (共 5 bits)，CAM 會回傳與其對應的 physical register index

• 雖然 SRAM 的存取速度比 CAM 來得快，而且 sRAT 比 cRAT 更省空間 (architecture registers 數量都是固定的，physical register 所佔的空間只為 log2 bits)，但是在現實的 CPU 中，仍然存在使用 cRAT 的設計

  • 這是因為 cRAT 在做 checkpoint 時，只需保存 valid bits 及 free list 的 read pointer (sRAT 同樣也需保存 free list 的 read pointer)，不需將整個 cRAT 做保存，大大減少 checkpoint 所需的電路面積
    • 因此相較於 sRAT，cRAT 不會隨著 checkpoint 的數量增加而增加大量的硬體面積
      • 當 checkpoints 的數量超過一定值，cRAT 就比 sRAT 有更大的優勢
    • 只需保存 free list 的 read pointer：
      • Write pointer + 1 代表有指令 retire，將 physical register 加回 free list 中
        • Write pointer 在 restore checkpoint 的時候不需要恢復，因為在 checkpoint restore 時，分支指令之前的指令有可能已經 retired 了，因此我們要保留其已經 free 掉的 physical registers
      • Read pointer + 1 代表有新的指令被執行，並使用 physical register 來映射 architecture register
        • Read pointer 在 checkpoint 的當下需要被保存，因為會從 free list 中拿 physical register 來建立映射關係的指令，都是分支指令之後的指令，restore checkpoint 後這些指令也需要被 flushed，因此需要恢復 read pointer
  • 現代處理器通常有較深 pipeline stages 及更多的 issue ways (可以處理的指令越多，代表一個 cycle 內出現的分支指令個數有可能也會增加)，因此需要更多的 checkpoints，此時 cRAT 就是一個比較好的選擇

7.3.1 - 基於 SRAM 的重命名映射表

• 當需要對分支指令狀態進行 checkpoint 時，需要備份整個 sRAT，因此這個實做方法每個 checkpoint 會佔用大量的硬體面積，因此限制了 checkpoints 的個數

  

• 對於一個 4-way 的 superscalar CPU 來說，每個 cycle 需要對 4 條指令做 register renaming，也就是 sRAT 需要支援 8 個 read ports 和 4 個 write ports (假設每條指令包含 2 個 source registers 和 1 個 destination register)；此外，還需要一個 free list 來記錄有哪些 physical registers 是 free 的

• 當有新的指令做 register renaming 時，有可能會發生 RAT entry 被蓋掉的問題，例如：

  • 此時不能直接把 RAT entry 給蓋掉，因為：
    • 一條指令在 retire 時，要將其對應的 physical registers 改為 free 狀態，並加回 free list 中，如果其 RAT entry 被覆蓋，就沒辦法更新 physical register
      • 例如：當發生 WAW 時，前後指令同樣的 destination register 會對應到不同的 physical registers，此時前面指令的 RAT entry 就會被後面指令的 RAT entry 給覆蓋
    • 當一條指令在 exception 或是 mis-prediction 的路徑上，這條指令最終會需要被 flushed 掉，同時也需要將該指令對 RAT 的修改給復原
      • 如果舊的映射關係沒有被保存下來，就無法將該指令對 RAT 的修改給復原
  • 因此，在一個 destination register 對 physical register 的映射關係被寫進 RAT 前，需要將其所覆蓋的 RAT entry (i.e. 舊的映射關係) 給寫進 ROB 中

• sRAT 相較于 cRAT，讀寫速度會快一點，設計複雜度也不會隨著 physical registers 的增加而變大，但其最大的缺點就是：Checkpoints 的數量有上限

  • 但隨著處理器的並行度的提高，會有更多的分支指令存在 pipeline 中，也就需要使用更多個 checkpoints
  • 不過當分支指令的預測正確時，checkpoint 是不會被使用的
    • 因此可以對分支指令的預測正確度也進行預測，對於那些預測準確度很高的分支指令，可以不使用 checkpoint，可以把 sRAT 的 checkpoints 留給那些預測準確度較低的分支指令
    • 但當這些未使用 checkpoint 的分支指令發生 mis-prediction 時，就需要使用速度較慢的方式來恢復 RAT
      • 如果發生頻率的很低，就不會對性能造成影響

7.3.2 - 基於 CAM 的重命名映射表

• 在 cRAT 中，architecture register 就是每個 CAM entry 所保存的內容，physical register 則是最後的結果

• cRAT 使用 architecture register 來索引 CAM，所有的 CAM entries 都會與欲索引的 architecture register 做比較，只有 CAM entry 內容與欲索引的 architecture register 相同時，其所對應的 physical register 才會被回傳；由於一個 architecture register 只會有一個對應的 physical register，因此只會有一個 CAM entry 相符

  • 相符的 entry 可以用 valid bit 來表示，i.e. V = 1

• 對 cRAT 做 checkpoint 時，只需 checkpoint valid bits 即可

  

• 由於 cRAT 所需的 checkpoint 資源很少，因此可以將 checkpoints 個數做得很大

  • E.g. Alpha 21264 使用 cRAT 做 register renaming，總共包含了 80 個 checkpoints，也就是最大允許 80 條分支指令存在 pipeline 中

• 對於一個 4-way superscalar CPU 而言，使用 cRAT：

  • cRAT 需要支援 8 個 read ports (2 source registers * 4) 及 4 個 write ports (4 destination registers)

• 基於 cRAT 進行 register renaming 仍然需要使用 free list 來記錄哪幾個 physical registers 是 free 狀態的

  • 要等指令 retire 時，才可以將其 architecture register 所對應的 physical register 改為 free 狀態並加回 free list 中
  • 因此，在 cRAT 中，並不是一個 physical register 的 valid bit 為 0 時，就代表其為 free 狀態，有可能是其映射關係剛被覆蓋而已

    • 例如：

      1 2	addi $r7, $r0, 2 addi $r7, $r3, 3

      • 第一條指令：$p11 → $r7 ⇒ V = 1
      • 第二條指令： $p12 → $r7 ⇒ V = 1；$p11 → $r7 ⇒ V = 1 → 0
        • $p11 → $r7 的映射關係被 $p12 → $r7 取代，因此 V = 1 → 0，但不代表 $p11 就是 free 狀態的

    • 指令實際在 pipeline 中的運算還是使用當初所被分配的 physical register，所以只有等到指令 retire 後，其 physical register 才可以被改為 free 狀態

      • i.e. 第一條指令 $r7 所使用的 physical register 依然是 $p11，RAT 只是記錄最新的映射狀態

• 當一條指令 retire，其 physical register 改為 free 狀態後，該 physical register 在 RAT 中的映射關係的 valid bit 也會被設為 0

  • 也就是說，V = 0 同時表示了：
    • 映射關係被取代
    • Physical register 已經被改為 free 狀態

• cRAT checkpoint & restore 範例 (只針對 destination register 的部份)：

  1 2 3 4 5 6 7 8

  指令 A：addi $r5, $r0, 1 指令 B：addi $r7, $r0, 2 指令 C：addi $r6, $r7, 3 指令 D：add $r7, $r7, $r1 指令 E：add $r7, $r7, $r2 指令 F：beq $r7, $r3, #TARGET1 指令 G：add $r9, $r5, $r6 指令 H：add $r5, $r9, $r9

  • 當分支指令 F 做 register renaming 時，需要對 cRAT 做 checkpoint，此時 cRAT 的內容如下：

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

    +--------------------------------------------+-------------------------------+ | cRAT | Checkpoints | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | Inst | Phys Regs | Arch Reg | V | GC0 | GC1 | GC2 | GC3 | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p0 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | ... | ... | ... | ... | ... | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | A | $p10 | $r5 | 1 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | B | $p11 | $r7 | 1 -> 0 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | C | $p12 | $r6 | 1 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | D | $p13 | $r7 | 1 -> 0 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | E | $p14 | $r7 | 1 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p15 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p16 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p17 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | ... | | | ... | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p63 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+

    • 當指令 D 做 register renaming 時，由於指令 D 和指令 B 都存取 $r7，因此指令 B 的映射關係會被 invalid (V = 0)
    • 當指令 E 做 register renaming 時，由於指令 E 和指令 D 都存取 $r7，因此指令 D 的映射關係會被 invalid (V = 0)
    • 分支指令 F 做 register renaming 時：
      • Checkpoint - GC0 的內容會被更新為：1, 0, 1, 0, 1

  • 在指令 G、指令 H 也做完 register renaming 後，指令 F 發生 mis-prediction，因此需要使用 GC0 來恢復 cRAT；在使用 GC0 來恢復前的 cRAT 內容如下：

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

    +--------------------------------------------+-------------------------------+ | cRAT | Checkpoints | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | Inst | Phys Regs | Arch Reg | V | GC0 | GC1 | GC2 | GC3 | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p0 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | ... | ... | ... | ... | ... | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | A | $p10 | $r5 | 1 | 1 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | B | $p11 | $r7 | 1 -> 0 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | C | $p12 | $r6 | 1 | 1 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | D | $p13 | $r7 | 1 -> 0 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | E | $p14 | $r7 | 1 -> 0 | 1 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | G | $p15 | $r9 | 0 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | H | $p16 | Rr7 | 1 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p17 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | ... | | | ... | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p63 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+

    • 當指令 H 做 register renaming 時，由於指令 H 和指令 E 都存取 $r7，因此指令 E 的映射關係會被 invalid (V = 0)
    • 當恢復 GC0 後，$p10 ~ $p16 的 V 值會被恢復成：1, 0, 1, 0, 1, 0, 0
      • 在分支指令 F 之前的指令有可能在恢復 checkpoint - GC0 的當下已經 retired 了，此時有以下可能：
        • Physical register 改為 free 狀態，並加入 free list 中 ⇒ V = 0
          • V 被 restored 回 0 (如指令 B)
            • 不會造成影響，因為本來 V = 0 本來也就可以表示 free 狀態
          • V 被 restored 回 1 (如指令 C)
            • 被恢復的指令已經 retired 了，其 physical register 已經被加入 free list 中，因此只要在存取 RAT 時有一併檢查 physical register 是否在 free list 中，就算 V 被 restored 回 1 也沒關係
        • Physical register 被其他指令重新映射 ⇒ V = 1
          • V 被 restored 回 0 (如指令 B)
            • 不會造成影響，因為重新映射的指令是分支指令之後的指令，本來就應該被 flushed 掉 ⇒ V = 0
          • V 被 restored 回 1 (如指令 C)
            • 重新映射的指令也應該被 flushed ⇒ V = 0，不過由於被恢復的指令已經 retired 了，其 physical register 已經被加入 free list 中，因此只要在存取 RAT 時有一併檢查 physical register 是否在 free list 中，就算 V 被 restored 回 1 也沒關係

• 一般情況下，pipeline 中允許存在的最多的分支指令數，和處理器最大可以支援的 checkpoints 數量是一樣的 (假設只有分支指令使用 checkpoint)

• 如果分支預測正確，就可以將分支指令對應的 checkpoint 給釋放掉，變成 free 狀態，後續分支指令可以繼續使用它

• 分支預測失敗，restore checkpoint 後，也會一併將該 checkpoint 給釋放掉，變成 free 狀態，後續分支指令也可以繼續使用它

• cRAT checkpoint & restore 兩條分支指令範例 (只針對 destination register 的部份)：

  1 2 3 4 5 6 7 8 9 10

  指令 A：addi $r7, $r0, 3 指令 B：add $r6, $r7, $r1 指令 C：add $r7, $r7, $r2 指令 D：beq $r7, $r3, #TARGET1 指令 E：add $r9, $r5, $r6 指令 F：add $r9, $r9, $r8 指令 G：beq $r9, $r3, #TARGET2 指令 H：addi $r7, $r0, 1 指令 H：addi $r6, $r0, 2 指令 H：sub $r9, $r1, $r0

  • 當分支指令 D 做 register renaming 時，需要對 cRAT 做 checkpoint，此時 cRAT 的內容如下：

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

    +--------------------------------------------+-------------------------------+ | cRAT | Checkpoints | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | Inst | Phys Regs | Arch Reg | V | GC0 | GC1 | GC2 | GC3 | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p0 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | ... | ... | ... | ... | ... | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | A | $p10 | $r7 | 1 -> 0 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | B | $p11 | $r6 | 1 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | C | $p12 | $r7 | 1 | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p13 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p14 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p15 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p16 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p17 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | ... | | | ... | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p63 | | | 0 | | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+

    • 當指令 C 做 register renaming 時，由於指令 C 和指令 A 都存取 $r7，因此指令 A 的映射關係會被 invalid (V = 0)
    • 分支指令 D 做 register renaming 時：
      • Checkpoint - GC0 的內容會被更新為：0, 1, 1

  • 當分支指令 G 做 register renaming 時，需要對 cRAT 做 checkpoint，此時 cRAT 的內容如下：

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

    +--------------------------------------------+-------------------------------+ | cRAT | Checkpoints | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | Inst | Phys Regs | Arch Reg | V | GC0 | GC1 | GC2 | GC3 | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p0 | | | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | ... | ... | ... | ... | ... | ... | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | A | $p10 | $r7 | 1 -> 0 | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | B | $p11 | $r6 | 1 | 1 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | C | $p12 | $r7 | 1 | 1 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | E | $p13 | $r9 | 1 -> 0 | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | F | $p14 | $r9 | 1 | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p15 | | | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p16 | | | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p17 | | | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | ... | | | ... | ... | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p63 | | | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+

    • 當指令 F 做 register renaming 時，由於指令 F 和指令 E 都存取 $r9，因此指令 E 的映射關係會被 invalid (V = 0)
    • 分支指令 G 做 register renaming 時：
      • Checkpoint - GC1 的內容會被更新為：0, 1, 1, 0, 1

  • 當所有指令都完成 register renaming 後，cRAT 的內容如下：

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

    +--------------------------------------------+-------------------------------+ | cRAT | Checkpoints | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | Inst | Phys Regs | Arch Reg | V | GC0 | GC1 | GC2 | GC3 | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p0 | | | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | ... | ... | ... | ... | ... | ... | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | A | $p10 | $r7 | 1 -> 0 | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | B | $p11 | $r6 | 1 -> 0 | 1 | 1 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | C | $p12 | $r7 | 1 -> 0 | 1 | 1 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | E | $p13 | $r9 | 1 -> 0 | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | F | $p14 | $r9 | 1 -> 0 | 0 | 1 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | H | $p15 | $r7 | 1 | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | I | $p16 | $r6 | 1 | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | J | $p17 | $r9 | 1 | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | ... | | | ... | ... | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+ | | $p63 | | | 0 | 0 | | | +---------+-------------+-----------+--------+-------+-------+-------+-------+

    • 當指令 H 做 register renaming 時，由於指令 H 和指令 C 都存取 $r7，因此指令 C 的映射關係會被 invalid (V = 0)
    • 當指令 I 做 register renaming 時，由於指令 I 和指令 B 都存取 $r6，因此指令 B 的映射關係會被 invalid (V = 0)
    • 當指令 J 做 register renaming 時，由於指令 J 和指令 F 都存取 $r9，因此指令 F 的映射關係會被 invalid (V = 0)

  • 如果指令 D 發生 mis-prediction，就需要使用 GC0 來恢復 cRAT，並在恢復完 cRAT 後將 GC0 給釋放掉

    • 如果是 in-order core，則在 restore checkpoint 時，分支指令一定會是最後一條指令，GC1 一定會是在 mis-prediction 的路徑上，因此 GC1 也可以被釋放掉

  • 如果指令 D 預測正確，但指令 G 發生 mis-prediction，就需要使用 GC1 來恢復 cRAT，並在恢復完 cRAT 後將 GC1 給釋放掉

  • cRAT 並不負責管理哪些 physical registers 是 free 狀態的，這個功能是透過 ROB 和 free list 來實現的

  • 基於 CAM 的重命名映射表最大的弊端就是其硬體面積會隨著 CPU 中 physical registers 的個數增大而變大，因為 CAM 的 entry 個數，就是 physical registers 的個數

    • 隨著處理器並行度的增加，需要更多的 physical registers，此時 cRAT 就需要更多的比較電路，進而拖慢 CPU 的速度
    • 但是由於 cRAT checkpoint 時只需保存 valid bits (以及 free list 的 read pointer) 即可，大大降低了對硬體的需求，尤其是現在處理器中，會有更多的指令在 pipeline 中，需要更多的 checkpoints 配合，這時 cRAT 的優勢就體現出來了
    • 因此在設計時需要權衡使用 cRAT 的優缺點

7.4 - 超標量處理器的暫存器重命名

• RAT 在初始化時，architecture registers 就已經有對應的 physical registers，因此 source register 可以直接讀取 RAT 取得對應的 physical register，例如：

  1 2 3 4 5

  $r0 -> $p0 $r1 -> $p1 $r2 -> $p1 ... $r31 -> $p31

  • 剩餘沒映射關係的 physical registers 會被加進 free list 中

• 對於一條：Dest = Src1 op Src2 的指令，register renaming 的過程如下：

  1. 從 RAT 找到 Src1 和 Src2 對應的 physical registers：Psrc1、Psrc2

     

  2. 從 free list 中找到一個 free 狀態的 physical register：Pdest

     

  3. 將 Dest → Pdest 的映射寫進 RAT 中

     

• 由上述範例可以知道：

  • RAT 需要支援 2 個 read ports (source registers) 和 1 個 write port (destination register)

  • (對於 sRAT) 為了將 physical register 釋放回 free list，因此還需要將每條指令之前的對應關係保存到 ROB 中 (參考：link)，因此 RAT 還需要 1 個額外的 read port 來讀取 destination register 所對應的 physical register

  • 對於 superscalar CPU 而言，N-way CPU 的 RAT 就提供 N 倍的 read ports 和 write ports：

    

• 除了 multi-port RAT 外，register renaming 還需考慮到每個 cycle 同時 rename 多條指令之間所存在的 dependencies，例如：

  

  • 指令 A 和指令 B 有 RAW dependency
    • 為 true dependency
  • 指令 A 、指令 B 和指令 D 有 WAW dependency
    • 可以透過 register renaming 解決，但實際上仍無法忽略其存在：

      1. 在一個 cycle 內多條指令發生 WAW，只需將最新那條指令的映射關係寫進 RAT 即可

         • 舊的指令還是會被分配 physical registers，後續在 pipeline 中的運算也是使用被分配的 physical registers，只是不需要將其映射關係給寫進 RAT，不然只是浪費 RAT 的空間

      2. 在將每條指令的舊映射關係寫進 ROB 時，如果發現一個 cycle 內有多條指令都使用同一個 destination register，那麼此時寫進 ROB 的舊映射關係，就不是來自 RAT，而是來自於與其發生 WAW 的那條指令 (參考：link)

         • 例如：
           • 指令 B 的 $r0 → $p31，$r0 舊的映射關係是來自指令 A 的 $p30，而不是來自於 RAT 所讀出的結果
           • 指令 D 的 $r0 → $p33，$r0 舊的映射關係是來自指令 B 的 $p31，而不是來自於 RAT 所讀出的結果
         • 因此 superscalar CPU 在做 register renaming 時，仍需對指令間的 WAW dependency 做檢查
  • 指令 B 和指令 D 有 WAR dependency
    • 可以透過 register renaming 解決

• 因此，superscalar CPU 在做 register renaming 時，需檢查 RAW 和 WAW 的 dependencies

7.4.1 - 解決 RAW 相關性

• 對 4-way superscalar CPU 來說，每個 cycle 可以處理 4 條指令，如果這 4 條指令之間不存在 RAW，則 register renaming 過程就相對單純，例如：

  

  1 2 3 4

  $r1 = $r1 + $r2 => $p31 = $p10 + $p11 $r3 = $r3 + $r4 => $p40 = $p12 + $p13 $r5 = $r6 x $r7 => $p8 = $p20 x $p21 $r8 = Load 9[$r9] => $p5 = Load 9[$p22]

• 但當這 4 條指令有 RAW 時：

  

  1 2 3 4

  $r1 = $r1 + $r2 => $p31 = $p10 + $p11 $r3 = $r3 + $r4 => $p40 = $p12 + $p13 $r5 = $r6 x $r1 => $p8 = $p20 x $p25 $r8 = Load 9[$r9] => $p5 = Load 9[$p22]

  • 對於 $r5 = $r6 x $r1 這條指令而言，$r1 的 physical register 應該來自於 $r1 = $r1 + $r2 中的 $r1 destination register 所對應的 physical register，也就是：$p31，而非 RAT 所輸出的 $p25
    • 如果不加以處理，運算結果就會有誤

• 需要有一個檢查機制，對 1 個 cycle 內的所有做 register renaming 的指令進行 RAW 的檢查

  • 在 register renaming stage，指令之間還是 in-order 的，因此只需要將所有指令的 source registers 與它前面所有指令的 destination registers 做比較，如果 registers 相同，那麼這個 source register 的 physical register 來源就不是 RAT，而是來自 free list

    • 如果多個 registers 皆相同，則使用最新指令的 physical register

  • 硬體設計如下圖：

    

    • 第一條指令的 source registers 所映射的 physical registers 一定只能來自於 RAT，也不需要進行 RAW 的檢查
    • 第二條指令的 source registers 所映射的 physical registers 有可能來自於 RAT，或是第一條指令的 destination physical register
    • 第三、第四條指令也是類似的
    • 此外，最後一條指令的 destination physical register 一定不會作為前面指令的 source register

    

7.4.2 - 解決 WAW 相關性

• WAW 影響 RAT 和 ROB 的寫入過程，因此也需要在 register renaming stage 對其進行檢查：

  1. 對寫 RAT 進行檢查：

     • 如果 1 個 cycle 內有多條指令的 destination registers 都相同，那麼只有最新的那條指令的映射關係會被寫入 RAT
     • 每條指令都必須比較其 destination register 與所有在其後面的指令的 destination registers，如果發現有相同的 destination registers，則代表該條指令的 destination register 映射關係就不該被寫進 RAT
       • 例如：

         • 4 條在同一個 cycle 進行 register renaming 的指令，destination registers 分別為 dst0, dst1, dst2, dst3：

           • dst0 需要與 dst1、dst2、dst3 比較
           • dst1 需要與 dst2、dst3 比較
           • dst2 需要與 dst3 比較
           • dst3 由於是最後一條指令，因此此 dst3 的映射關係一定會被寫進 RAT

           

  2. 對寫 ROB 進行檢查：

     • 為了能夠釋放那些不再使用的 physical register，同時又可以恢復處理器的狀態，每條指令的 destination register 都必須在做 register renaming 時，將舊的映射關係寫進 ROB 當中 (參考：link)；如果在 1 個 cycle 內，有兩條以上的指令存在 WAW，那麼比較新的指令的 destination register 舊的映射關係就直接來自比較舊的那條指令，而不是來自於 RAT

       

       • 指令 D 的 $r0 之前的 physical register 應該來自於指令 B 的 $p31，而不是 RAT 讀出的值

     • 每條指令都必須比較其 destination register 與所有在其前面的指令的 destination registers，如果發現有相同的 destination registers，則該條指令的 destination register 舊的映射關係就是與其最相近指令的 destination register 所對應的 physical register

     

     • 第一條指令由於前面沒有其他的指令，其 destination register 舊的映射關係只能是來自於 RAT
     • 第二條指令必須和第一條指令的 destination register 比較
     • 第三條指令必須和第二條、第一條指令的 destination registers 比較
     • 第四條指令必須和第三、第二、第一條指令的 destination registers 比較

7.5 - 暫存器重命名過程的恢復

• 當發生 mis-prediction 或 exception 時，需要把在錯誤路徑上的指令給 flushed 掉；如果這些要被 flushed 的指令已經經過了 register renaming stage，就代表這些指令也佔據了 RAT、ROB、Issue Queue 等資源；當指令被 flushed 時，也需要將這些被佔據的資源給恢復，這樣才能保證後續的指令可以在一個正確的 pipeline 中開始執行
• Register renaming 的恢復包含了：
  • ROB 的恢復
  • Issue Queue 的恢復
  • RAT 的恢復
    • 以下方法對前面介紹的三種 register renaming 的方式 (使用 ROB 來實做暫存器重命名、擴充 ARF 來實做暫存器重命名、使用統一的 PRF 來實做暫存器重命名) 都適用：
      • 使用 Checkpoint 來恢復 RAT
      • 使用 WALK 來恢復 RAT
      • 使用 Architecture State 來恢復 RAT

7.5.1 - 使用 Checkpoint

• 對於一個實現了 Checkpoint 的 RAT 來說，在 SRAM 的每個最小儲存單元：MBC (Main Bit Cell) 周圍都加入同樣的儲存單元：CBC (Checkpoint Bit Cell)，這些 CBC 就實現了 Checkpoint 的功能，可以快速的完成 RAT checkpoint & restore
  • 當要保存 RAT 狀態時，就將 MBC 的內容複製到 CBC
  • 當要恢復 RAT 狀態時，就將 CMC 的內容複製到 MBC
• cRAT 只需要保存 valid bits
• sRAT 則需要將整個 SRAM 都保存下來，checkpoint 所需的電路面積很大，對處理器的速度和面積都會造成不小的負面影響，在設計時需要有所權衡

7.5.2 - 使用 WALK

• Checkpoint 電路會增加硬體的開銷，因此，還有一種比較廉價的方式來保存和恢復 RAT 狀態，那就是使用 ROB
  • 在 ROB 中保存每條指令之前 architecture registers → physical registers 的映射關係，利用這個資訊，就可以將 RAT 的狀態逐步地”倒回去”，使那些在錯誤路徑上的指令，一個一個恢復其對 RAT 的修改
  • 這種方式稱為 WALK
• WALK 對 RAT 的恢復是比較慢的，它首先需要 flush 錯誤路徑上的指令，同時還需要逐個指令恢復 RAT，消耗非常多的時間
  • 對於分支指令而言，這樣的方法會增加分支預測失敗時的 mis-penalty
• WALK 的優點就是消耗的硬體資源比較少，因此在某些 CPU 中，例如 MIPS R10000，就使用這種方法來恢復發生 exception 時的狀態
  • Exception 發生的頻率比分支預測失敗的頻率來得低，因此這種相對比較慢的方式在某些情況下也是可以接受的

7.5.3 - 使用 Architecture State

• 當需要從 CPU 外部存取一個 architecture register 時 (e.g. debugger)，直接使用 register renaming stage 的 RAT 是很難做到的，因為它仍處在 speculative 的階段，因此一般都會在 pipeline 的 commit stage 也使用一個 RAT，所有正確 retire 的指令都會將其對應的 physical registers 更新到這個 RAT，因此這個 RAT 所記錄的映射狀態肯定是正確的；這個 RAT 稱為 aRAT (Architecture RAT)
  • 只有從 aRAT 才可以找到 architecture registers 對應的正確狀態的 physical registers
• 利用 aRAT 也可以用來恢復 register renaming stage 的 RAT
  • 舉例來說，當一條分支指令發生 mis-prediction 時，並不馬上進行 RAT 的恢復，而是讓 pipeline 繼續執行 (分支指令之前的 pipeline 必須 stall)，當這條分支指令變成 pipeline 中最舊的指令時，此時 aRAT 即表示了分支指令所對應的正確狀態的 RAT，因為分支指令之前的指令都已經順利 retired，並更新了 CPU 的狀態了
    • 此時，便可以將 aRAT 內容，直接複製到 register renaming stage 的 RAT，就完成了 RAT 的恢復
• 但當在 execution stage 發現分支指令 mis-prediction 時，可能 pipeline 中還存有很多比這條分支指令還舊的指令；如果這些指令中包含了 D-cache miss 的 load 指令，那麼這條分支指令就可能得等待一段時間才能變為最舊的指令，這會增大 mis-penalty，一定程度上影響了處理器的效能
• 使用 aRAT 的好處：
  • 在 superscalar CPU 中，在分支指令之前的指令，如果有指令發生了 exception，那麼就必須等到這條指令變為 pipeline 中最舊的指令時，將 pipeline 中的指令給全部 flush 掉，其中也包含了分支指令；由於這條分支指令並不會被執行，因此即使在 register renaming stage 做了 checkpoint 也是浪費，使用 aRAT 在這種情況下就不會白作工

7.6 - 分發

• Pipeline 中的 Dispatch stage 就是 in-order execution 和 out-of-order execution 的分界點；指令經過 register renaming stage 後，就會進到 dispatch stage
  • 在這個階段，經過 register renaming 後的指令會被寫到不同的 buffers 中，為 out-of-order execution 做好準備
• Buffers 主要分為三大類：
  • Issue Queue (out-of-order)
    • 大部分的 FU (Function Unit) 都可以 out-of-order 來執行指令
    • 當指令進到 Issue Queue 中時，其 operands 有可能還沒完全準備好，那麼就必須先在 Issue Queue 中等待
    • 只要有任一條指令的 operands 都準備好了，就可以將其送到 FU 來執行，不用理會這條指令在程式中原先的執行順序 (i.e. out-of-order)
    • 由於 out-of-order execution 的關係，Issue Queue 中的 empty entries 分佈是沒有規律的，需要有特別的設計方法
  • Issue Queue (in-order)
    • 即使在 out-of-order core 中，也是有部份的指令是照著程式中的執行順序來執行的，例如分支指令和 store 指令
      • 這些指令如果按照 out-of-order 的方式來執行，會帶來不少的硬體消耗，且在性能上也不一定能提昇多少，因此對這些指令一般採取 in-order 的方式來執行
    • Issue Queue 本質上就是一個 FIFO，透過調整 write pointer 就可以找到 free entries，將 register renaming 過的指令放到其中
      • 可以透過 interleaving 的方式來實現這種 Issue Queue
  • ROB
    • ROB 可以將 out-of-order execution 的指令拉回程式的執行順序；指令經過 register renaming 後會按照程式的執行順序寫到 ROB 中
      • 即使有些指令很早就完成執行了，它仍必須等到 ROB 中在它前面的指令執行完成後，才能被 retired 並更新 CPU 的 architecture state (程式可見)
    • ROB 本質上也是一個 FIFO，透過調整 write pointer 就可以找到 free entries，將 register renaming 過的指令放到其中
• Pipeline 中的 dispatch stage 就是將 register renaming 後的指令寫到 Issue Queue 和 ROB 的過程，指令被 dispatched 到 Issue Queue 後，就可以以 out-of-order 的方式來執行了，而透過 ROB 可以將 out-of-order execution 的指令拉回程式的執行順序
• Dispatch 可以跟 register renaming 放在同一個 cycle 內完成，但當 Issue Queue 和 ROB 的容量比較大時，向它們寫入資料會變得很慢，嚴重影響 CPU 的 cycle time，因此很多 CPU 都會將 dispatch 獨立為一個 stage

6.1 - 指令緩存

• 現代處理器可以在 fetch stage 從 I-Cache 讀出大於每個 cycle 可以 decode 指令個數的指令，因此需要在 fetch stage 和 decode stage 之間加一個 buffer，用來將 I-Cache 讀出的所有指令保存起來，這個 buffer 就稱為 Instruction Buffer
• Fetch stage 最終會輸出兩個主要的內容給 Instruction Buffer：
  • 從 I-Cache 讀出的 N 條指令 (並非所有指令都是有效的)
  • 有效的指令個數
    • 1 instruction fetch 位址不是 cache aligned 時，或是 fetch group 中包含預測為 taken 的指令，會導致 fetch stage 沒辦法寫入 N 條指令進 Instruction Buffer
    • 此時需要告知 Instruction Buffer，有效的指令個數
• 現在 superscalar CPU 需要 Instruction Buffer 的原因：
  • Superscalar CPU 可以每個 cycle 可以 fetch 的指令個數大於每個 cycle 可以 decode 的指令個數，這樣即使在發生 I-Cache miss 時，Instruction Buffer 中仍有可能還有保存尚未 decode 的指令，因此不需要 stall pipeline，可以繼續 decode 指令，增加 CPU 的性能
  • Superscalar CPU 中即使每個 cycle 可以 decode 的指令個數與每個 cycle 所 fetch 的指令個數相等，在 decode stage 仍會有一些特殊的指令需要處理，導致在 fetch stage 所 fetch 的指令沒有辦法全部被 decode
    • 如 ARM 的 multiply-accumulate 指令 (UMAAL RdLo, RdHi, Rn, Rm)，會有兩個 destination registers，為了減少對 register renaming 的影響，會將其拆分成兩條普通的指令，每條指令只有一個 destination register
    • 因此，如果在 decode stage 沒有特別的處理，會導致 decode 的指令個數大於 fetch 指令的個數，但後續的 pipeline 都是依照原先的指令個數來設計的，不可能因為這些不常見的指令而增加後續 pipeline 的處理能力 (因為會增加硬體面積，且使用率也不高)
    • 為了解決此問題，就需要加入 Instruction Buffer，讓 multiply-accumulate 後面的指令，可以等到下一個 cycle 再 decode
• 由於 Instruction Buffer 可以在一個 cycle 內寫入多條的指令，也可以讀出多條的指令，因此也是一個 multi-port 的 FIFIO；但在實際設計上，並不會使用真的 multi-port 的 SRAM 來實現這樣的 FIFO，而是會採用 interleaving 的方式 (參考：2.3.1 - True Multi-port)，使用多個 single-port 的 SRAM 來實現，從而避免使用 multi-port SRAM 所導致的硬體速度上的限制

6.2 - 一般情況

• ARM 的 CPSR，只有 4 個 bits (N、C、Z、V)，但其他的暫存器都是 32 bits 的；如果將 CPSR 跟其他的暫存器統一對待，會造成很多暫存器無法有效的被利用，因為 32 bits 的暫存器，只存了 4 bits 的資料
  • 因此，一般都是將 CPSR 單獨處理，對 CPSR 單獨使用一套 register renaming 的流程，這樣就可以根據 CPSR 的特性來訂製 register renaming 的流程
  • 且考慮到條件執行的指令只是少部份，所以所使用的 register file 可以很小，例如只需只用 16 個 physical registers 就足夠了
  • 指令所攜帶的 source registers 和 destination registers 的個數直接決定了 register renaming 電路在實現上的難易度：
    • 像是 register renaming mapping tables 的 ports 數、指令間相關性檢查電路的複雜度
  • 由於 RISC 架構的指令比較整齊劃一，很容易解析出指令中的 opcode 和 operands，在 decode stage 產生的 pipeline 控制訊號也比較少，因此 RISC 架構的 instruction decoding 通常都可以在 1 個 cycle 完成
  • 一般情況下，RISC 處理器在 decode stage 完成的任務可以概括為：
    • What type：例如指令是算術指令還是分支指令
    • What operation：例如當指令是算術指令時，是進行什麼運算；是分支指令時，它的跳轉條件是什麼樣的
    • What resource：例如對算術指令時來說，其 source 和 destination registers 是哪些，有沒有 immediate value

6.3 - 特殊情況

• 即使在 RISC 指令集中，也存在一些特殊的指令；這些指令不能按照一般的方法處理
  • 例如：ARM 的 LDM / STM 指令，需要多個 cycles 才能完成；而且它們的 source 和 destination registers 有多個，如果在 superscalar CPU 中對它們跟普通指令一樣來處理的話，會需要增加 register renaming mapping table、issue queue 和 ROB 所需的 ports 數，增加硬體的面積，並降低處理效能
• 因此在 superscalar CPU 中，並不會直接處理 LDM / STM 這樣的指令，而是會將其轉換為多條普通的指令 (µops)，每條普通的指令就是一般的 load / store 指令，這樣就可以用普通指令的方式來處理

6.3.1 - 分支指令的處理

• 先前提到，採用 checkpoint 的方式對 mis-prediction 的分支指令恢復 CPU 的狀態，為了減少分支指令編號分配電路的複雜度，需要限制每個 cycle 能 decode 的分支指令個數，例如每個 cycle 只能 decode 一條分支指令 (參考：4.4 - 分支預測失敗時的恢復)
• 但是，每個 cycle 從 Instruction Buffer 讀取的指令中，有可能存在多條的分支指令，需要在 decode stage 做特別的處理

  • 簡單的作法：

    • 遇到分支指令時，就不在同個 cycle decode 這條分支指令後面的指令，而是將它們 stall 到下個 cycle
    • 這個功能只需更新 Instruction Buffer 的 pointer 即可實現

    

    • 原本從 Instruction Buffer 中讀取指令：ADD → BR → SUB → BR
    • Cycle 1 只 decode ADD 和 BR，Instruction Buffer pointer + 2
    • SUB 和 BR stall 到 Cycle 2 才被 decoded，Instruction Buffer pointer + 2

  • 限制每個 cycle 最多只能 decode 一條分支指令，降低了分支指令編號分配電路的複雜度

    • 雖然效能會下降一點，但是比較容易實現，是一種折衷的方法

  • P.S. 採用 ROB 來恢復發生 mis-prediction 時 CPU 的狀態，就不再需要分支指令編號分配電路了，因此也不用限制每個 cycle 最多只能 decode 一條分支指令

• 在 decode stage 還有另外一項重要的任務，就是位分支預測是否正確進行初步的檢查
  • 越早發現 mis-prediction，penalty 越小
  • 對於直接跳轉類型的指令，由於在 decode stage 就可以計算出其要跳轉的位址，因此可以在 decode stage 對這些分支指令的目標位址是否預測正確進行檢查
    • 如果發現 mis-prediction，可以直接使用正確的位址來 fetch instruction
• 分支指令在 decode stage 是無法得到實際跳轉的方向的 (除了如：jmp 這種 unconditional branch 的指令)，因此在 decode stage 無法對分支預測的方向進行檢查，需要等到後續的 pipeline stage 階段才能完成

6.3.2 - 乘累加/乘法指令的處理

• 乘法和乘累加指令在 MIPS 架構中是一種特殊的指令；指令中包含兩個 destination registers (Hi register、Low register)
  • 這兩個暫存器並不屬於通用暫存器，因此需要特別處理
• 在 superscalar CPU 中，需要對每條指令都進行 register renaming：
  • 將指令的 source registers 變為對應的 physical registers
  • 並為 destination register 分配一個 physical register
• 大部分的指令都只有一個 destination register，但這種指令確有兩個 destination registers；此外，如果直接將此乘累加/乘法指令直接加進 ROB 中，則 ROB 也需要能夠存放兩個 destination registers，增加了 ROB 的面積，但這些增加的部份大部分都是沒有被使用的，造成了資源的浪費
• 可以採用下列的兩種方式來處理：
  1. 將 Hi register、Low register 分配為 MIPS CPU 的第 33、34 個通用暫存器，這種分配過程只在 CPU 內部進行，register renaming mapping table 也同樣要支援新的通用暫存器
  2. 將乘法/乘累加指令拆成兩條指令：
     • 乘法指令：{Hi, Lo} = Rs x Rt
       • 可以拆解為如下的兩條指令：
         • Hi = Rs x Rt
         • Lo = Rs x Rt
       • 這兩條指令經過 register renaming 並寫進 ROB 中時，會佔用兩個 ROB entries
       • 實際上，這兩條指令只使用一個乘法器就足夠了，只要這個乘法操作在 pipeline 的 execution stage 計算完畢，這兩條指令就同時完成了
     • 乘累加指令：{Hi, Lo} = {Hi, Lo} + Rs x Rt
       • 需要讀取四個 source registers (Rs, Rt, Hi, Lo)，同時也有兩個 destination registers (Hi, Lo)，正好是兩倍的普通指令，則可以將乘累加指令拆分成兩條普通指令：
         • Lo = {Hi, Lo}
         • Hi = Rs x Rt
       • 在 CPU 內部，乘累加指令仍然是以一個完整的指令來完成運算，因此指令的拆分只是更有利於 register renaming，以及便於在 ROB 中的存放，每條被拆分的指令並不是單獨進行運算的
• 此外，也需要對 issue queue 做特殊的處理，將乘法指令和乘累加指令使用一個 FU (Function Unit)，這個 FU 的 issue queue 和其他的有所不同，它包含了四個 source registers、兩個 destination registers
• 在 decode stage 拆分的兩條指令，經過 register renaming 後，就要寫入 ROB 和 issue queue 中 (i.e. Dispatch)，此時：
  • 寫進 ROB 中依舊是以兩條指令的方式寫入，佔據 ROB 兩個 entries
  • 寫進 issue queue 時則是將兩條指令進行融合 (fusion)，這兩條指令在 issue queue 中又變為了一條完整的乘累加或乘法指令，這樣就能夠保證 FU 在執行時，能夠執行一個完整的乘累加或乘法指令
• 在 N-way 的 superscalar CPU 中，每個 cycle 可以 decode 和 register rename N 條指令，但如果 decode 的 N 條指令中包含乘法和乘累加指令，那麼就會 decode 出 > N 條的指令，register renaming 不可能特別為了極少出現的情況而浪費其硬體面積，此問題可以透過下列兩種方法來解決：

  1. 在 decode stage 和 register renaming stage 新增一個 buffer，暫存 decode stage 所產生的指令；在 register renaming stage，每個 cycle 都從此 buffer 讀取指令來處理即可

     • 指令經過 decode 後會得到很多的資訊，例如 pipeline 的控制訊號等，導致這個 buffer 需要的 bits 數會很大，在一定程度上增加了硬體的面積

  2. 限制每個 cycle decode 的指令數，一旦在 decode stage 發現乘累加指令 (e.g. MADD 指令，會被拆分為 MADD1 及 MADD2 指令)，那麼只有 MADD1 以及在其之前的指令可以進行 decode，MADD2 以及在其之後的指令需要等到下個 cycle 才可以被 decoded

     

     • Cycle 1：ADD、MADD1 (MADD 被拆分，因此MADD2 必須等待)
     • Cycle 2：MADD2、SUB、MSUB1 (MSUB 被拆分，因此MSUB2 必須等待)
     • Cycle 3：MSUB2
     • 這樣的作法雖然會降低 CPU 的性能，但考慮到乘累加指令的使用頻率並不高，這種方式易於實現，因此是一種可以接受的折衷方案

6.3.3 - 前/後變址指令的處理

• ARM 指令集中還有一種前/後變址 (pre-index/post-index) 指令，能夠在一條指令中完成兩個任務
  • 例如：ldr $r2, [$r1, #4]!
    • Load mem[$r1 + 4] to $r2
    • $r1 = $r1 + 4
  • 相當於此 load 指令有兩個 destination registers，會給 register renaming 以及後續的過程帶來麻煩
  • 因此在 superscalar CPU 實現時，仍舊會在 decode stage 將這條 load 指令，拆成兩條普通的指令：
    • ldr $r2, [$r1, #4]
    • add $r1, $r1, 4
  • 經過拆分後，一樣會導致在 decode stage 得到的指令個數 > N 條的指令，可以參考 6.3.2 節的解決方法

6.3.4 - LDM/STM 指令的處理

• ARM LDM/STM 指令：
  • LDM/STM <Rn>{!}, <register list>
    • STM：將多個暫存器的值，存到記憶體的一段連續位址
    • LTM：將記憶體一段連續位址的值，載入到多個暫存器
  • 例如：ldm $r5!, {$r0 ~ $r3}

    • 這條指令在 superscalar CPU 內部中，會被拆成四條普通的 load 指令和一條普通的 add 指令

      

6.3.5 - 條件執行指令的處理

• ARM 的條件執行指令，會檢查 CPSR 的值決定該條指令是否執行；在 ARM CPU 中，本質就是將 CPSR 也當作一個 source / destination registers 來看待

  • 當一條指令會更新 CPSR 時，CPSR 就會被當作為一個 destination register
    • E.g. subs 指令
  • 當一條指令需要條件執行時，CPSR 就會被當作為一個 source register
    • E.g. addeq 指令

  

• 對於 out-of-order CPU 來說，由於指令是亂序執行的，在條件執行指令被執行的當下，CPSR 的值有可能不是最新的；如果不加以處理，就會發生錯誤，例如：

  

  • inst4 被提前到 inst2 之前執行並更新了 CPSR，那麼當 inst2 和 inst3 執行並讀取 CPSR 時，就會錯誤的使用到 inst4 所更新的狀態了
  • inst6 被提前到 inst4 之前執行，此時讀取的 CPSR 值內容有可能是來自 inst1，而不是 intn4

• 因此，當一條指令要更新 CPSR 時 (e.g. 上述範例中的 inst1 和 inst4)，需要使用一個新的 CPSR 來保存這條指令的狀態，並給這個 CPSR 一個新的名字；與之對應的指令 (e.g. 上述範例中的 inst2, inst3 與 inst5, inst6)，都會使用新的 CPSR 來作為其 source register

  • 透過 register renaming 的方法，就可以消除 ARM CPU 中條件執行指令所帶來的問題

• 分支指令的目標位址可以分為兩種：
  • 直接跳轉 (direct)：
    • 對於直接跳轉指令 (e.g. RISC-V 的 beq、jal、lui 指令)，它的跳轉 offset 是以 immediate value 的方式 encode 在 opcode 中 (有可能是 PC-relative，也有可能不是)，所以它的目標位址是固定的，只要記錄這條分支指令目標位址即可
    • 當再次遇到這條分支指令時，如果分支預測結果是 taken，那麼目標位址就可以直接使用先前所記錄的值
  • 間接跳轉 (indirect)：
    • 對於間接跳轉指令 (e.g. RISC-V 的 jalr 指令)，由於它的目標位址來自於暫存器，而暫存器的值是有可能一直變化的，所以對間接跳轉指令來說，要預測目標位址並不是一件容易的事情
    • 然而慶幸的是，程式中大部份的間接跳轉指令都是用來呼叫函式的，也就是 call 和 return；這種目標位址是有規律的，因此可以對其進行預測

4.3.1 - 直接跳轉類型的分支預測

• 對於直接跳轉類型的分支指令 (假設是 PC-relative)，其目標位址有兩種情況：

  1. 當分支指令 not taken 時：
     • 目標位址 = 當前分支指令的 PC 值 + sizeof(fetch group)
       • e.g. PC + 4
  2. 當分支指令 taken 時：
     • 目標位址 = 當前分支指令的 PC 值 + signed extended offset

• e.g. PC + offset

• 由於直接跳轉的分支指令，其跳轉的 offset 以 immediate value 的方式 encode 在 opcode 中的，所以 offset 是不會發生變化的，因此對於此類型的指令進行分支預測是很容易的

  • 只需使用一個表格，記錄下每條分支指令的目標位址即可；當一條分支指令執行且預測為 taken 時，直接查詢該表格即可得知該分支指令的目標位址

• 此表格也就是所謂的 BTB (Branch Target Buffer)，本質上就是一種 cache，使用 PC 值的一部分作為 index，PC 值的另外一部份作為 tag (i.e. partial-tag)

  

  • BTB 中存放多條的 BTA (Branch Target Address)
  • 因為 index 部份相同的分支指令會 index BTB 中同一條 BTA，因此還需要使用 tag 來判斷是否 hit 或 miss
  • 同樣的，由於 BTB 大小有限，當發生 conflict 時，就需要將原本的 BTA 給 evict 出去，然後將新的 BTA 寫入 BTB

• BTB 也可以採用 set-associative 的設計，當有多條 index 相同的分支指令時，可以將它們的 BTA 寫到不同的 ways 中

  

• Set-associative 的 BTB 會增加硬體設計的複雜度，使 BTB 的佔用的硬體面積變大，同時降低了 BTB 的訪問速度，因此現實的處理器中，BTB 的 way 數通常都會比較小

• 除了使用 PC 值的一部分作為 partial-tag，也可以採用其他的方法 (如：XOR) 來 encode tag，降低 tag 的 bits 數：

  

  • 此方法將 28 bits 的 PC 值，每相鄰的 4 個 bits 做 XOR，最後得到 14 bits 的 tag 值

• 一般情況下，為了最大限度的利用 BTB 有限的空間，只會將發生 taken 的分支指令的目標位址存入 BTB 中；對於 not taken 的分支指令，其目標位址就是下一條指令的位址，因此不需要特別做處理

• 當一條分支指令發生 BTB miss 或是 BTB conflict 時，可以採用以下兩種方式來處理：

  1. 停止執行：

     • 當發生 BTB miss 或是 BTB conflict 時，暫停 instruction fetch (i.e. 產生 bubbles，也就是 pipeline stall)，直到這條分支指令的目標位址被算出來為止

       

       • 在 Cycle i (fetch stage) 的時候發現分支指令的 PC，但在 BTB 中找不到對應的 BTA，發生 BTB miss，那麼就得暫停後續的 instruction fetch，直到分支指令從 I-Cache 中讀取出來並 decode (Cycle i + 2)，因此會引入兩個 bubbles，在 Cycle i + 3 才可以再根據預測目標位址 fetch 下一道指令

         • 如果對 I-Cache 的訪問需要比較多的 cycles，就會引入更多的 bubbles

       • 對於直接跳轉的分支指令，其目標位址可以在 decode stage 就得知其跳轉的 offset，此時就可以將目標位址給計算出來：

         

  2. 繼續執行：

     • 發生 BTB miss 的時候，不將 pipeline 給停下來，而是直接繼續使用下一道指令的位址來 fetch instruction (e.g. PC + 4)
     • 當最後分支指令的目標位址計算出來後，如果發現目標位址跟下一道的指令位址不同，則將所有分支指令之後的指令都從 pipeline 中給 flush 掉，並重新使用計算出來後的目標位址來 fetch instruction
     • 由於分支指令也有可能是 not taken，所以直接繼續使用下一道指令的位址來 fetch instruction，而不停下 pipeline，也是有可能是正確的
     • 但從功耗的觀點來看，這樣做是更浪費功耗的，所以如果是採用此方法，對於功耗比較敏感的設計並不是一個好的選擇

4.3.2 - 間接跳轉類型的分支預測

• 對於間接跳轉的分支指令來說，其目標位址是存在暫存器中的，且是經常變化的，所以無法透過 BTB 的方式來對目標位址進行準確的預測
• 所幸的是，大部分的間接跳轉的分支指令都是用來呼叫函式的，也就是 call 和 return；這種目標位址是有規律的，因此可以對其進行預測

1. Call 和 return 指令的分支預測：

   • 對於程式中一條 call 指令，其每次呼叫的函式都是固定的，也代表其目標位址都是固定的，因此可以透過 BTB 來對 call 指令來進行預測：

     

   • 但對於 return 指令而言，有可能會 return 到不同的目標位址

     • E.g. printf() 被不同的函式呼叫

     

   • 根據 return 指令的特點，可以設計一個暫存器，保存最近執行的 call 指令的下一條指令的位址；這個暫存器是 LIFO 的，也就符合函式呼叫和返回的特點

     • 這個暫存器的工作原理和 stack 是一樣的，稱為：RAS (Return Address Stack)

       

   • 綜合起來，可以使用 BTB 對 call 指令進行預測，而使用 RAS 對 return 指令進行預測：

     

     • 要使 RAS 能夠正確工作，需要符合下面兩個條件：
       1. 當遇到 call 指令時，需要能夠將 call 指令的 return address 寫進 RAS，而這需要識別出哪條指令是 call 指令
          • 正常狀態下，只有到了 pipeline 的 decode stage 才能得知指令是否為 call 指令
          • 但是現代處理器都需要好幾個 cycles 才能從 I-Cache 中取得指令，因此當指令達到 pipeline 的 decode stage 時，在這條指令後面已經有很多條指令進到 pipeline 內了，如果當中包含 return 指令 (e.g. 假設函式很短)，那麼這個 return 指令將無法從 RAS 中取得正確的 return address，造成分支預測失敗，降低處理器的執行效率
          • 如果能在分支預測階段 (e.g. fetch stage) 就可以得知一條指令是否為 call 指令，也就是透過 PC 值就可以知道是否為 call 指令，那麼就可以即時將 call 指令的 return address 寫進 RAS；即使 call 指令後面馬上接著一條 return 指令，這條 return 指令也可以透過 RAS 來預測正確的目標位址
          • 要實現這個功能依舊需要借助 BTB，BTB 中保存了所有發生跳轉的指令，且 call 和 return 指令總是會跳轉的，因此它們都會被保存在 BTB 中

            • 需要在 BTB 中新增一個欄位，用來標記分支指令的類型

              

            • 而後只需要透過查詢 BTB，就可以得知這條分支指令是否為一個 call / return 指令了

       2. 當預測 return 指令的目標位址時，需要能夠選擇 RAS 中的輸出作為目標位址，而不是選擇 BTB 的輸出值，因此仍需要在分支指令預測階段 (e.g. fetch stage) 就知道指令的類型
          • 使用 1. 的方法，透過 BTB 中新增的指令類型欄位，得知該分支指令是否是一個 recall 指令

   • 但如果一個 recursive 函式有很多層，導致 RAS 的空間不夠存放所有 retrun 指令的目標位址時，要如何處理?

     

     • 當 call SHR 的時候，RAS 已經沒有空間可以存放其 return address 了：

       

   • 有兩種方法可以處理這種情況：

     1. 不對 call 指令進行處理：

        • 不修改 RAS，新的 call 指令的 return address 會被直接拋棄，這樣在下一次執行 return 指令時，就一定會發生 mis-prediction
        • 除此之外，這樣的作法還要求 RAS 的 pointer 不能改變，否則後續的 return 指令都無法對應到自己的目標位址
        • 顯然這是一個較差的作法

     2. 繼續按照順序將 call 指令的 return address 寫入 RAS，最舊的 return address 會從 RAS 中被 evicted：

        

        • 這樣的方式，當要執行被 evicted 的 return address 對應的 return 指令時，勢必一定會發生 mis-prediction，但這樣的方式比 1. 要來得好的原因在其存在一定的正確性：

          

          • 針對這樣的 recursive function，其實寫入到 RAS 和被 evicted 的 return address 都是同樣的：

            

          • 這樣即使較舊的 return address 被 evicted，RAS 還是有可能給出正確的 return address

            • P.S. 這邊假設 RAS 應該是一個 circular buffer

        • 不過像這樣 RAS 都被同一個 call 指令的 return address 所佔用，是非常浪費空間的；對於連續執行的同一條 call 指令來說，其 return address 可以只保留一份，並透過新增一個 counter 來標記 call 指令被執行的次數

          • E.g. 使用一個 8 bits counter，就可以紀錄到最多 256 次的 recursive call 了

        • RAS 的 pointer 只有在執行 return 指令，counter 值減 1 後為 0 時，才會將 RAS 的 pointer 指向下一個 return address

2. 其他預測方法：

   • 對於其他 call 和 return 指令以外的間接跳轉類型的分支指令，雖然其目標位址理論上可以有很多種可能性，不過實際上只會有幾個固定的位址而已，例如：

     1 2 3 4 5 6 7

     switch (a) { case 1: /* Jump to address 1 */ case 2: /* Jump to address 2 */ case 3: /* Jump to address 3 */ ... case 9: /* Jump to address 9 */ }

     • 以這個例子為例，目標位址最多就 9 種而已 (address 1 ~ address 9)，也就有機會預測其目標位址

   • 對於間接跳轉類型的分支指令，其目標位址也可能是和過去的執行情況有關，因此可以利用基於局部歷史預測的分支預測方法中的 BHR 對目標位址進行預測：

     

     • 跟之前 2-bit saturating counter 分支預測方法唯一的差別在於將 PHT 換成了 Target Cache

• 總結：
  • 使用 BTB 對直接跳轉類型的分支指令，和 call 指令進行預測
  • 使用 RAS 對 return 指令進行預測
  • 使用 BHR + Target Cache 對其他間接跳轉類型的分支指令進行預測
• 尤其是 BTB 和 RAS，幾乎是現代 superscalar CPU 必備的元件

4.3.3 - 小結

• 預測分支指令的方向：使用 BHR (多個 BHRs 組成 BHT)、GHR 和 PHT (2-bit saturating counter)

• 預測分支指令的目標位址：使用 BTB、RAS 和 BHR + Target Cache

• 綜合到目前為止，完整的分支預測方法如下：

  

• 在 superscalar CPU 中，有很多階段都可以得到分支指令的結果，例如：

  • Fetch stage 可以得到直接跳轉分支指令的結果
  • Execution stage 可以得到間接跳轉分支指令的結果

• 在得到分支指令結果後，就可以跟分支預測是否正確做檢查，如果發生 mis-prediction，就需要將在這條分支指令之後 fetch 進 pipeline 的指令都給 flush 掉，也就會造成多個 bubbles，降低處理器的性能，i.e. mis-prediction penalty

• 此外，這些要被 flushed 的指令有可能已經更改了 pipeline 中的元件的內容 (e.g. register renaming 的 mapping table 被更新)，因此需要一個機制來恢復被 mis-prediction 更改的內容

4.4 - 分支預測失敗時的恢復

• 在 pipeline 中，有很多 stages 可以對分支預測是否正確進行檢查：

  • Decode stage：
    • 可以得到一個 PC 值對應的指令是否為分支指令，以及這條分支指令的類型
    • 如果是直接跳轉 (direct) 類型的指令，還可以在這個階段得到其目標位址
      • 例如：RISC-V 的 jal 指令，在 decode stage 就可以由 offset 得知其目標位址，如果這條指令是預測 not taken，那就代表發生 mis-prediction
    • 在 decode stage 發現預測失敗的 mis-prediction penalty 最小，可以馬上進行恢復
    • 然而，由於間接跳轉 (indirect) 類型指令的目標位址是存在暫存器中，在 decode stage 仍無法得知其目標位址，因此如果發生 mis-prediction，CPU 也沒辦法在這個 stage 取得下一個 fetch 指令的位址
      • 只能暫停 instruction fetch
  • 讀取暫存器的 stage (有可能是在 register renaming stage 之後，也有可能在 issue stage 之後，取決於 CPU 的設計)：
    • 如果此時讀到了暫存器的值，那麼就可以對間接跳轉的分支指令的目標位址進行檢查，如果發現目標位址預測錯誤，那麼就可以用正確的目標位址來 fetch instruction
      • 此時仍需在將該分支指令之後進入到 pipeline stage 的指令給 flushed 掉
        • 但這並不容易實現，因為這些指令有可能已經進到 Issue queue 中了；Issue queue 中也包含了分支指令之前的指令，這些指令不應該被 flushed，因此需要有條件的 flush 在 Issue queue 中的指令
  • Execution stage：

    • 不管是什麼類型的分支指令都可以在這個 execution stage 取得其正確的目標位址，可以對分支指令是否正確 (包含方向和目標位址) 進行檢查

    • 但此時發生 mis-prediction 的 penalty 也是最大的

    • 當發生 mis-prediction 時，所有在此分支指令之後的指令都要被 flushed 掉

      • 然而，針對 out-of-order CPU，在此分支指令之前的指令，有可能在 execution stage，也有可能還在 Issue queue 中，這些指令不應該被 flushed

    • 指令之間的順序是被記錄在 ROB (Re-Order Buffer) 中的，因此可以透過 ROB 來恢復發生 mis-prediction 時 CPU 的狀態

    • 當發生 mis-prediction 時，將此訊息記錄在此分支指令對應的 ROB entry 中，並暫停 instruction fetch；當這條分支指令在 pipeline 中變成最老的指令時，就代表在 pipeline 中，剩餘的指令都比這條分支指令還新，可以直接將整個 pipeline stage 中的指令都 flush 掉，並從正確的目標位址 fetch instruction

      

      • 缺點：
        • 需要分支指令在 pipeline 中一定時間後才能進行處理
        • 如果在此分支指令之前有一道 D-cache miss 的 load 指令，這個等待的時間就會變得非常長，i.e. mis-prediction 的 penalty 很大，降低了處理器的性能
          • 這段時間內都沒辦法 fetch 新的指令來執行
      • 優點：
        • 這種方法容易實現，是在硬體複雜度和執行效率之間一個比較折衷的方案

• 除了基於 ROB 的方法來恢復 mis-prediction 的狀態，現在很多處理器都採用了基於 Checkpoint 的方法來恢復 mis-prediction 的狀態

  • 在分支指令之後的指令更改 CPU 的狀態前，先將 CPU 的狀態保存下來，包含：
    • Register renaming 的 mapping table
    • 預測 taken 的分支指令其對應的下一條指令的 PC… etc

• 通常在分支指令進入到 register renaming stage 時，就需要保存 CPU 的狀態

• 相比於使用 ROB 的方式，使用 Checkpoint 的方式需要消耗更多的硬體資源，但是這種方式可以快速地將 CPU 的狀態給恢復，並馬上從正確的 PC 值開始 fetch instruction，因此執行效率更高

• 當發生 mis-prediction 時，只有在該分支指令之後的指令才能被 flushed，在分支指令之前的指令要保留下來，因此需要一個機制來正確地識別哪些指令處在 mis-prediction 的路徑上

  • 可以透過對每一條分支指令都分配一個編號，所有在分支指令之後的指令都會給予同一個編號，直到碰到下一個分支指令為止；該編號會被記錄在 ROB entry 中

    

    • 當發生 mis-prediction 時，就可以利用分支指令所分配到的編號，將所有在該分支指令之後的指令都 flushed 掉，而不需要等到分支指令變成 pipeline 中最老的指令

• 分支指令的編號個數決定了最多可以存在 pipeline 中分支指令的個數

  • 例如：假設一 CPU 支援最多 128 條指令在流水線中，假設每 5 條指令就有 1 個分支指令，最多會有 128 / 5 = 26 條分支指令存在 pipeline 中，也就是說需要 26 個編號，因此需要 5 個 bits (2^5 = 32) 來存放編號

• 這些編號值會被保存在一個 FIFO (tag list) 中，一旦這個 FIFO 滿了，就沒辦法再向 pipeline 中送入分支指令

  • 當 tag list 滿時，如果又 decode 出一條分支指令，就得暫停 decode stage 之前的 pipeline，直到 tag list 有空間為止
  • Tag list 中的 entries 是 in-order 的

• 其中一個設計方法：

  

  • Free tag list：用來存放還沒有被分配的編號
  • Tag list：用來存放已經被分配的編號
  • 在 decode stage 解析出一條新的分支指令時，就從 free tag list 中取得一個編號，指定給該分支指令，並編號加入 tag list 中
  • 當發生 mis-prediction 時，就可以透過這個編號來識別所有在分支指令後面的指令，並從 pipeline 中給 flushed，最後再將這些編號加回 free tag list 中

• 對於 superscalar CPU 而言，當一條分支指令發生 mis-prediction 時並需將在其之後的指令都從 pipeline 中給 flush 掉，實際上包含了以下兩個部份：

  • 在 issue stage 前的指令：
    • 在 issue stage 前，指令都還是 in-order 的，因此當在 issue stage 中發現一條 mis-prediction 的分支指令時，只需將直接將在 issue stage 前的指令給 flush 掉即可
      • 可以在 1 個 cycle 內完成
  • 在 issue stage 及 issue stage 之後的指令：
    • 從 issue stage 開始，指令就是 out-of-order 了，一部分的指令可能是在 mis-prediction 的路徑上的，因此需要透過上述的 tag list 的方式，找出在 mis-prediction 分支指令之後的指令並從 pipeline 中給 flush 掉
      • 在 1 個 cycle 內無法完成
    • Flush ROB 中的指令：

      • ROB 中有每個指令的編號，因此可以透過 tag list 找出 mis-prediction 分支指令之後所有指令的編號，並透過 broadcast 的方式通知 ROB，並將對應的 ROB entry 給 invalidate：

        

        • 這無法在 1 個 cycle 內完成，因為如果想要在 1 個 cycle 內比較所有的 ROB entries (最慘的情況下)，會需要非常大的硬體面積和增加 latency
    • Flush Issue queue 中的指令：
      • 可以採用類似 ROB 的方式，將 Issue queue 中相關的指令給 flush 掉
    • Flush issue stage 之後的指令：
      • 可以採用類似 ROB 的方式，將 issue stage 之後的指令給 flush 掉
    • 其實並不一定要在 1 個 cycle 內將相關指令給 flushed 掉，因為在 execution stage 發現 mis-prediction 後並開始從正確的位址開始 fetch instructions，這些新指令需要經過好幾個 stages 才會進到 dispatch stage (到了 dispatch stage 才需要使用到 ROB 和 Issue queue)，因此只要在這些新的指令進到 dispatch stage 前來得及將相關的指令給 flush 掉即可，就不需要 stall pipeline 了
    • 因此，一個折衷的方式就是每個 cycle 只從 tag list 中 broadcast 一個或幾個編號，這樣當編號個數不是很多時 (大部分情況是如此)，使用幾個 cycles 就可以將相關的指令給 flush 掉，也就不用 stall pipeline
    • 只有在少數的情況下，當編號個數很多時，才需要花費多個 cycles 來 flush 相關的指令
      • 新的指令在進入 issue stage 前，必須等待所有在 mis-prediction 路徑上的指令都被 flushed 並恢復 CPU 狀態後，才可以進入 issue stage

• 在把 pipeline 中相關的指令給 flush 掉後，就可以使用 Checkpoint 的方式回覆 CPU 的狀態

  • 主要是將 register renaming 的 mapping table 給恢復

• 什麼時候對分支指令分配一個編號呢?

  • Fetch stage：
    • Fetch stage 只有 PC 值，對於一個指令是否為分支指令只能用推測的方式，因此此時分配編號並不合適
  • Decode stage：
    • 只有在 decode stage 才可以真正判斷一條指令是否為分支指令，此時就可以對分支指令分配一個編號

• 由於 superscalar 一個 cycle 內會解析多個分支指令，因此最差的情況就是 N-ways 的 CPU，會有 N 條分支指令，也就代表 free tag list 和 tag list 都需要在一個 cycle 內提供 N 個編號，也就需要使用 multi-port FIFO 的設計，對硬體面積和功耗會有所影響

  • 實際上，絕大部分情況下，每個 cycle decode 的指令最多只會有一、兩條分支指令，如果使用 multi-port FIFO 的設計，大部分的 ports 都會是閒置狀態的，因此實際上並不會採用 multi-port FIFO 的設計
  • 一種折衷的作法是限制每個 cycle 最多只能處理一條分支指令
    • 如果在 decode stage 讀出來的 N 條指令中，有超過一條的分支指令，那麼只會從 free tag list 拿出一個編號，第二條以後的分支指令都必須 stall 到下一個 cycle 才能被處理
    • 對大部分的程式來說分支指令都並不密集，因此這種方法不會對性能造成太大的負面影響

• 在 execution stage 檢查分支指令預測正確性時，要如何得知該分支指令之前所預測的值?

  • 可以將每條分支指令的預測值，存在 PTAB (Prediction Target Address Buffer) 中，且此分支指令在 PTAB 的 index 會隨著分支指令在 pipeline 中流動，等到分支指令進入 execution stage 時就可以用來跟實際的跳轉結果做比較

    • 在實際的處理器中，可以優化為只存預測為 taken 的分支指令預測值即可

    

  • 分支指令預測值與實際的結果有以下的可能性：

    • 實際結果為 not taken，並在 PTAB 中沒有找到對應的內容 (i.e. not taken) ⇒ 預測正確
    • 實際結果為 not taken，但在 PTAB 中有找到對應的內容 (i.e. taken) ⇒ 預測錯誤，需要使用 Next PC 來作為正確的目標位址
    • 實際結果為 taken，但在 PTAB 中沒有找到對應的內容 (i.e. not taken) ⇒ 預測錯誤，需要使用實際的目標位址
    • 實際結果為 taken，但在 PTAB 中有找到對應的內容 (i.e. taken) ⇒ 預測方向正確，但此時仍需要比較 predict address 是否與實際的目標位址相符：
      • 相符：預測正確
      • 不相符：需使用實際的目標位址

  • 寫 PTAB 的過程可以在 fetch stage 完成，只要在 fetch stage 預測到一條發生跳轉的分支指令，就可以將其寫進 PTAB 中

4.5 - 超標量處理器的分支預測

• 對於 superscalar CPU，在 fetch stage 給一個 PC 值，可以透過 I-Cache 同時取出多條的指令並組成 fetch group，CPU 亦會根據 fetch group 中的指令個數，調整下一個 cycle instruction fetch 的位址，因此 superscalar CPU 的 instruction fetch PC 值並不會是連續的，且每次送到 I-Cache 的 fetch address 也只會是 fetch group 中第一條指令的位址而已
  • 因此，如果只是根據第一條指令的位址做分支預測是不夠的
• 如果對 instruction fetch 的位址進行限制，例如針對一個 4-way issue 的 CPU，每個 cycle fetch 的 instructions 都是 4-word aligned (共 4 條指令) 的，那麼就可以使用 fetch group 中所有指令共同的部份：PC[31:4] 來做 branch predict；對於 branch predictor 而言，它也只需要記下每個 4-word aligned 的指令中，第一條預測跳轉分支指令資訊即可

  • 在大多數的情況下，4-word aligned 的指令只會有一條分支指令

  • 不過仍需在 BTB 中記錄下該分支指令在這 4 條指令中的 index：

    

    • 此範例中，分支指令的 index 在這四條指令的 index 為 01，但此 cycle 的 instruction fetch 的 PC 值在 10，因此在進行分支預測時，由於分支指令並不在 instruction fetch 的範圍內，因此不會使用其預測值

  • 如果這 4-word aligned 的指令中，包含超過一條分支指令，那麼這些分支指令就會忽相干擾，影響分支預測的準確度，不過在大部分的程式中，分支指令出現的頻率並不會這麼高

• 但實際上，每個 cycle fetch 的 instructions 是可以不侷限於 N-word aligned 的 (參考：2.4 - 超標量處理器的取指令)
  • 如一個 4-way issue 的 superscalar CPU，其每個 cycle fetch 的 instructions 是可以不侷限於 4-word aligned 的範圍內的，那麼要達到最理想的結果，就需要對一個 cycle 內 fetch group 內的指令都進行分支預測，如果當中存在 taken 的分支指令，那麼變需要並將第一個預測為 taken 的分支指令目標位址作為下一個 cycle 的 PC 值
  • 實務上，要在一個 cycle 對 fetch group 內的指令都進行分支預測是不可接受的，因為這代表需要 BTB 支援 multi-port (參考：2.3.1 - True Multi-port)，才能在一個 cycle 內同時讀出多條指令的目標位址；即使採用 interleaving (參考：2.3.3 - Multi-banking ) 的方式來避免使用 multi-port，但考慮到在使用過程中，最多只會使用一個 port 的值 (i.e. 第一個預測為 taken 的分支指令)，所以這種方式對硬體使用效率是非常低的
• 如果可以在分支指令的方向預測完畢後，再進行目標位址的預測，就可以避免 multi-port BTB 使用的需求
  • 但是這樣變成分支方向和目標位址的預測是 serialized 的，有可能就沒辦法在一個 cycle 內完成，也就無法”連續地”預測每個 cycle 的 instruction fetch 的位址
• 不過大部分的分支指令都是直接跳轉類型的，其分支指令的目標位址是可以很快地被計算出來；對於此類的指令，其實並不需要進行目標位址的預測，而是直接在 instruction fetch 的階段，就馬上進行目標位址的計算
  • 雖然不一定能在一個 cycle 內完成分支預測 (還有分支方向需預測)，但不一定會比 serialized 的方式來得慢，而且還可以取得分支指令正確的目標位址
  • 要實現此功能，必須在指令進入 I-Cache 之前，就先進行 pre-decode，並馬上識別出分支指令，從而進行快速的分支位址的計算
  • 但對於間接跳轉類型的指令 (除了 return 指令外)，就無法採用此方式了
• 對於 superscalar CPU，由於需要一個 cycle 內對多條指令進行方向預測，從而找到第一條 taken 的分支指令：
  • 基於局部歷史的分支預測：
    • 需要 PHT 和 BHT 都支援 multi-port，可以透過 interleaving 的方式來避免 multi-port 的設計 (參考：2.3.3 - Multi-banking )

      • 例如將 PHT 改成 interleaving：

        

        • Addr[1:0] 用來作為 multi-bank 的 index
        • Addr[6:2] 用來作為 bank 中 (sub-)PHT 的 index
  • 基於全局歷史的分支預測：
    • 並無法簡單地將 PHT 改成 multi-port 即可，因為多條指令對應的 GHT 有可能是不同的，需要進行特殊的處理
• Interleaving 在 superscalar CPU 中是經常被使用的，大部分需要 multi-port 設計的元件，如 ROB、Issue Queue、Instruction Buffer… etc，都可以採用 interleaving 的方式來設計

• 分支預測和 Cache 左右著 CPU 的效能，對於 superscalar CPU 來說，準確度高的分支預測更為重要

• 在一般的 RISC 指令集中，分支指令包含兩個要素：

  1. 方向：
     • 分支指令的方向只有兩種：跳轉 (taken)，或是不跳轉 (not taken)
     • 有些跳轉指令是無條件執行的 (e.g. jmp 指令)，有些跳轉指令則是需要根據指令中攜帶的條件是否成立來決定是否發生跳轉 (e.g. beq 指令)
  2. 目標位址：
     • 對於一般的 RISC 指令集，目標位址在指令中有兩種形式：
       • 直接跳轉 (direct)：
         • 目標位址 = 當前分支指令 (或分支指令的下一條指令) 的 PC 值 + immediate PC offset
         • 由於指令通常只有 32/64 bits，因此 immediate PC offset 的值範圍也就有限，因此也限制了直接跳轉能夠跳轉的範圍
         • 因為 immediate PC offset 值是 encode 在分支指令中，因此在 pipeline 的 decode stage 就可以直接將 immediate PC offset 給解析出來，因此這種類型的指令是很容易進行分支預測的
         • 這種跳轉指令的執行效能也比較好
       • 間接跳轉 (indirect)：
         • 目標位址是來自於 register 的內容，由於 register 是 32/64 bits，因此可以跳轉到任何位址
         • 由於跳轉位址來自於 register，因此此類的分支指令的目標位址需要等待一段時間才能獲得 (e.g. 要等到 pipeline 的 execute stage)
           • 在確認目標位址前進到 pipeline 的指令，有可能都會是無效的 (if taken)，因此增大了 mis-prediction penalty
         • 且由於 register 的內容是會動態變化的，因此這類的分支指令很難對目標位址進行預測
           • 不過慶幸的是，這類指令通常都是 call 或是 return 類型的指令，這類指令都有很強的規律性，是容易被預測的

• MIPS R3000 只使用了 5 級的 pipeline，在第二個階段的 decode stage，就可以得到分支指令跳轉的目標位址，即使發生了跳轉 (taken)，也只需要丟棄一道仍在 fetch stage 的指令，misprediction penalty 並不高

  

  • MIPS CPU 甚至為了減少這一個 cycle 的浪費，還會特別找一條一定會被執行，不相關的指令放在分支指令之後；不論分支是否跳轉或不跳轉，該指令都一定會被執行
    • 分支指令後面的那個位置就被 MIPS 稱為分支延遲槽 (branch delay slot)，需要透過 compiler 或 programmer 找到一條不相關一定會被執行的指令，將其放置分支延遲槽中
    • 但當 CPU 的並行度提高，以及 pipeline 的加深，當發生 misprediction 的時候，pipeline 中已經有很多指令都錯誤地進到 pipeline 裡了；這些指令都必須被拋棄，此時技使使用 branch delay slot，也很難得到滿意的結果，因為已經無法從分支指令之前的程序中找到這麼多不相關的指令了

• 對於 superscalar CPU，要進行分支預測，首先要從 I-Cache 取出的指令組 (fetch group) 中，判斷哪些指令是分支指令：

  

  • 最容易的辦法是將 fetch group 中的指令，從 I-Cache 取出後，進行快速的 decode

    

    • 從 I-Cache 取出指令後，只需辨別目前的指令是否為一個分支指令，如果是的話，就可以直接將分支指令對應的 PC 值送到 branch predictor 中，就可以對分支指令進行預測了
    • 然而，當 cycle time 比較短的時候，I-Cache 的訪問可能需要好幾個 cycles 才能完成 (e.g. 可能需要訪問 L2 Cache、memory)；在這些 cycles 內由於無法獲得準確的預測結果，只能照順序讀取指令 (i.e. not taken)，降低的分支預測的準確度，進而影響 CPU 的效能
    • 此外，在指令從 I-Cache 讀出來後，fast decode 和 branch predict 是放在同一個 cycle 內的，會嚴重影響 CPU 的 cycle time
    • 為了解決以上的問題，可以在指令從 L2 Cache 寫入 I-Cache 之前進行快速的 decode，也就是 pre-decode，然後將指令是否是分支指令的資訊和指令一起寫進 I-Cache 中；雖然這樣會增加 I-Cache 的面積，但可以省略 fast decode 的電路，在一定程度上緩解 對 CPU cycle time 的影響
      • 但是 instruction fetch 到得到分支指令的預測結果這段的間隔時間還是過長的，無法透過以上的方式來解決

• 在 pipeline 中，分支預測越靠前面幾個 stages 是越好的，如果指令從 I-Cache 讀出後才進行分支預測，那麼由於 I-Cache 的訪問可能需要多於 1 個 cycle 才能完成，可能經過了好幾個 pipeline stages 了才能得到分支指令預測的結果，在此期間已經有很多的指令進入到了 pipeline，但如果發生 misprediction，這段期間進入到 pipeline 的指令都必須被 flushed，降低了CPU 的執行效能

  • 因此分支預測，最好是可以發生在一得到 instruction fetch 的 PC 值時，在 instruction fetch 的同時進行分支預測，這樣在下一個 cycle 的時候，根據分支預測的結果來 fetch instruction
    • 在同一個 process 內，PC 的 VA 值都是固定的，因此可以直接拿 PC 值來進行預測
    • 當發生 context-switch 時，需要將 branch predictor 的內容給清空，才能保證不同 processes 間的分支預測不會互相影響
      • 如果有使用 ASID，那麼可以將 ASID 和 PC 值一起進行分支預測，如此在發生 context-switch 時，就不用清空 branch predictor

• 在一得到 instruction fetch 的 PC 值時，根據 PC 值來預測當下 cycle 的 instruction fetch 中是否存在分支指令，以及分支指令的方向和目標位址：

  

• 分支預測是影響 CPU 效能的關鍵因素之一，需要在硬體面積及功耗、預測準確度和 latency 之間找到一個平衡點

4.2 - 分支指令的方向預測

• 最簡單的動態預測方法就是直接使用上一次分支的結果 (last-outcome prediction)：

  

  • 相比於靜態分支預測，使用 last-outcome prediction 在不同的情況下可以獲得更優的結果；然而當分支指令發生變化時，其準確度有可能比靜態分支預測還差：

    

    • 當分支每次都發生變化時，此方法的分支預測失敗率是 ~100%

• 因此，last-outcome prediction 的準確度在現在處理器是無法被接受的，因此也沒有被現代處理器所採納

• 現代處理器用得最廣泛的分支預測方法，都是基於 2-bit saturating counter 為基礎而衍生出的不同實做

4.2.1 - 基於兩位飽和計數器的分支預測

• 2-bit saturating counter 分支預測方法不會馬上使用分支指令上一次的結果，而是根據一條分支指令前兩次的執行結果來預測本次分支的方向，通常有四種 FSM 狀態：

  • Strongly taken (編碼：11)：Counter 處於飽和狀態，預測此次分支會發生跳轉 (taken)

  • Weakly taken (編碼：10)：Counter 不處於飽和狀態，預測此次分支會發生跳轉 (taken)

  • Weakly not taken (編碼：01)：Counter 不處於飽和狀態，預測只次分支不會發生跳轉 (not taken)

  • Strongly not taken (編碼：00)：Counter 處於飽和狀態，預測此次分支不會發生跳轉 (not taken)

  

  • 當分支指令總是朝著一個方向的時候，FSM 就會處於飽和狀態，此時預測的正確率會比較高
  • 當分支指令的方向總是發生變化時，FSM 無法處於飽和狀態，此時預測的準確率比較低

• 其他 2-bit saturating counter 的實現方式：

  

  • 上：Weakly not taken 只要分支指令一跳轉 (taken)，就將 FSM 設為 Strongly taken
  • 下：Weakly taken 只要分支指令一不跳轉 (not taken)，就將 FSM 設為 Strongly not taken
  • 不過實務上，這樣的設計並不會讓 benchmark 結果變得比較好，因此這種兩實做並沒有很常使用

• 一般來說，都是使用 Strongly not taken 或 Weakly not taken 作為 FSM 的起始狀態

• 可以使用 Gray code 將 FSM 的狀態編碼，保證在狀態轉換時，只有一個 bit 會發生變化

• 考慮以下 for-loop：

  1 2 3

  for (i = 0; i < m; i++) { ... }

  • 假設初始狀態是在 Weakly not taken：
    • i = 0：Weakly not taken ⇒ 預測失敗，FSM 切換到 Weakly taken
    • i = 1：Weakly taken ⇒ 預測b，FSM 切換到 Strongly taken
    • i = 2 ~ i = m - 1：Strongly taken ⇒ 預測成功，FSM 保持在 Strongly taken
    • i = m，離開迴圈：Strongly ⇒ 預測失敗，FSM 切換到 Weakly taken
  • 整個迴圈失敗的比例：2 / m，如果 m 很大，那麼這樣的預測結果就是可以接受的

• 對於絕大數的程式來說，使用 2-bit saturating counter 就可以獲得比較高的準確率了；增加 counter 的 bits 數 (e.g. 使用 3-bit saturating counter)，會讓硬體的複雜度上升和更多的空間需求，這些額外的開銷所帶來的負面影響可能大於實際可以獲得預測準確度的提高，因此主流 CPU 都是使用 2-bit saturating counter

• 分支預測都是基於 PC 值為基礎運行的，正常來說，每一個 PC 值都應該對應一個 2-bit 的 saturating counter，因此 32-bit CPU 就需要 2^30 * 2 個 bits (假設 PC 值都是 32 bits，所以最低 2 bits 不考慮)，顯然實務上不可能使用一個這麼大的硬體空間

• 由於不是所有指令都是分支指令，因此一般都使用以下的方法來紀錄 2-bit saturating counters：

  

  • PHT (Pattern History Table) 是一個表格，用來存放每個 k-bit PC 值所對應的 2-bit saturating counters
  • 這個 PHT 總共儲存了 2^k 個 saturating counters，因此 PHT 的大小為：2^k * 2 bits；PHT entry 是透過 k-bit 的 PC 來索引的
  • 使用 k-bit PC 來索引 PHT，必然就導致了有相同 k-bit 的 PC 都會索引到同一個 saturating counter，如果這些有相同 k-bit 的 PC 對應到的指令不只一條是分支指令，那麼這些分支指令彼此間就會相互影響，也就是造成 aliasing 的問題
    • Neutral aliasing：多條 aliasing 的指令跳轉的方向都相同
    • Destructive aliasing：多條 aliasing 的指令跳轉方向不相同
  • 雖然這樣的實做方法會有 aliasing 的問題，但考量到這樣的方法實做起來比較簡單，且佔用的硬體空間也不大，因此輕微的預測準確度下降也是可以接受的

• PHT 的大小對分支預測準確度的影響：

  

  • PHT 的大小是 2 KB，準確度已經達到 93% 以上
    • k = log(2 * 1024 * 8 bits) / 2 bits = 13，也就是使用 PC 中的 13 bits 來索引 PHT entry

• 避免 PHT aliasing 的方法：

  • 將 PC 做 hash 後，再拿 k-bit 的 hash 值去索引 PHT entry：

    

  • hash 的實做方法可以很簡單，例如使用普通的 XOR 運算，或是設計得更複雜以取得更好的 hash 結果

• 2-bit saturating counters 需要根據跳轉指令的結果，更新對應的 PHT entry，有三個時間點可以更新 PHT：

  1. 在 Fetch stage，分支預測時，更新 PHT entry
  2. 在 Execution stage，分支指令的方向被實際運算出來時，更新 PHT entry
  3. 在 Commit stage，當分支指令要離開 pipeline 時，更新 PHT entry

• 第一種方法，在 Fetch stage 根據分支預測的結果，直接更新 PHT entry，是否不可靠的，因為分支預測的結果有可能是錯誤的

• 第二、第三種方法，由於 superscalar CPU 的 pipeline stages 都很深，且每個 cycles 會執行多條指令，導致一條分支指令可能在 PHT entry 被更新前就被 fetched 過很多次了 (e.g. 很小的 for-loop body)，這條分支指令在進行分支預測時，就沒有利用到它之前被執行的分支結果

  • 但考量到 saturating counter 的特性，只要 saturating counter 處於飽和的狀態，其分支預測的結果就會比較固定，即使更新 PHT entry 的時間點較晚，也不會改變 saturating counter 的狀態，所以對分支預測準確度並不會造成太大的負面影響
  • 此外，雖然第二種在 Execution stage 更新 PHT entry 比第三種在 Commit stage 才更新 PHT entry 的時間點早，但在 out-of-order CPU，即使在 Execution stage 得到分支指令的結果，也不能保證它一定會被執行 (有可能這個分支指令是在 mis-prediction 的路徑上)，有可能會被 flushed 掉，因此不能利用這個分支指令在 Execution stage 的結果來更新 PHT entry
  • 所以，只有第三種在 Commit stage 更新 PHT entry 的方式，才是萬無一失的

• 這種基於 2-bit saturating counter 的分支預測方法，其預測準確度有一定的上限，很難達到 98% 以上的準確度，因此現代處理器都不會直接使用此方法

4.2.2 - 基於局部歷史的分支預測

• 針對以下的情境，2-bit saturating counter 並不會有比較高的準確度：

    ![image.png](image%2011.png)
  

  • 針對這樣的情境，2-bit saturating counter 並沒辦法達到飽和的狀態，始終在 Weakly not taken 和 Weakly taken 之間做切換
    • 假設 FSM 的起始狀態是 Weakly not taken，此時的分支預測準確率是 0%
    • 假設 FSM 的起始狀態是 Strongly not taken，此時的分支預測準確率是 50%
  • 不論是哪一種情況，這樣的分支預測準確度都是無法接受的

• 可以使用 BHR (Branch History Register) 來紀錄一條分支指令過去的歷史狀態，這種預測方法稱為基於局部歷史 (Local History) 的預測方法

  • 透過將每次分支的結果 (1: Taken，0: Not taken)，從右 shift 進 BHR，就可以紀錄這條分支指令的歷史狀態了

  

  • 一個寬為 n 位的 BHR 可以紀錄一條分支指令過去 n 次的分支預測結果 (taken or not taken)，並使用 BHR 去索引 PHT 的 entry
  • PHT 仍是一個表格，大小為 2^n * 2 bits，每個 PHT entry 都存儲了 saturating counter 的值
    • FSM Update Logic 硬體仍是獨立於 PHT 之外，每個 PHT entry 都是透過這個 FSM Update Logic 來更新其 counter 值
  • 當一條分支指令得到其分支結果時，就將對應 PHT entry 的 counter 值讀出來，並根據其分支結果進行更新，然後將結果寫回 PHT entry

• 假設有一條分支指令，其 BHR 的寬度為 2 bits，也就是這條分支指令的前 2 次分支歷史結果會被紀錄在 BHR 中：

  • BHR 的值總共四種可能：

    • 00：此分支指令前兩次都是 not taken
    • 01：此分支指令前兩次分別是：not taken → taken
    • 10：此分支指令前兩次分別是：taken → not taken
    • 11：此分支指令前兩次都是 taken

  • 假設這條分支指令有如下的執行順序：taken → not taken → taken → not taken → taken…，則此 BHR 的值依執行順序分別會是 (從右 shift 進 BHR，BHR 的初始值為 00)：

    • taken：01
    • not taken：10
    • taken：01
    • not taken：10
      • 可以統整出：
        • 當 BHR 的值為 01 時，下次 shift 進 BHR 的值一定會是 0，i.e. 下次是 not taken
        • 當 BHR 的值為 10 時，下次 shift 進 BHR 的值一定會是 1，i.e. 下次是 taken
      • BHR 值：10 → 對應到 PHT entry 2，此 PHT entry 的 saturating counter 會是 Strongly taken 的飽和狀態 (因為每次都是 taken)
      • BHR 值：01 → 對應到 PHT entry 1，此 PHT entry 的 saturating counter 會是 Strong not taken 的飽和狀態 (因為每次都是 not taken)
      • BHR 值：00 和 11，沒有用到，因此 PHT entry 0，entry 3 也就不會被使用到，也就是 4 個 PHT entries 中，只有 2 個 entries 是有起作用的

  • 假設執行順序是：TTNNTTNNTTNN…，BTN 的序列值會是：110011001100

    • 11 之後必接 0
    • 10 之後必接 0
    • 00 之後必接 1
    • 01 之後必接 1
    • 也就是說，序列中每 2 位數後跟著的值都是唯一的，稱這個序列的循環週期為 2
      • entry 3、entry 2 最終會是 Strongly not taken
      • entry 0、entry 1 最終會是 Strongly taken

  • 對於一個最小循環週期為 n 的序列來說，任何大於 n 的值都可以作為這個序列的循環週期

    • 例如：110011001100
      • n = 2：
        • 11 之後必接 0
        • 10 之後必接 0
        • 00 之後必接 1
        • 01 之後必接 1
      • n = 3：
        • 110 之後必接 0，與 n = 2，10 相同
        • 100 之後必接 1，與 n = 2，00 相同
        • 001 之後必接 1，與 n = 2，01 相同
        • 011 之後必接 0，與 n = 2，11 相同

  • 如果一個序列中，連續相同的 taken 或 not taken 最多有 p 個，那麼這個序列的循環週期就為 p

  • 例如，假設執行順序是：TTTNTTTN…，BTN 的序列值會是：11101110，其循環週期為 3

    

• 更寬的 BNT：

  • 優點：
    • 可以紀錄到分支指令越多的歷史分支結果，提高分支預測的準確度
  • 缺點：
    • 要讓此 BNT 達到飽和，需要更長的訓練時間；在達到飽和狀態前，分支預測的準確度是比較低的
    • 需要的 PHT entries 數也更多，佔用硬體空間

• 將所有分支指令的 BHR 組合起來稱作 BHT (Branch History (Register) Table)

• 在實務中，BHT 不可能照顧到所有的 PC (一個 n 位的 BHR，需要的 PHT 空間為 2^n * 2)

• 一般都是採用 k-bit PC 來索引 BHT 中的 BHR，t-bit PC 來索引 PHT，再根據 BHR (寬度為 n-bit) 的值，索引 PHT entry：

  

  • BHR = n bits
  • BHT = 2^k * n bits
  • PHT = 2^n * 2 bits
  • PHTs = (2^n * 2) * 2^t bits
  • 一般來說：t < k

• 由於使用了 PC 的一部分來索引 BHT 和 PHTs，有可能會碰到 aliasing 的問題；這些 aliased 的分支指令會使用同一個 BHR 及 PHT，彼此之間會互相影響，使分支預測的準確度下降

• 以下兩種情況會造成 PHT aliasing：

  1. 兩條分支指令的 k-bit PC 相同，因此索引到同一個 BHR，也就對應到同一個 PHT entry
  2. 兩條分支指令的 k-bit PC 不同，索引到不同的 BHR，但 BHR 的內容相同，因此對應到w同一個 PHT entry

• 為了避免上述的兩種狀況，可以將 PC 值和對應的 BHR 值進行一定的處理，使用處理後的值來索引 PHT：

  

  • 將 BHR 的值和分支指令的 PC 值的一部分拼接，用得到的新的值索引 PHT 來得到分支預測結果
    • 這種方法將分支指令的 PC 值也考慮進來，一定程度上避免了 PHT aliasing 的問題，因此可以提高分支預測的準確度

• 上述 BHR 的值和分支指令的 PC 值的拼接方法其實效果並不是很理想，還有其他的方式可以對 BHR 的值和分支指令的 PC 值做處理，獲得的效果會更好一點，例如使用 XOR：

  

• 現實處理器會使用更複雜的演算法，盡量避免 PHT aliasing 的情況發生

• 現實情況中，當一條分支指令的循環週期太大時 (e.g. 比較大的 for-loop body)，就需要一個寬度很大的 BHR，這會導致過長的訓練時間，並且 PHT 也會隨之佔用更大的硬體空間，這在現實處理器是無法接受的

  • 現實處理器只能用有限寬度的 BHR，寬度不夠，就會導致就算是很有規律的分支指令 (e.g. 999 次的 taken → 1 次的 not taken)，也無法獲得最完美的分支預測結果

• 基於 2-bit saturating counter 的分支預測方法可以稱為基於局部歷史 (Local History) 的分支預測，因為都是根據同一條分支指令過去的執行結果來預測，並沒有考量到其他條分支指令的執行結果對預測結果造成的影響

  • 有時候一條分支指令的執行結果並不取決於自身在過去的執行結果，而是和它前面的分支指令的結果息息相關，因此需要採用基於全局歷史 (Global History) 的分支預測方法

4.2.3 - 基於全局歷史的分支預測

• 當對一條分支指令進行分支預測時，如果同時考慮到它前面分支指令的執行結果，則稱這種分支預測方法為：基於全局歷史 (Global History) 的分支預測

• 一條分支指令什麼時候會和它前面的分支指令的執行結果相關呢?

  1 2 3 4 5 6 7

  if (aa == 2) // b1 aa = 0; if (bb == 2) // b2 bb = 0; if (aa != bb) { // b3 .... }

  • 如果 b1 和 b2 都 taken 了，b3 一定是 not taken
  • 只依靠 b3 分支指令的預測，是一定不會發現這樣的規律的
  • 因此需要在預測 b3 時，將前面 b2 和 b1 的執行結果也考慮進去，這就是基於全局歷史 (Global History) 的分支預測

• 基於全局歷史分支預測方法也需要一個暫存器，用來記錄程式中所有分支指令在過去的執行結果，這個暫存器稱為：GHR (Global History Register)

• 現實中，GHR 不可能記錄所有分支指令的執行結果，因為 GHR 的寬度是不可能無限大的，因此一般都是使用一個有限 bits 的 GHR，來紀錄最近分支指令的執行結果

  • 每當執行一條分支指令時，就將其分支結果 (1: Taken，0: Not taken)，從右 shift 進 GHR

• 使用基於全局歷史分支預測時，每當要對一條分支指令進行預測，就會根據當前 GHR 的值來預測，此時仍需要借助 PHT (i.e. 2-bit saturating counter)，e.g.

  • 當 b3 分支要執行時，如果 GHR 最低 2 bits 的值是 11 (i.e. b1 和 b2 都是 taken, b3 一定會是 not taken)，其對應的 PHT 在經過一段訓練的時間後就會達到飽和狀態 (e.g. Strongly not take)，之後就可以準確的預測 b3 的分支結果為 not taken 了
  • 但當 b3 分支要執行時，如果 GHR 最低 2 bits 的值不是 11，那麼 b3 有可能會跳轉 (e.g. aa = 2 → aa = 0, bb = 3)，也可能不會跳轉 (e.g. aa = 2 → aa = 0, bb = 0)，這種並沒有規律的情況，分支預測的準確度就沒辦法保證了

• 基於全局歷史分支預測最理想的方法，就是所有的分支指令都對應一個 PHT，並根據 GHR 的值來索引 PHT entry：

  

  • 由於每個分支指令都有自己的 PHT，因此即使 GHR 的值相同，不同條的分支指令也不會索引到同一個 PHT
  • 但很顯然的，這種設計方法太佔硬體空間，在現實中是不可能使用的

• 一般都會使用 hash 將 PC 值進行處理後，得到較小 bits 數的 hash 值後，再用來索引 PHT：

  

  • P.S. 當 BHT 中的 BHR 個數減少到只有一個 BHR 時，基於局部歷史 (Local History) 的分支預測法就跟基於全部歷史 (Global History) 的分支預測法一樣了
    • i.e. 此時 BHR 跟功能跟 GHR 一樣

• 上述方法中，其實有很多的 PHT entry 都沒有被使用到，因此可以採用一種更為簡單的設計方式：

  

  • 缺點：
    • 如果兩條分支指令在執行時的 GHR 值相同，那麼就會對應到同一個 PHT entry，造成衝突
      • 如果兩條分支指令的跳轉結果是不相同的，那就會對分支預測造成負面影響

• 為了解決這個問題，可以同樣將分支指令部份的 PC 值和 GHR 值做拼接或 XOR，得到的值再拿來索引 PHT entry，就不會對應到同一個 PHT entry 了：

  

  • 同樣的，現實處理器會使用更複雜的演算法，盡量避免 PHT aliasing 的情況發生

• 使用基於全局歷史的分支預測法，並無法對分支指令：TNTNTN… 進行完美的預測

  • 因為此時分支指令反而會受到其他分支指令的影響
  • 且每次遇到這條分支指令時，都需要重新對 PHT 進行訓練，進而降低了分支預測的準確度

• 造成這樣的現象，就是因為有些分支指令適合使用基於局部歷史的分支預測法，但另外一些分支指令適合使用基於全局歷史的分支預測法，如果能根據實際狀況，對不同的分支指令使用不同的分支預測法，那就可以得到更高的預測準確度

4.2.4 - 競爭的分支預測

• 由於有些分支指令適合使用基於局部歷史的分支預測法，但另外一些分支指令適合使用基於全局歷史的分支預測法，因此可以設定一種自我調整 (self-adapting) 的分支預測方法，根據不同的分支指令執行情況自動選擇是要基於局部歷史或是全局歷史的分支預測法，稱為競爭的分支預測 (Tournament Predictor)，就像兩種分支預測方法在進行競爭一樣：

  

  

• CPHT (Choice PHT) 是由分支指令 PC 值來索引的一個表格，類似於 PHT，也是由多個 2-bit saturating counter 所組成

  • 將分支指令部份的 PC 值，和 GHR 的值，做一定的處理 (e.g. XOR)，用來索引 CPHT

• CPHT 中每個 2-bit saturating counter 的 FSM 如下：

  

  • P1 (Global) 預測正確，且 P2 (Local) 預測錯誤時，i.e. 1/0，counter 值 - 1
  • P1 (Global) 預測錯誤，且 P2 (Local) 預測正確時，i.e. 0/1，counter 值 + 1
  • 當 P1 (Global) 和 P2 (Local) 預測的結果一樣時，i.e. 0/0 或 1/1，不管預測正確與否，counter 值都保持不變
  • 00 / 01：使用 P1 (Global) 的預測結果
  • 11 / 10：使用 P2 (Local) 的預測結果
  • 同一條分支指令，根據 CPHT 的值，有可能有時候使用基於局部歷史的分支預測法，有時候使用基於全局歷史的分支預測法

• 考慮以下的程式：

  1 2 3 4 5 6

  if (aa == 0) // b1 a = 0; if (bb == 0) // b2 b = 1; if (aa == bb) // b3 c = 3;

  • 如果 b1 和 b2 都 taken 了，b3 一定是 taken
    • 此時 b3 使用基於全局歷史的分支預測法較為合適
  • 如果 b1 和 b2 中只有一個 taken，b3 一定是 not taken
    • 此時 b3 使用基於全局歷史的分支預測法較為合適
  • 如果 b1 和 b2 都 not taken 了，此時 b3 是否 taken 很難預測 (i.e. aa == bb 是否成立無法預測)
    • 此時 b3 使用基於局部歷史的分支預測法較為合適

4.2.5 - 分支預測的更新

• 在實際的 superscalar CPU 中，對於 branch predictor 的更新需要考量到對 pipeline 的影響
  • 對於基於局部歷史和基於全局歷史兩種分支分支預測法，什麼時候更新 branch predictor 對分支預測的準確度是會有所影響的
• 對分支指令的方向預測，需要更新的內容包含兩個方面：
  1. 歷史暫存器：
     • 基於局部歷史的分支預測法：BHR
     • 基於全局歷史的分支預測法：GHR
  2. 2-bit saturating counter：
     • 不論是哪種分支預測法，都需要更新 PHT 中的 2-bit saturating counter (i.e. PHT entry)
• 更新歷史暫存器：
  • GHR：
    • 有三個時間點可以更新 GHR：

      1. Commit stage：當分支指令 commit，要準備 retire 時，根據分支結果更新 GHR

         • 最保守，但也是最正確的，此時更新 GHR 一定沒有問題
         • 但 superscaler CPU 的 pipeline 都很深，等分支指令 commit 並準備 retire 時，該分支指令後面已經有很多條指令已經進入 pipeline 了，這些指令都沒辦法享受到正確的分支預測結果

         

         • 分支指令 Br2 ~ Br5 都使用同一個 GHR 值，沒辦法享受到 Br1 的分支執行結果

      2. Execution stage：當分支指令方向被計算出來後，根據分支結果更新 GHR

         • 對於普通的 CPU 而言，其 pipeline 並不會很深 (e.g. IF, DC, EX, MEM, WB)，因此，在 execution stage 更新 GHR，大部分後續的分支指令都可以享受到此分支指令的執行結果
         • 但對於 superscalar CPU 而言，在 EX 和 IF stages 之間會存在很多的指令
         • 此外：
           • 如果是 in-order CPU，如果發生了 exception，在 execution stage 的分支指令是需要被 flushed 的
           • 如果是 out-of-order CPU，在 execution stage 的分支指令有可能是處在 mis-prediction 的錯誤路徑上
         • 因此，分支指令在 execution stage 的更新 GHR 並不一定是正確的，有可能該分支指令實際上根本不會被執行到

      3. Fetch stage：在 fetch instruction 時，直接進行分支預測並更新 GHR

         • 綜合 1. 和 2. 的結果來說，在 fetch stage，直接進行分支預測並更新 GHR，是一個不錯的方法
           • 可以使後續的分支指令都用到最新的 GHR 內容
           • 當一條分支指令預測錯誤時，即使後續的分支指令都使用到了錯誤的 GHR，其實也是沒關係的，因為後續分支指令也會在 mis-prediction 的路徑上，都應該從 pipeline 中被 flushed 掉
           • 在 fetch stage 進行分支預測是 speculative 的，當分支預測失敗時，需要有一種機制可以將 GHR 進行修復，使 GHR 可以恢復到正確的值
    • GHR 的修復，有兩種方法：

      1. Commit stage 修復法：

         • 在 pipeline 中的 comit stage 也放一個 GHR，每當一條分支指令 commit / retire 時，就將正確的分支結果，更新到這個 GHR 中，這個 GHR 稱為：Retired GHR
         • 因此，在 pipeline 中就有兩個 GHRs：
           • Fetch stage 的 Speculative GHR，採用 speculative 分支預測並更新 GHR
           • Commit stage 的 Retired GHR，每當一條分支指令 commit / retire 時，就將正確的分支結果，更新到這個 GHR 中
         • 當一條分支指令發生 mis-prediction 時，Speculative GHR 的內容一定是錯誤的，因此需要等到該分支指令進到 commit stage，並更新 Retired GHR 後，將 Retired GHR 的內容，覆蓋掉 Speculative GHR 的內容，就完成了 Speculative GHR 的修復；然後再根據這條分支指令所跳轉的位址，重新 fetch instruction 即可

         

         • 缺點：
           • 會增大 mis-prediction 的 penalty，因為必須等到該分支指令 commit / retire 時，才能重新 fetch instruction
             • 尤其是當該分支指令前有 D-cache miss 的 load 指令時，penalty 會更為嚴重，並降低處理器的性能

      2. Checkpoint 修復法：

         • 在 fetch stage 進行 GHR 更新前，其實就可以先將”舊的” GHR 值給保存起來，這個保存內容就稱為：Checkpoint GHR
         • 一旦該分支指令的結果被計算出來後 (e.g. 在 execution stage)，就可以檢查是否發生 mis-prediction；如果發生 mis-prediction，就可以直接用 Checkpoint GHR 的內容，覆蓋掉 Speculative GHR 的內容，並 flush pipeline；然後再根據這條分支指令所跳轉的位址，重新 fetch instruction 即可

         

         • 有一個暫存器專門用來儲存 Checkpoint GHR 的內容
         • 由於新的分支結果是從右邊 shift 進 GHR 的，因此只需將 speculative 的預測結果反轉 (taken → not taken / taken → not taken)，從右邊 shift 進 Checkpoint GHR，即為”舊的” Speculative GHR 的值
         • 當 mis-prediction 發生時，就可以用 Checkpoint GHR 的內容，覆蓋掉 Speculative GHR 的內容，即完成 Speculative GHR 的修復
         • 由於分支預測發生在 fetch stage，此時指令仍是 in-order 的，所以 Checkpoint GHR 的值只要使用 FIFO 的方式，寫進暫存器即可
         • 但如果是 out-of-order CPU，在 execution stage 的時候，指令已經是亂序執行了，因此就無法直接照 FIFO 的順序讀取這個暫存器，增加了此暫存器的設計難度
         • 甚至，對於 out-of-order CPU，分支指令的執行結果也有可能是 mis-predict 的，因為該分支指令有可能是在 mis-prediction 的路徑上 (i.e. 更早之前有條分支指令發生 mis-prediction 了，該分支指令根本不應該被執行)
           • 所以依舊需要在 commit stage 時，對分支預測的結果進行檢查
         • 因此，在 commit stage，還是需要使用 Retired GHR，當分支指令 commit / retire 時，如果發現分支預測錯了，那就需要將 Retired GHR 的內容，覆蓋掉 Speculative GHR 的內容，並 flush pipeline；然後再根據這條分支指令所跳轉的位址，重新 fetch instruction
         • Checkpoint 方法除了在 execution stage 可以修復 Speculative GHR，也可以在 commit stage 修復 Speculative GHR，這樣就可以加快分支指令在發生 mis-prediction 時的修復時間，提高處理器的執行效率
  • BHR：

    • BHR 的更新也可以是 speculative 的，也可以是 non-speculative 的

    • 不過跟 GHR 不一樣的是，BHR 儲存的是當前分支指令自身在過去的執行情況，通常只有在循環體很短的情況下，才有可能出現一條分支指令在 pipeline 的 commit stage 更新 BHR 時，pipeline 中又已經出現這條分支指令並使用 BHR 進行分支預測

      

      

      • 假設 bne 指令對應的 BHR 和 PHT 都已經訓練好，也就是現在是 taken，且分支位址也已經存在 BTB 中
      • 在第一個 bne 指令在 commit (retire) stage 更新 BHR 前，所有後續的 bne 指令都使用不到第一個 bne 指令的分支預測結果
        • 但這並不會對性能造成太大的影響，因為經過一段的訓練時間後，branch predictor 對於 bne 這個指令都是預測 taken 的，只有在 for-loop 最後一個迴圈結束時會預測錯誤，其他預測結果都是正確的
  • 綜合起來：
    • 在 fetch stage 更新 GHR 是最合適的，GHR 使用了指令間的相關性
    • 在 commit (retire) stage 更新 BHR 是最合適的，可以簡化設計，又不會對處理器的性能造成太大的影響
• 更新 PHT 的 saturating counter：
  • 當一條分支指令比較有規律時，其對應的 saturating counter 總是處在飽和狀態，因此即使是在該分支指令 commit / retire 時更新 PHT 的 saturating counter，也不會對分支預測的準確度造成太大的影響
    • 因此，不論是基於局部歷史的分支預測法，或是基於全局歷史的分支預測法，一般都是在 commit stage (指令 retire 時) 更新 PHT 的 saturating counter

3.2.3 - Page Fault

• PTE (page table entry) 中包含：
  • valid bit：標記這個 PTE 是否有效，當作業系統設定好 page table 後，就需要將對應 PTE 的 valid bit 設成 1
  • dirty bit：當一個 page 內容被更新時 (e.g. 執行 store 指令)，硬體會自動將 dirty bit 設成 1，代表這個 page 如果被選中要被替換時，需要將 page 的內容 swap 回硬碟
  • access bit：當一個 page 被訪問 (load/store) 時，硬體會自動將 access bit 設成 1，作業系統則會定期的將 access bit 清為 0
  • 當要替換 page table 時，就可以根據 access bit 來得知最近 page 是否有被訪問過，進而實現近似 LRU (Least Recently Used) 的替換策略
• 當 page 要被 swapped out 前：
  • 要先將 D-Cache 的內容 flush 進 memory，以確保要被 swapped out 的 page 內容是最新的
  • 將 PTE 的 valid bit 設成 0，以避免其他 CPU 或 MMU 在接下來 swap out 期間誤讀這個 page
    • valid bit 為 0 時，代表該 page 並不存在記憶體中，當 MMU 存取時會觸發 page fault 讓作業系統從硬碟讀取 page 進記憶體
    • valid bit 是由作業系統在把 page 讀進記憶體後設為 1 的
  • 執行如 RISC-V 的 sfence.vma 指令，確保 TLB 中對應的 entries 被清空，以避免 MMU 錯誤存取到被 swapped out page 的 cache 內容

3.4 - 加入 TLB 和 Cache

3.4.1 - TLB 的設計

• TLB entry 中也會包含：
  • valid bit：標記這個 TLB entry 是否有效；當 TLB entry 被 swap in 時，valid bit 會被設為 1
  • dirty bit：當執行 store 指令時，如果 TLB hit，就不會再訪問 PTE，也就不會更新 PTE 中的 dirty bit；只有當 TLB entry 要被替換時，才會同步至 PTE
  • access bit：當執行 load/store 指令時，如果 TLB hit，就不會再訪問 PTE，也就不會更新 PTE 中的 access bit；只有當 TLB entry 要被替換時，才會同步至 PTE
  • P.S. RISC-V 中，TLB entry 並沒有包含 dirty 和 access bits，作業系統需要自己確保 PTE 的更新
    • sfence.vma 只會將 TLB 中對應的 entries 給 invalid 而已 (針對 TLB 的部份)
    • 如果 CPU 有支援 Svadu extension，那麼硬體就會自動更新 PTE 中的 dirty 和 access bit
      • 如果硬體支援 access 和 dirty bits 自動更新， 作業系統只需要讀取 PTE 即可獲得最新的 access 和 dirty bits 的狀態
    • 如果硬體不支援 access 和 dirty bits 自動更新，當 access=0 或 dirty=0 時：
      1. MMU 會觸發 page fault
      2. 作業系統在 page fault handler 中設置 access=1 或 dirty=1
         1. 作業系統得先透過設定 PTE 的 valid bit (追蹤 page 是否有被 accessed) 和 disable write permission (追蹤 page 是否有被 stored) 來當 page fault 發生時，在 page fault handler 更新 access 或 dirty bit
      3. 重新執行造成 page fault 的那道指令
      • 也就是讓作業系統來自行管理 PTE 中 access 和 dirty bits 的內容，效能較差，但硬體設計較簡單
      • RISC-V privilege spec:
        • If pte.a=0, or if the original memory access is a store and pte.d=0:
          • If the Svade extension is implemented, stop and raise a page-fault exception corresponding to the original access type.
• 一般為了減少 TLB miss rate，會使用 fully-associative 來設計 TLB
  • 缺點：TLB 容量不能太大，不然會增加查找的時間
• 因此，有些架構也會使用 set-associative 來設計容量比較大的 TLB
• 因為是 fully-associative 或 set-associative，因此 TLB entry 中，還會包含 tag 欄位 (VPN，Virtual Page Number)，用來比對 TLB 是否 hit
  • P.S. TLB entry 中的 data 是 PFN (Page Frame Number)
• 現代處理器架構，通常都使用 2-level TLB
  • 1st level 採用 Harvard 架構，分為 I-TLB (指令) 和 D-TLB (數據)，一般採用 fully-associative 設計
  • 2nd level 採用 Von Neumann 架構，指令和數據共用，一般採用 set-associative 設計
• 現代處理器中因應程式的 size 越來越大，因此還會支持容量更大的 page
  • E.g. 128 entries 的 TLB，只能映射到 128 * 4KB = 512 MB 大小的程式，顯然不夠用
• 更大的 page：
  • 優點：
    • 降低 TLB miss rate
  • 缺點：
    • 當發生 page fault 的時候，需要花更多的時間才能將更大的 page 內容從硬碟搬至記憶體
    • 如果程式用不到這麼大的 page，那麼空間就被浪費了，且也會造成 page fragment，降低 page 的使用效率
• 總和以上原因，現代處理器都支持大小可變的 page，由作業系統負責管理，根據程式的特點選用不同大小的 page，最大程度地利用 TLB 有限的空間，並降低 page fragment
  • 在 TLB 中會有相對應的設定可以調整映射的 page 大小
• 因為記憶體的存取速度相對於 CPU 的執行速度來說非常慢，因此 TLB 通常只會採用 Write-back 的方式設計，且因為 TLB entry 中 tag 和 data 等欄位是不會變動的，因此當發生 TLB miss，需要將 TLB entry swap out 時，只需要將 dirty bit (執行 store 指令時會被更新) 和 access bit (執行 load/store 指令時會被更新) 寫回 PTE 中即可
• TLB miss 發生的情況：
  1. Page 並不在記憶體中，因此也不在 TLB 中
  2. Page 在記憶體中，page table 中也有對應的 PTE，但這個 PTE 並沒有被 cache 在 TLB 中
  3. Page 在記憶體中，page table 中也有對應的 PTE，這個 PTE 也曾經存在 TLB 中，但是因為先前的 TLB miss，因此被替換出來了
• TLB miss 時，TLB entry 的替換策略：
  • LRU (Least Recently Used)
  • Random：如同 cache，使用一個 counter，每個 cycle 都會 + 1，每次 TLB miss 要替換 TLB entry 時，就根據當下 counter 的值決定是哪個 entry 要被替換
  • LRU 比較難實現，所以通常會採用 Random 的替換策略，實做也比較簡單
• 如果 TLB 採用 Write-back，TLB entry 中的 dirty 和 access bits 就有可能跟 PTE 的內容不同步，如果 page 要被 swap out 的時候，作業系統會無法即時得知究竟 page 是否 dirty，以及是否有被 accessed 過
  • 直觀解法：每次發生 page fault 要 swap page 的時候，先將 TLB entries flush 至 PTE
    • 缺點：需要耗費額外的時間 flush TLB
  • 另類解法：作業系統可以認為，有在 TLB 中被 cached 對應的 pages 都是正在使用的，因此不能將其 swap out
    • 需要作業系統自行維護一張表，紀錄哪些 PTE 有被 cached 在 TLB 中，且為 valid 的
      • 不過這種設計並不常見
• 如果系統中有 D-Cache，page 也是 dirt 的，那麼 page 被更動的內容也有可能還存在 D-Cache 中，因此在 page swap out 前也必須先 flush D-Cache

3.4.2 - Cache 的設計

• 兩種 caches：

  • Physical cache：

    

  • Virtual cache：

    

• Virtual cache 會有 aliasing (synonyms，同義) 問題：

  • 多個 VA 對應到同一個 PA

    

  • 缺點：

    • 造成 cache 空間的浪費，因為可能會有兩個 cache sets (不同 VA) 都是對應到同一個 PA 的資料
    • 當執行 store 指令更新 cache 的內容時，只有一個 cache set 的內容會被更新，但實際上，所有對應到同一個 PA 的 cache sets 內容都應該被更新，否則其他 CPU 讀到的 cache 內容就會不同步

  • 並不是所有情況都會有 aliasing (synonyms) 問題，例如：

    • 當 page 為 4 KB，VA 轉成 PA 時，low 12 bits 的位址是不會發生變化的，因此當一個 direct-mapped 的 cache 容量 ≤ 4KB 時，由於 cache index 最多只會用到 page offset 內的 12 bits (i.e. cache sets 數量 ≤ page offset 可表達的範圍)，即使兩個不同 VA 對應到同一個 PA，還是會 mapping 到同一個 cache set，也就沒有 aliasing (synonyms) 問題

      • 只有在 cache 容量 > 4KB 時，才會導致 cache index bits > 12 bits (i.e. cache sets 的數量 > page offset 可表達的範圍，也就是 cache index bits 包含了 VPN 的部份)，造成兩個不同 VA 對應到同一個 PA，有可能會 mapping 到不同個的 cache sets，導致 aliasing (synonyms) 問題

        

        • E.g. 即使 VA：0x800 和 0x1800 都是對應到同一個 PA，但因為 VA 的 bits[12] 也是 cache index bits 的一部分，因此還是會被 mapping 到不同的 cache sets

  • 使用 bank 解決 aliasing 問題：

    • 最簡單的方式：在寫 cache 時，將 aliased 的 cache sets 都進行更新

      • 需要將 PA 的一部分作為 cache tag 來使用，並需要使用兩個 banks
      • 缺點：浪費 cache 使用空間

    • 如何在不浪費 cache 使用空間的情況下，透過 bank 的方式解決 aliasing 問題：

      

      • 範例：8 KB 切成兩個 4 KB 的 cache banks
        • 讀取 cache 時，使用 VA[11:0] 同時查詢兩個 banks，輸出的 cache sets 再透過 PA[12] 控制的 Mux 來選取是哪個 cache set 要被讀出
          • 由於 PA 需要透過 TLB 轉換才能得知，處理時間較長，因此會增加 CPU 的 cycle time
          • Cache tag 也必須是 PA，才能跟 TLB 轉換出來的 PFN 做比對
        • 寫 cache 時，因為只有被 retired 的指令才會把數據寫入 cache，此時 PA 已經得到了，所以直接拿 PA[12] 來判斷要寫入到哪個 bank 中即可
        • 缺點：
          • 增加硬體的複雜度
          • 由於讀取 cache 時必須同時查找所有的 banks，因此也會增加功耗

• Virtual cache 會有 homonyms (同名) 問題：

  • 一個 VA 對應到多個 PA
    • 不同 processes，同一個 VA 可能對應到的 PA 不同
  • 在 context switch 時，需要把 virtual indexed cache 的 cache 內容都 invalidate
  • 同樣的，在 context switch 時，也需要把所有的 TLB entries 都 invalidate，以避免存取到錯誤的 VA -> PA mappings
  • 可以透過 ASID (Address Space Identifier) 來只 invalidate 被 context switched 的 cache 內容和 TLB entries
  • 可以再透過引入 global bit 來標記該 page 是被多個 processes 共享的 (e.g. Linux kernel space)

• DMA 搬 memory 的資料前，必須先 flush D-Cache，確保記憶體中的內容是最新的

• CPU 在讀取 DMA 搬完的 memory 資料前，必須先 invalidate D-Cache，確保 CPU 一定會從 memory 讀取最新的資料

• 當發生 page fault，並需要將 page swap out 至硬碟前，如果該 page 是 dirty 的，那就需要先 flush D-Cache，確保要被 swapped out 的 page 內容是最新的

• 在執行完 self-modifying codes 的指令後，必須先 flush D-Cache，確保指令的修改有正確的寫進 memory；然後要再 invalid I-Cache，確保 CPU 可以讀取到 self-modified 完後最新的指令

• Cache 在上電時，大部分都是關閉的，所以起始程式通常都是放在 non-cacheable 的 memory region；等到初始化完 cache 後，cache 才可以被開啟及使用

3.4.3 - 將 TLB 和 Cache 放入流水線

• PIPT Cache (Physically-indexed, Physically-tagged)：

  

  • Cache index 和 tag 都是 PA
  • 缺點：
    • TLB lookup 需要消耗一定的時間，為了不影響 CPU 的 cycle time，可能會需要將 TLB lookup 獨立成一個獨立的 pipeline stage
      • 對 I-Cache 來說，branch mis-prediction 的 penalty 會增加
      • 對 D-Cache 來說，load 指令的 latency 會變長
        • 且 load 指令通常都是其他指令的 dependency，因此也會影響其他指令可以被 issued 的時間
    • 真實世界的 CPU 很少 L1 Cache 是採用 PIPT cache 的設計，因為這樣將 cache 訪問和 TLB lookup 給綁定在一起了，會影響 pipeline
      • 實際上也沒有必要，如果 page offset 就可以作為 cache 的 index，VA 的 page offset 和 PA 的 page offset 都是一樣的，可以直接使用 VA 的 page offset，沒有必要再透過 TLB 做轉換
      • 不過 L2/L3 Cache 通常就是使用 PIPT cache 的設計，因為 L2/L3 Cache 被訪問時，TLB lookup 有可能已經完成

• VIPT Cache (Virtually-indexed, Physically-tagged)：

  

  • Cache index 是 VA，tag 是 PA
  • VIPT 是目前最多被使用的 cache
  • 優點：
    • Cache 訪問和 TLB lookup 可以同時進行
  • 缺點：
    • Cache 的大小會有所限制，因為要避免 aliasing 的問題
  • 假設一 direct-mapped cache，cache line：2^b bytes，cache sets 個數：2^L ⇒ Cache size = 2^(L + b)；Page size：2^k bytes，會有以下三種情況：

    • Page size (k) > Cache size (L + b)：

      

    • Page size (k) = Cache size (L + b)：

      

    • Page size (k) < Cache size (L + b)：

      

    • 針對 Page size (k) > Cache size (L + b) 和 Page size (k) = Cache size (L + b)：

      • 有機會 cache 訪問和 TLB lookup 在同一個 stage 完成

      • 為了要避免 aliasing 的問題，因此 cache size 被限制最大只能是一個 page 的大小

      • 如果 cache size 要超過一個 page，就只能使用 set-associative 的設計：

        

    • 針對 Page size (k) < Cache size (L + b)：

      • 如果已經增加 ways 數 (ways 數不可能無限制的增加)，但還想再增加 cache 的 size，當 cache size > page size 時，就會造成 aliasing 的問題

      • 除了透過先前介紹 bank 的方式來解決 aliasing 的問題，還可以透過 inclusive L2 cache 來解決 aliasing 的問題：

        • L2 cache 包含所有 L1 I-Cache 和 L1 D-Cache 的內容

        

        • L2 Cache 中的 a1 (VA) 是 VA1 的，所以如果跟 VA2 的 a2 (VA) 部份不相同的話，就代表有 aliasing 的問題
        • 透過 {a1, offset} 的組合，可以找到 VA1 在 L1 Cache 中的 cache line：
          • 如果是 dirty，將其 flush 回 L2 Cache 後，再 invalidate cache line
          • 如果沒有 dirty，直接 invalidate cache line
        • 此時就可以將 VA2 的內容從 L2 Cache 讀回 L1 Cache 中，且因為只有 VA2 在 L1 Cache 的 cache line 是 valid 的，也就不存在 aliasing 的問題

• VIVT Cache (Virtually-indexed, Virtually-tagged)：

  • Cache index 和 tag 都是 VA

  

  • 優點：
    • Cache hit 的話，完全不用 TLB lookup
  • 缺點：
    • 同樣會有 aliasing 的問題
      • 可以同樣用跟 VIPT 的方式查找 VA1 在 L1 Cache 的 cache line，並將其 invalidate
      • 不過此時 L2 Cache 沒辦法只存 a1 (VA)，必須存整個 VA1 (VA)，因為 L1 Cache 是 virtually-tagged 的，會使用 VA 的一部分作為 tag，只用 {a1, offset} 是不夠的
        • L2 Cache 中的 VA1 (VA) 是 VA1 的，所以如果跟 VA2 的 VA2 (VA) 部份不相同的話，就代表有 aliasing 的問題

• L1 Cache 通常分為 I-Cache 和 D-Cache，為 private cache
  • I-Cache 需要能夠在一個 cycle 內，讀取多條的指令
  • D-Cache 需要能在一個 cycle 內，處理多條 load/store 指令的訪問，因此需要使用 multi-port 的設計
• Instruction fetch 的時候，會向 L1 Cache 嘗試讀取指令，因此 L1 Cache 也是 pipeline 的一部分
• L1 Cache 必須保持跟 CPU 相近的速度，因此通常是透過 SRAM 實現的
• L2 Cache 通常都是指令和資料一起 share 整個 cache，容量通常以 MB 為單位
• 現在大部份的 multi-core 都是 shared 同一個 L3 Cache
• L2 Cache 被訪問的頻率通常不是很高 (L1 Cache miss 才會訪問 L2 Cache)，因此不需要使用 multi-port 的設計
• 需要盡可能的提昇 L2 Cache 的命中率，因為如果 L2 Cache miss，且沒 L3 Cache 的話，就需要去訪問 DRAM 了，訪問時間會很長

2.1.1 - Cache 的組成方式

• Set-associative cache：

  

  • TLB 和 Victim Cache 通常使用 fully-associative 架構

  • I-Cache 和 D-Cache 通常使用 set-associative 架構

  • Compulsory miss 可以透過 prefetching 來降低其發生的頻率

  • Capacity miss 沒有方法可以降低其發生的頻率

  • Conflict miss 可以透過 Victim Cache 來降低其發生的頻率

  • Set-associative：

    • 優點：
      • 可以降低 cache miss rate
    • 缺點：
      • 需要比對多個 cache line，因此 latency 會比較高

  • 補充：

    

    • 4-way set associative cache：
      • 共 256 個 sets，透過 (Set) Index (8 bits) 來選取
      • 每個 set 有 4 個 ways (i.e. 共 4 條 cache line)
      • 同時間這四個 ways 中對應的 cache line 都會被選中，然後透過比對 Tag 來決定是哪個 way hit
      • 最後再透過 Word + Byte (= Block Offset)，決定 way hit 的那條 cache line 中，要被讀/寫的 word (一條 cache line 通常包含了好幾個 words)

  • 在實際的實做上，Cache Tag 和 Data 是分開的，也就是：Tag SRAM 和 Data SRAM

  • Tag SRAM 和 Data SRAM 有兩種存取方式：

    • 同時訪問 Tag SRAM 和 Data SRAM

      

      

      • Address Calculation stage 先計算出 memory 的位址，Disambiguation stage 再透過 LSU (Load-Store Unit) 檢查 load/store 指令之間的 memory disambiguation，確保 load/store 指令之間依賴關係有正確的被處理 (因為指令是 Out-of-Order 執行)，Cache Access stage 再根據 tag 的比較結果，決定存取哪一個 cache set；Tag hit 的 way 就可以同時間訪問其 Tag SRAM 和 Data SRAM，最後在 Result Drive stage 根據 block offset 從 cache line 上取得資料
      • 優點：
        • 比先訪問 Tag SRAM，再訪問 Data SRAM 的設計，少了一個 pipeline stage
        • 較適合 In-Order CPU
      • 缺點：
        • 較低的 CPU frequency (因為 pipeline stage 比較少)
        • 較大的功耗 (因為多了 Way Mux)
        • 較不適合 Out-of-Order CPU

    • 先訪問 Tag SRAM，根據 Tag 的比較結果，再訪問 Data SRAM

      

      

      • Address Calculation stage 先計算出 memory 的位址，Disambiguation stage 再透過 LSU (Load-Store Unit) 檢查 load/store 指令之間的 memory disambiguation，確保 load/store 指令之間依賴關係有正確的被處理 (因為指令是 Out-of-Order 執行)，Tag access stage 可以直接比對 tag 是否 hit，而不需要使用 Way Mux 決定是哪條 way (因為 Data SRAM 還沒有被存取)。Tag hit 的 way 就可以在 Data Access stage 訪問其 Data SRAM，最後在 Result Drive stage 根據 block offset 從 cache line 上取得資料
      • 優點：
        • 較高的 CPU frequency (因為 pipeline stage 比較多)
        • 較小的功耗 (因為少了 Way Mux)
        • 較適合 Out-of-Order CPU
      • 缺點：
        • 比同時訪問 Tag SRAM 和 Data SRAM 的設計，多了一個 pipeline stage
          • 不過 Out-of-Order CPU 可以將訪問 cache 這段時間，透過 reorder 其他的指令來填補
            • 因此比較不適合 In-Order CPU

  • Fully-associative cache：

    

    • 所有的 cache lines 的 Tag 都會被比較

    • 因此通常都是使用 CAM (Content Address Memory) 來儲存 Tag，SRAM 來儲存 Data

      CAM 是一種類型的記憶體，它允許透過內容（而非位址）來存取儲存的資料。這與傳統的 RAM（Random Access Memory，隨機存取記憶體）不同，因為 RAM 透過記憶體位址來讀取或寫入資料，而 CAM 則根據輸入的內容來搜尋對應的儲存單元，並返回匹配的結果。

    • 優點：

      • cache miss rate 最低 (因為只要有空的 cache line 就可以使用)

    • 缺點：

      • Latency 也是最長的 (因為有大量的 Tags 需要被比較)

    • 通常 TLB 會使用 fully-associative 來實現

2.1.2 - Cache 的寫入

• Self-modifying codes 的執行流程：
  • Self-modified 的 codes 存至 D-Cache → 將 D-Cache 的內容 flush 至 L2/L3 Cache 或是 memory→ Invalidate I-Cache → 下次 CPU fetch 該指令的時候，就會從 L2/L3 Cache 或是 memory 取得並存進 I-Cache 中了
• 當執行 store 指令的時候：
  • 如果 cache line 存在：
    • Write-through：
      • 資料會一路寫進 D-Cache → L2/L3 Cache → Memory
      • 優點：
        • 設計較簡單，不須額外的 dirty bit 紀錄來哪條 cache line 是 dirty 的
        • Cache 和 Memory 的資料是一致的，適合 multi-core 的系統
      • 缺點：
        • CPU 的效率會降低，因為 D-Cache 同步至 L2/L3 Cache, Memory 的速度很慢
        • 如果寫入了資料只會用過一次，那麼同步至 L2/L3 Cache, Memory 就是多餘的開銷
    • Write-back：
      • 當執行 store 指令的時候，資料只會寫進 D-Cache，並標記該 cache line 為 dirty；只有在該 cache line 要被 evicted 的時候，才會將 dirty cache line 同步至 L2 Cache or L3 Cache or Memory (只需同步至下一級)
      • 優點：
        • 資料只須寫入 D-Cache，效率較佳
      • 缺點：
        • 不同層級的 caches 資料有可能不一致，會需要處理一致性的問題
        • 需要額外的 dirty bit 來紀錄哪些 cache line 是 dirty 的
  • 如果 cache line 不存在 (i.e. Write miss)：
    • Non-write-allocate：
      • 直接將資料寫至下一級的 cache 或 memory，不寫進 D-Cache
    • Write-allocate：
      • 如果搭配 Write-through：
        • 從下一級的 cache 讀出對應的 cache line 並寫回 D-cache 中，再將 store 的資料更新至該 cache line 中對應的 block
        • 該 D-Cache 的 cache line 會再同步回 L2/L3 Cache, Memory
      • 如果搭配 Write-back：
        • 如果該 D-Cache 的 cache line 已經是 dirty 了，需先將該 cache line flush 至下一級的 cache 或 memory
        • 從下一級的 cache 讀出對應的 cache line 並寫回 D-cache 中，再將 store 的資料更新至該 cache line 中對應的 block
        • 只須將該 D-Cache 的 cache line 標記為 dirty
      • 為何需要先從下一級的 cache 讀出對應的 cache line，而不是直接把資料寫進 D-Cache?
        • 因為通常 store 只會寫入一個 word 的值 (e.g. 32 bits)，但 cache line 可能是 512 bits，如果直接該 word 寫進 cache，會導致整條 cache line 都變 dirty，當 cache line 被 evicted 的時候，整條 cache line 都會同步至下一級的 cache 或 memory，導致資料不一致
          • 因為有可能 cache line 其他 words 在 store 指令執行時，是 invalid 的，例如：第一次寫入該 cache line
          • 除非一條 cache line 有多個 dirty bits 可以 track 各個 word 的 dirty 狀態，不過這樣會需要耗費多餘的硬體，一致性的問題也會更難處理
  • 實做通常搭配：

    • Write-through + Non-write-allocate

      

      • Write-through 和 Non-write-allocate 都會將資料寫至下一級的 cache 或 memory
      • 如果是搭配 Write-allocate，需要先從下一級的 cache 讀出對應的 cache line 並寫回 D-cache 中，但 Write-through 又會將資料寫至下一級的 cache 或 memory，前面從下一級 cache 的讀取就是多餘的

    • Write-back + Write-allocate

      

      • Write-back 搭配 Write-allocate 只須將 cache line 標記為 dirty 就好，不用再同步回L2/L3 Cache, Memory
      • 如果是搭配 Non-write-allocate，資料是直接寫至下一級的 cache 或 memory，不會寫進 D-Cache 的，因此下一次存取的時候 D-Cache 還是會 miss
      • Write-back + Write-allocate 相較於 Write-through + Non-write-allocate：
        • 優點：
          • 同步至下一級的 cache 或 memory 的次數較少，效能較好
        • 缺點：
          • 設計較為複雜

2.1.3 - Cache 的替換策略

• LSU (Least Recently Used)，近期最少使用法：
  • 選擇最近被使用次數最少的 cache line 來替換
  • 每個 cache line 都有個 age 的欄位紀錄被使用的次數，每被使用一次，age 就會 + 1
  • age 最小的 cache line，就是最近被使用次數最少的，也就是會被替換的 cache line
  • Directed-mapped cache 不須使用 LSU，因為會被替換的 cache line 都是固定的
  • Set-associative cache 可以針對 way 來紀錄 age
    • 例如：2-way set-associative cache 每個 way 的每條 cache line 可以各自用 1 個 bit 的 age 來紀錄 way 的 cache line 是 LSU
      • 當 way 0 被使用時，將 way 0 的 age 設成 1，way 1 的 age 設成 0，代表最近 way 0 有被使用
      • 反之，當 way 1 被使用時，將 way 1 的 age 設成 1，way 0 的 age 設成 0，代表最近 way 1 有被使用
      • 如此，只要找到 age 是 0 的那個 way，就可以將該 way 的 cache line 給取代了
    • 然而，當 ways 數增加時，精準的 LSU 實做會非常昂貴，因此實務上都是使用 pseudo-LSU 的方法來實現：

      • 將所有的 way 分組並分級，每一組 ways 使用 1 個 bit 的 age：

        

        • 共需要 1 + 2 + 4 = 7 個 bits
• Random Replacement，隨機替換法：
  • 不再需要紀錄每個 way 的 age，而是隨機挑一個 way 來替換
  • 優點：
    • 設計較 LSU 來得簡單
  • 缺點：
    • 相較於 LSU，cache miss rate 會比較高，但隨著 cache 的容量增大，這個差距會越來越小
  • 實務上很難實做出嚴格的隨機，一般是採用時鐘算法 (clock algorithm) 來實現近似的隨機：
    • 本質上為一個 counter，每個 cycle 都會 + 1，counter 的 bits 由 ways 數決定 (如 8 ways 就需要 3 個 bits)，每次 cache line 要被替換的時候，就根據當下 counter 的值決定是哪個 way 的 cache line 要被替換

2.2. 提高 Cache 的性能

2.2.1 Write Buffer

• 當 D-Cache miss 時，需要從下一級的 cache 或 memory 讀取資料回 D-Cache 並寫入 cache line；如果 D-Cache 的 cache line 是 dirty 的，那還需要先將 dirty cache line 寫至下一級的 cache 或 memory，才能再從下一級的 cache 或 memory 讀取資料回 D-Cache

• 由於訪問下一級的 cache 或 memory 的 latency 很長，會影響 cache miss 的處理時間，因此可以引入 write buffer 來解決此問題：

  

• Dirty cache line 會先被寫進 write buffer，等到下一級的 cache 或 memory 有空閒的時候，才會將 dirty cache line 寫入

• Dirty cache line 寫入的時間會因此被隱藏，D-Cache 在將 dirty cache line 寫進 write buffer 後，就可以開始從下一級的 cache 或 memory 讀取資料回 D-Cache

  • 對於 write-through 類型的 D-Cache，write buffer 是非常必要的元件

• 缺點：

  • 會增加系統的設計複雜度：
    • 當發生 cache miss 的時候，不只要查詢下一級的 cache 或 memory，同時間也要查詢 write buffer
      • 因此 write buffer 通常也是使用 CAM 來實做
      • 當 write buffer 中有 cache miss 所需的數據時，會優先採用 write buffer 的數據

2.2.2 流水線

• 讀 D-Cache：
  • Tag SRAM 和 Data SRAM 可以同時讀取，因此可以在一個 cycle 內完成
• 寫 D-Cache：
  • 讀 Tag SRAM 和 寫 Data SRAM 只能依序完成，因為必須先讀取 tag 並比較，確認要寫的位址在 cache 中後才能將數據寫進 Data SRAM
  • 這些操作很難在一個 cycle 內完成，因此需要對寫 D-Cache 的操作採用 pipeline 的架構
• 比較經典的設計方式是：

  • 將 tag 的讀取和比較放在同一個 cycle

  • 寫 D-Cache 放在下一個 cycle

  • 對一個 store 指令而言，就算 cache hit，至少也需要 2 個 cycles 才能完成；但如果是連續的 store 指令，那麼還是可以透過 pipeline，每個 cycle 執行一道 store 指令 (假設沒有 hazard)

    

    • Load 指令在 D-Cache hit 的情況下，只需要 1 個 cycle 就可以完成
    • Store 指令在 D-Cache hit 的情況下，需要 2 個 cycles (讀 tag 並比較 + 寫 data) 才可以完成
    • 當 load 指令執行時，有可能其所需的數據存在 store 指令的 register (Delayed Store Data) 中，而不是來自 Data SRAM，因此需要將 load 指令的位址，和 store 指令的位址 (Delayed Store Addr) 做比較；如果相等，那麼就可以直接將 store 指令的 register (Delayted Store Data) 內容，直接 forward 給 load 指令

      • E.g.

        1 2	sw a0, 0(a1) lw a2, 0(a1) # Store 指令的 $a0 可以直接 forward 給 load 指令的 $a2

2.2.3 - 多級結構

• 一般處理器設計中：

  • L1 Cache 可以採用 Write-through 或 Write-back 的設計
    • Write-through 可以簡化 pipeline 的設計，尤其是針對 multi-core，需要處理 coherence 的問題，Write-through 的設計會比較簡單一點
  • (Shared) L2 Cache 會採用 Write-back 的設計

• Inclusive cache vs. Exclusive cache：

  

  • Inclusive cache：L2 Cache 包含了所有 L1 Cache 的內容
    • 優點：
      • 可以將數據直接寫進 L1 Cache，因為被 evicted 的 cache line 在 L2 Cache 中也一定存在；直接將數據寫進 L1 Cache 不會引起任何的問題 (假設被 evicted 的 cache line 並不是 dirty 的)
      • 簡化了 cache coherence 的管理
        • 在 multi-core 的平台，當其中一個 CPU 更新了其 private cache (e.g. L1 D-Cache) 某個位址的數據 (e.g. 執行 store 指令)，如果其他 CPU 也有相同位址的數據，那就必須將其設為 invalid，以免其他 CPU 存取到舊的值
        • 如果是採用 inclusive cache，那麼只需檢查 last-level (shared) cache (e.g. L2 Cache) 中，是否有該位址的數據，如果 last-level cache 中沒有，那就代表 private cache 中也一定沒有，如此就不用打擾其他 CPU 的 private cache，影響 pipeline 的執行
    • 缺點：
      • 浪費了 cache 的空間，實做成本比較高
  • Exclusive cache：L2 Cache 和 L1 Cache 的內容完全不相同 (i.e. 互斥)
    • 優點：
      • 避免了 cache 空間的浪費，實做成本比較低
    • 缺點：
      • 如果是採用 exclusive cache，那麼在 multi-core 的平台，當某一個 CPU 更新了其 private cache (e.g. L1 D-Cache) 某個位址的數據 (e.g. 執行 store 指令)，那麼每個 CPU 都必須檢查其每個 cache 是否也有包含其位址的數據，如果有的話，就必須將其設為 invalid，也因此會影響 pipeline 的執行
      • 同時，當要讀取的數據不在 L1 Cache，而是在 L2 Cache 時，除了將 L2 Cache 的數據拉回 L1 Cache 外，還需要將 L1 Cache 中被 evicted 的值，寫進 L2 Cache，這種交換過程會降低 CPU 的執行效率
  • 目前大部分的處理器，都還是採用 Inclusive cache 的設計

2.2.4 - Victim Cache

• 有時候，被 evicted 的 cache line 有可能又會馬上被使用，例如：

  

  • A、B、C 都被分配在同一個 cache set，如果同時間都被頻繁使用 (e.g. A -> C -> B)，那就有可能被 evicted 後，又會馬上被讀回 cache，然後又被 evicted，而且會一直 cache miss
  • 而且 cache 的 ways 數有上限，沒辦法無上限的透過增加 ways 數來解決這個問題；其他的 cache sets 也未必會有同樣的狀況，為此增加 ways 數可能只是浪費空間

• 可以引入 Victim cache 來解決這樣的問題，Victim cache 是用來保存最近被 evicted 的 cache lines，因此所有的 cache sets 都可以透過 Victim cache 來”增加 ways 數”

• Victim cache 通常採用 fully-associative 設計，容量也會比較小 (一般可以存 4 ~ 16 條 cache lines)

  

• 一般情況下 Victim cache 的數據跟 L1 D-Cache 的數據是互斥的，CPU 可以同時讀取它們，只要有其中一個 hit，就可以直接使用

• 如果 L1 D-Cache 中沒有找到數據，但有在 Victim cache 中找到，那麼該數據會被讀進 L1 D-Cache，同時間 L1 D-Cache 中被 evicted 的數據，會被寫進 Victim cache，也就是互換了兩邊的數據 (因為 L1 D-Cache 和 Victim cache 是互斥的)

• Victim cache 可以降低 cache miss rate

• 現代大多數處理器都有採用 Victim cache

• Filter cache 則是另外一種類似 Victim cache 的設計，它會被放置在 L1 D-Cache 前：

  

• 當一個數據第一次被使用時，它不會被馬上放進 cache，而是會先放到 Filter cache；只有等到這個數據再次被使用時，才會真的搬進 cache

• 使用 Filter cache 可以防止那些只有偶爾才會被使用的數據佔據 cache 的空間，進而提高 cache 的使用效率

2.2.5 - 預取 (Prefetch)

• 硬體預取：
  • 指令的 prefetch 是相對容易的，只要在取一個指令進 I-Cache 時，同時間也取其後的幾條指令進 I-Cache 即可
  • 因為有分支指令，所以有可能會 prefetch 錯指令，浪費 I-Cache 的空間

    • 可以將 prefetch 的指令，放到一個單獨的 buffer 中，來避免這個問題

      

      • 如果 fetch 指令時 I-Cache miss，但有在 Stream Buffer 中找到該指令，那麼 CPU 可以直接從 Stream Buffer 中讀取指令，且該指令會被搬進 I-Cache，Stream Buffer 也會繼續從 L2-Cache prefetch 後面的指令，並搬進 Stream Buffer 中
  • 數據的 prefetch 就相對困難許多，因為數據的使用是沒有一定規律的
  • 一般情況下，當 D-Cache miss 時，除了將數據從 L2 cache 中讀出來外，也會同時 prefetch 下一個數據
    • 然後，這種方法並不準確，因為有可能接下來要使用的數據，並不是 prefetch 的數據，prefetch 只是做白工
    • 這種方法目前被廣泛得使用在現代處理器中
  • Intel Pentium 4 和 IBM Power 5 的處理器中，採用了 Strided Prefetch 的機制
    • Prefetcher 可以自行觀察程式中數據使用的規律，例如第一個數據位於位址 a，第二個數據位於位址 a + 128，第三個數據位於 a + 256，那麼 Prefetcher 就可以預測接下來的數據在 a + 384、a + 512、a + 640… etc
  • Prefetcher 是否實用，還是得根據實際跑的程式而定
    • Prefetch 錯，就只是增加功耗而已
• 軟體預取：

  • 如果有支援 prefetch 指令，則軟體可以利用 prefetch 指令來提前將指令 prefetch 進 cache，e.g.

    1 2 3 4 5

    for (i = 0; i < N; i++) { prefetch(&a[i + P)]); prefetch(&b[i + P)]); sum = sum + a[i] + b[i]; }

    • 不過 prefetch 指令有可能會引起 exception，此時有兩種處理方法：
      • 處理 exception
      • 不處理 exception，直接將此 prefetch 指令轉為 NOP
        • 現代處理器大多採用此方式