Issue on 0xc0de

<超標量處理器概覽> 第 11 章 - 真實世界的例子：Alpha 21264 處理器

Sat, 10 May 2025 00:00:00 +0800

11.1 - 概述

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 分別為：

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

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 保持高效率的執行

<超標量處理器概覽> 第 8 章 - 發射 (Part 2)

Sat, 19 Apr 2025 00:00:00 +0800

8.5 - 喚醒 (Wake up)

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 的設計

<超標量處理器概覽> 第 8 章 - 發射 (Part 1)

Wed, 09 Apr 2025 00:00:00 +0800

8.1 - 概述

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 的分配並沒有一個標準答案，需要根據實際的需求並分析