-
Stand der
Technik
-
Technisches
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft Prozessoren und im Besonderen Prozessoren
mit einem oder mehreren Trace-Puffern.
-
Beschreibung
des Stands der Technik
-
Aktuelle
superskalare Prozessoren wie etwa Mikroprozessoren führen Techniken
wie etwa eine Sprung- bzw. Verzweigungsvorhersage und eine Out-of-Order-Ausführung aus,
um die Leistung zu verbessern. Prozessoren mit Out-of-Order-Ausführungs-Pipelines
führen
bestimmte Befehle in einer anderen Reihenfolge als der Reihenfolge
aus, in der die Befehle erfasst und decodiert worden sind. Beispiele
können
Out-of-Order in Bezug auf Befehle ausgeführt werden, für die keine
Abhängigkeiten existieren.
Die Out-of-Order-Ausführung
erhöht
die Prozessorleistung, indem ein Leerlauf einfach aufgrund einer
Programmbefehlsreihenfolge verhindert wird. Die Befehlsergebnisse
werden nach der Ausführung
neu angeordnet.
-
Die
Aufgabe der Behandlung bzw. Handhabung von Abhängigkeiten wird dadurch vereinfacht, dass
die Befehlsdecodierung auf in-Order
beschränkt
wird. Die Prozessoren können
danach erkennen, wie Daten von einem Befehl zu folgenden Befehlen
durch die Register verlaufen. Um eine Korrektheit des Programms
zu gewährleisten,
werden die Register umbenannt und Befehle warten in Reservierungsstationen,
bis deren Eingabeoperanden erzeugt werden, wobei sie zu diesem Zeitpunkt
an die entsprechenden Funktionseinheiten zur Ausführung ausgegeben
werden. Die Befehle der Registerumbenennungseinrichtung, der Reservierungsstationen
und der verwandten Mechanismusverknüpfungen weisen gemeinsame Abhängigkeiten
auf, so dass ein abhängiger
Befehl nicht vor dem Befehl ausgeführt wird, von dem er abhängig ist.
Demgemäß sind derartige
Prozessoren durch die In-Order-Erfassung und -Decodierung beschränkt.
-
Wenn
der Befehl aus dem Befehlscache fehlschlägt oder eine Verzweigung falsch
vorhergesehen wird, müssen
die Prozessoren entweder warten, bis der Befehlsblock aus dem Higher-Level-Cache oder Speicher
erfasst wird, oder bis die falsch vorhergesehene Verzweigung aufgelöst worden
ist, und die Ausführung
des falschen Pfads zurückgesetzt
wird. Das Ergebnis eines derartigen Verhaltens ist es, dass unabhängige Befehle
vor oder nach Fehlschlägen
des Befehlscache und falsch vorhergesehenen Verzweigungen nicht
parallel ausgeführt
werden können,
obwohl dies korrekt sein könnte.
-
"Trace Processors" von Rotenberg et
al., Proceedings of the 30th Annual IEEE/ACM International Symposium
on Microarchitecture, 1. bis 3. Dezember 1997, Seiten 138 bis 148,
offenbart einen Trace-Prozessor, der den Datenfluss unter Verwendung
der Datenprädiktion
bzw. der Datenvorhersage steuert.
-
"Instruction Issue
Logic for High-Performance, Interruptible, Multiple Functional Unit,
Pipelined Computers",
von Sohi G.S., IEEE Transactions on Computers, US, Band 39, Nr.
3, 1. März
1990, Seiten 349 bis 359, offenbart einen Prozessor mit Pipeline-Struktur,
der Abhängigkeiten
von Daten unter Verwendung von Puffern dynamisch auflöst.
-
Gemäß dem Stand
der Technik kann eine Vielzahl von Spekulationen zu Spekulationsfehlern führen. Benötigt werden
verbesserte Mechanismen in einem Prozessor, die eine Regeneration
bzw. Wiederherstellung des Prozessors aus Spekulationsfehlern ermöglichen.
-
Zusammenfassung
der Erfindung
-
Vorgesehen
ist gemäß einem
ersten Aspekt der vorliegenden Erfindung ein Prozessor gemäß dem gegenständlichen
Anspruch 1.
-
Vorgesehen
ist gemäß einem
zweiten Aspekt der vorliegenden Erfindung ein Verfahren gemäß dem gegenständlichen
Anspruch 10.
-
Kurze Beschreibung
der Zeichnungen
-
Die
Erfindung wird aus der folgenden genauen Beschreibung und aus den
beigefügten
Zeichnungen mit Ausführungsbeispielen
der Erfindung umfassender verständlich,
wobei die vorliegende Erfindung jedoch nicht auf die bestimmten
beschriebenen Ausführungsbeispiele
beschränkt
ist, wobei die Ausführungsbeispiele
vielmehr lediglich der Erläuterung
und dem Verständnis
dienen. Es zeigen:
-
1 eine
High-Level-Blockdiagrammdarstellung bestimmter Komponenten in einem
Ausführungsbeispiel
eines Prozessors;
-
2 ein
Blockdiagramm eines Prozessors gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung;
-
3 ein
Blockdiagramm eines Prozessors gemäß einem weiteren Ausführungsbeispiel
der vorliegenden Erfindung;
-
4 ein
Flussdiagramm eines Beispiels von zwei Threads bzw. Prozesssträngen;
-
5 ein
Flussdiagramm eines weiteren Beispiels von zwei Threads bzw. Prozesssträngen;
-
6 ein
Flussdiagramm eines Beispiels von vier Threads;
-
7 einen
Graphen der sich überlagernden
Ausführung
der Threads aus 6;
-
8 ein
Blockdiagramm einzelner Trace-Puffer gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung;
-
9 eine
Anordnung, welche die Programm- und Rückordnungsanordnungen zu zwei Zeitpunkten
anzeigt;
-
10 eine
Blockdiagrammdarstellung bestimmter Komponenten in einem Ausführungsbeispiel
eines Trace-Puffers aus 8;
-
11 eine
Blockdiagrammdarstellung bestimmter Komponenten in einem weiteren
Ausführungsbeispiel
eines Trace-Puffers aus 8;
-
12 eine
grafische Darstellung von Abschnitten eines Ausführungsbeispiels einer Befehlswarteschlangenanordnung
des Trace-Puffers aus 10;
-
13 eine
grafische Darstellung von Abschnitten eines Ausführungsbeispiels einer Daten- und
Abhängigkeitsanordnung
des Trace-Puffers aus 10;
-
14 ein
Ausführungsbeispiel
von Modifikationsregistern und eines modifizierten Registers, das
bei der Erzeugung des Abhängigkeitsfelds
der Anordnung aus 10 verwendet wird;
-
15 ein
logisches ODER-Gatter, das zur Erzeugung des Abhängigkeitsfelds der Anordnung aus 13 verwendet
wird;
-
16 ein
Flussdiagramm eines Ausführungsbeispiels
der Operationen, die zur Erzeugung des Abhängigkeitsfelds der Anordnung
aus 13 verwendet werden;
-
17 eine
grafische Darstellung eines bestimmten Registers und von Positionen
in einem Trace-Puffer, der diesbezüglich Abhängigkeiten gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung aufweist;
-
18 eine
grafische Darstellung von Abschnitten eines Ausführungsbeispiels einer Ausgaberegisterdatei
des Trace-Puffers
aus 10;
-
19 eine
grafische Darstellung von Abschnitten eines Ausführungsbeispiels einer Eingaberegisterdatei
des Trace-Puffers
aus 10;
-
20 ein
Blockdiagramm eines Komparators und einer Wiedergabeauslöselogik,
die in Verbindung mit der Ausgaberegisterdatei aus 18 und
der Eingaberegisterdatei aus 19 gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung verwendet wird;
-
21 ein
Flussdiagramm von Punkten, an denen der Inhalt der Ausgaberegisterdatei
verwendet werden kann;
-
22 ein
Blockdiagramm einzelner Speicheranordnungspuffern (MOBs als englische
Abkürzung
von Memory Order Buffers) in dem MOB aus 2 gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung;
-
23 eine
grafische Darstellung von Abschnitten eines Ausführungsbeispiels eines Speicherpuffers
eines der MOBs aus 22;
-
24 eine
grafische Darstellung von Abschnitten eines Ausführungsbeispiels eines Ladepuffers
eines der MOBs aus 22;
-
25 einen
Komparator, der Adressen von Lade- und Speicherbefehlen vergleicht;
-
26 einen
Komparator, der Adressen von Speicher- und Ladebefehlen vergleicht;
-
27 eine
Blockdiagrammdarstellung eines MOB-Steuerschaltkreises und von Speicherpuffern
gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung;
-
28 eine
Blockdiagrammdarstellung eines MOB-Steuerschaltkreises und von Ladepuffern gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung;
-
29 ein
Flussdiagramm eines Beispiels von sechs Threads;
-
30 einen
Baum, der eine Beziehung der Threads aus 29 zum
Zeitpunkt t1 veranschaulicht;
-
31 einen
Baum, der eine Beziehung der Threads aus 29 zum
Zeitpunkt t2 veranschaulicht, wobei angenommen wird, dass der Thread
T4 zurückgesetzt
wird, bevor der Thread T1 rückgeordnet
wird;
-
32 einen
Baum, der eine Beziehung der Threads aus 29 zum
Zeitpunkt t2 veranschaulicht, wobei angenommen wird, dass der Thread
T1 rückgeordnet
wird, bevor der Thread T4 zurückgesetzt
wird;
-
33 einen
Baum, der eine Beziehung der Threads aus 29 zum
Zeitpunkt t3 veranschaulicht;
-
34 ein
Flussdiagramm eines Beispiels von fünf Threads;
-
35 einen
Baum, der eine Beziehung der Threads aus 34 zum
Zeitpunkt t1 veranschaulicht;
-
36 einen
Baum, der eine Beziehung der Threads aus 34 zum
Zeitpunkt t2 veranschaulicht;
-
37 eine
Blockdiagrammdarstellung eines Prozessors gemäß einem alternativen Ausführungsbeispiel
zu dem Ausführungsbeispiel
aus 2; und
-
38 ein
Computersystem, das den Prozessor aus 2 aufweist.
-
Genaue Beschreibung
der bevorzugten Ausführungsbeispiele
-
- A. Erzeugung von Threads und Übersicht über die Pipeline 108
- B. Einzelheiten zu den Trace-Puffern 114
1. Trace-Puffer 114A
a.
Befehlswarteschlangenanordnung 202A
b. DAD-Anordnung 206A und
Abhängigkeitserzeugungsschaltung 212A
c.
Ausgaberegisterdatei 210A und Eingaberegisterdatei 208A
2.
Trace-Puffer 114'
- C. Ein Wiedergabesequenzalgorithmus
- D. Zweite Ebene oder abschließende Rückordnung
- E. Speichersystem
1. Speicherpuffer und Ladepuffer
2.
Vergleiche von Lade- und Speicheradressen
a. Ausführung von
Ladebefehlen
b. Ausführung
von Speicherbefehlen
c. Zurücksetzung
bzw. Reset
3. Wiedergabe von Speicherbefehlen
4. Wiedergaben
von mehreren Ladebefehlen
5. Abschließende Rückordnung von Lade- und Speicherbefehlen
- F. Zusätzliche
Informationen zur Thread-Managementlogik und abschließenden Rückordnungslogik
- G. Ein Ausführungsbeispiel
ohne Multithreading
- H. Zusätzliche
Informationen und Ausführungsbeispiele
-
Die
Abbildung aus 1 veranschaulicht bestimmte
Komponenten eines Prozessors 10. Der Prozessor 10 weist
eine Ausführungs-Pipeline 12 und
einen Trace-Puffer 14 auf, der sich außerhalb der Ausführungs-Pipeline 12 befindet.
Die Ausführungs-Pipeline 12 kann
einen Speicheranordnungspuffer aufweisen. Befehle an den Leitern 18 werden zur
Ausführung
an die Ausführungs-Pipeline 12 bereitgestellt.
Die Befehle werden ferner durch die Leiter 22 dem Trace-Puffer 14 bereitgestellt.
Die Befehle können
in der Ausführungs-Pipeline 12 spekulativ ausgeführt werden.
Beispiele für
die Spekulation sind die Datenspekulation und die Abhängigkeitsspekulation.
Jede Spekulation einer Vielzahl möglicher Spekulationen kann
dabei einbezogen werden. Der Prozessor 10 weist Mechanismen
auf, auch in dem Trace-Puffer 14, um Spekulationsfehler
(Fehlspekulationen) zu detektieren und eine entsprechende Behebung
vorzusehen.
-
Wenn
eine Fehlspekulation detektiert wird, wird der fehlerhaft spekulierte
Befehl von dem Trace-Puffer 14 durch die Leiter 24 an
die Ausführungs-Pipeline 12 vorgesehen
und in der Ausführungs-Pipeline 12 erneut
wiedergegeben. Wenn ein Befehl "erneut
wiedergegeben" wird,
werden der Befehl und alle von dem Befehl abhängigen Befehle erneut ausgeführt, wobei
dies jedoch nicht unbedingt gleichzeitig erfolgen muss. Wenn ein
Befehl "vollständig erneut
wiedergegeben" wird,
so werden der Befehl und alle Befehle, die in der Programmreihenfolge
auf den Befehl folgen, erneut ausgeführt. Die Programmreihenfolge
ist die Reihenfolge, in der Befehle in einem In-Order- Prozessor ausgeführt werden
würden.
Befehle können
vollständig
in der Programmreihenfolge oder in einer anderen Reihenfolge als
der Programmreihenfolge durch die Leiter 18 verlaufen.
Bei dem Prozessor 10 kann es sich um einen In-Order- oder
um einen Out-of-Order-Prozessor handeln. Die erneute Ausführung eines
abhängigen Befehls
kann zu Befehlen führen,
die von dem erneut wiedergegebenen abhängigen Befehl abhängig sind. Die
Anzahl der erneuten Ausführungen
von Befehlen kann durch Steuerung bzw. Regelung der Ereignisse geregelt
bzw. gesteuert werden, welche die erneuten Wiedergaben auslösen. Allgemein
kann der Begriff Ausführen
bzw. Ausführung
die ursprüngliche
Ausführung
und die erneute bzw. wiederholte Ausführung umfassen. Ergebnisse
zumindest eines Teils der Befehle werden durch die Leiter 26 an
den Trace-Puffer vorgesehen. Die abschließende Rückordnungslogik 34 führt die
abschließende
Rückordnung von
Befehlen in dem Trace-Puffer 14 aus, nachdem angenommen
worden ist, dass die Befehle entweder ursprünglich oder in erneuter Ausführung korrekt ausgeführt worden
sind.
-
Bei
der Ausführungs-Pipeline 12 kann
es sich um jede einer Vielzahl möglicher
Ausführungs-Pipelines
handeln, wobei es sich ferner auch um eine Sektion einer größeren Pipeline
handeln kann. Die Ausführungs-Pipeline 12 kann
in Verbindung mit einer Vielzahl verschiedenartiger Prozessoren
verwendet werden. Die Abbildung aus 2 weist
Beispiele auf, in der Komponenten eines Prozessors 50 mit
einer Ausführungs-Pipeline 108 dargestellt
sind, wobei die Abbildung aus 3 einen Prozessor 100 mit
einer Ausführungs-Pipeline 308 veranschaulicht.
In dem Ausführungsbeispiel
der vorliegenden Erfindung aus 2 weist
die Ausführungs-Pipeline 108 eine
Registerumbenennung auf. In anderen Ausführungsbeispielen weist die
Ausführungs-Pipeline
keine Registerumbenennung auf. Der Prozessor kann gleichzeitig mehrere
Threads bzw. Prozessstränge
verarbeiten (wie der Prozessor 50 aus 2),
wobei er aber mehrere Threads aber auch nicht gleichzeitig ausführen kann
(wie der Prozessor 100 aus 3). Der
Prozessor 50 wird zuerst erörtert.
-
Verweise
in der vorliegenden Patentschrift auf "ein Ausführungsbeispiel" bedeuten, dass ein
in Bezug auf ein Ausführungsbeispiel
beschriebenes bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft
in mindestens einem Ausführungsbeispiel
der Erfindung enthalten ist. Das Vorkommen der Phrase "in einem Ausführungsbeispiel" an verschiedenen
Stellen in der vorliegenden Patentschrift bezieht sich nicht notwendigerweise
immer auf ein und dasselbe Ausführungsbeispiel.
-
A. Erzeugung von Threads
und Übersicht über die Pipeline 108
-
Befehle
werden durch die Leiter 102 an einen Befehlscache (I-Cache) 104 bereitgestellt.
Ein Decodierer 106 ist dargestellt, der Befehle von dem I-Cache 104 empfängt, wobei
die Befehle alternativ jedoch auch decodiert werden können, bevor
sie den I-Cache 104 erreichen. Abhängig von dem Kontext und der
ausgewählten
Implementierung kann der Begriff "Befehle" Makrooperationen (Makro-Ops), Mikrooperationen
(Mikro-Ops) oder eine andere Befehlsform aufweisen. Verwendet werden
kann eine Vielzahl von Befehlssätzen,
wie unter anderem, ohne. darauf beschränkt zu sein, RISC-Befehle (RISC als
englische Abkürzung
von Reduced Instruction Set Computing) oder CISC-Befehle (CISC als englische Abkürzung von
Complex Instruction Set Computing). Ferner kann der Decodierer 106 CISC-Befehle
in RISC-Befehle decodieren. Die Befehle aus dem I-Cache 104 werden
durch den MUX 110 an die Pipeline 108 und durch
die Leiter 118 an die Trace-Puffer 114 vorgesehen.
-
Ein
Trace ist ein Befehlssatz. Ein Thread umfasst den Trace und verwandte
Signale wie etwa Registerwerte und Programmzählerwerte.
-
Die
Thread-Management-Logik 124 erzeugt verschiedene Threads
von einem Programm oder Prozess in dem I-Cache 104, indem
Anfangszählwerte
an die Programmzähler 112A, 112B,
..., 112X über die
Leiter 130 vorgesehen werden (wobei X die Anzahl der Programmzähler anzeigt).
Als ein Beispiel kann X 4 oder einem höheren bzw. einem niedrigeren Wert
entsprechen. Die Thread-Management-Logik 124 beendet
ferner Threads, indem der zugeordnete Programmzähler angehalten wird. Die Thread-Management-Logik 124 kann
bewirken, dass der Programmzähler
einen weiteren Thread startet. Teile bzw. Abschnitte verschiedener
Threads werden gleichzeitig aus dem I-Cache 104 ausgelesen.
-
Zur
Bestimmung, wo in einem Programm oder Prozess ein Thread erzeugt
werden soll, kann die Thread-Management-Logik 124 über die
Leiter 128 Befehle aus dem Decodierer 106 lesen.
Die Threads können
Befehle aufweisen, die von einem Programmierer oder einem Kompilierer
eingegeben worden sind, welchen den Anfang und das Ende von Threads
ausdrücklich
demarkieren. Alternativ kann die Thread-Management-Logik 124 Befehle
des Programms oder des Prozesses analysieren, um ein dem I-Cache 104 zugeführtes Programm
oder einen entsprechenden Prozess in verschiedene Threads aufzuteilen.
Gute Stellen für
eine Aufteilung von Threads sind zum Beispiel Verzweigungen, Schleifen,
Rückwärtsverzweigungen,
Rücksprünge, Sprünge, Prozeduraufrufe
und Funktionsaufrufe. Die Thread-Management-Logik 124 kann die Länge eines
potenziellen Threads berücksichtigen,
wie viele Variablen involviert sind, die Anzahl der Variablen, die
aufeinander folgende Threads gemeinsam haben sowie sonstige Faktoren
zur Berücksichtigung,
wo ein Thread beginnen soll. Die Thread-Management-Logik 124 kann
die Programmreihenfolge bei der Bestimmung der Begrenzungen von
Threads berücksichtigen.
Die Programmreihenfolge ist die Reihenfolge der Threads, und die Befehle
in den Threads würden
in einem In-Order-Prozessor ausgeführt. Die Befehle in den Threads
können
Out-of-Order (im Gegensatz zu der Programmreihenfolge) ausgeführt werden.
Die Threads können
von der Pipeline 108 im Wesentlichen unabhängig ausgeführt werden. Die Thread-Management-Logik 124 kann
einen Prädiktionsmechanismus
aufweisen, einschließlich
einer Stamm- bzw.
Verlaufstabelle, um es zu vermeiden, dass suboptimale Entscheidungen
getroffen werden. Wenn in diesem Fall der gleiche Code auftritt,
kann der Prädiktionsmechanismus
dazu verwendet werden, zu bestimmen, ob der gleiche Thread erneut
erzeugt werden soll. Die Thread-Management-Logik 124 kann
eine Kombination aus einer dynamischen Erzeugung von Threads und
der Nutzung ausdrücklicher
Befehlshinweise von einem Kompilierer oder Programmierer einsetzen,
um zu bestimmen, an welchen Stellen in den Befehlen Threads erzeugt
werden sollen.
-
Bei
der dynamischen Erzeugung von Threads werden Threads aus einem Programm
erzeugt, das nicht speziell für
das Multithreading geschrieben oder kompiliert worden ist, wobei
mindestens einer der Threads von einem anderen Thread abhängig ist.
Das Programm kann von einem Chip stammen, der die Ausführungs-Pipeline 108 und
die Thread-Management-Logik 124 aufweist. Das dynamische
Erzeugen der Threads, das Ausführen
der Threads und das Detektieren und Korrigieren von Spekulationsfehlern
in der Ausführung
wird als dynamisches Multithreading bezeichnet.
-
Die
Abbildung aus 4 veranschaulicht einen Thread
T1, der einen bedingten Rückwärtsverzweigungsbefehl
aufweist. In der Programmreihenfolge wird der Thread T2 nach dem
bedingten Verzweigungsbefehl ausgeführt. In zeitlicher Reihenfolge
wird der Thread T2 spekulativ ausgeführt, beginnend mit dem Zeitpunkt,
an dem der Thread T1 zuerst den bedingten Verzweigungsbefehl erreicht.
Somit werden Abschnitte bzw. Teile der Threads T1 und T2 gleichzeitig
ausgeführt.
Wenn der Thread T2 Fehlspekulationen aufweist, so werden die betroffenen Befehle
des Threads T2 erneut wiedergegeben.
-
Die
Thread-Management-Logik 124 kann den Zählwert der Programmzähler durch
die Leiter 130 überwachen.
Ein Zweck für
die Überwachung des
Zählwerts
ist es zu bestimmen, wann ein Thread enden soll. Wenn der Zustand
der bedingten Verzweigung zum Beispiel nicht erfüllt wird, wenn der Programmzähler des
Threads T1 fortgeführt
wird, so würde
er zu dem ersten Befehl aus Thread T2 springen. Die Thread-Management-Logik 124 hält somit den
Programmzähler
des Threads T1 an, wenn die Bedingung nicht erfüllt ist.
-
Die
Abbildung aus 5 veranschaulicht einen Thread
T1, der einen Funktionsaufrufbefehl aufweist. Wenn in der Programmreihenfolge
der Aufrufbefehl erreicht wird, so springt der Programmzähler zu
der Position der Funktion und führt
bis zu einem Rücksprungbefehl
aus, wobei der Programmzähler zu
diesem Zeitpunkt zu dem Befehl. nach dem Aufruf zurückkehrt.
In der Programmreihenfolge beginnt der Thread T2 an dem Befehl,
der auf den Rücksprung folgt.
In zeitlicher Reihenfolge wird der Thread T2 spekulativ ausgeführt, beginnend
zu dem Zeitpunkt, zu dem der Thread T1 zuerst den Aufruf erreicht. Wenn
der Thread T2 Fehlspekulationen aufweist, so werden die bewirkten
Befehle des Threads T2 erneut wiedergegeben. Der Thread T1 endet,
wenn dessen Programmzähler
den ersten Befehl des Threads T2 erreicht. Die Befehle MX Laden
und MX Speichern aus 5 werden nachstehend näher erörtert.
-
Die
Abbildung aus 6 veranschaulicht die Threads
T1, T2, T3 und T4, die Teil einer Sektion bzw. eines Abschnitts
eines Programms sind. Verschiedene Programmzähler erzeugen die Threads T1,
T2, T3 und T4. Der Thread T1 weist Befehle an den Punkt A (Funktionsaufrufbefehl)
und in der Folge von dem Punkt B zu dem Punkt C (bedingter Rückwärtsverzweigungsbefehl)
auf, zu dem Punkt D und wieder zu dem Punkt C (die Schleife kann
mehrmals wiederholt werden). Der Thread T2 beginnt bei dem Befehl
in der Programmreihenfolge, der unmittelbar auf den Rücksprungbefehl
der Funktion folgt, die zu dem Punkt A aufgerufen wird. Der Thread
T3 beginnt bei dem Befehl, der in der Programmreihenfolge direkt
auf die bedingte Rückwärtsverzweigung
von Punkt C folgt und zu dem Punkt E, zu dem Punkt F, zu dem Punkt
G, zu dem Punkt H und zu dem Punkt I fortfährt, wobei es sich um einen
Rücksprungbefehl zu
dem Befehl handelt, der unmittelbar auf den Punkt A folgt, wo der
Thread T2 beginnt. Der Thread T4 beginnt bei dem Befehl, der in
der Programmreihenfolge unmittelbar auf die bedingte Rückwärtsverzweigung
an dem Punkt E folgt.
-
Wie
dies in der Abbildung aus 7 dargestellt
ist, werden Abschnitte der Threads T1, T2, T3 und T4 gleichzeitig
erfasst, decodiert und ausgeführt. Die
Threads werden Out-of-Order erfasst, decodiert und ausgeführt, da
die Programmreihenfolge nicht eingehalten wird. In zeitlicher Reihenfolge
beginn die Ausführung
der Threads T2, T3 und T4 unmittelbar nach den entsprechenden Befehlen
an den Punkten A, C und E. Die vertikalen gestrichelten Linien zeigen ein
Eltern-Kind-Verhältnis. Die
Threads T2, T3 und T4 werden spekulativ ausgeführt, indem sich auf Daten in
Registern und/oder an Speicherplätzen
verlassen wird, bevor es sicher ist, dass die Daten korrekt sind.
Der Prozessor 100 weist Mechanismen zum Detektieren von
Fehlspekulationen auf, und wobei die Mechanismen die erneute Wiedergabe
von fehlspekulierten Befehlen bewirken. Es folgt, dass der Thread
T4 kein Bestandteil der Programmreihenfolge ist. Der Thread T4 kann
ausgeführt
werden, bis die Thread-Management-Logik 124 bestimmt, dass
der Thread T4 kein Bestandteil der Programmreihenfolge ist. Zu diesem
Zeitpunkt kann der Thread T4 zurückgesetzt
werden, und die Ressourcen, die den Thread T4 in dem Prozessor 100 speichern
oder verarbeiten, können freigegeben
und danach für
einen anderen Thread zugeordnet werden. In der Programmreihenfolge
würden
die Threads T1, T2 und T3 wie folgt ausgeführt: zuerst der Thread T1,
gefolgt von dem Thread T3 und danach dem Thread T2.
-
In
Bezug auf die Abbildung aus 2 werden
Befehle von dem MUX 110 von einer Umbenennungs-/Zuordnungseinheit 150 empfangen,
die eine physikalische Registeridentifikation (PRID) des umbenannten
physikalischen Registers in der Registerdatei 152 vorsieht.
Die PRID wird über
Umgehungsleiter 126 an den Trace-Puffer 114 bereitgestellt.
Die Zuordnung umfasst die Zuweisung von Registern an die Befehle
und die Zuweisung von Einträgen
der Reservierungsstationen der Scheduling-/Ausgabeeinheit 156.
Nachdem die Operanden für
einen bestimmten Befehl in den Reservierungsstationen bereit sind,
wird der Befehl an eine der Ausführungseinheiten
(z.B. ganzzahlig, Gleitkomma) der Ausführungseinheiten 158 oder
eine Speicherausführungs-Pipeline
ausgegeben, die eine Adresserzeugungseinheit (AGU) 172,
einen Speicheranordnungspuffer (MOB) 178 und einen Datencache 176 aufweist.
Abhängig
von den Befehlen können
Operanden aus der Registerdatei 152 durch die Leiter 168 vorgesehen
werden. Gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung können
abhängige
Befehle in einem Thread so verknüpft
werden, dass sie nicht Out-of-Order ausgeführt werden. Abhängige Befehle
aus verschiedenen Threads können
jedoch gleichzeitig Out-of-Order erfasst, decodiert und ausgeführt werden.
Die Ausführung
bestimmter Threads kann spekulativ erfolgen.
-
Für eine hohe
Leistungsfähigkeit
sind die Reservierungsstationen und die verwandten Mechanismen so
gestaltet bzw. konfiguriert, dass sie Befehle mit einer niedrigen
Latenzzeit und mit hoher Bandbreite ausgeben. Die Anforderungen
in Bezug auf die Latenzzeit und die Bandbreite sehen Einschränkungen
in Bezug auf die Anzahl der Befehle vor, die in den Reservierungsstationen
warten können.
Durch die Positionierung der Trace-Puffer 114 außerhalb der
Pipeline 108 kann eine große Anzahl von Befehlen zur
Ausführung/zur
erneuten Wiedergabe zur Verfügung
stehen, ohne dabei den Durchsatz der Pipeline 108 signifikant
zu verringern. Der Effekt der Latenzzeit zwischen der Ausführungs-Pipeline 108 und
den Trace-Puffern 114 kann durch die Pipeline-Verarbeitung
reduziert werden.
-
Das
Ergebnis einer Ausführung
und verwandter Informationen wird aus einer Writeback-Einheit 162 durch
die Leiter 122 (im Fall von Registern) und durch den MUX 192 und
die Leiter 196 zu den Trace-Puffern 114 geschrieben
werden. Die Ergebnisse und verwandte Informationen können ebenfalls in
die Registerdatei 152 und einen zugeordneten Umordnungspuffer
(ROB) 164 geschrieben werden. Sobald das Ergebnis und Informationen
eines Befehls in die Registerdatei 152 und den ROB 164 geschrieben worden
sind, wird der Befehl in der Reihenfolge rückgeordnet, soweit dies die
Pipeline 108 betrifft. Diese Rückordnung (englisch: Retirement)
wird als erste Ebene oder erste Rückordnung bezeichnet. Bei oder vor
der Rückordnung
der ersten Ebene werden die Ressourcen für den rückgeordneten Befehl in der Scheduling-/Ausgabeeinheit 156 einschließlich der Reservierungsstationen,
der Registerdatei 152 und dem ROB 164 freigegeben.
Allerdings werden alle erforderlichen Details in Bezug auf den Befehl
in Trace-Puffern 114 gespeichert
und in dem MOB 178, bis eine endgültige Rückordnung erfolgt, wie dies
nachstehend im Text beschrieben ist.
-
Es
existiert eine Abhängigkeit
zwischen einem späteren
Thread und einem früheren
Thread, wenn sich diese in der Programmreihenfolge befinden, wobei
in dem späteren
Thread verwendete Daten in dem früheren Thread erzeugt werden.
Die Daten können
in dem früheren
Thread durch einen Speicherbefehl oder einen speicherfremden Befehl erzeugt
werden. Zum Beispiel kann der spätere Thread
von dem früheren
Thread abhängig
sein, wenn ein Ladebefehl in dem späteren Thread die gleiche Adresse
aufweist wie ein Speicherbefehl in dem früheren Thread. Der spätere Thread
kann auch von dem früheren
Thread abhängig
sein, wenn ein Befehl in dem späteren
Thread ein Register aufweist, das in dem früheren Thread modifiziert worden
ist. In ähnlicher
Weise ist ein späterer
Befehl von einem früheren
Befehl abhängig,
wenn der spätere
Befehl in der Programmreihenfolge Daten verwendet, die durch den
früheren
Befehl erzeugt worden sind. Das Wort "Abhängigkeit" wird auch in der
Phrase "Abhängigkeitsspekulation" verwendet. Ein Beispiel
für eine Abhängigkeitsspekulation
ist die Spekulation, dass zwischen einem Ladebefehl und einem früheren Speicherbefehl
keine Abhängigkeit
existiert. Die Adressabstimmung ist ein Beispiel für eine Technik zur
Prüfung
auf Abhängigkeitsspekulationsfehler.
Ein Beispiel für
eine Datenspekulation ist die Spekulation, dass die Daten in einem
Register die korrekten Daten sind. Die Registerabstimmung ist ein
Beispiel für
eine Technik zur Prüfung
auf Datenspekulationsfehler.
-
B. Einzelheiten zu den
Trace-Puffern 114
-
In
Bezug auf die Abbildung aus 8 weisen die
Trace-Puffer 114 die Trace-Puffer 114A, 114B, 114C,
..., 114Y auf, wobei Y die Anzahl der Trace-Puffer darstellt.
Wenn Y zum Beispiel gleich 4 ist (d.h. Y = D), so existieren insgesamt
vier (4) Trace-Puffer. Wenn Y kleiner ist als 3, so umfassen die Trace-Puffer 114 nicht
alle in der Abbildung aus 8 dargestellten
Trace-Puffer. Y kann mit X (der Anzahl der Programmzähler übereinstimmen
oder sich von X unterscheiden. Die Trace-Puffer 114 können einen
einzelnen Speicher darstellen, der in einzelne Trace-Puffer unterteilt
ist, oder es kann sich um physikalisch getrennte Trace-Puffer handeln
sowie um eine Kombination der beiden Möglichkeiten.
-
In
Bezug auf die Abbildung aus 9 weist die
Thread-Management-Logik 124 in
einem Ausführungsbeispiel
eine Anordnung bzw. Array 198 auf, welche die Programmreihenfolge
(die auch der Rückordnungsreihenfolge
entspricht) der Thread-IDs
spezifiziert. In dem Beispiel weist jeder Trace-Puffer eine eindeutige
Thread-ID bzw. Thread-Kennung auf oder eine Eins-zu-Eins-Abbildung
auf eine Thread-ID. Zum Beispiel wird dem Trace-Puffer 114A die Thread-ID
1 zugewiesen, dem Trace-Puffer 114B wird
die Thread-ID 2 zugewiesen, etc. Die Thread-IDs können fest verdrahtet oder programmiert
sein. In einem Ausführungsbeispiel
sind jedem Programmzähler
eine bestimmte Thread-ID und ein Trace-Puffer zugeordnet. (Alternativ
ist keine derartig eingeschränkte
Beziehung gegeben.) Die Abbildung aus 9 zeigt
ein Beispiel der Rückordnungsreihenfolge
der Threads zum Zeitpunkt t1 und Zeitpunkt t2. In dem Beispiel sind
nur vier Trace-Puffer und vier Thread-IDs gegeben. Die zugeordneten Thread-Nummern
sind in Klammern dargestellt. Abhängig von der Implementierung
ist die Thread-Nummer in Klammern nicht tatsächlich in der Anordnung bzw.
der Array 198 vorgesehen. Zum Zeitpunkt t1 lautet die Programm-
und die Rückordnungsreihenfolge
Thread T1, T3, T2 und T4 wie in dem Beispiel aus 6.
Zwischen dem Zeitpunkt t1 und dem Zeitpunkt t2 wird bestimmt, dass
sich der Thread T4 nicht in der Programmreihenfolge befindet. Der
Thread T4 wird somit zurückgesetzt,
wobei Platz für
den Thread T5 (in der Abbildung aus 5 nicht
dargestellt) in dem Trace-Puffer 114D geschaffen wird.
Der Thread T5 ist der Thread-ID 4 zugeordnet. Der Thread T1 wird
rückgeordnet
und macht Platz für
den Thread T6 in dem Trace-Puffer 114A. Der Thread T6 ist
der Thread-ID 1 zugeordnet: Zum Zeitpunkt t2 lautet die Programm-
und Rückordnungsreihenfolge
Thread T3, T2, T5 und T6. (Wenn der Thread T1 rückgeordnet wird, bevor der
Thread T4 zurückgesetzt
worden ist, so weisen die Threads T5 und T6 unterschiedliche Thread-IDs
auf, wobei sich die Programm- und Rückordnungsreihenfolge nicht ändern würde.) Abhängig von
dem verwendeten Algorithmus kann es sein, dass der Thread T2 ursprünglich in
der Anordnung 198 vor dem Thread T3 gelegen hat, wobei
die Programm- und Rückordnungsreihenfolge
jedoch ebenso wie die Anordnung 198 zum Zeitpunkt t1 berichtigt
werden würde.
-
Wie
dies bereits vorstehend im Text erwähnt worden ist entspricht die
Programmreihenfolge der Threads der Reihenfolge, in der die Threads
in einem In-Order-Prozessor ausgeführt werden würden. Die Programmreihenfolge
der Befehle ist die Reihenfolge, in der die Befehle in einem In-Order-Prozessor ausgeführt werden
würde.
Die Thread-Management-Logik 124 bestimmt anfangs nicht
unbedingt die echte Programmreihenfolge für die Threads. Die Thread-Management-Logik 124 bestimmt
jedoch letztendlich die wirkliche Programmreihenfolge.
-
In
Bezug auf die Abbildung aus 8 empfangen
die Trace-Puffer 114A, 114B,
..., 114Y Befehle über
die Leiter 118A, 118B, ..., 118Y, die
mit den Leitern 118 verbunden sind. Es kann eine Demultiplexing-Schaltkreisanordnung
zwischen den Leitern 118A, 118B, ..., 118Y und
den Leitern 118 vorhanden sein. Alternativ können Freigabesignale
steuern bzw. regeln, welcher Trace-Puffer aktiviert wird. Wiederum alternativ
können
genügend
parallele Leiter gegeben sein, um parallele Transaktionen zu behandeln.
Die Trace-Puffer 114A, 114B, ..., 114Y sehen
Befehle und verwandte Informationen zur Wiedergabe über die
Leiter 120A, 120B, ..., 120Y an die Pipeline 108 vor,
wobei diese Leiter mit den Leitern 120 verbunden sind.
Hiermit wird festgestellt, dass mehrere Befehle von den Trace-Puffern 114 gleichzeitig
zur erneuten Ausführung
durch die Leiter 120 und den MUX 110 verlaufen
können.
Gleichzeitig können
mehrere Befehle von dem Decodierer 106 auch zum ersten
Mal durch den MUX 110 verlaufen. Eine Thread-ID und eine
Befehlskennung (Befehls-ID) begleiten jeden Befehl durch die Pipeline.
Ein Wiedergabezählwert kann
ebenfalls den Befehl begleiten. Im Falle von Lade- und Speicherbefehlen
können
auch eine Ladepufferkennung (LBID) und eine Speicherpufferkennung
(SBID) den Befehl begleiten. In einem Ausführungsbeispiel begleiten die
LBID und die SBID jeden Befehl, obwohl die Werte der LBID und der
SBID bei Befehlen bedeutungslos sein können, die keine Lade- oder
Speicherbefehle sind. Wie dies nachstehend im Text beschrieben ist,
kann ein erneut ausgeführter
Befehl auch von einer PRID oder einem Wert begleitet sein.
-
Die
Trace-Puffer 114A, 114B, ..., 114Y empfangen
die Werte der PRID, der LBID und der SBID von der Umbenennungs-/Zuordnungseinheit 150 über die
Umgehungsleiter 126A, 126B, ..., 126Y,
die mit den Leitern 126 verbunden sind. Die Trace-Puffer 114A, 114B,
..., 114Y empfangen Writeback-Ergebnisinformationen und verwandte
Signale über
die Leiter 122A, 122B, ..., 122Y, die
mit den Leitern 122 verbunden sind, und über die
Leiter 196A, 196B, ..., 196Y, die mit
den Leitern 196 verbunden sind. Wiedergabesignale werden
durch die Leiter 194A, 194B, ..., 194Y vorgesehen,
die mit den Leitern 194 verbunden sind. Eine Multiplexing-
und/oder Freigabeschaltkreisanordnung und/oder eine erhebliche Anzahl
paralleler Leiter können
in den Leitern 120, 126, 122, 194 und 196 verwendet
werden. Die Trace-Puffer können
identisch sein oder sich in gewisser Weise unterscheiden.
-
In
der Abbildung aus 10 veranschaulicht der Trace-Puffer 114A ein
erstes Ausführungsbeispiel
eines Trace-Puffers. In der Abbildung aus 11 veranschaulicht
der Trace-Puffer 114' ein zweites
Ausführungsbeispiel
eines Trace-Puffers. Weitere Ausführungsbeispiele von Trace-Puffern können verschiedene
Variationen der Trace-Puffer 114A und 114A' oder eine deutlich
andere Architektur aufweisen.
-
1. Trace-Puffer 114A
-
In
Bezug auf die Abbildung aus 10 weist der
Trace-Puffer 114A eine Befehlswarteschlangenanordnung 202A,
eine Daten- und Abhängigkeitsanordnung
(DAD-Array) 206A, eine Eingaberegisterdatei 208A,
eine Ausgaberegisterdatei 210A, eine Abhängigkeitserzeugungsschaltkreisanordnung 212A und
eine Steuerschaltkreisanordnung 224A auf. Der Begriff "Anordnung" oder "Array" umfasst im weiteren Sinne
Informationen in mehrere Richtungen, ohne auf eine bestimmte Form
beschränkt
zu sein.
-
a. Befehlswarteschlangenanordnung 202A
-
In
Bezug auf die Abbildung aus 12 ist nachstehend
die Struktur einer Befehlswarteschlangenanordnung 202A und
deren Interaktion mit anderen Komponenten gemäß einem Ausführungsbeispiel
der Erfindung beschrieben. Die Befehlswarteschlangenanordnung 202A empfängt von
dem I-Cache 204 empfangene Befehle, die Teil eines bestimmten
Threads sind. Die Befehle in einem Thread werden erfasst und in
ihrer Reihenfolge in die Befehlswarteschlangenanordnung 202A geschrieben. Die
Befehle, die Teil eines anderen Threads sind, werden in eine Befehlswarteschlange
eines anderen Trace-Puffers
oder durch die Befehlswarteschlangenanordnung 202A zu einem
anderen Zeitpunkt geschrieben. Die Befehlswarteschlangenanordnung 202A weist
verschiedene Informationsfelder für jede Befehlskennung (Befehls-ID)
auf. Verschiedene Ausführungsbeispiele
können
in gewisser Weise unterschiedliche Felder und eine andere Anzahl
von Reihen aufweisen. In dem Ausführungsbeispiel der Befehlswarteschlangenanordnung 202A wird
der Befehlszählerwert nicht
berücksichtigt,
wobei dies in anderen Ausführungsbeispielen
jedoch der Fall sein kann. Die Befehlswareschlangenanordnung 202A und
alle anderen in den Zeichnungen dargestellten Komponenten können verschiedene
Felder, Signale und nicht veranschaulichte Strukturen aufweisen. Derartige
Felder, Signale und Strukturen sind nicht veranschaulicht, da sie
abhängig
von der Implementierung veränderlich
sind, wobei sie für
den Fachmann auf dem Gebiet jedoch bekannt sind und die Patentschrift
in großem
Maße komplizierter
gestalten und dazu neigen würden,
die vorliegende Erfindung zu verschleiern.
-
Befehle
warten in dem Trace-Puffer 114A, bis sie endgültig rückgeordnet
oder entsorgt werden (da zum Beispiel bestimmt wird, dass der Thread nicht
Bestandteil einer In-Order-Ausführung des
Programms ist). Wenn sich die Befehlswarteschlangenanordnung 202A füllt, während sich
in der Trace immer noch Befehle befinden, die noch nicht ausgeführt worden
sind, so werden die Befehle nicht von dem Trace-Puffer 114 oder
der Umbenennungs-/Zuordnungseinheit 150 empfangen, bis
ein Befehl endgültig
aus der Befehlswarteschlangenanordnung 202A rückgeordnet
und eine Reihe bzw. Zeile freigegeben wird. Einträge der verschiedenen
Anordnungen in dem System 100 können durch die Bewegung von Kopf-
und Endzeigern zugeordnet und freigegeben werden.
-
Die
Befehlswarteschlangenanordnung 202A wird in Bezug auf die
folgenden Codezeilen beschrieben:
I0: mul R1, R2 → R1
I1:
mul R3, R4 → R2
I2:
add R1, R2 → R1
I3:
add I0, R1 → R4
I4:
speich. R2 → Mx
I5:
speich. R1 → My,
wobei
es sich dabei um die ersten sechs Befehle in einem Thread handelt.
Es ist offensichtlich, dass ein anderer Trace-Puffer als der Trace-Puffer 114A in
der Programmreihenfolge vor dem Trace-Puffer 114A angeordnet
ist.
-
Das
Feld "Op Code" weist den Operationscode
auf, der dem bestimmten Befehl zugeordnet ist. Die Felder "Dest", "Source 1" und "Source 2" identifizieren das
Ziel, die Quelle 1 und die Quelle 2 des Befehls. Das Feld "Index für Source
1" identifiziert
Befehlseinträge
in dem Trace-Puffer 114A, welche die Quelle aufweisen.
Zum Beispiel wird das Ziel der Befehls-ID 0 für die Source 1 für die Befehls-ID
2 verwendet. Somit wird in dem Feld "Index für Source 1" der Befehls-ID 2 eine 0 platziert.
Das Ziel der Befehls-ID 2 wird für
die Source 2 für
die Befehls-ID 3 verwendet. Somit wird eine 2 in dem Feld "Index für Source
2" der Befehls-ID
3 platziert. Ein X zeigt eine Gleichgültigkeit an.
-
Die
Felder "Gültig 1" und "Gültig 2" sind Bits, die auf einen ersten Wert
gesetzt werden (z.B. eine logische 0), wenn ein entsprechender Quellenoperand
einer Befehls-ID vorher durch einen Befehl außerhalb des Threads in dem
Trace-Puffer 114A erzeugt worden ist, und auf einen zweiten
Wert (z.B. eine logische 1), wenn der Quellenoperand für eine Befehls-ID
vorher durch einen Befehl in dem Thread erzeugt worden ist. Die
Quelle bzw. Source 1 (R1) der Befehls-ID 0 wird außerhalb
der Trace in der Befehlswarteschlangenanordnung 202A erzeugt.
Gemäß entspricht
ein Gültig
1 der Befehls-ID 0 einer logischen 0. Die Source 2 für die Befehls-ID
3 stammt von dem Ziel der Befehls-ID 2. Demgemäß entspricht ein Gültig 2 der
Befehls-ID 3 einer logischen 1.
-
Der
Befehl I3 umfasst das Addieren von R1 zu einer Konstanten "10". Die Konstante kann
in Verbindung mit dem Befehl gespeichert werden, und zwar in einem
besonderen Register (nicht abgebildet), in dem Feld Source 1 oder
durch einen anderen Mechanismus. In der Abbildung aus 12 ist
ein X (Gleichgültigkeit)
in dem Feld Source 1 für
die Befehls-ID 3 dargestellt. Alternativ kann ein bestimmter Indikator
in dem Feld Source 1 platziert werden.
-
Ein
Feld einer Speicherpuffer-ID (SBID) speichert eine SBID, die einem
Speicherbefehl in einem Speicherpuffer zugeordnet ist, wie dies
nachstehend im Text beschrieben ist. Ein Ladepufferfeld (LBID) speichert
einen LBID-Eintrag, der einem Ladebefehl in einem Ladepuffer zugeordnet
ist, wie dies nachstehend im Text beschrieben ist. Die Werten für SBID und
LBID werden durch die Umbenennungs-/Zuordnungseinheit 150 zugeordnet
und über
die Umgehungsleiter 126 in die Befehlswarteschlangenanordnung
geschrieben. Ein Feld für
eine Thread-ID-Nummer kann in der Befehlswarteschlangenanordnung 202A enthalten
sein, wobei es jedoch nicht benötigt wird,
da es implizit ist.
-
b. DAD-Anordnung 206A und
Abhängigkeitserzeugungsschaltung 212A
-
In
Bezug auf die Abbildung aus 13 weist ein
Ausführungsbeispiel
der DAD-Anordnung 206A die Einträge "Befehls-ID" (Reihen bzw. Zeilen) auf, die den Befehls-ID-Einträgen der
Befehlswarteschlangenanordnung 202A Eins-zu-Eins entsprechen.
Tatsächlich
kann es sich bei der Befehlswarteschlangenanordnung 202A und
der DAD-Anordnung 206A um unterschiedliche Abschnitte der
gleichen Anordnung handeln. In bestimmten Ausführungsbeispielen können der
Befehlswarteschlangenanordnung 202A und der DAD-Anordnung 206A unterschiedliche
Lese-Ports zugeordnet sein.
-
Die
DAD-Anordnung 206A weist ein Feld "Wert oder PRID" auf, das entweder den durch einen Befehl
erzeugten Wert oder die PRID in der Registerdatei 152 aufweist.
Der Wert wird von den Ausführungseinheiten
an den Trace-Puffer 114A zurückgeschrieben, und zwar durch
die Writeback-Einheit 162 und die Writeback-Busse 122 und 196.
Ein Feld "Status", das zwei Bits aufweisen
kann, zeigt an, ob das Feld "Wert
oder PRID" einen "Wert" oder eine "PRID" aufweist. In einem
Ausführungsbeispiel
ist es möglich,
dass das Feld "Wert
oder PRID" weder
einen gültigen "Wert" noch eine gültige "PRID" aufweist. Ein Feld "Wiedergabezählwert", das eindeutig eine Befehlsausgabe
bezeichnet, wird jedes Mal erhöht, wenn
der Befehl der gleichen Befehls-ID in der Pipeline 108 erneut
wiedergegeben wird. In einem Ausführungsbeispiel ist es möglich, dass
ein Befehl gleichzeitig mehr als einmal in der Pipeline 108 wiedergegeben
wird. In diesem Fall werden in einem Ausführungsbeispiel nur die Informationen,
die dem höchsten "Wiedergabezählwert" zugeordnet sind,
zurück
in die DAD-Anordnung 206A geschrieben.
-
Das "Abhängigkeitsfeld" weist ein Bit für jedes
logische Register auf. In der Abbildung aus 13 sind
zur Vereinfachung nur vier logische Register (R1, R2, R3 und R4)
dargestellt. Die Anzahl kann jedoch deutlich höher sein. In dem Beispiel sind die
Einträge
in dem Abhängigkeitsfeld
auf 1 gesetzt, um anzuzeigen, dass eine Datenabhängigkeitskette zwischen einem
Eingabewert in eine Trace und einem Befehlseintrag existiert, und
wobei die Einträge auf
0 gesetzt werden, wenn keine Abhängigkeit
gegeben ist. Die Abhängigkeitsfeldeinträge identifizieren,
welche Befehle in der Trace ausgeführt werden müssen, wenn
ein Eingabewert empfangen wird (wie zum Beispiel, wenn der Wert
Fehlspekulation detektiert wird).
-
Wenn
die Befehle erfasst, decodiert und in den Trace-Puffer 114A geschrieben
werden, werden die Abhängigkeitsbits
sequentiell berechnet und in die DAD-Anordnung 206A geschrieben.
Die Abhängigkeitsbits
können
erzeugt werden, bevor bestimmt wird, ob ein Befehl erneut wiedergegeben
werden muss. Die Abhängigkeitsbits
aus 13 sind für
die sechs Befehle I0 bis I5 vorgesehen, die vorstehend in Abschnitt
B.1.a. beschrieben worden sind.
-
Das
Abhängigkeitsfeld
kann durch einen mechanischen Ansatz erzeugt werden. Vor der Beschreibung
eines derartigen Ansatzes wird die Erzeugung auf einer intuitiveren
Ebene beschrieben.
-
i. Intuitive Ebene
-
Das
Ergebnis des Befehls I0 ist nur von den Registern R1 und R2 abhängig. Somit
wird eine 1 in die Spalten R1 und R2 platziert und eine 0 bleibt
in den Spalten R3 und R4 der Befehls-ID 0 (welche Informationen
zu dem Befehl I0 speichert).
-
Das
Ergebnis von Befehl I1 ist nur von den Registern R3 und R4 abhängig. Somit
wird eine 0 in den Spalten R1 und R2 platziert und eine 1 in die Spalten
R3 und R4 der Befehls-ID 1.
-
Das
Ergebnis des Befehls I2 ist direkt von den Registern R1 und R2 abhängig, das
entsprechend in den Befehlen I0 und I1 erzeugt wird. In dem Befehl
I0 ist R1 von den Werten von R1 und R2 zu Beginn der Trace abhängig. In
dem Befehl I2 ist R2 von den Werten von R3 und R4 zu Beginn der
Trace abhängig.
Somit ist der Befehl I2 indirekt von den Werten von R1 bis R4 zu
Beginn der Trace abhängig, und
eine 1 wird in den Spalten R1 bis R4 der Befehls-ID 2 platziert.
-
Das
Ergebnis des Befehls I3 ist direkt von dem in dem Befehl I2 erzeugten
Register R1 abhängig.
Somit ist der Befehl I3 indirekt von den Werten von R1 bis R4 zu
Beginn der Trace abhängig,
da der Befehl I2 von diesen Werten abhängig ist, und eine 1 wird in
den Spalten R1 bis R4 der Befehls-ID 3 platziert.
-
Das
Ergebnis von Befehl I4 ist direkt von dem Register R2 abhängig, das
in dem Befehl I1 erzeugt wird. R2 ist von den Werten der Register
R3 und R4 zu Beginn der Trace abhängig. Somit wird eine 0 in
den Spalten R1 und R2 platziert, und eine 1 wird in den Spalten
R3 und R4 der Befehls-ID 4 platziert.
-
Das
Ergebnis von Befehl I5 ist direkt von dem Register R1 abhängig, das
in dem Befehl I2 erzeugt wird, der von den Registern R1 bis R4 zu
Beginn der Trace abhängig
ist. Somit wird eine 1 in den Spalten R1 bis R4 der Befehls-ID 5
platziert.
-
ii. Mechanischer Ansatz
-
In
der Folge handelt es sich um Register und einen Algorithmus, die
für die
Erzeugung eines Abhängigkeitsfelds
gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung verwendet werden können. In Bezug auf die Abbildung
aus 14A weist die Abhängigkeitserzeugungsschaltkreisanordnung 212A die
temporären
Register 230, 232, 234 und 236 auf,
und zwar ein Register für
jedes logische Register sowie ein zusätzliches temporäres Register 240.
-
Die
temporären
Register 230, 232, 234 und 236 weisen
Modifikatoren für
die logischen Register R1, R2, R3 und R4 auf. Das modifizierte Register 240 weist
eine Anordnung von Bits auf, welche anzeigen, welche logischen Register
durch Befehle in einer Trace modifiziert werden sollen. Die Register 230, 232, 234, 236 und 240 werden
jedes Mal aktualisiert, wenn ein neuer Befehl in den Trace-Puffer
geschrieben wird. Die Grenzen zwischen den Registern sind in gewisser
Weise willkürlich
bzw. wahlfrei. Zum Beispiel können
sie alle in einem kombinierten bzw. verknüpften Register vorgesehen sein.
-
Für jedes
logische Register ist ein Trace-Puffer-Adressregister vorgesehen, das auf den
letzten Befehl in dem Trace-Puffer 114A zeigt, um das logische
Register zu modifizieren. Die modifizierten Bits und die letzten
Modifikatoradressen werden zur Berechnung der Abhängigkeitsbits
für den
als nächstes in
den Trace-Puffer 114A zu schreibenden Befehl verwendet.
-
Hiermit
wird festgestellt, dass eine hierin erwähnte Modifikation eines Registers
lediglich bedeutet, dass ein Wert in das Register geschrieben wird. Dies
bedeutet nicht unbedingt, dass sich der Inhalt des Registers als
Folge des Befehls unterscheidet. Wenn der Inhalt von R1 und R2 zum
Beispiel multipliziert wird (wie in dem Befehl I0) und das Ergebnis
In das Register R1 geschrieben wird, so unterscheidet sich der Inhalt
von R1 nicht unbedingt als Folge des Befehls I0. Zum Beispiel wäre der Inhalt
von R1 nach dem Befehl nicht anders, wenn der Inhalt von R1 gleich "0" oder wenn R2 vor dem Befehl gleich "1" ist.
-
In
der Abbildung aus 16 zeigt ein Flussdiagramm 250 einen
Algorithmus, der für
jeden Quellenoperanden eines Befehls (z.B. Source 1 oder Source
2) ausgeführt
wird, um das Abhängigkeitsfeld der
DAD-Anordnung 206A zu erzeugen. In dem Schritt 252 wird
bestimmt, ob das zugeordnete Bit in dem Register 240 gesetzt
ist. Wenn, wie dies in dem Schritt 254 beschrieben ist,
das Bit in dem Register 240 nicht gesetzt ist, so wird
das Bit in dem Abhängigkeitsfeld,
das dem Register zugeordnet ist, auf eine logische 1 gesetzt. Wenn,
wie dies in dem Schritt 258 ausgeführt ist, das Bit in dem Register 240 gesetzt
ist, so wird das Quellenabhängigkeitsfeld
unter Verwendung des Index gelesen, der aus dem Modifikationsregister
(230, 232, 234 oder 236) für das relevante
Register erzeugt worden ist. Als nächstes werden gemäß dem Schritt 262 die
Quellenabhängigkeitsbits
mit den aktuellen Befehlsabhängigkeitsbits unter
Verwendung einer logischern ODER-Operation zusammengeführt. Eine
derartige logischer ODER-Operation ist in der Abbildung aus 15 durch
das ODER-Gatter 244 dargestellt (wobei in dieser Abbildung
mehrere Bits an den Eingängen
dargestellt sind). Bei der Ausführung
des Algorithmus aus 16t handelt es
sich bei den genannten modifizierten Registern und Modifikatoren
um diejenigen, die unmittelbar vor der Ausführung eines Befehls existiert
haben.
-
In
Bezug auf I0 weist das Register 240 vor dem Befehl I0 den
Wert einer logischen 0 für
R1, R2, R2 und R4 auf, und die Werte der Register 230, 232, 234 und 236 entsprechen
X (Gleichgültigkeit).
In dem Schritt 252 entsprechen die modifizierten Bits in
den Registern 240 für
R1 und R2 jeweils 0. In dem Schritt 254 werden die Abhängigkeitsfeldbits
für R1
und R2 somit jeweils in der Zeile Befehls-ID 0 der DAD-Anordnung 206A auf
1 gesetzt. Die Register R3 und R4 sind nicht betroffen und verbleiben
in der Zeile der Befehls-ID 0 bei 0. Der Befehl I0 modifiziert das
Register R1. Somit wird eine 0 in dem Register 230 platziert,
wobei angezeigt wird, dass der Befehl I0 den aktuellsten Befehl
zum Modifizieren des Registers R1 darstellt. Die Werte in den Registern 232, 234 und 236 bleiben
gleich X (Gleichgültigkeit).
Das Bit R1 des Registers 240 wird auf 1 gesetzt, wobei
angezeigt wird, dass R1 durch einen Befehl in der Trace modifiziert
worden ist.
-
Das
Abhängigkeitsfeld
für den
Befehl I1 wird auf ähnliche
Art und Weise wie für
den Befehl I0 erzeugt. Die Logikregisterspalte R1 des modifizierten Registers 240 bleibt
auf eine 1 gesetzt. Eine logische 1 wird in der Spalte R2 des modifizierten
Registers 240 platziert. Die 1 in dem Register 232 stellt
den Befehl I1 dar.
-
In
Bezug auf den Befehl I2 entsprechen die modifizierten Bits in dem
Register 240 für
R1 und R2 vor dem Befehl I2 in dem Schritt 252 jeweils
einer logischen 1 (d.h. gesetzt). In dem Schritt 258 werden die
Modifikatorregister R1 (230) und R2 (232) unmittelbar
vor dem Befehl I2 als ein Index verwendet. Das Register 230 weist
eine 0 für
den Befehl I0 auf. Das Abhängigkeitsfeld
für den
Befehl I0 in der Befehls-ID 0 der DAD-Anordnung 206A ist
gleich 0011. Das Register 232 weist eine 1 für den Befehl
I1 auf. Das Abhängigkeitsfeld
für den
Befehl I1 in der Befehls-ID ist gleich 1100. In dem Schritt 262 entspricht
das logische ODER von 0011 und 1100 1111. Somit wird 1111 für die Befehls-ID
2 in dem Abhängigkeitsfeld
der DAD-Anordnung 206A platziert. R1 wird durch den Befehl
I2 modifiziert. Allerdings befindet sich für das Register R1 bereits ein
Wert von 1 in dem Register 240. Eine 2 wird in dem Register 230 platziert,
wobei angezeigt wird, dass es sich bei dem Befehl I2 um den aktuellsten
Befehl zur Modifikation des Befehls R1 handelt.
-
Das
Abhängigkeitsfeld
für den
Befehl I3 wird auf ähnliche
Art und Weise wie für
den Befehl I2 erzeugt. Eine logische 1 wird der Spalte R4 des modifizierten
Registers 240 hinzugefügt,
und eine den Befehl I3 Dargestellte 3 wird in dem Register 236 platziert.
Das logische ODER erzeugt 1111.
-
In
Bezug auf den Befehl I4 wird vor dem Befehl I4 in dem Schritt 252 das
modifizierte Bit in dem Register 240 für R2 auf 1 gesetzt. In dem
Schritt 258 wird das Modifikationsregister für R2 (232)
unmittelbar vor dem Befehl I4 als Index verwendet. Das Register 232 weist
eine 1 für
den Befehl I1 auf. Das Abhängigkeitsfeld
für den
Befehl I1 in der Befehls-ID 1 der DAD-Anordnung 206A entspricht
1100. In dem Schritt 262 entsprechen das logische ODER
von 1100 (Quelle 1 der Befehls-ID 1) und 0000 (keine Quelle bzw.
Source 2) 1100. Somit wird 1100 für die Zeile Befehls-ID 4 in
dem Abhängigkeitsfeld
der DAD-Anordnung 206A platziert.
-
Das
Abhängigkeitsfeld
des Befehls I5 wird auf ähnliche
Art und Weise wie für
den Befehl I4 erzeugt. Die Befehle I5 und I6 modifizieren einen
externen Speicherplatz und bewirken keine Veränderung in den Registern 230, 232, 234, 236 oder 240.
-
Die
Abhängigkeitsinformationen
können
für die
Scheduling-/Ausgabeeinheit 156 verwendet
werden, oder die Scheduling-/Ausgabeeinheit 156 kann einfach
ihre eigenen Abhängigkeitsinformationen
ableiten.
-
Es
gibt verschiedene Möglichkeiten
für die Ausgabe
einer Befehlsfolge oder eines Befehlsstrangs aus einem Trace-Puffer 114A bei
der Wiedergabe. Eine Möglichkeit
ist das sequentielle Lesen des Trace-Puffers und das Extrahieren
der Befehle, die gesetzte Abhängigkeitsbits
aufweisen, sowie das Senden dieser zu Wiedergabe. Nullen können jedoch den
Effekt der Blasenerzeugung in der Pipeline aufweisen. Ein weiterer
Ansatz ist die Blasenentfernung durch Packen der Logik, bevor Befehle
zur Ausführung/Wiedergabe
gesendet werden. In Bezug auf die Abbildung aus 17 umfasst
ein weiterer Ansatz zusätzliche
Hardware, die eine Anordnung bzw. eine Array 268 für jedes
Logikregister aufweist. Die Anordnung 268 weist Befehls-ID-Werte von Befehlen
auf, die von dem Register R1 abhängig
sind. Diese Werte in der Anordnung 268 fungieren als Zeiger
auf alle Befehls-ID-Einträge
in der Befehlswarteschlangenanordnung 202A. Dies ermöglicht das
sehr schnelle Lesen aus dem Befehlspuffer. Ein Befehlsblock (vielleicht
2 oder 4 Befehle) werden gleichzeitig gelesen. Der Trace-Puffer 114A kann
mehrere Ports aufweisen und vier Decodierer, und wobei jeder dieser
Indizes weitergeleitet werden kann, der aus der Registeranordnung
erhalten wird, und zwar in die Decodierer, und wobei die Befehle
I0, I2, I3 und I5 In einem Zyklus gelesen werden können. Die
Registeranordnung R1 kann zum Zeitpunkt der Erzeugung des Abhängigkeitsfelds
zusammengesetzt werden, bevor die Wiedergabe beginnt. Die Indirektheit
erleichtert eine Wiedergabe mit hoher Bandbreite.
-
c. Ausgaberegisterdatei 210A und
Eingaberegisterdatei 208A
-
Die
Trace-Puffer 114 weisen einen Detektionsschaltkreis zum
Detektieren bestimmter Spekulationsfehler auf. Gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung weist jeder Trace-Puffer eine Ausgaberegisterdatei
auf, die den Registerkontext des zugeordneten Threads speichert,
und mit einer Eingaberegisterdatei zum Empfangen des Registerkontexts
des in der Programmreihenfolge unmittelbar vorhergehenden Threads.
Der Registerkontext entspricht dem Inhalt oder Zustand der Logikregister. Der
Inhalt der Ausgaberegisterdateiveränderungen wird häufig aktualisiert,
und zwar wahrscheinlich bei jeder Änderung in einem Register.
Der Inhalt der Eingaberegisterdatei wird nur nach einem Vergleich
aktualisiert, wie dies nachstehend im Text beschrieben ist.
-
Die
Abbildungen der 18 und 19 veranschaulichen
Ausführungsbeispiele
einer Ausgaberegisterdatei 208A (in dem Trace-Puffer 114A)
und einer Eingaberegisterdatei 208B (in dem Trace-Puffer 114B),
wobei natürlich
auch andere Ausführungsbeispiele
verwendet werden können.
Die Ausgaberegisterdatei 208A und die Eingaberegisterdatei 210B weisen
ein Wert- oder PRID-Feld und ein Statusfeld auf. Das Statusfeld
zeigt an, ob ein gültiger
Wert oder eine gültige
PRID in dem Wert- oder PRID-Feld gespeichert wird. In einem Ausführungsbeispiel
ist entweder ein gültiger
Wert oder eine gültige
PRID gegeben. In einem anderen Ausführungsbeispiel ist beides möglich, wobei
ein Befehl, der von einer Eingaberegisterdatei abhängig ist,
auf eine der beiden Möglichkeiten
wartet.
-
Hiermit
wird festgestellt, dass der Befehl I0 in dem vorstehend beschriebenen
Beispiel die Register R1 und R2 aufweist, die beide nicht vorher
das Ziel bzw. der Bestimmungsort eines Befehls in dem Thread gewesen
sind, der den Befehl I0 aufweist. Der Wert oder die PRID für die Register
R1 und R2 ist jedoch aus der Eingaberegisterdatei 208A zur
Verwendung bei der Ausführung
des Befehls I0 verfügbar.
-
In
Bezug auf die Abbildung aus 20 vergleicht
ein Komparator 280B den Inhalt der Eingaberegisterdatei 208B (in
dem Trace-Puffer 114B) für einen aktuellen Thread mit
dem Inhalt der Ausgaberegisterdatei 210A (in dem Trace-Puffer 114A)
für einen
in der Programmreihenfolge unmittelbar vorausgehenden Thread. Der
Vergleich kann am Ende der Ausführung
des unmittelbar vorangehenden Threads vorgenommen werden oder während der
ursprünglichen
Ausführung
des vorangehenden Threads. Der Vergleich wird auch am Ende der Rückordnung
des vorangehenden Threads vorgenommen. In einem Ausführungsbeispiel
wird der Vergleich zur am Ende der Rückordnung des vorangehenden
Threads vorgenommen.
-
Verschiedene
Ereignisse können
einen Vergleich durch den Komparator 280B auslösen. Der Vergleich
wird zum Detektieren von Spekulationsfehlern ausgeführt. Wenn
zwischen den Eingabe- und Ausgaberegisterdateien
eine Differenz bzw. ein Unterschied existiert, so haben sich die
Werte eines oder mehrerer Ausgaberegister des unmittelbar vorangehenden
Threads geändert.
Als Reaktion darauf wird die Eingaberegisterdatei 208B aktualisiert,
und die Wiedergabeauslöselogik 284B bewirkt
die Wiedergabe der betroffenen Befehle mit den veränderten Registerwerten.
Das Abhängigkeitsfeld
kann von der Wiedergabeauslöselogik 284B verwendet
werden. Es gibt keine Gewähr
dafür,
dass die veränderten bzw.
geänderten
Werte die ultimativ Richtigen Werte sind (d.h. die Registerwerte,
die in einem vollständig und
absolut In-Order-Prozessor erzeugt werden würden). Es kann erforderlich
sein, die Befehle erneut wiederzugeben, unter Umständen auch
mehrere Male.
-
In
einem Ausführungsbeispiel
weist der Detektionsschaltkreis für einen Thread eine Ausgaberegisterdatei,
eine Eingaberegisterdatei, einen Komparator und zugeordnete Steuerschaltkreise
auf, um bestimmte Spekulationsfehler in Befehlen zu detektieren,
die in dem Trace-Puffer gespeichert sind, der die Eingaberegisterdatei
aufweist. In anderen Ausführungsbeispielen
kann der Detektionsschaltkreis eine in gewisser Weise unterschiedliche
Schaltkreisanordnung aufweisen.
-
Zum
Beispiel ist in Bezug auf die Abbildung aus 21 der
Thread T2 der aktuelle Thread, der dem Trace-Puffer 114B zugeordnet
ist. Der Thread T1 ist der dem Thread T2 unmittelbar vorangehende Thread,
und er ist dem Trace-Puffer 114A zugeordnet. Der Thread
T1 weist einen Funktionsaufruf, die Funktion und einen Rücksprung
von dem Funktionsaufruf auf. Die Ausführung des Thread T2 beginnt
unmittelbar nach dem Funktionsaufruf. Der Inhalt des Ausgaberegisters 210A,
wie er zum Zeitpunkt des Funktionsaufrufs existiert hat, wird in
die Eingaberegisterdatei 208B kopiert. Die Befehle des
Threads T2 werden spekulativ auf der Basis des Registerkontexts
in der Eingaberegisterdatei 208B ausgeführt. Zum Zeitpunkt des Rücksprungbefehls
wird der Inhalt der Eingaberegisterdatei 208B durch den
Komparator 280B mit dem Inhalt der Ausgaberegisterdatei 210A verglichen.
Wenn ein Unterschied existiert, wird die Eingaberegisterdatei 208B aktualisiert,
und die betroffenen Befehle in dem Thread T2 werden wiedergegeben.
Der Vergleich kann auch zu einem oder mehreren dazwischen liegenden
Zeitpunkten vorgenommen werden. Dies kann dabei helfen, Engpässe zu verhindern,
indem die Wiedergabe von Befehlen gleichmäßiger verteilt wird, wobei
dies zusätzliche
Wiedergaben verursachen kann, wenn sich zum Beispiel der Inhalt
der Ausgaberegisterdatei Während
der Funktion mehr als einmal verändert.
In Bezug auf die konstante Veränderung
der Ausgaberegisterdatei kann ein intermediärer Puffer wünschenswert
sein, der den Inhalt der Ausgaberegisterdatei 210A empfängt. Der
Vergleich kann dabei zwischen dem Inhalt des intermediären Puffers
und dem Inhalt der Eingaberegisterdatei 208B vorgenommen werden.
-
Wie
dies in den Abbildungen der 8 und 10 veranschaulicht
ist, wird der Registerkontext zwischen den Ausgaberegisterdateien
und den Eingaberegisterdateien über
die Leiter 216 weitergeleitet. Die Leiter 216 verbinden
jede Eingaberegisterdatei mit der Ausgaberegisterdatei jedes Trace-Puffers, der die
Trace für
den unmittelbar vorangehenden Thread speichern kann. Wenn gewährleistet
werden kann, dass die Programmreihenfolge stets einer bestimmten
Trace-Puffer-Anordnung
folgt, so kann das Layout für
die Leiter 216 ziemlich einfach gestaltet sein. Die Ausgabe-
und Eingaberegisterdateien können
durch die Steuerschaltkreisanordnung 224A aus den Abbildungen
der 10 und 11 gesteuert werden.
-
Da
die Ausgabe- und Eingaberegisterdateien entweder einen Wert oder
eine PRID vorsehen, kann eine sehr geringe Latenzzeit zwischen dem Empfang
von Inhalten in einer Eingaberegisterdatei und der Fähigkeit
zur Ausführung
von Befehlen unter Verwendung eines Registers von der Eingaberegisterdatei
als ein Quellenoperand gegeben sein. Wenn kein Wert verfügbar ist,
kann die PRID an eine Registerdatei 152 zur Ausführung in
der Pipeline 108 verwendet werden.
-
Es
wird erwartet, dass viele Befehle mehrfach wiedergegeben werden,
wenn sich richtige Quellenoperanden ihren Weg durch die Registerdateien
der verschiedenen Threads nehmen. Es wird ferner erwartet, das für viele
Programme zahlreiche Befehle entweder gar nicht oder sehr selten
erneut wiedergegeben werden müssen,
was zu einer erheblichen Zunahme der je Zeiteinheit korrekt ausgeführten Befehle
führt sowie
zu einem Rückgang
der insgesamt für
die Ausführung
eines Programms erforderlichen Zeit.
-
2. Trace-Puffer 114'
-
In
Bezug auf die Abbildung aus 1 ist der Trace-Puffer 114' dem Trace-Puffer 114 (in 10) ähnlich.
In dem Trace-Puffer 114' wird das Abhängigkeitsfeld
in der Abhängigkeitserzeugungs-
und Decodierungsschaltkreisanordnung 218A erzeugt, nachdem
entschieden worden ist, dass ein Befehl wiedergegeben werden soll.
Die kann bei der Wiedergabe zwar eine gewisse anfängliche
Latenz erzeugen, jedoch wenn die Ausgabe von Befehlen zur Wiedergabe
und zur Bestimmung von Abhängigkeiten
durch Pipeline-Verarbeitung ausgeführt wird, kann die zusätzliche
Latenz nach Beginn des Prozesses sehr geringfügig sein.
-
In
einem Ausführungsbeispiel
speichert die Abhängigkeitserzeugungs-
und Decodierungsschaltkreisanordnung 218A nur ein Feld
für Abhängigkeitsinformationen.
(In der Abbildung aus 13 sind vier Felder vorgesehen.)
Das gleiche Feld kann wieder verwendet werden. Während der Wiedergabe von Befehlen,
die von dem Register R1 abhängig
sind, kann das Feld zum Beispiel zur Aufführung von Befehlen verwendet
werden, die von dem Register R1 abhängig sind.
-
Während der
Wiedergabe von Befehlen, die von dem Register R2 abhängig sind,
kann das gleiche Feld zur Aufführung
von Befehlen verwendet werden; die von dem Register R2 abhängig sind,
etc. Die Abhängigkeitserzeugungs-
und Decodierungsschaltkreisanordnung 218A kann nur ein
Modifikatorfeld und ein Modifikatorregister aufweisen. (In der Abbildung
aus 4 sind vier vorgesehen.) Alternativ kann die Abhängigkeitserzeugungs-
und Decodierungsschaltkreisanordnung 218A mehrere Abhängigkeitsfelder
und Register aufweisen. Die Abhängigkeitserzeugungs-
und Decodierungsschaltkreisanordnung 218A kann Abhängigkeiten
auch nur für
wenige Befehle gleichzeitig bestimmen.
-
Die
Datenanordnung 214A weist ein Wert- oder PRID-Feld, ein
Statusbitfeld und ein Wiedergabezählwertfeld für jeden
Befehls-ID-Eintrag auf (wie in der DAD-Anordnung 206A aus
den Abbildungen der 10 und 13). Alternativ
kann der Inhalt der Datenanordnung 214A in der Abhängigkeitserzeugungs-
und Decodierungsschaltkreisanordnung 218A platziert werden,
was die Datenanordnung 214A unnötig macht. Es gibt zwei Gründe dafür, warum
es vorteilhaft sein kann, die Datenanordnung 214A und die
Abhängigkeitserzeugungs-
und Decodierungsschaltkreisanordnung 218A getrennt zu halten.
Erstens können
sie verschiedene Leseanschlüsse
aufweisen. Zweitens weist die Abhängigkeitserzeugungs- und Decodierungsschaltkreisanordnung 218A in
einem Ausführungsbeispiel
nicht so viele Zeilen auf wie die Befehlswarteschlangenanordnung 202A und
die Datenanordnung 214A. Anders ausgedrückt verwendet die Abhängigkeitserzeugungs-
und Decodierungsschaltkreisanordnung 218A in einem Ausführungsbeispiel
Zeilen wieder, ebenso wie Abhängigkeitsfelder
wieder verwendet werden können. Es
gibt natürlich
zahlreiche Möglichkeiten.
-
Wie
dies nachstehend im Text näher
beschrieben ist, zeigt der MOB 178 an, wenn Ladebefehle
durch die Leiter 194 wiedergegeben werden sollen. Eine
Anordnung mit einem Abhängigkeitsfeld (wie
das für
R1 in 13) kann erzeugt werden, um die
Befehle abhängig
von dem wiederzugebenden Ladebefehl aufzuführen. Für einen Ladebefehl beginnt
die Liste der abhängigen
Befehle mit dem Ladebefehl anstatt mit dem ersten Befehl in der
Trace, wie in dem Fall von Registern. Das Abhängigkeitsfeld für Ladebefehle
kann sich in der Abhängigkeitserzeugungs-
und Decodierungsschaltkreisanordnung 218A befinden (in 11).
(Natürlich
würden
Ladebefehle für
andere Traces von anderen Trace-Puffern wiedergegeben werden.) In
einem Ausführungsbeispiel
wird die Abhängigkeitserzeugungs- und Decodierungsschaltkreisanordnung 218A für Abhängigkeitsfelder
für Ladebefehle
und -register verwendet. Das gleiche Feld kann für beide Zwecke verwendet werden.
In einem anderen Ausführungsbeispiel
befinden sich die Abhängigkeitsfelder
für Register
in einer DAD-Anordnung 206A, und die Abhängigkeitsfelder
für Ladebefehle
befinden sich in der Abhängigkeitserzeugungs-
und Decodierungsschaltkreisanordnung 218A.
-
In
einem weiteren Ausführungsbeispiel
wird der Ladebefehl vollständig
wiedergegeben (d.h. alle Befehle, die dem Ladebefehl folgen, werden
erneut ausgeführt),
so dass das Abhängigkeitsfeld
nicht erforderlich ist.
-
C. Ein Wiedergabesequenzalgorithmus
-
Wenn
eine Wiedergabeauslöselogk
(wie etwa die Wiedergabeauslöselogik 284B)
bestimmt, dass ein Quellenoperand (oder ein anderer Eingabewert)
falsch vorhergesehen worden ist, löst sie den entsprechenden Trace-Puffer
(wie etwa den Trace-Puffer 114B) aus, um die Befehle auszugeben,
die direkt oder indirekt abhängig
sind von dem in der Pipeline 108 wiederzugebenden, falsch
vorhergesehen Quellenoperanden. Die direkt oder indirekt unabhängigen Befehle
können
aus dem Abhängigkeitsfeld
der DAD-Anordnung in dem Trace-Puffer oder durch eine andere Anordnung
wie in 11 identifiziert werden.
-
Die
identifizierten Befehle werden aus dem Trace-Puffer in der Reihenfolge
ausgegeben, in de die Befehle in dem Trace-Puffer angeordnet sind (dies
entspricht der Programmreihenfolge). Zum Beispiel wird der Befehl
in dem Befehls-ID0-Eintrag vor oder gleichzeitig zu einem Befehl
in dem Befehls-ID1-Eintrag ausgegeben. Die Befehle können jedoch
auch Out-of-Order gesteuert durch die Scheduling-/Ausgabeeinheit 156 ausgeführt werden,
wie etwa in jedem Out-of-Order-Prozessor. Die Steuerbits werden
an den von dem Trace-Puffer ausgegebenen Befehl angehängt, um
der Umbenennungs-/Zuordnungseinheit 150 anzuzeigen, ob
(1) das Register umbenannt werden soll, (2) der Umbenennungs-Alias-Tabellenverweis
in der Umbenennungs-/Zuordnungseinheit 150 umgangen
und stattdessen die PRID aus dem entsprechenden Trace-Puffer verwendet
werden soll, oder (3) ob die Umbenennung vollständig umgangen werden und der Wert
aus der DAD-Anordnung verwendet werden soll, als wäre es ein
konstanter Operand in dem Befehl.
-
Wie
dies in Bezug auf die Abbildung aus 12 erläutert wird,
handelt es sich bei dem Feld "Gültig 1" und "Gültig 2" um Bits, die auf einen ersten Wert
(z.B. eine logische 0) gesetzt werden, wenn ein entsprechender Quellenoperand
einer Befehls-ID durch einen Befehl von außerhalb des Threads in dem
Trace-Puffer 114A erzeugt worden ist (z.B. das Ziel eines
Befehls), und wobei sie auf einen zweiten Wert (z.B. eine logische
1) gesetzt werden können, wenn
der Quellenoperand für
eine Befehls-ID durch einen Befehl in dem Thread erzeugt worden
ist. Die Quellenoperanden für
einen aus dem Trace- Puffer 114A ausgegebenen
wiedergegebenen Befehl können
wie folgt bestimmt werden:
- (1) Gültiges Bit
1. Wenn das gültige
Bit in der Befehlswarteschlangenanordnung 202A auf eine
logische 1 gesetzt wird, wird der Index für den Quellenoperanden zum
Lesen des entsprechenden Werts oder die PRID in der DAD-Anordnung 206A verwendet.
Wenn weder das Wertebit oder das PRID-Bit des Anordnungsstatusfeldes
gültig
sind, so bedeutet dies, dass das Quellenoperandenregister noch nicht
umbenannt worden ist. In diesem Fall wird der Befehl durch die Leiter 120 und
den MUX 110 ausgegeben, wobei die Werte- und PRID-Statusbits Werte
einer logischen Null aufweisen, so dass die Umbenennungs-/Zuordnungseinheit
150 einen Alias-Tabellenverweis (Registerumbenennung)
so ausführen
kann, wie dies normalerweise erfolgt. Wenn die PRID oder der Wert
gültig
sind, so wird die PRID oder der Wert gemeinsam mit dem Befehl durch
den Leiter 120 und den MUX 110 zu der Umbenennungs-/Zuordnungseinheit 150 geleitet,
welche als Reaktion darauf die Umbenennungsstufe umgeht.
- (2) Gültiges
Bit 0: Wenn das gültige
Bit für
einen Quellenoperanden auf eine logische 0 gesetzt wird, stammt
der Eingabeoperand von außerhalb der
Trace. Der Quellenregistername wird für den Zugriff auf die Eingaberegisterdatei 208A verwendet.
Der Wert oder die PRID aus der Eingaberegisterdatei 208A wird
gemeinsam mit dem Befehl an die Umbenennungs-/Zuordnungseinheit 150 geleitet,
die als Reaktion darauf die Umbenennungsstufe umgeht.
-
Unabhängig davon,
ob das gültige
Bit 0 oder 1 entspricht, werden für jeden ausgegebenen Befehl die
Wert- und PRID-Statusfeldbits
in der DAD-Anordnung 206A auf eine logische 0 zurückgesetzt
oder verbleiben auf dieser. Dadurch werden zwei Zwecke erreicht.
Erstens wird gewährleistet,
dass ein späterer
abhängiger
Befehl, der ausgegeben wird, bevor die PRID in den Eintrag aus der
Umbenennungsstufe kopiert wird, aus der Umbenennungs-Aliastabelle umbenannt
werden kann, so dass die Nutzung einer simplen PRID von dem Trace-Puffer 114A verhindert werden
kann. Zweitens wird zudem gewährleistet, dass
ein Befehl nicht rückgeordnet
wird, bevor das letzte Ausführungsereignis
zurückgeschrieben
wird, wodurch eine Rückordnung
eines Befehls nur dann ermöglicht
wird, wenn alle Datenfehlprädiktionen
korrigiert worden sind.
-
D. Zweite Ebene oder abschließende Rückordnung
-
Ein
Befehl wird abschließend
aus dem Trace-Puffer 114 rückgeordnet, wenn alle Befehle
für alle
vorherigen Threads rückgeordnet
worden sind, und wenn alle Wiedergabeereignisse behandelt worden
sind, die zu dem Befehl gehören.
Anders ausgedrückt
wird ein Befehl vollständig
rückgeordnet,
wenn sichergestellt werden kann, dass der Befehl mit dem richtigen
Quellenoperanden ausgeführt
worden ist. Die Threads werden der Reihe nach rückgeordnet. Zum Beispiel kann
ein Befehl in dem Thread X nicht rückgeordnet werden, bevor nicht
alle vorherigen Threads rückgeordnet
worden sind (d.h. die Befehle aller vorhergehenden Threads sind
rückgeordnet worden).
Die Befehle innerhalb eines Threads werden der Reihe nach rückgeordnet,
wobei Befehle, die bereits für
die Rückordnung
bereit stehen, gleichzeitig rückgeordnet
werden können.
-
Die
abschließende
Rückordnung
wird durch eine Logik 134 für die abschließende Rückordnung geregelt
bzw. gesteuert. In einem Ausführungsbeispiel
umfasst die abschließende
Rückordnung
(1) die Rückmeldung
der Ergebnisse in eine In-Order-Registerdatei;
(2) Dienstunterbrechungen, Ausnahmen und/oder Verzweigungs-Fehlprädiktionen;
(3) die Freigabe des Trace-Puffers und Ressourceneinträge des MOB 178;
und (4) dem MOB anzeigen, Speicherungen als rückgeordnet zu markieren und
diese an den Speicher auszugeben. Die Freigabe von Einträgen kann
das Bewegen des Kopfzeigers umfassen. Wie dies nachstehend beschrieben
ist, können Speicherbefehle
in dem MOB 178 nicht freigegeben werden, bis sicher ist,
dass zugeordnete Daten in den Datencache 176 oder einen
anderen Speicher kopiert werden. Einzelheiten zu der abschließenden Rückordnung
von Lade- und Speicherbefehlen in dem MOB 178 werden nachstehend
im Text beschrieben.
-
E. Speichersystem
-
Die
Abbildung aus 22 veranschaulicht, dass ein
Ausführungsbeispiel
des MOB 178 aus 2 die MOBs 178A, 178B,
..., 178Y aufweist, wobei Y die Anzahl der MOBs darstellt
und der Anzahl der Trace-Puffer 114 entspricht. Die MOBs 178A, 178B,
..., 178Y speichern Kopien der Lade- und Speicherbefehle
der Traces in den entsprechenden Trace-Puffern 114A, 114B,
..., 114Y. Ladebefehle werden in den Ladepuffern 182A; 182B,
..., 182Y gespeichert. Die Speicherbefehle werden in den
Speicherpuffern 184A, 184B, ..., 184Y gespeichert.
Die Leiter 292 stellen verschiedene Leiter dar, die Signale
zu und von einem MOB 178 führen. Die Wiedergabeleiter 194 sehen
Signale von dem MOB 178 an Trace-Puffer 114 vor,
wobei den Trace-Puffern 114 dabei angezeigt wird, dass
ein Ladebefehl wiedergegeben werden soll. Die Steuerschaltung 302 führt eine
Vielzahl von Steuerfunktionen aus.
-
1. Speicherpuffer
und Ladepuffer
-
Die
Abbildung aus 23 veranschaulicht ein Ausführungsbeispiel
eines Speicherpuffers 184A, der repräsentativ für die Speicherpuffer 184B,
..., 184Y ist. Verschiedene andere Ausführungsbeispiele können ebenfalls
verwendet werden. Der Speicherpuffer 184A weist verschiedene
Felder für
Zeilen von Speicherpuffereinträgen
auf. Jeder Eintrag wird durch eine Speicherpuffer-ID bzw.
-
Speicherpufferkennung
(SBID) identifiziert. Die Umbenennungs-/Zuordnungseinheit 150 weist jedem
Speicherbefehl einen SBID-Eintrag
zu, wenn der jeweilige Befehl zum ersten Mal erfasst und ausgeführt wird,
jedoch nicht bei der Wiedergabe. Der Speicherbefehl weist bis zur
abschließenden
Rückordnung
den gleichen SBID-Wert auf. Zum Beispiel wird in der Abbildung aus 23 der
Eintrag SBID 0 für
die Befehlsspeicherung 0 zugeordnet. Der Eintrag SBID 1 wird für den Befehlsspeicher
1 zugeordnet, etc. Ein LBID-Feld, das einen nachstehend beschriebenen
Wert "Speicher-LBID" speichert, ist in
der Abbildung aus 23 dargestellt. Wenn in einem
Ausführungsbeispiel
ein Eintrag der Befehlswarteschlangenanordnung 202A (in 12)
einen Speicherbefehl speichert, speichert das SBID-Feld der Befehlswarteschlangenanordnung 202A die
SBID, welche den Eintrag in dem Speicherpuffer 184A identifiziert, der
den Speicherbefehl aufweist, und das LBID-Feld speichert die Speicher-LBID,
sofern eine vorgesehen ist, für
den Speicherbefehl. Die SBID und die Speicher-LBID begleiten den
Speicherbefehl durch die Pipeline 108. In diesem Ausführungsbeispiel
kann das LBID-Feld auch nicht in dem Speicherpuffer 184A enthalten
sein.
-
Ein
Feld Befehls-ID speichert die Befehls-ID für den Speicherbefehl in der
Befehlswarteschlangenanordnung 202A. Die Thread-Puffer-ID
ist sowohl in dem Speicherpuffer 184A als auch in dem Trace-Puffer 114A implizit.
Ein Operationscodefeld (Op Code) speichert den Operationscode des
Speicherbefehls. Ein Speicheradressfeld speichert die Adresse, an
welche der Speicherbefehl gerichtet ist. In dem veranschaulichten
Ausführungsbeispiel
wird die Adresse durch die AGU 172 erzeugt. Ein Feld für eine gültige SB-Adresse
weist ein Bit auf, das anzeigt, ob es sich bei der Speicheradresse
um eine gültige
Adresse handelt. Ein Datenfeld speichert die zu speichernden Daten.
Ein Datengültigkeitsfeld weist
ein Bit auf, das anzeigt, ob die Daten gültig sind. Es können separate
Bits für
die Gültigkeit
der Adresse und der Daten verwendet werden, da die gültige Adresse
zu einem anderen Zeitpunkt ankommen kann als die gültigen Daten.
Sowohl die Adresse als auch die Daten erreichen ihr Ziel, bevor
der Speicherbefehl ausgeführt
wird. Gemäß einem
Ausführungsbeispiel
sind die Daten Bestandteil des Befehls. Ein rückgeordnetes Feld weist ein
Bit auf, das gesetzt wird, wenn die Logik 134 für eine abschließende Rückordnung
anzeigt, dass der Speicherbefehl rückgeordnete werden soll, und
das zurückgesetzt
wird, wenn eine Bestätigung
von dem Speicher empfangen wird, dass der Speichervorgang in den Speicher
abgeschlossen ist. Die Rückordnung
von Lade- und Speicherbefehlen wird nachstehend im Text näher erörtert. Ein
Wiedergabezählfeld
weist einen Wiedergabezählwert
auf (und entspricht dem Wiedergabezählwertfeld der DAD-Anordnung 206A aus 13).
Das Wiedergabezählwertfeld
ist nicht unbedingt erforderlich. Gemäß einem Ausführungsbeispiel
kann ein Speicherbefehl zu einem bestimmten Zeitpunkt nur einmal
wiedergegeben werden, und es existiert kein Wiedergabezählwertfeld.
-
Die
Abbildung aus 24 veranschaulicht ein Ausführungsbeispiel
eines Ladepuffers 182A, der für die Ladepuffer 182B,
..., 182Y repräsentativ
ist. Verschiedene andere Ausführungsbeispiele
können ebenfalls
verwendet werden. Der Ladepuffer 182A weist verschiedene
Felder für
Zeilen der Ladepuffereinträge
auf. Jeder Eintrag ist durch eine Ladepufferkennung bzw. eine Ladepuffer-ID
(LBID) identifiziert. Die Umbenennungs-/Zuordnungseinheit 150 ordnet jedem
Ladebefehl, wenn dieser zum ersten Mal erfasst und ausgeführt wird,
jedoch nicht bei dessen Wiedergabe, eine LBID zu. Der Ladebefehl
weist den gleichen LBID-Wert bis zur abschließenden Rückordnung auf. Zum Beispiel
wird in der Abbildung aus 24 ein
Eintrag LBID 0 für
den Befehlsladewert 0 zugeordnet. Der Eintrag LBID 1 wird für einen
Befehlsladewert 1 zugeordnet, etc. (Die LBID-Eintragsnummer und das SBID-Feld können als
MOB-ID bezeichnet werden.) Ein SBID-Feld, das einen nachstehend
beschriebenen Wert "Lade-SBID" führt, ist
in der Abbildung aus 24 veranschaulicht. Wenn in einem
Ausführungsbeispiel
ein Eintrag der Befehlswarteschlangenanordnung 202A (in 12)
einen Ladebefehl speichert, so führt
das LBID-Feld der Befehlswarteschlangenanordnung 202A die
LBID, welche den Eintrag in dem Ladepuffer 182A identifiziert, der
den Ladebefehl speichert, und das SBID-Feld speichert die Lade-SBID, sofern eine
solche existiert, für
den Speicherbefehl. Die LBID und die Lade-SBID begleiten den Ladebefehl
durch die Pipeline 108. In diesem Ausführungsbeispiel kann es ebenfalls
sein, dass das SBID-Feld nicht in dem Ladepuffer 182A enthalten
ist.
-
Ein
Feld Befehls-ID weist die Befehlskennung des Ladebefehls in der
Befehlswarteschlangenanordnung 202A auf. Die Thread-Puffer-ID ist sowohl in
dem Ladepuffer 182A und dem Treace-Puffer 114A implizit. Ein Operationscodefeld
speichert den Operationscode des Ladebefehls. Ein Ladeadressfeld
speichert die Adresse der Ladebefehlsladevorgänge. Ein Feld für einen
gültigen
Eintrag weist ein Bit auf, das anzeigt, dass der Eintrag durch einen
gültigen
Ladebefehl belegt ist. In dem veranschaulichten Ausführungsbeispiel
ist kein Feld für
eine gültige Adresse
vorhanden, da die Adresse bereits durch die AGU 172 erzeugt
worden ist. Ein PRID-Feld weist eine PRID von der Umbenennungs-/Zuordnungseinheit 152 auf,
welche das Ziel bzw. den Bestimmungsort für Ladebefehle in der Registerdatei 152 anzeigt. SB
Hit, SBID, Thread ID und ein Wiedergabezählwertfeld (sofern vorhanden)
können
als Teil eines Statusfelds gelten, und wobei sie nachstehend in
Bezug auf die Ausführung
von Speicherbefehlen beschrieben werden.
-
Zu
dem Zeitpunkt, wenn Speicher- und Ladebefehle zum ersten Mal von
der Umbenennungs-/Zuordnungseinheit 150 empfangen werden,
werden Einträge
für die
Speicher- und Ladebefehle in Speicherpuffern 184 und Ladepuffern 192 zugeordnet, und
Einträge
für Register
für den
Empfang geladener Werte werden in der Registerdatei 150 und
dem ROB 164 Zugeordnet. Die Einträge werden keiner Rückordnung
erster Ordnung bzw. auf erster Ebene ausgesetzt, vielmehr bleibt
ihre Zuordnung wie die Einträge
in den Trace-Puffern 114 bis zur abschließenden Rückordnung
zugeordnet. Demgemäß werden die
Einträge
bei der Wiedergabe nicht neu zugeordnet. Wenn ein Speicher- oder
Ladepuffer voll ist, verläuft
ein Speicher- oder Ladebefehl entsprechend von dem I-Cache 104 nicht
durch die Umbenennungs-/Zuordnungseinheit 150,
bis ein Eintrag freigegeben wird. Ein Lade- oder Speicherbefehl,
der aus einem Trace-Puffer erneut ausgeführt wird, verläuft jedoch
durch die Umbenennungs-/Zuordnungseinheit 150.
-
In
Bezug auf die Abbildung aus 5 wird MX
speichern in dem Thread T1 ausgeführt, bevor MX laden in dem
Thread T2 ausgeführt
wird. Aufgrund der gleichzeitigen Ausführung kann MX speichern in
zeitlicher Reihenfolge jedoch auch vor oder nach MX laden ausgeführt werden.
Wenn MX speichern vor MX laden in der zeitlichen Reihenfolge ausgeführt wird,
so ist die spekulative Ausführung
von MX laden in der richtigen Reihenfolge in Bezug auf MX speichern
gegeben. Wenn alle Befehle in der Programmreihenfolge vor MX speichern
rückgeordnet
worden sind, ist es sicher, dass MX laden den richtigen Wert aus
dem Speicherplatz MX lädt.
Der richtige Wert ist der Wert, der geladen werden würde, wenn
die Threads in einem In-Order-Prozessor ausgeführt wird. Wenn nicht alle Befehle
vor MX speichern in der Programmreihenfolge rückgeordnet worden sind, so
ist es jeweils möglich,
dass die Daten für MX
speichern nicht richtig sind.
-
Wenn
im Gegensatz dazu MX speichern in der zeitlichen Reihenfolge nach
MX laden ausgeführt wird,
so weist die spekulative Ausführung
von MX laden nicht die richtige Reihenfolge in Bezug auf MX speichern
auf, und es gibt keine Sicherheit dafür, dass MX laden den richtigen
Wert lädt.
Es wäre
lediglich ein Zufall, wenn sich an dem Speicherplatz MX der richtige
Wert befinden würde
(oder in dem Datenfeld des Speicherpuffereintrags, welcher MX speichern
speichert, bis MX speichern abschließend rückgeordnet ist). Um eine ultimativ
richtige Ausführung
zu gewährleisten,
weist der MOB 178 verschiedene Mechanismen auf, um eine
Speicherdatenkohärenz
zwischen Threads zu gewährleisten.
-
a. Ausführung von
Ladebefehlen
-
Bevor
ein Ladebefehl ausgeführt
wird, wird dessen Adresse mit den Adressen von Speicherbefehlen
verglichen, um zu bestimmen, welcher Speicherbefehl, sofern vorhanden,
den nahe liegendsten vorausgegangenen, übereinstimmenden Speicherbefehl
(CEMSI als englische Abkürzung
von Closest Earlier Matching Store Instruction) darstellt. "Übereinstimmend" bedeutet, dass er
die gleiche Adresse wie der Ladebefehl aufweist. "Vorausgegangen" bedeutet, dass der
CEMSI in der Programmreihenfolge vor dem Ladebefehl aufgetreten
ist. "Nahe liegendst" bedeutet, dass zwischen
dem CEMSI und dem auszuführenden
Ladebefehl kein anderer übereinstimmender
Speicherbefehl existiert. Wenn nur ein näherer übereinstimmender Speicherbefehl
existiert, so ist dies der CEMSI.
-
Wenn
ein CEMSI existiert, liest der Ladebefehl dessen Daten aus dem Datenfeld
des CEMSI. Wenn kein CEMSI existiert, entnimmt der Ladebefehl seine
Daten aus dem Speicher, wie etwa dem Datencache 176, einem
L2-Cache oder Hauptspeicher. Daten aus dem Speicherpuffer 184 oder
Speicher werden durch den MUX 192 geleitet und in den Eintrag in
den Trace-Puffern 114 geschrieben, bezeichnet durch die
Thread-ID und die Befehls-ID.
Die Daten können
auch in das Register in der Registerdatei 152, bezeichnet
durch die PRID, geschrieben werden. Die Daten können auch abhängig von
den Caching-Regeln (z.B. Write-Back, Write-Through, etc.) in dem
Datencache 176 gespeichert werden. Der MUX 192 stellt
eine Umgehung dar, da er den Speicher umgehen kann, wie zum Beispiel
den Daten-Cache 176, einen L2-Cache oder Hauptspeicher.
-
In
einem Ausführungsbeispiel
ist ein anderer Komparator jedem Eintrag jedes der Speicherpuffer 184 zugeordnet,
um Vergleiche zwischen dem auszuführenden Ladebefehl und der
Adresse von Speicherbefehlen vorzunehmen. Bei dem Komparator 320 aus 25 handelt
es sich um ein Beispiel, und er empfängt die Ladebefehlsadresse
und die Speicheradresse der Eintrags-SBID 1 in dem Speicherpuffer 184A.
Der Leiter 322 sowie die Ausgabeleiter von anderen Komparatoren
sind mit der MOB-Steuerschaltkreisanordnung 302 verbunden.
-
Die
Lade-SBID zeigt auf die SBID eines nahe liegendsten vorausgegangenen
Speicherbefehls (CESI) in Bezug auf den auszuführenden Ladebefehl. Der CESI
befindet sich in dem Speicherpuffer, der die gleiche Thread-ID aufweist
wie der Ladebefehl. Wenn ein CEMSI existiert, so ist dieser entweder
der CESI oder er liegt früher
als der CESI in der Programmreihenfolge. Die Umbenennungs-/Zuordnungseinheit 150 überwacht
die Reihenfolge der Speicher- und Ladebefehle in dem Programm und sieht
die SBID- und LBID-Werte vor. Sie können durch die Leiter 126 an
die Trace-Puffer 114 geschrieben werden. Wenn gemäß einem
Ausführungsbeispiel
keine CESI in Bezug auf einen Ladebefehl existiert, so ist dem Befehl
keine Lade-SBID zugeordnet. Dies erfolgt, wenn es sich bei dem ersten Speicherbefehl
in einem Trace um einen Ladebefehl handelt. Verschiedene Techniken
können
zur Handhabung dieser Situation verwendet werden, einschließlich dem
Senden bestimmter Signale durch die Umbenennungs-/Zuordnungseinheit 150,
um anzuzeigen, dass keine gültige
Lade-SBID existiert. Zu diesem Zweck kann die Anordnung Bitumlauf
(Wrap Around Bit) verwendet werden, die nachstehend beschrieben
ist.
-
Speicher-
und Ladebefehle werden in der folgenden Programmreihenfolge berücksichtigt:
0
speichern
1 speichern
0 laden
2 speichern
1
laden
3 speichern
4 speichern
2 laden.
-
Die
Speicher-LBID-Werte in dem LBID-Feld sind in dem Speicherpuffer 184 dargestellt.
Die Lade-SBID-Werte in dem SBID-Feld sind in dem Ladepuffer 182 dargestellt.
Zum Beispiel zeigt die 2 in dem SBID-Feld des LBID-Eintrags 1 an,
dass der Speicherbefehl in dem Eintrag SBID 2 in dem Speicherpuffer 184A CESI
in Bezug auf den Ladebefehl in dem LBID-Eintrag 1 speichert. Die
Befehle 0 speichern, 1 speichern, 2 speichern und 0 laden sind älter bzw.
früher
als 1 laden. Die Befehle 3 speichern, 4 speichern und 2 laden sind
jünger
bzw. später
als 1 laden.
-
Es
gibt verschiedene Möglichkeiten,
wie die Steuerschaltkreisanordnung 302 bestimmen kann, welcher
Speicherbefehl, wenn überhaupt
vorhanden, der CEMSI ist. Beispiele für die Möglichkeiten werden in Bezug
auf die Abbildung aus 27 erörtert, wobei die Speicherpuffer 184A, 184B, 184C und 184D die
einzigen Speicherpuffer in dem MOB 178 und entsprechend
den Threads A, B, C und D zugeordnet sind. Angenommen wird eine
Programmreihenfolge Thread A, Thread B, Thread C und Thread D. In
dem Beispiel befindet sich der Ladebefehl in dem Ladepuffer 182C.
Es gibt einen CESI, der sich in dem Speicherpuffer 184C befindet.
-
Die
Leiter 342, 344, 346 und 348 sind
die Ausgabeleiter der verschiedenen Komparatoren. Die Leiter 362, 364, 366 und 368 sehen
Steuersignale vor, die den Komparatoren das Ausführen von Vergleichen ermöglichen.
In verschiedenen Ausführungsbeispielen
ermöglicht
die Steuerschaltkreisanordnung 302 (1) die Komparatoren
für alle
Einträge
in jedem Speicherpuffer; (2) nur die Komparatoren, die sich in einem
Speicherpuffer mit einer Thread-ID befinden, die in der Programmreihenfolge
mit der Ladebefehls-Thread-ID übereinstimmt
oder zeitlich vor dieser liegt; oder (3) nur die Komparatoren, die
Einträgen
zugeordnet sind, die in der Programmreihenfolge zeitlich vor dem
Ladebefehl liegen.
-
Die Übereinstimmungsbestimmungslogik 356 bestimmt,
welcher, sofern überhaupt,
Speicherbefehl der CEMSI ist. In der Abbildung aus 27 ist der
Befehl MX speichern in dem oberen Abschnitt des Speicherpuffers 184C der
CEMSI. Wenn sich der Befehl MX speichern nicht in dem Speicherpuffer 184C ist,
so wäre
der CEMSI der Befehl MX speichern in dem Speicherpuffer 184B.
Während
die Komparatoren und die Übereinstimmungsbestimmungslogik 356 bestimmen,
ob ein CEMSI existiert, kann ein Verweis in dem Datencache 176 (und
sonstigen Speicher) als bereit erscheinen, wenn kein CEMSI existiert.
Die Übereinstimmungsbestimmungslogik 356 weist
eine Datenpfadsteuerlogik 390 auf, die ein Signal an dem
Leiter 370 vorsieht, um zu steuern, ob der MUX 192 Daten
von einem Speicher oder einem Speicherpuffer leitet bzw. weiterleitet.
-
Gemäß einem
Ansatz werden von der MOB-Steuerschaltkreisanordnung 302 zwei
Prioritätsbestimmungen
vorgenommen. Einmal kann die Priorität der Speicherbefehle in den
Speicherpuffern bestimmt werden. Zum anderen kann die Priorität der Speicherpuffer
bestimmt werden. Die Bestimmungen können in beliebiger Reihenfolge
erfolgen. Eine Übertragungskettenstruktur
kann für
die Bestimmung der Priorität
in dem Speicherpuffer verwendet werden. In einem Ausführungsbeispiel
wird zum Beispiel für
jeden anderen Speicherpuffer als den mit der gleichen Thread-ID
wie der Ladebefehl bestimmt, welcher übereinstimmende Speicherbefehl,
falls vorhanden, der jüngste
in der Programmreihenfolge ist. Für den Speicherpuffer mit der
gleichen Thread-ID wie der Ladebefehl wird bestimmt, welcher übereinstimmende
Befehl, falls vorhanden, der in der Programmreihenfolge dem CESI
am nächsten
liegende Befehl ist (einschließlich
mit diesem identisch). Danach wird bestimmt, welche dieser Speicherpuffer
mit einem übereinstimmenden
Befehl eine Thread-ID aufweisen, die in der Programmreihenfolge
der Thread-ID des Ladebefehls am nächsten ist.
-
Die
Speicherpuffer 184 können
runde Anordnungen mit einem Kopf- und Schwanzende bzw. mit einem
oberen und einem unteren Ende darstellen Bei der Freigabe und Zuordnung
von Speichereinträgen läuft das
untere Ende letztendlich um, so dass das obere Ende auf einen höheren SBID-Eintrag
zeigt als das untere Ende. In einem Ausführungsbeispiel wird ein Umlaufbit
umgeschaltet, wenn das untere Ende von dem höchsten zu dem niedrigsten SBID-Wert wechselt
und wird an die Bestimmungslogik 356 für die beste Übereinstimmung
vorgesehen.
-
b. Ausführung von
Speicherbefehlen
-
Wenn
ein Speicherbefehl ausgeführt
wird, so wird dessen Adresse mit den Adressen von Ladebefehlen verglichen,
um zu bestimmen, welche Ladebefehle, falls vorhanden, die in der
Programmreihenfolge später
erfolgen (aus dem gleichen oder einem jüngeren Thread), die gleiche
Adresse aufweisen wie der Speicherbefehl. Ein am nächsten liegender,
späterer
Ladebefehl (CLLI), auf den die Speicher-SBID zeigt, bezeichnet den
frühesten
Ladebefehl, der in Frage kommt.
-
In
einem Ausführungsbeispiel
ist jedem Eintrag jedes der Ladepuffer 182 für diese
Vergleiche ein anderer Komparator zugeordnet. Einer der Komparatoren
ist der Komparator 324 aus 26. Als
reines Beispiel ist der Komparator 324 dem Eintrag LBID
1 des Ladepuffers 182A zugeordnet. Der Komparator 324 empfängt die
Adresse eines Speicherbefehls an einem Eingang und die Adresse in
dem Feld Adresse laden des Eintrags LBID 1 in dem Ladepuffer 182A an
einem anderen Eingang. Ein Signal an dem Ausgabeleiter 326 zeigt
an, ob die Adressen übereinstimmen.
Der Leiter 326 sowie die Ausgabeleier anderer Komparatoren
sind mit der MOB-Steuerschaltkreisanordnung 302 verbunden.
Die Komparatoren (wie etwa der Komparator 324) können auch
Statusbits des Speicherbefehls mit Statusbits in dem Ladepuffer vergleichen,
wie dies nachstehend im Text beschrieben ist.
-
Die
Abbildung aus 28 ist der Abbildung aus 27 ähnlich.
In der Abbildung aus 28 werden die Ladebefehlsadressen
in den Ladepuffern 182A – 182D jedoch mit
der Adresse eines auszuführenden
Speicherbefehls verglichen, und die Übereinstimmungsbestimmungslogik 356 bestimmt,
ob Ladebefehle erneut wiedergegeben werden sollen. In einem Ausführungsbeispiel
weist die Übereinstimmungsbestimmungslogik
eine Wiedergabeauslöselogik 394 auf,
die Signale an den Leitern 194 bereitstellt, um den Trace-Puffern
anzuzeigen, welche Ladebefehle wiedergegeben werden sollen. In einem Ausführungsbeispiel
berücksichtigt
die Übereinstimmungsbestimmungslogik 356 Übereinstimmungen von Ladebefehlen
mit dem Speicherbefehl, der mit dem CLLI beginnt. Dabei können verschiedene
Algorithmen verwendet werden. Die Thread-Management-Logik 124 zeigt
die Thread-IDs an, die in de Programmreihenfolge später erfolgen
als die Thread-ID des ausgeführten
Speicherbefehls. In einem Ausführungsbeispiel
sind alle Komparatoren freigegeben. In einem anderen Ausführungsbeispiel sind
nur die Leier in den Ladepuffern freigegeben, welche Thread-IDs
aufweisen, die in der Programmreihenfolge gleichzeitig oder nach
der Thread-ID des Ladebefehls angeordnet sind. In einem weiteren Ausführungsbeispiel
sind nur die Leiter in den Ladepuffern freigegeben, die dem CLLI
und späteren
Befehlen zugeordnet sind. Die zu berücksichtigenden Threads können vor,
nach oder während
der Bestimmung berücksichtigt
werden, welche Ladebefehle in den Ladepuffern in der Programmreihenfolge
nach dem Speicherbefehl angeordnet sind.
-
Gemäß einem
Ausführungsbeispiel
umfasst die Detektionsschaltkreisanordnung zum Detektieren bestimmter
Spekulationsfehler bei der Ausführung von
Ladebefehlen die den Ladebefehlen zugeordneten Komparatoren, Abschnitte
der Übereinstimmungsbestimmungslogik 356 und
zugeordnete Steuerschaltkreise. In anderen Ausführungsbeispielen kann die Detektionsschaltkreisanordnung
eine in gewisser Weise andere Schaltkreisanordnung aufweisen. Es
ist erforderlich, dass sich die Detektionsschaltkreisanordnung zum
Detektieren von Spekulationsfehlern in der Ausführungs-Pipeline befindet. Eine
andere Übereinstimmungsbestimmungslogik kann
in Verbindung mit der Datenpfadsteuerlogik und der Wiedergabeauslöselogik
verwendet werden.
-
i. Fälle, in denen eine Adressübereinstimmung
gegeben ist
-
Das
Statusfeld (SB Hit, SBID, Thread ID, Wiedergabezählwert (sofern verwendet))
für diese jüngeren Befehle,
für die
eine Adressübereinstimmung
existiert, wird bei der Bestimmung, ob eine Wiedergabe erfolgen
soll, berücksichtigt.
Das Statusfeld zeigt an, ob der Ladebefehl seine Daten aus dem Speicher
(z.B. Datencache 176) erhalten hat oder dem Datenfeld eines
Speicherpuffers. Das Feld SB Hit weist zum Beispiel eine 0 auf,
wenn die Daten aus dem Speicher stammen, und eine 1, wenn die Daten aus
dem Speicherpuffer stammen. Die Felder SBID und Thread ID weisen
die SBID und die Thread-ID des Speicherbefehls auf, von dem die
Daten stammen. Die Thread-ID des Speicherbefehls ist nicht unbedingt
die Thread-ID des Ladebefehls, für
den eine Adressübereinstimmung
existiert. Die Thread-ID des Ladebefehls befindet sich implizit
in dem Ladepuffer. Das Wiedergabezählwertfeld (sofern verwendet) zeigt
an, welche Wiedergabe betroffen ist. (Wenn SB Hit gleich 0 ist,
sind die Daten in den Feldern SBID, Thread ID und Wiedergabezählwert bedeutungslos.) Bei
SB Hit = 0 (vorangehende Daten aus dem Speicher) wird ein Wiedergabeereignis
aus dem Ladepuffer über
die Leiter 194 an den durch die Thread-ID des Ladebefehls
identifizierten Trace-Puffer
signalisiert, und dieser Ladebefehl und alle abhängigen Befehle werden aus dem
Trace-Puffer angezeigt. Die Befehls-ID und die Thread-ID werden über die
Leiter 194 weitergeleitet, um anzuzeigen, welcher Befehl wiedergegeben
wird.
-
Bei
SB Hit = 1 (vorangehende Daten aus dem Speicherpuffer), steuern
die Werte in dem Feld SBID, dem Feld Thread ID und dem Feld Wiedergabezählwert (sofern
verwendet), ob eine Wiedergabe ausgelöst wird. In einem ersten Fall
entspricht die Thread-ID des Statusfelds für den jeweiligen Ladebefehl
der Thread-ID des Speicherbefehls, und die SBID in dem Statusfeld
des jeweiligen Ladebefehls entspricht der SBID des Speicherbefehls.
In dem ersten Fall wird der Ladebefehl wiedergegeben, wenn der Wiedergabezählwert des
Speicherbefehls größer ist
als der Wiedergabezählwert
in dem Statusfeld. Wenn kein Wiedergabezählwert existiert (da ein Speicherbefehl
zu einem bestimmten Zeitpunkt nur einmal wiedergegeben werden kann),
so wird der Ladebefehl wiedergegeben.
-
In
einem zweiten Fall entspricht die Thread-ID in dem Statusfeld der
Thread-ID des Speicherbefehls, wobei die SBID in dem Statusfeld nicht
mit der SBID des Speicherbefehls übereinstimmt. In dem zweiten
Fall wird der Ladebefehl wiedergegeben, wenn die SBID in dem Statusfeld
kleiner ist als die SBID des Speicherbefehls, wobei keine Wiedergabe
erfolgt, wenn die SBID in dem Statusfeld größer ist als die SBID des Speicherbefehls.
-
In
einem dritten Fall stimmen die Thread-IDs des Statusfelds und des
Speicherbefehls nicht überein.
Es wird erwartet, dass dies ein selten auftretender Fall ist. Gemäß einem
Ausführungsbeispiel
wird zur Vereinfachung der Ladebefehl wiedergegeben (auch wenn dies
im Gegensatz zu der Programmreihenfolge steht). Dabei kann es sich
um eine falsche Wiedergabe handeln. Wenn der Ladebefehl wiedergegeben
wird, empfängt
er die richtigen Speicherdaten. Andere Ansätze können verwendet werden, wobei
sie jedoch deutlich weniger komplex sein können, als wie dies für einen
derartig seltenen Fall gerechtfertigt ist.
-
ii. Fälle, in denen keine Adressübereinstimmung
gegeben ist
-
Wenn
die Adressen nicht übereinstimmen, so
wird mit Ausnahme des folgenden seltenen Falls keine Wiedergabe
ausgelöst.
Bei SB Hit = 1 stimmt die Thread-ID des Statusfelds mit der Thread-ID
des Speicherbefehls überein,
und die SBID des Statusfelds stimmt mit dem SBID des Speicherbefehls überein.
-
In
diesem Fall ist eine Wiedergabe gegeben, und der wiedergegebene
Ladebefehl empfängt
seine Daten von einem neuen Eintrag oder dem Speicher.
-
c. Zurücksetzung bzw. Reset
-
Ein
Thread wird zurückgesetzt,
wenn bestimmt wird, dass sich der Thread nicht in der Programmreihenfolge
befindet. Ladevorgänge
aus anderen Threads können
Daten aus dem Datenfeld entnommen haben, das den Speicherbefehlen
in diesem Thread zugeordnet ist. Die Thread-Management-Logik 124 sendet
ein Signal an die Steuerschaltkreisanordnung 302. Wenn
ein Thread in einem Ausführungsbeispiel
zurückgesetzt
wird, wird die Thread-ID des zurückgesetzten
Threads mit jedem Ladebefehl in jedem Ladepuffer verglichen (ausgenommen
ist unter Umständen
der dem zurückgesetzten
Thread entsprechende Ladepuffer). Eine Wiedergabe wird für Ladebefehle
ausgelöst,
wobei die Thread-ID in dem Statusfeld mit der Thread-ID des zurückgesetzten
Threads übereinstimmt.
Die Ladebefehle werden aus den entsprechenden Trace-Puffern wiedergegeben.
-
3. Wiedergabe
von Speicherbefehlen
-
Wie
dies bereits vorstehend im Text beschrieben worden ist, werden Ladebefehle
als Reaktion auf die Ausführung
von Speicherbefehlen wiedergegeben. In einem Ausführungsbeispiel
werden Speicherbefehle als Reaktion auf Registervergleiche in den
Trace-Puffern wiedergegeben, welche anzeigen, dass sich ein Registerwert
verändert
hat. In Bezug auf die Abbildungen der 12 und 13 sind die
Befehls-IDs 4 und 5 in dem Trace-Puffer 114A, die Speicherbefehle
darstellen, zum Beispiel abhängig
von den Registern R1 bis R4 dargestellt.
-
4. Wiedergaben von mehreren
Ladebefehlen
-
Es
ist möglich,
dass mehr als ein Ladebefehl in einem Ladepuffer eine Statusfeldübereinstimmung mit
einem Speicherbefehl aufweist. Um eine komplizierte Logik zu vermeiden,
wird gemäß einem
Ansatz für
die Steuerschaltkreisanordnung 302 detektiert, wenn mehrere
Ladeadressenübereinstimmungen gegeben
sind, und wobei eine erneute Ausführung aller Befehle nach dem
frühesten
Ladebefehl in der Trace bewirkt wird.
-
5. Abschließende Rückordnung
von Lade- und Speicherbefehlen
-
Wenn
ein Lade- oder Speicherbefehl abschließend rückgeordnet wird, sieht die
Logik 134 für eine
abschließende
Rückordnung
Signale an die Trace-Puffer 114 und den MOB 184 vor,
die anzeigen, dass ein Befehl abschließend rückgeordnet werden soll. Der
Eintrag in dem Trace-Puffer (durch die Befehls-ID und die Thread-ID
angezeigt) wird freigegeben. Für
den Fall von Ladebefehlen wird der Eintrag in dem Ladepuffer (identifiziert
durch die Thread-ID und die LBID) freigegeben. Für den Fall von Ladebefehlen
ist die abschließende
Rückordnung
damit abgeschlossen. Für
den Fall von Speicherbefehlen müssen
die Daten in dem Datenfeld vor der Freigabe in dem Speicher gespeichert
werden. Die Freigabe des Eintrags in dem Speicherpuffer und folglich
die abschließende
Rückordnung
erfolgen erst, nachdem eine Bestätigung
empfangen worden ist, dass der Speichervorgang abgeschlossen ist.
Alternativ kann der Eintrag vor der Bestätigung abschließend rückgeordnet
werden, wobei eine neue Zuordnung des Eintrags erst nach einem Empfang
der Bestätigung erfolgen
kann. Signale an den Leitern 200 können der Thread-Management-Logik 124 anzeigen,
wenn eine abschließende
Rückordnung
der Speicherbefehle abgeschlossen ist und der nächste Thread beginnen kann.
-
SB
rückgeordnet
zeigt an, dass ein Befehl rückgeordnet
worden ist. Zu diesem Zeitpunkt zeigt die Logik 134 für eine abschließende Rückordnung an,
dass ein Befehl rückgeordnet
werden soll, wobei ein Bit in dem Feld SB rückgeordnet geltend gemacht wird.
Nachdem das Feld SB rückgeordnet
geltend gemacht worden ist, wird der zugeordnete Befehl in der richtigen
Reihenfolge in den Speicher geschrieben. Sobald der MOB 184A erfährt, dass
der Befehl in den Speicher geschrieben worden ist, wird das Feld
SB rückgeordnet
aufgehoben und der Befehl wird freigegeben.
-
Der
Ladepuffer 182A und der Speicherpuffer 184A können Warteschlangen
mit einem oberen und einem unteren Ende darstellen. Das obere Ende
wird verschoben, wenn ein Befehl freigegeben wird. In dem Ladepuffer 184A und
den Trace-Puffern 114 können
die Rückordnung
und die Freigabe gleichzeitig erfolgen. Die Logik 134 für eine abschließende Rückordnung
sieht ein Signal durch die Leiter 136 und 140 vor.
Der Demultiplexer (Demux) 188 entscheidet, ob einer der
Ladepuffer 182 oder der Speicherpuffer 184 ein
Rückordnungssignal
empfängt. Der
Demux 188 ist optional und kann durch Freigabeanschlüsse in den
Ladepuffern 182 und den Speicherpuffern 184 ersetzt
werden.
-
F. Zusätzliche Informationen zur Thread-Managementlogik
und abschließenden
Rückordnungslogik
-
In
einem Ausführungsbeispiel
verwendet die Thread-Management-Logik 124 eine
Baumstruktur, um die Thread-Reihenfolge zu verfolgen. Gemäß der Baumstruktur
verläuft
die Programmreihenfolge (die auch der Rückordnungsreihenfolge entspricht)
von oben nach unten, und ein Knoten auf der rechten Seite ist in
der Programmreihenfolge einem Knoten auf der linken Seite vorangestellt.
Eine Wurzel stellt den Beginn der Programmreihenfolge dar. Ein Baum
ist eine abstrakte Idee, während
eine Baumstruktur eine Schaltkreisanordnung darstellt, die den Baum
implementiert.
-
Threads
beginnen mit dem Befehl, der auf eine Rückwärtsverzweigung oder einen Funktionsaufruf
folgt. Das heißt,
Threads beginnen mit dem nächsten
Befehl, wenn angenommen wird, dass die Rückwärtsverzweigung nicht erfolgt
ist oder die Funktion nicht aufgerufen worden ist (wie dies durch die
Threads T2 in den Abbildungen der 4 und 5 dargestellt
ist). Aus der Perspektive eines Threads (Knotens) ist die Programmreihenfolge
von untergeordneten Threads des Threads in diesem Fall umgekehrt
angeordnet wie der Beginn der Threads (deren Erzeugung). In der
Abbildung aus 6 beginnt die Ausführung des
Threads T2 zum Beispiel vor der Ausführung des Threads T3, wobei
der Thread T3 in der Programmreihenfolge jedoch vor dem Thread T2
auftritt.
-
In
einem Ausführungsbeispiel
können
drei Ereignisse die Entfernung eines Threads von dem Baum bewirken:
(1) Ein Thread an der Wurzel des Baums wird entfernt, wenn der Thread
rückgeordnet wird.
Wenn der Thread an der Wurzel rückgeordnet wird,
wird der nächste
Thread (Knoten) in der Programmreihenfolge zur Wurzel und die Knoten
werden dementsprechend neu zugeordnet. (2) Ein Thread, der in der
Programmreihenfolge an letzter Stelle steht, wird von dem Baum entfernt,
um Platz für
das Hinzufügen
eines höheren
Threads in der Programmreihenfolge zu schaffen. Diesbezüglich fungiert
der Baum als Last-in-First-Out-Stapel (LIFO-Stapel). (3) Ein Thread
kann zurückgesetzt und
dadurch von dem Baum entfernt werden, wenn festgestellt wird, dass
sich der Programmzähler
des übergeordneten
Threads außerhalb
eines Bereichs zwischen dem Anfangszählwert und einem Endzählwert befindet.
Wenn ein untergeordneter Thread an einer Rückwärtsverzweigung erzeugt wird
(z.B. der Thread T4 aus den Abbildungen der 6 und 29),
so ist der Anfangszählwert
das Ziel der Rückwärtsverzweigung,
und der Endzählwert
ist der Programmzählerwert
an dem Rückwärtsverzweigungsbefehl.
Ein nach einem Funktionsaufruf gestarteter Thread kann ebenso zurückgesetzt
werden, da kein Rücksprung
von der Funktion erfolgt, obwohl dies sehr selten auftritt. Ein
Ansatz zur Behandlung der Möglichkeit,
dass kein Rücksprung
von einer Funktion erfolgt, ist es, die Möglichkeit zu ignorieren, und
wobei das System den Thread letztlich von dem Baum entfernen kann,
wenn dieser in der Programmreihenfolge den untersten Platz einnimmt,
wie dies für
(2) gilt. Wenn ein Thread von dem Baum entfernt wird, werden die
diesem Thread zugeordneten Ressourcen (wie etwa ein Trace-Puffer,
ein Speicherpuffer und ein Ladepuffer) freigegeben.
-
Die
Ereignisse (1) und (3) sind in der Abbildung aus 29 veranschaulicht,
welche die Threads aus dem Beispiel aus 6 aufweist
sowie zusätzlich
die Threads T5 und T6. Der Thread T5 beginnt nach einem Rückwärtsverzweigungsbefehl
an dem Punkt J, und der Thread T6 beginnt nach einem Funktionsaufruf
an dem Punkt K. Es wird angenommen, dass nur vier Trace-Puffer vorhanden
sind. Die Abbildung aus 30 veranschaulicht
die Baumstruktur zum Zeitpunkt t1. Der Thread T2 wird zu dem Baum
hinzugefügt,
bevor der Thread T3 dem Baum hinzugefügt wird. Der Thread T4 wird
dem Baum hinzugefügt,
nachdem der Thread T3 dem Baum hinzugefügt worden ist. Die Threads
T2 und T3 sind untergeordnete Threads des Thread T1. Der Thread
T4 ist dem Thread T3 untergeordnet. Gemäß den Regeln von oben nach
unten und von rechts nach links lauten die Programm- und Rückordnungsreihenfolgen T1,
T3, T4 und T2. Die Abbildung aus 3 veranschaulicht
die Baumstruktur zum Zeitpunkt t2, wobei angenommen wird, dass der
Thread T4 zurückgesetzt
wird, bevor der Thread T1 rückgeordnet
wird. Die Programm- und Rückordnungsreihenfolgen
lauten Thread T1, T3, T2 und T5. Die Abbildung aus 32 veranschaulicht
die Baumstruktur zum Zeitpunkt t2, wobei angenommen wird, dass der
Thread T2 rückgeordnet
wird, bevor der Thread T4 zurückgesetzt
wird. Die Programm- und Rückordnungsreihenfolgen
lauten Thread T3, T4, T2 und T5. Die Abbildung aus 33 veranschaulicht
die Baumstruktur zum Zeitpunkt t3, der zeitlich nach der Rückordnung von
Thread T1 und dem Zurücksetzen
von Thread T4 liegt. Die Programm- und Rückordnungsreihenfolgen lauten
T3, T2, T5 und T6.
-
Das
Ereignis (2) ist in der Abbildung aus 34 dargestellt,
welche verschachtelte Funktionen aufweist. In zeitlicher Reihenfolge
werden die Threads in der Reihenfolge T1, T2, T3, T4 und T5 erzeugt
(begonnen). Die Programmreihenfolge lautet jedoch T1, T5, T4, T3
und T2. In dem Beispiel sind nur vier Trace-Puffer vorhanden. Somit
existieren nicht alle fünf
Threads gleichzeitig. Die Abbildung aus 35 veranschaulicht
die Baumstruktur zum Zeitpunkt t1, der vor dem Beginn von Thread
T5 liegt. Die Programm- und Rückordnungsreihenfolge
lautet T1, T4, T3 und T2. Der Thread T5 ist noch nicht Bestandteil
der Baumstruktur. Die Abbildung aus 36 veranschaulicht
die Baumstruktur zum Zeitpunkt t2, der nach dem Beginn von Thread
T5 liegt. Der Thread T2, der in der Programmreihenfolge an unterster Stelle
steht, wird aus der Baumstruktur entfernt, um Platz für den Thread
T5 zu schaffen. Ein von der Baumstruktur entfernter Thread kann
zu einem späteren
Zeitpunkt erneut gestartet werden. Alternativ kann ein anderer Thread
die Befehle des von dem Baum entfernten Threads ganz oder teilweise
ausführen.
In einem Ausführungsbeispiel
kann ein Thread für
den Fall einer Zurücksetzung
vorziehen, dem nächsten
folgenden Thread als dem zurückgesetzten
Thread zugeordnet zu werden. Alternativ kann der Thread einfach
nur fortgeführt
werden, bis er anderweitig endet. Die Funktion der Anordnung bzw.
Array 198 kann in den Knoten des Baums ausgeführt werden.
-
Die
Thread-IDs der untergeordneten Threads werden gemäß der Programmreihenfolge
in der Baumstruktur ordnungsgemäß positioniert.
(Obwohl sich die durch die Thread-Management-Logik 124 bestimmte Programmreihenfolge ändern kann.) Ein
Thread ist abgeschlossen, wenn er dem Programmzählwert des nächsten Threads
in dem Baum in Programmreihenfolge hinzugefügt wird oder mit diesem übereinstimmt.
Wenn der Thread nur einen untergeordneten Thread aufweist, so ist
dieser der nächste
Thread in der Programmreihenfolge. Zum Beispiel ist der Thread T2
in der Abbildung aus 33 der nächste Thread der Programmreihenfolge
in dem Baum.
-
Die
Logik 134 für
die abschließende
Rückordnung
erhält
von der Baumstruktur Informationen über die Zusammensetzung der
Anordnung 198 oder direkt von der Schaltkreisanordnung
der Baumstruktur. Zwischen der Baumstruktur und der sonstigen Logik
der Thread-Management-Logik 124 und der Logik der Logik 134 der
abschließenden
Rückordnung
kann eine Decodierungsschaltkreisanordnung angeordnet sein. Es ist
möglich,
dass eine Anordnung 198 nicht erforderlich ist.
-
Zusammengefasst
liefert die Baumstruktur Informationen für zumindest die folgenden Zwecke: (1)
der Baum spezifiziert die Rückordnungsreihenfolge;
(2) der Baum spezifiziert die Programmreihenfolge, die zum Beispiel
von dem MOB 178 gemäß der vorstehenden
Beschreibung verwendet wird; (3) der Baum spezifiziert einen Endpunkt
eines Threads, indem der Startbefehl eines anderen Threads angezeigt
wird; (4) der Baum wird bei der Thread-Ressourcenzuweisung verwendet,
indem angezeigt wird, welche Ressourcen verfügbar sind und welche Ressourcen
freigegeben werden.
-
G. Ein Ausführungsbeispiel
ohne Multithreading
-
Die
Abbildung aus 3 veranschaulicht einen Prozessor 100,
der eine Pipeline 308 aufweist. Der Prozessor 100 ist
dem Prozessor 50 ähnlich.
Allerdings ist der Trace-Puffer 300 der einzige Trace-Puffer,
und der MOB 310 ist der einzige MOB. Der Prozessor 50 ist
nicht für
die Verarbeitung mehrerer Threads ausgelegt. Die Thread-Management-Logik ist
für den
Prozessor 100 somit nicht erforderlich. Der Trace-Puffer 300 kann
zum Beispiel dem Trace-Puffer 144A entsprechen, mit der
Ausnahme, dass keine spezifischen Multithread-Komponenten erforderlich sind.
Zum Beispiel sind die Leiter 216 und die Ausgaberegisterdatei 210 nicht
erforderlich. Zum Detektieren von Spekulationsfehlern können verschiedene Schaltkreisanordnungen
verwendet werden, einschließlich
allgemein bekannter Schaltkreisanordnungen. Der MOB 310 kann
zum Beispiel dem MOB 178A ähnlich sein, mit der Ausnahme,
dass keine spezifischen Multithread-Merkmale erforderlich sind. Zum
Beispiel kann ein Feld Thread-ID in dem Ladepuffer nicht erforderlich
sein. Andere Komponenten des Prozessors 100 können in
gewisser Weise in Bezug auf deren Konfiguration in dem Prozessor 50 modifiziert
werden, um Multithreadingrelevante Merkmale zu entfernen. Der Trace-Puffer 300 und
der MOB 310 können
in Verbindung mit verschiedenen Spekulationen und zur Wiederherstellung
von Fehlern darin verwendet werden. Der Trace-Puffer ermöglicht es,
dass eine große
Anzahl von Befehlen außerhalb
der Pipeline gespeichert wird, um eine mögliche Wiedergabe vor der abschließenden Rückordnung
zu ermöglichen.
-
Der
Prozessor 50 kann in Verbindung mit einem Programm ohne
Multithreading eingesetzt werden. In diesem Fall kann die Thread-Management-Logik 124 in
der Programmreihenfolge stets die gleiche Thread-ID führen. Alternativ
kann die Thread-Management-Logik 124 deaktiviert
werden. In dem Fall ohne Multithreading wird nur einer der Trace-Puffer 114 und
nur einer der MOBs 178 verwendet. Alternativ können die
Trace- Puffer kombiniert
werden, um einen größeren Trace-Puffer
zu gestalten, und MOBs können
zur Gestaltung eines größeren MOB
verknüpft
werden.
-
H. Zusätzliche Informationen und Ausführungsbeispiele
-
In
Bezug auf die Abbildung aus 37 handelt
es sich bei dem Prozessor 400 um einem Multiprozessorchip
(MP-Chip) mit einer Multi-Pipeline-Einheit 402. Die Multi-Pipeline-Einheit 400 unterscheidet
sich von der Pipeline 108 mit gemeinsam genutzten Ressourcen
aus 2 dadurch, dass die gesamte Pipeline (z.B. separate
Umbenennungs-/Zuordnungseinheit für jede Pipeline) für jede Pipeline
0, 1, ... W der Multi-Pipeline-Einheit 402 enthalten
ist (W kann größer, kleiner
oder gleich X sein). Ansonsten kann der Prozessor 400 im
Wesentlichen dem Prozessor 50 entsprechen oder sich erheblich von
diesem unterscheiden. Andere Prozessoren können einige Funktionen bzw.
Merkmale der Multi-Pipeline-Einheit 402 und einige Merkmale
der Pipeline 108 aufweisen.
-
Jeder
der hierin erwähnten
Prozessoren kann in einem Eil einer Vielzahl von Computersystemen
enthalten sein. In Bezug auf die ausschließlich als Beispiel dienende
Abbildung aus 38 kann der Prozessor 50 ein
Bestandteil eines Computersystems 430 sein. Das System 430 kann
ferner einen zweien Prozessor 434 aufweisen. Ein chipintegrierter L2-Cache
(L2 als Abkürzung
von Second Level) kann in dem Prozessor 50 enthalten sein.
Der Prozessor 50 kann über
einen Prozessorbus 42 mit einer Speichersteuereinheit 440 kommunizieren.
Die Speichersteuereinheit 440 kann über die Busse 452 und 454 mit
dem Hauptspeicher 446 und Peripheriegeräten 448 kommunizieren.
-
Eine
der Pipeline 108 oder 308 ähnliche Pipeline (2 und 3)
kann in einem Prozessor verwendet werden, der keine Registerumbenennung verwendet.
In diesem Fall können
die an der Registerumbenennung beteiligten Komponenten (z.B. die Umbenennungs-/Zuordnungseinheit 150)
modifiziert werden, um Funktionen bzw. Merkmale in Bezug auf die
Umbenennung zu entfernen.
-
Die
beschriebenen und veranschaulichten Einzelheiten dienen ausschließlich Beispielzwecken. Verschiedene
andere Schaltungen und Einzelheiten können an ihrer Stelle verwendet
werden. Ferner sind verschiedene Designkompromisse möglich, wie zum
Beispiel in Bezug auf die Größe, die
Latenzzeit, etc. Zum Beispiel kann es sein, dass die maximale Betriebstaktfrequenz
gesenkt werden muss, wenn Puffer in dem Ausführungspfad (z.B. in der Reservierungsstation,
der Registerdatei, dem ROB) zu groß sind. Die hierin veranschaulichten
Komponenten können
gemäß verschiedenen
Techniken gestaltet und konstruiert werden.
-
Zwischen
zwei veranschaulichten Strukturen können sich eine intermediäre Struktur
(wie etwa ein Puffer) oder Signale befinden. Bestimmte Leiter können abweichend
von der Veranschaulichung nicht ununterbrochen sein, wobei sie vielmehr
durch eine intermediäre
Struktur unterbrochen werden. Die Begrenzungen der Kästchen in
den Abbildungen dienen Veranschaulichungszwecken. Ein tatsächlicher
Baustein müsste
keine Komponenten mit auf diese Weise festgelegten Begrenzungen
aufweisen. Die relative Größe der veranschaulichten
Komponenten soll keine tatsächlich
gegebenen relativen Größen darstellen.
Pfeile zeigen bestimmte Datenflüsse
in bestimmten Ausführungsbeispielen,
jedoch nicht jedes Signal, wie zum Beispiel Datenanforderungen.
Wenn vorstehend ein logisch hohes Signal beschrieben ist, so kann
es durch ein logisch niedriges Signal ersetzt werden oder vice versa.
-
Die
in einem Prozessor veranschaulichen Komponenten können sich
alle auf dem gleichen Prozessorchip befinden. Alternativ können sich
zum Beispiel die Trace-Puffer auf einem anderen Chip als die Ausführungs-Pipeline
befinden.
-
Die
Begriffe "verbunden", "gekoppelt" sowie verwandte
Begriffe sind nicht auf eine direkte Verbindung oder eine direkte
Kopplung beschränkt,
vielmehr können
sie eine indirekte Verbindung oder eine indirekte Kopplung einschließen. Der
Begriff "reagierend" bzw. "ansprechend" und verwandte Begriffe
bedeuten, dass ein Signal oder ein Ereignis in gewisser Weise durch
ein anderes Signal oder ein anderes Ereignis beeinflusst ist, allerdings
nicht unbedingt vollständig
oder direkt. Wenn in der Beschreibung darauf verwiesen wird, dass
eine Komponente enthalten sein "kann", "könnte" oder "vorzugsweise enthalten ist", so muss die jeweilige
Komponente nicht zwingend enthalten sein.
-
Ein
MOB kann eine Datenanpassung an Stelle der Adressenanpassung zum
Detektieren einer Fehlspekulation verwenden.
-
Der
von der vorliegenden Offenbarung profitierende Fachmann erkennt,
dass zahlreiche weitere Abänderungen
in Bezug auf die vorstehende Beschreibung und die Zeichnungen gemäß dem Umfang
der vorliegenden Erfindung vorgenommen werden können. Demgemäß ist der
Umfang der vorliegenden Erfindung durch die folgenden Ansprüche einschließlich etwaiger
Abänderungen
dieser definiert.