DE69829693T2

DE69829693T2 - Prozessor mit mehrfachprogrammzählern und ablaufverfolgungspuffern ausserhalb einer ausführungspipeline

Info

Publication number: DE69829693T2
Application number: DE69829693T
Authority: DE
Inventors: Haitham Akkary; Kingsum Chow
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1997-12-16
Filing date: 1998-12-11
Publication date: 2006-01-12
Anticipated expiration: 2018-12-12
Also published as: BR9813650A; US6493820B2; WO1999031580A1; HK1031005A1; US6182210B1; JP3957455B2; CN100390727C; DE69829693D1; EP1068570A4; US6247121B1; EP1068570A1; US20010014941A1; CN1286769A; KR20010033242A; TW406239B; EP1068570B1; KR100388947B1; AU1913799A; JP2002508564A

Description

Stand der Technik
Technisches Gebiet der Erfindung
Die vorliegende Erfindung betrifft Prozessoren und im Besonderen Prozessoren, die Threads gleichzeitig verarbeiten.
Beschreibung des Stands der Technik
Aktuelle superskalare Prozessoren wie etwa ein Mikroprozessor 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.
Multithreading-Prozessoren wie etwa Multithreading-Prozessoren mit gemeinsam genutzter Ressource und On-Chip-Mikroprozessoren (MP) können mehrere Threads bzw. Prozessstränge gleichzeitig verarbeiten und ausführen. Die von diesen Prozessoren verarbeiteten und ausgeführten Threads sind voneinander unabhängig. Zum Beispiel stammen die Threads von vollständig unabhängigen Programmen oder aus dem gleichen Programm, wobei sie dabei speziell kompiliert sind, um Threads ohne Abhängigkeiten zwischen den Threads zu erzeugen. Diese Prozessoren sind jedoch nicht in der Lage, verschiedene Threads aus dem Programm, die Abhängigkeiten aufweisen, gleichzeitig auszuführen. Die Nützlichkeit der Multithreading-Prozessoren ist dadurch beschränkt.
Als Beispiele kann dabei auf folgende Dokumente verwiesen werden: "Trace Processors" von E. Rotenberg et al., Proceedings of the 30th Annual IEEE/ACM International Symposium on Microarchitecture. Micro-30, Research Triangle Park, NC, USA, 1. bis 3. Dezember 1997, Proceedings of the Annual International Symposium on Microarchitecture, Los Alamitos, CA, USA: IEEE Computer Soc., Band 30. Conf, 1. Dezember 1997 (1997-12-01), Seiten 138 bis 148, XP000785841 ISBN: 0-8186-7977-8, offenbart die Fähigkeit, unabhängige Threads gleichzeitig auszuführen.
"Dynamic Instruction Reuse" von A. Sodani et al, 24th Annual International Symposium on Computer Architecture, Denver, 2. bis 4. Juni 1997, Annual International Symposium on Computer Architecture, New York, ACM, US, Band Conf. 24, 2. Juni 1997 (1997-06-02), Seiten 194 – 205, XP000738157 ISBN: 0-7803-4175-9, offenbart einen Pipeline-Prozessor, der Abhängigkeiten von Daten unter Verwendung von Puffern auflöst.
"Single-Program Speculative Multithreading (SPSM) Architecture: Compiler Assisted Fine-Grained Multithreading" von P.K. Dubey, K. O'Brien, K.M. O'Brien, C. Barton, Proceedings International Conference on Parallel Architectures and Compilation Techniques, 27. bis 29. Juni 1995, Seiten 109 – 121, XP008003494, Limassol, Zypern, offenbart eine spekulative Multithreading-Architektur für ein Einzelprogramm, die eine spekulative Decodierung und Ausführung von mehreren Programmstellen gleichzeitig ermöglicht.
Benötigt werden somit Multithreading-Prozessoren, die gleichzeitig verschiedene Threads aus dem gleichen Programm ausführen können, wobei zwischen den Threads Abhängigkeiten existieren können.
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 9.
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 Multithreading-relevante 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.

Claims

Prozessor, der folgendes umfasst: eine Ausführungspipeline (12), die gleichzeitig zumindest Teilstücke von Threads ausführen kann; gekennzeichnet durch einen Detektionsschaltkreis (10), der Spekulationsfehler detektieren kann, die Thread-Abhängigkeiten bei der Ausführung von Threads bewirkt durch fehlerhaft spekulierte Anweisungen umfassen; Überwachungspuffer (14) außerhalb der Ausführungspipeline, die Anweisungen der Threads speichern können, welche die fehlerhaft spekulierten Anweisungen aufweisen; und eine Auslöselogik, die zumindest einige der Anweisungen, sofern zutreffend, als von mindestens einer der fehlerhaft spekulierten Anweisungen abhängig identifizieren und die erneute Ausführung der fehlerhaft spekulierten Anweisungen und zumindest einiger der identifizierten abhängigen Anweisungen, sofern vorhanden, auslösen kann.
Prozessor nach Anspruch 1, wobei dieser ferner eine Thread-Verwaltungslogik (124) zur Steuerung der Erzeugung der Threads umfasst, wobei die Thread-Verwaltungslogik eine Struktur zur Festlegung einer Programmreihenfolge der Threads aufweist, und wobei die Thread-Verwaltungslogik die Erzeugung der Threads abweichend von der Programmanordnung und ohne Bezug auf Thread-Abhängigkeiten steuert.
Prozessor nach Anspruch 2, wobei es sich bei der Struktur um eine Baumstruktur handelt.
Prozessor nach Anspruch 1, wobei dieser ferner eine Thread-Verwaltungslogik (124) zur Steuerung der Erzeugung der Threads umfasst, wobei die Thread-Verwaltungslogik eine Struktur zur Festlegung eines Endpunkts eines der Threads aufweist, indem ein Anfangsbefehl eines anderen Threads angezeigt wird.
Prozessor nach Anspruch 1, wobei dieser ferner eine Thread-Verwaltungslogik (124) zur Steuerung der Erzeugung der Threads umfasst, wobei die Thread-Verwaltungslogik eine Struktur zur Verfolgung der Threads und zur Entfernung einer Darstellung eines der Threads von der Struktur aufweist, um Platz für eine Darstellung eines Threads zur Aufnahme in die Struktur zu schaffen, der in der Programmreihenfolge höher angeordnet ist.
Prozessor nach Anspruch 1, wobei dieser ferner eine Thread-Verwaltungslogik (124) zur Steuerung der Erzeugung der Threads umfasst, wobei die Thread-Verwaltungslogik eine Struktur zur Verfolgung der Threads und zur Entfernung einer Darstellung eines der Threads von der Baumstruktur aufweist, wenn sich ein Programmzähler des übergeordneten Thread außerhalb eins Bereichs zwischen einem Anfangszählwert und einem Endzählwert befindet.
Prozessor nach Anspruch 1, wobei dieser ferner eine Thread-Verwaltungslogik (124) zur Steuerung der Erzeugung der Threads umfasst, wobei die Thread-Verwaltungslogik eine Struktur zum Anzeigen von Ressourcen aufweist, die einen verfügbaren der Überwachungspuffer aufweisen sowie von Ressourcen, die einen freizugebenden der Überwachungspuffer aufweisen.
Prozessor nach Anspruch 1, wobei dieser ferner eine Thread-Verwaltungslogik (124) zur Steuerung der Erzeugung der Threads umfasst, und wobei die Thread-Verwaltungslogik nach dem Rückzug eines Threads Ressourcen zuweist, darunter die Zuordnung eines der für den zurückgezogenen Thread verwendeten Überwachungspuffers an einen in der Programmreihenfolge jüngsten Thread.
Verfahren, das folgendes umfasst: das Erzeugen von Threads außerhalb der Programmreihenfolge (12) ohne Bezug auf Thread-Abhängigkeiten; das gleichzeitige Ausführen zumindest von Teilstücken der Threads in einer Ausführungspipeline; das Detektieren (10) eines Spekulationsfehlers, der eine Thread-Abhängigkeit bei der Ausführung der Threads verursacht durch eine fehlerhaft spekulierte Anweisung aufweist; das Speichern der Threads (14) einschließlich der fehlerhaft spekulierten Anweisung und der Ergebnisse zumindest einiger der Anweisungen in Überwachungspuffern außerhalb der Ausführungspipeline; und das Identifizieren zumindest einiger der Anweisungen, sofern vorhanden, als von der fehlerhaft spekulierten Anweisung abhängig, und das Auslösen einer erneuten Ausführung der fehlerhaft spekulierten Anweisung und zumindest einiger der identifizierten abhängigen Anweisungen, sofern vorhanden.
Verfahren nach Anspruch 9, wobei dieses ferner den Rückzug zumindest einiger der Anweisungen in den Überwachungspuffern umfasst, und wobei einige der Anweisungen nach der Ausführung anfänglich zurückgezogen werden können (34).