... | ... | @@ -18,7 +18,7 @@ |
|
|
|
|
|
普通の五段パイプラインで考えてみます。
|
|
|
分岐先バッファがなければ、フェッチしてデコードするまで分岐命令であることが分かりません。
|
|
|
したがって、分岐命令をデコードしているサイクルでフェッチされた命令は破棄しなければいけません。
|
|
|
したがって、分岐命令をデコードしているサイクルでフェッチされた命令は破棄しなければいけません[^7]。
|
|
|
つまり分岐方向予測が100%当たったとしても、分岐が成立するたびに最低1 cycleのペナルティが生じます。
|
|
|
分岐先バッファがあれば、フェッチと並行して分岐であることが分かるため、その次のサイクルのフェッチは分岐先の命令をフェッチすることができます。
|
|
|
|
... | ... | @@ -76,4 +76,5 @@ |
|
|
[^3]: 近年の商用プロセッサでは、条件分岐の場合は条件が成立したときのみ分岐先バッファに書き込むらしい(論文:https://ieeexplore.ieee.org/document/9408197 )。絶対に成立しない分岐命令 (例えば配列外アクセスであるかを検査する分岐命令など。never-taken branch)のために分岐先バッファの容量が使われることがなるという利益がある。
|
|
|
[^4]: 分岐先バッファはキャッシュだが、タグを全部は持たないというハードウェア容量ケチり最適化がある。その最適化をした場合、分岐先バッファは嘘を言うことがある。予測を間違えてもどうせ分岐予測失敗対策のハードウェアが存在するので問題ないという思想である。そもそも、プログラムが変化すれば「このPCの命令は以前分岐命令だったから、今回もそのはず」というのは成り立たないから、分岐先バッファを全面的に信用することはできない。
|
|
|
[^5]: 商用プロセッサでは飛び先が動的に変化する分岐命令用の分岐予測器(間接分岐予測器)が使われることもある。またリターン命令はコール命令がフェッチされたのを見張っておけば十分予測可能である(リターンアドレススタックと呼ばれる技術。その場合、分岐先バッファに「コール命令か」「リターン命令か」フラグも入れたほうが良い)。
|
|
|
[^6]: 特に直列化する理由はないので、分岐先バッファに問い合わせるのと並列に分岐方向予測器にも問い合わせておけば遅延が減る。分岐先バッファに問い合わせた結果条件分岐でないと判明した場合は、分岐方向予測器の答えを単に捨てればよい。 |
|
|
\ No newline at end of file |
|
|
[^6]: 特に直列化する理由はないので、分岐先バッファに問い合わせるのと並列に分岐方向予測器にも問い合わせておけば遅延が減る。分岐先バッファに問い合わせた結果条件分岐でないと判明した場合は、分岐方向予測器の答えを単に捨てればよい。
|
|
|
[^7]: ここでは、実質ノーコストでできる「常に分岐しないと予測」を行なって、PC+4の命令を投棄的にフェッチするシチュエーションを考えている。大半の命令はそもそも分岐命令ではないから、この予測はかなり当たる。そのような場合でも、分岐命令をデコードしたサイクルは有効なフェッチが行えないという話。 |
|
|
\ No newline at end of file |