BP と BTP は当然密接に関連していますが、明らかに同じものではありません。あなたの最大の混乱は、BTP は特定の分岐のターゲットを予測するので、結果(つまり、次に実行される命令は何か) を教えてくれるという主張から来ていると思います。そうではありません。
ブランチ ターゲットは、このブランチが取得された場合に送信される可能性のあるアドレスです。分岐が行われるかどうかは、まったく別の問題であり、分岐予測子によって対処されます。実際、2 つのユニットは通常、パイプラインの初期段階で連携して動作し、(必要に応じて) 取得/非取得とアドレス予測の両方を生成します。次に、基本的に言う複雑なロジックがあります-それが分岐であり、それが取られると予測される（または無条件である）場合、ターゲットがある場合は（既知または予測されているかどうかにかかわらず）ターゲットにジャンプします。
ブランチタイプリストで自分自身を引用したように-ブランチが取得されることを予測する必要があるかどうか(条件付きかどうか)、およびブランチがターゲットを予測する必要があるかどうか(それは直接/固定ターゲットですか?)どちらも適用可能であり、それぞれが他に関係なく双方向に進む可能性があるため、リストした 4 つの選択肢が提供されます。
理論的には、無条件の直接分岐は予測を必要としません。CPU フロント エンドは単にターゲットを読み取り、分岐を「取得」します (新しいアドレスからパイプライン コードを供給します)。ただし、最新の CPU は、分岐をデコードし、そこにエンコードされたターゲットを識別するのに依然として時間がかかるため、分岐予測子 (通常はパイプの先頭にあります) でのストールを回避するために、そのアドレスも予測する必要があります。ただし、予測の確認は簡単なので (デコード直後)、予測ミスのペナルティはそれほど高くありません。コード キャッシュや tlb ミスが原因でまだ停止する可能性がありますが、それ以外は最速です (ただし、最も弱いと言う人もいるかもしれません)。
条件付き直接分岐は、デコード後にターゲットを認識します (ただし、その前にそれを予測する必要があります)。パイプ。これは、以前の命令に依存する可能性があり、条件の原因が判明するまで停止する可能性があります。したがって、ターゲットと方向の 2 つの予測が行われます (方向がフォールスルーの場合はターゲットは必要ありません) が、方向の解像度の方がリスクが高くなります。分岐予測子 (実際、最新の CPU には通常複数あります) は、知識に基づいた推測を行い、そこからフェッチを続けます。いくつかの研究が行われており、主にアカデミーで、両方のパスをフェッチして実行しようとすると（ただし、通常は数命令ごとに分岐があるため、これは指数関数的に爆発する可能性があることがすぐにわかります。通常、予測が難しいものに予約されています）。もう 1 つの一般的なオプションは、2 つのパスを「予測」することです (「a」に注意してください..)。つまり、パイプラインにいくつかのビットを送信して、どのパスであるかをマークし、解決策がわかったら間違ったパスを簡単にフラッシュできるようにします。これは、言語構造のためにデータフロー マシンで非常に一般的ですが、これはまったく新しい問題です。解決策がわかれば、間違ったパスを簡単にフラッシュできます。これは、言語構造のためにデータフロー マシンで非常に一般的ですが、これはまったく新しい問題です。解決策がわかれば、間違ったパスを簡単にフラッシュできます。これは、言語構造のためにデータフロー マシンで非常に一般的ですが、これはまったく新しい問題です。
ret無条件の間接分岐 - これらは両方とも一般的 (たとえば、すべて) であり、予測が難しいため厄介です。前のケースではブランチの解決は単純でしたが (そして常にいくつかのヒューリスティックまたはパターン推測に頼ることができました)、これは実際のアドレスを提供する必要があるため、おそらくこの特定のターゲットでこの特定のブランチに数回アクセスする必要があります。 BTP はそこでパターンを学習します。
条件付き間接分岐 - 運が悪かったので、両方の予測が必要です...
したがって、決定は直交していますが、それは予測子がそうでなければならないという意味ではありません。分岐履歴の単一の「ストリーム」があることに注意してください。そのため、いくつかのテーブルまたはロジックを共有して、何らかの方法で予測子を関連付けることがおそらく有効です。設計上の決定がどの程度正確であり、実際のハードウェアの実装に依存するため、Intel/AMD がどのようにそれを行うかについて詳細を知ることはおそらくないでしょうが、そのトピックに関する学術研究はたくさんあります。
2 番目の質問については、少し大まかですが、実際の CPU の正確な詳細をすべて把握することはできませんが、あちこちでヒントを得ることができます。たとえば、このHaswell レビューの図を参照してください(どこかの前にここに現れたかもしれません) :
この図ですべてがわかるわけではありません、明らかに BP/BTP の入力、またはそれらの区別さえ欠落しています (それ自体が、おそらく一緒に構築されていることをすでに示しています) が、これが明らかにパイプラインの最初で最も重要な部分であることを示しています. フェッチ/デコード/... パイプライン (または代替の uop-cache パイプライン) にフィードする前に、次の命令ポインターを予測する必要があります。これはおそらく、次にどの命令を実行するかを考えることによって、CPU がすべてのサイクルを開始することを意味します (そうです、実際にはすべてが並行して行われますが、パイプラインを段階的なプロセスと考えるのに役立ちます)。彼が私たちが前回どこにいたかを知っているとしましょう。したがって、それは非分岐命令 (ああ、しかし可変長についてはどうですか.. このユニットが解決する必要がある別の複雑さ)、または分岐のいずれかです。
私が「推測」と書いたことに注意してください - 図が真実を語っている場合、デコード段階は本当に遠くにあり、この時点ではそれが分岐であることさえ知りません. あなたの質問に答えるために-このBP / BTPユニットは実行/ WBユニットと通信する必要があるため、条件付き分岐の結果を知ることができ、デコードユニットを使用して、現在決定されている命令が分岐であり、そのタイプを知ることができますつまり、フェッチのさまざまなパイプラインを使用して、出力をフィードします。他のユニットとのさらなる関係があると推測しています（たとえば、一部の設計では、ターゲットの予測に基づいてコードのプリフェッチを送信することを決定する場合があります..）。