Welche Verzweigungsfehlvorhersage erkennt der Branch Target Buffer?

Das ist eine gute Frage! Ich glaube, die Verwirrung, die es verursacht, ist auf Intels seltsame Benennungsschemata zurückzuführen, die oft die Begriffe in der Wissenschaft überladen. Ich werde versuchen, sowohl Ihre Frage zu beantworten als auch die Verwirrung, die ich in den Kommentaren sehe, zu klären.

Zunächst einmal. Ich stimme zu, dass in der Terminologie der Computerwissenschaften ein Verzweigungszielpuffer nicht gleichbedeutend mit Verzweigungsprädiktor ist. In der Terminologie von Intel ist der Branch Target Buffer (BTB) [in Großbuchstaben] jedoch etwas Spezifisches und enthält sowohl einen Prädiktor als auch einen Verzweigungszielpuffercache (BTBC), der nur eine Tabelle mit Verzweigungsbefehlen und deren Zielen auf einem genommenen Ergebnis darstellt. Diese BTBC verstehen die meisten Leute als Verzweigungszielpuffer [Kleinschreibung]. Also, was ist der Branch Address Calculator (BAC) und warum brauchen wir ihn, wenn wir einen BTB haben?

Sie verstehen also, dass moderne Prozessoren in Pipelines mit mehreren Stufen aufgeteilt sind. Ob dies ein einfacher Pipelineprozessor oder ein außer Betrieb befindlicher Supersclarprozessor ist, die ersten Stufen sind typischerweise holen dann decodieren . In der fetch Stufe haben wir nur die Adresse der aktuellen Anweisung, die im Programmzähler (PC) enthalten ist. Wir verwenden den PC, um Bytes aus dem Speicher zu laden und sie an die Stufe decodieren zu senden. In den meisten Fällen inkrementieren wir den PC, um die nachfolgende (n) Anweisung (en) zu laden, aber in anderen Fällen verarbeiten wir eine Kontrollflussanweisung, die den Inhalt des PC vollständig ändern kann.

Der Zweck des BTB besteht darin, zu erraten, ob die Adresse im PC auf einen Verzweigungsbefehl zeigt, und wenn ja, wie sollte die nächste Adresse im PC lauten? Das ist gut, wir können einen Prädiktor für bedingte Verzweigungen und den BTBC für die nächste Adresse verwenden. Wenn die Vorhersage richtig war, ist das großartig! Wenn die Vorhersage falsch war, was dann? Wenn der BTB die einzige Einheit ist, die wir haben, müssen wir warten, bis der Zweig die Ausgabe / execute Stufe der Pipeline erreicht. Wir müssten die Pipeline spülen und neu beginnen. Aber nicht jede Situation muss so spät gelöst werden. Hier kommt der Branch Address Calculator (BAC) ins Spiel.

Der BTB wird in der Phase fetch der Pipeline verwendet, der BAC befindet sich jedoch in der Stufe decode . Sobald der Befehl, den wir abgerufen haben, entschlüsselt ist, haben wir tatsächlich viel mehr Informationen, die nützlich sein können. Die erste neue Information, die wir kennen, ist: "Ist die Anweisung, die ich tatsächlich einen Zweig abgerufen habe?" In der Abrufphase haben wir keine Ahnung und das BTB kann nur raten, aber in der Dekodierungsstufe wissen wir es sicher. Es ist möglich, dass der BTB eine Verzweigung voraussagt, wenn die Anweisung tatsächlich keine Verzweigung ist; In diesem Fall stoppt der BAC die Abrufeinheit, korrigiert den BTB und führt das erneute Abrufen korrekt aus.

Was ist mit Zweigen wie unconditional relative und call ? Diese können bei der Dekodierung validiert werden. Der BAC prüft den BTB, prüft, ob Einträge in der BTBC vorhanden sind, und setzt den Prädiktor so, dass er ihn immer vorhersagt. Für conditional -Verzweigungen kann die BAC nicht bestätigen, ob sie bereits genommen / noch nicht genommen wurden, aber sie kann zumindest die vorhergesagte Adresse validieren und den BTB im Falle einer schlechten Adressenvorhersage korrigieren. Manchmal wird der BTB überhaupt keine Filiale erkennen / vorhersagen. Die BAC muss dies korrigieren und dem BTB neue Informationen über diese Anweisung geben. Da der BAC keinen eigenen bedingten Prädiktor hat, verwendet er einen einfachen Mechanismus (Rückwärtszweige genommen, Vorwärtszweige nicht genommen).

Jemand muss mein Verständnis dieser Hardware-Zähler bestätigen, aber ich glaube, sie meinen Folgendes:

• BACLEAR.CLEAR wird inkrementiert, wenn der BTB in fetch fehlerhaft ist Job und der BAC in decode kann es beheben.
• BPU_CLEARS.EARLY ist inkrementiert, wenn fetch (falsch) entscheidet, den nächsten zu laden Anweisung, bevor der BTB voraussagt, dass er tatsächlich von laden soll der genommene Pfad stattdessen. Dies liegt daran, dass der BTB mehrere Zyklen benötigt und holen diese Zeit verwendet, um spekulativ einen fortlaufenden Block von Befehlen zu laden. Dies kann daran liegen, dass Intel zwei BTBs verwendet, einen schneller und den anderen langsamer, aber genauer. Es dauert mehr Zyklen, um eine bessere Vorhersage zu erhalten.

Dies erklärt, warum der Nachteil der Erkennung einer Fehlvorhersage im BTB 2/3 Zyklen beträgt, während der Nachweis einer Fehlvorhersage im BAC 8 Zyklen beträgt.