第一次學 branch prediction 的時候
天真的以為最 naive 的實作方式是永遠猜不跳
cpu 會一直 pc+4 執行下去直到 branch taken/not taken 被算出來才 flush
沒想到在實際的硬體還可以選擇先停止 fetch 後面的指令
直到 branch taken/not taken 和 target 被算出來之後才繼續執行

這些選擇會實際上影響到功耗和設計複雜度
甚至可以設計成在 fetch 階段就先判斷
我們可以觀察 riscv ISA opcode 的設計
指令的 opcode field 是固定的
我們可以用簡單的 inst[6:0] == 1100011 就判斷這是不是 branch 指令
還有 branch target 也可以很簡單的用 pc + imm 算出來，不用讀任何 register
好處就是可以提前拿到 target 資訊幫助 branch prediction
在實作 CPU 的時候可以觀察到這些指令有很多設計的巧思

這次的設計主要採用 always not taken 的實作
雖然停止 fetch 的實作是對 pipeline 改動最小的實作
但是這種小麻煩才無法阻止我探索 rename recovery 機制的熱情

這幾個實作是讓新的指令停止在 dispatch 階段直到 branch resolved:

• tiny5_single_inorder
• tiny5_dual_inorder
• tiny5_dual_ooo

這個則是會讓後面的指令繼續執行，猜錯了再 cycle by cycle recover rename map

• tiny5_dual_ooo_retire

git link with tag: https://github.com/hsufit/TINY5_OOO/tree/ithome2026_D19