... | ... | @@ -77,4 +77,4 @@ |
|
|
[^4]: 分岐先バッファはキャッシュだが、タグを全部は持たないというハードウェア容量ケチり最適化がある。その最適化をした場合、分岐先バッファは嘘を言うことがある。予測を間違えてもどうせ分岐予測失敗対策のハードウェアが存在するので問題ないという思想である。そもそも、プログラムが変化すれば「このPCの命令は以前分岐命令だったから、今回もそのはず」というのは成り立たないから、分岐先バッファを全面的に信用することはできない。
|
|
|
[^5]: 商用プロセッサでは飛び先が動的に変化する分岐命令用の分岐予測器(間接分岐予測器)が使われることもある。またリターン命令はコール命令がフェッチされたのを見張っておけば十分予測可能である(リターンアドレススタックと呼ばれる技術。その場合、分岐先バッファに「コール命令か」「リターン命令か」フラグも入れたほうが良い)。
|
|
|
[^6]: 特に直列化する理由はないので、分岐先バッファに問い合わせるのと並列に分岐方向予測器にも問い合わせておけば遅延が減る。分岐先バッファに問い合わせた結果条件分岐でないと判明した場合は、分岐方向予測器の答えを単に捨てればよい。
|
|
|
[^7]: ここでは、実質ノーコストでできる「常に分岐しないと予測」を行なって、PC+4の命令を投棄的にフェッチするシチュエーションを考えている。大半の命令はそもそも分岐命令ではないから、この予測はかなり当たる。そのような場合でも、分岐命令をデコードしたサイクルは有効なフェッチが行えないという話。 |
|
|
\ No newline at end of file |
|
|
[^7]: ここでは、実質ノーコストでできる「常に分岐しないと予測」を行なって、PC+4の命令を投棄的にフェッチするシチュエーションを考えている。大半の命令はそもそも分岐命令ではないから、この予測はかなり当たる。そのような場合でも、成立する(と予測した)分岐命令をデコードしたサイクルは有効なフェッチが行えないという話。 |
|
|
\ No newline at end of file |