DE102019119956A1

DE102019119956A1 - Architektur und verfahren zur datenparallelen einzelprogramm- mehrfachdaten(spmd)-ausführung

Info

Publication number: DE102019119956A1
Application number: DE102019119956.5A
Authority: DE
Inventors: Jonathan Pearce; David Sheffield; Srikanth Srinivasan; Jeffrey Cook; Deborah Marr; Abhijit Davare; Andrey Ayupov
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-09-29
Filing date: 2019-07-24
Publication date: 2020-04-02
Also published as: US20200104139A1; CN110968345A; US10831505B2

Abstract

Eine Vorrichtung und ein Verfahren zur datenparallelen Einzelprogramm-Mehrfachdaten(SPMD)-Ausführung. Eine Ausführungsform eines Prozessors umfasst zum Beispiel: Befehlsabrufverschaltung zum Abrufen von Befehlen eines oder mehrerer primärer Threads; einen Decoder zum Decodieren der Befehle zum Erzeugen von uops; einen datenparallelen Cluster (DPC) zum Ausführen von Mikrothreads, die eine Teilmenge der uops umfassen, wobei der DPC ferner umfasst: eine Vielzahl von Ausführungssignalleitungen zum Durchführen einer parallelen Ausführung der Mikrothreads; eine Befehlsdecodierwarteschleife (IDQ) zum Speichern der uops vor der Ausführung; und eine Planungseinheit zum Auswerten der Mikrothreads auf Grundlage von assoziierten Variablen, die Befehlszeiger(IP)-Werte enthalten, wobei die Planungseinheit Mikrothreads auf Grundlage der Auswertung in Fragmente zur parallelen Ausführung in den Ausführungssignalleitungen zusammenzufassen hat.

Description

STAND DER TECHNIK
Gebiet der Erfindung
Die Ausführungsformen der Erfindung betreffen allgemein das Gebiet der Computerprozessoren. Genauer betreffen die Ausführungsformen eine Vorrichtung und ein Verfahren zur datenparallelen Einzelprogramm-Mehrfachdaten(SPMD)-Ausführung.
Beschreibung der verwandten Technik
Ein Befehlssatz oder eine Befehlssatzarchitektur (ISA) ist der Teil der Computerarchitektur, der mit Programmierung verbunden ist und die nativen Datentypen, Befehle, Registerarchitektur, Adressierungsarten, Arbeitsspeicherarchitektur, Unterbrechungs- und Ausnahmebehandlung und externe Eingabe und Ausgabe (E/A) enthält. Es sei angemerkt, dass sich der Begriff „Befehl“ hierin im Allgemeinen auf Makrobefehle bezieht - d. h. auf Befehle, die dem Prozessor zur Ausführung bereitgestellt werden - im Gegensatz zu Mikrobefehlen oder Mikro-Ops - d. h. auf das Ergebnis des Decoders eines Prozessors, der Makrobefehle decodiert. Die Mikrobefehle oder Mikro-Ops können ausgelegt sein, eine Ausführungseinheit am Prozessor anzuweisen, Operationen durchzuführen, um die mit dem Makrobefehl assoziierte Logik zu implementieren.
Die ISA unterscheidet sich von der Mikroarchitektur, die der Satz von Prozessordesigntechniken ist, der zum Implementieren des Befehlssatzes verwendet wird. Prozessoren mit verschiedenen Mikroarchitekturen können einen gemeinsamen Befehlssatz teilen. Zum Beispiel implementieren Intel® Pentium 4-Prozessoren, Intel® Core™-Prozessoren und Prozessoren von Advanced Micro Devices, Inc. in Sunnyvale, CA, USA, nahezu identische Versionen des x86-Befehlssatzes (mit einigen Erweiterungen, die bei neueren Versionen hinzugefügt wurden), weisen jedoch verschiedene interne Konstruktionen auf. Zum Beispiel kann die gleiche Registerarchitektur der ISA auf unterschiedliche Weise in unterschiedlichen Mikroarchitekturen unter Verwendung hinlänglich bekannter Techniken implementiert werden, einschließlich dedizierter physischer Register, wobei ein oder mehrere dynamisch zugeordnete physische Register einen Registerumbenennungsmechanismus verwenden (z. B. die Verwendung einer Registeraliastabelle (RAT), eines Neuordnungspuffers (ROB) und einer Stilllegungsregisterdatei). Sofern nicht anders angegeben, werden die Ausdrücke Registerarchitektur, Registerdatei und Register hierin verwendet, um auf das Bezug zu nehmen, was für die Software bzw. den Programmierer sichtbar ist, und auf die Weise, in der Befehle Register spezifizieren. Wenn eine Unterscheidung erforderlich ist, werden die Adjektive „logisch“, „architektonisch“ oder „für Software sichtbar“ verwendet, um Register/Dateien in der Registerarchitektur anzugeben, während andere Adjektive zur Bezeichnung von Registern in einer gegebenen Mikroarchitektur verwendet werden (z. B. physisches Register, Neuordnungspuffer, Stilllegungsregister, Register-Pool).
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden Zeichnungen erhalten werden, in denen gilt:

1A und 1B sind Blockdiagramme, die ein generisches vektorgerechtes Befehlsformat und dessen Befehlsvorlagen nach Ausführungsformen der Erfindung veranschaulichen;
2A-C sind Blockdiagramme, die ein beispielhaftes VEX-Befehlsformat nach Ausführungsformen der Erfindung veranschaulichen;
3 ist ein Blockdiagramm einer Registerarchitektur nach einer Ausführungsform der Erfindung; und
4A ist ein Blockdiagramm, das sowohl eine beispielhafte In-Order-, Decodier-, Stilllegungs-Pipeline als auch eine beispielhafte Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline nach Ausführungsformen der Erfindung illustriert;
4B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines In-Order-Kerns für Abrufen, Decodieren, Stilllegung als auch eines beispielhaften Architekturkerns für Registerumbenennung, Out-of-Order-Ausgabe/-Ausführung zur Aufnahme in einen Prozessor nach Ausführungsformen der Erfindung veranschaulicht;
5A ist ein Blockdiagramm eines einzelnen Prozessorkerns zusammen mit seiner Verbindung zu einem rohchipinternen Zwischenverbindungsnetz;
5B veranschaulicht eine erweiterte Ansicht eines Teils des Prozessorkerns in der 5A nach Ausführungsformen der Erfindung;
6 ist ein Blockdiagramm eines Einzelkernprozessors und eines Mehrkernprozessors mit integrierter Arbeitsspeichersteuerung und integrierter Grafik nach Ausführungsformen der Erfindung;
7 veranschaulicht ein Blockdiagramm eines Systems nach einer Ausführungsform der vorliegenden Erfindung;
8 veranschaulicht ein Blockdiagramm eines zweiten Systems nach einer Ausführungsform der vorliegenden Erfindung;
9 veranschaulicht ein Blockdiagramm eines dritten Systems nach einer Ausführungsform der vorliegenden Erfindung;
10 veranschaulicht ein Blockdiagramm eines Ein-Chip-Systems (SoC) nach einer Ausführungsform der vorliegenden Erfindung;
11 veranschaulicht ein Blockdiagramm, das die Verwendung eines Software-Befehlswandlers zum Umwandeln von binären Befehlen in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz nach Ausführungsformen der Erfindung gegenüberstellt;
12 veranschaulicht Beispiele verschiedener Arten von Code, die in Kombination mit Ausführungsformen der Erfindung verwendet werden können;
13 veranschaulicht eine Ausführungsform einer datenparallelen Clusterarchitektur;
14A-C veranschaulichen unterschiedliche Implementierungen zum Integrieren eines DPC mit einem Prozessor;
15 veranschaulicht ein Beispiel eines Mikrothread-Zustands;
16 veranschaulicht eine Ausführungsform einer DPC-Kachel;
17 veranschaulicht eine beispielhafte Codesequenz, die in einer Ausführungsform der Erfindung verarbeitet werden kann;
18 veranschaulicht ein Beispiel, in dem unterschiedliche Threads verschiedene grundlegende Codeblöcke ausführen;
19 veranschaulicht eine Rekonvergenzverschaltung nach einer Ausführungsform der vorliegenden Erfindung;
20 veranschaulicht eine Ausführungsform einer Anordnung von Befehlszeigern;
21 veranschaulicht ein Beispiel einer mikroarchitekturellen Maskenmanipulation;
22 veranschaulicht ein Verfahren nach einer Ausführungsform;
23 veranschaulicht einen Beispielsatz von Befehlsfeldern;
24 veranschaulicht ein Beispiel einer Anordnung von Zeilen und Spalten einer Matrix und assoziierte Operationen;
25 veranschaulicht Operationen, die an einem Beispielsatz von Kacheln durchgeführt werden;
26-28 veranschaulichen unterschiedliche Anordnungen von Verarbeitungselementen;
29A-B veranschaulichen eine Verarbeitungsreihenfolge für verschiedene Kacheln;
30 veranschaulicht zusätzliche Details einer Ausführungsform eines DPC-Front-Ends;
31 veranschaulicht ein Verfahren zum Erkennen und Verwalten von Gang-Invarianz innerhalb eines Parallelprozessors;
32 veranschaulicht eine Ausführungsform zum Koppeln eines Hostprozessors/Kerns an eine Parallelverarbeitungsengine;
33 veranschaulicht eine Ausführungsform eines Verfahrens zum Zuteilen von Arbeit an eine Parallelverarbeitungsengine;
34 veranschaulicht einen beispielhaften übergeordneten Thread, der Schleifeniterationen hervorbringt, die an Parallelausführungsressourcen verteilt werden; und
35 veranschaulicht ein Beispiel einer Parallelverarbeitung über zwei Signalleitungen hinweg.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zum Zwecke der Erläuterung zahlreiche spezifische Details dargelegt, um ein gründliches Verständnis der nachstehend beschriebenen Ausführungsformen der Erfindung bereitzustellen. Es ist allerdings für Fachleute auf dem Gebiet offensichtlich, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Details umgesetzt werden können. In anderen Fällen werden allgemein bekannte Strukturen und Einrichtungen in Blockdiagrammform dargestellt, um zu vermeiden, dass die zugrunde liegenden Prinzipien der Ausführungsformen der Erfindung unverständlich werden.
BEISPIELHAFTE PROZESSORARCHITEKTUREN, BEFEHLSFORMATE UND DATENTYPEN
Ein Befehlssatz enthält ein oder mehrere Befehlsformate. Ein gegebenes Befehlsformat definiert verschiedene Felder (Anzahl von Bits, Position von Bits), um unter anderem die Operation, die durchgeführt werden soll (Opcode), und den/die Operand(en), an dem/denen diese Operation durchgeführt werden soll, zu spezifizieren. Manche Befehlsformate sind ferner durch die Definition von Befehlsvorlagen (oder Teilformaten) aufgegliedert. Zum Beispiel können die Befehlsvorlagen eines bestimmten Befehlsformats definiert sein, verschiedene Teilsätze der Felder des Befehlsformats aufzuweisen (die enthaltenen Felder sind üblicherweise in der gleichen Reihenfolge, aber zumindest einige weisen verschiedene Bitpositionen auf, da weniger Felder enthalten sind), und/oder definiert sein, ein bestimmtes Feld unterschiedlich interpretiert aufzuweisen. Deshalb wird jeder Befehl einer ISA unter Verwendung eines bestimmten Befehlsformats ausgedrückt (und, falls definiert, in einer bestimmten der Befehlsvorlagen dieses Befehlsformats) und enthält Felder zum Spezifizieren der Operation und der Operanden. Zum Beispiel weist ein beispielhafter ADD-Befehl einen bestimmten Opcode und ein Befehlsformat auf, das ein Opcode-Feld, um diesen Opcode zu spezifizieren, und Operanden-Felder enthält, um Operanden auszuwählen (Quelle 1/Ziel und Quelle 2); und ein Auftreten dieses ADD-Befehls in einem Befehlsstrom wird spezifische Inhalte in den Operanden-Feldern aufweisen, die spezifische Operanden auswählen.
Ausführungsformen des hierin beschriebenen Befehls bzw. der hierin beschriebenen Befehle können in unterschiedlichen Formaten ausgeführt werden. Zusätzlich werden beispielhafte Systeme, Architekturen und Pipelines nachfolgend ausführlich beschrieben. Ausführungsformen des Befehls bzw. der Befehle können auf derartigen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf die besprochenen beschränkt.
Generisches vektorfreundliches Befehlsformat
Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das für Vektorbefehle geeignet ist (zum Beispiel gibt es bestimmte Felder, die für Vektorvorgänge spezifisch sind). Obwohl Ausführungsformen beschrieben werden, bei denen sowohl Vektor- als auch skalare Operationen durch das vektorfreundliche Befehlsformat unterstützt werden, verwenden alternative Ausführungsformen nur Vektoroperationen des vektorfreundlichen Befehlsformats.
1A-1B sind Blockdiagramme, die ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen davon nach Ausführungsformen der Erfindung veranschaulichen. 1A ist ein Blockdiagramm, das ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen der Klasse A davon nach Ausführungsformen der Erfindung illustriert; während 1B ein Blockdiagramm ist, das das generische vektorfreundliche Befehlsformat und Befehlsvorlagen der Klasse B davon nach Ausführungsformen der Erfindung illustriert. Genauer, ein generisches vektorgerechtes Befehlsformat 100, für das Klasse-A- und Klasse-B-Befehlsvorlagen definiert sind, die beide Befehlsvorlagen 105 ohne Arbeitsspeicherzugriff und Befehlsvorlagen 120 mit Arbeitsspeicherzugriff umfassen. Der Begriff „generisch“ im Kontext des vektorfreundlichen Befehlsformats bezieht sich darauf, dass das Befehlsformat an keinen spezifischen Befehlssatz gebunden ist.
Während Ausführungsformen der Erfindung beschrieben werden, in denen das vektorfreundliche Befehlsformat Folgendes unterstützt: eine Vektoroperandenlänge (oder -größe) von 64 Bytes mit 32-Bit- (4-Byte-) oder 64-Bit- (8-Byte-)Datenelementbreiten (oder -größen) (und deshalb besteht ein 64-Byte-Vektor aus entweder 16 doppelwortgroßen Elementen oder alternativ 8 quadwortgroßen Elementen); eine Vektoroperandenlänge (oder -größe) von 64 Bytes mit 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-)Datenelementbreiten (oder -größen); eine Vektoroperandenlänge (oder -größe) von 32 Bytes mit 32-Bit- (4-Byte-), 64-Bit- (8-Byte-), 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-)Datenelementbreiten (oder -größen); und eine Vektoroperandenlänge (oder -größe) von 16 Bytes mit 32-Bit- (4-Byte-), 64-Bit- (8-Byte-), 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-)Datenelementbreiten (oder -größen); können alternative Ausführungsformen mehr, weniger und/oder unterschiedliche Vektoroperandengrößen (z. B. 256-Byte-Vektoroperanden) mit mehr, weniger oder unterschiedlichen Datenelementbreiten (z. B. 128-Bit-(16-Byte-)Datenelementbreiten) unterstützen.
Die Klasse-A-Befehlsvorlagen in 1A enthalten: 1) in den Befehlsvorlagen ohne Arbeitsspeicherzugriff 105 wird eine Operationsbefehlsvorlage 110 ohne Arbeitsspeicherzugriff vom vollständigen Rundungssteuerungstyp und eine Operationsbefehlsvorlage 115 ohne Arbeitsspeicherzugriff vom Datentransformationstyp gezeigt; und 2) in den Befehlsvorlagen mit Arbeitsspeicherzugriff 120 wird eine zeitliche Arbeitsspeicherzugriffsbefehlsvorlage 125 und eine nicht zeitliche Arbeitsspeicherzugriffsbefehlsvorlage 130 gezeigt. Die Klasse-B-Befehlsvorlagen in 1B enthalten: 1) in den Befehlsvorlagen ohne Arbeitsspeicherzugriff 105 wird eine Operationsbefehlsvorlage 112 ohne Arbeitsspeicherzugriff vom vollständigen Schreibmaskensteuerungs- und teilweisen Rundungssteuerungstyp und eine Operationsbefehlsvorlage 117 ohne Arbeitsspeicherzugriff vom Schreibmaskensteuerungs-vsize-Typ gezeigt; und 2) in den Befehlsvorlagen mit Arbeitsspeicherzugriff 120 wird eine Schreibmaskensteuerungsbefehlsvorlage 127 mit Arbeitsspeicherzugriff gezeigt.
Das generische vektorfreundliche Befehlsformat 100 enthält die unten aufgeführten folgenden Felder in der in den 1A-1B veranschaulichten Reihenfolge.
Formatfeld 140 - Ein spezifischer Wert (ein Befehlsformatidentifikatorwert) in diesem Feld identifiziert das vektorfreundliche Befehlsformat eindeutig und somit Fälle des Auftretens von Befehlen im vektorfreundlichen Befehlsformat in Befehlsströmen. Als solches ist dieses Feld in dem Sinne optional, dass es für einen Befehlssatz, der nur das generische vektorfreundliche Befehlsformat aufweist, nicht erforderlich ist.
Basisoperationsfeld 142 - Sein Inhalt unterscheidet verschiedene Basisoperationen.
Registerindexfeld 144 - Sein Inhalt gibt direkt oder durch Adressgenerierung die Orte der Quell- und Zieloperanden an, egal ob in Registern oder in Arbeitsspeicher. Diese enthalten eine ausreichende Anzahl von Bits, um N Register aus einer PxQ-Registerdatei (z. B. 32x512, 16x128, 32x1024, 64x1024) auszuwählen. Während in einer Ausführungsform N bis zu drei Quellen- und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quellen- und Zielregister unterstützen (z. B. können sie bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel fungiert, können sie bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel fungiert, können sie bis zu zwei Quellen und ein Ziel unterstützen).
Modifikatorfeld 146 - Sein Inhalt unterscheidet Auftreten von Befehlen im generischen Vektorbefehlsformat, die einen Arbeitsspeicherzugriff angeben, von denen, die dies nicht tun; das heißt zwischen Befehlsvorlagen ohne Arbeitsspeicherzugriff 105 und Befehlsvorlagen mit Arbeitsspeicherzugriff 120. Arbeitsspeicherzugriffsoperationen lesen aus der Arbeitsspeicherhierarchie und/oder schreiben in diese (in einigen Fällen unter Angabe der Quell- und/oder Zieladressen unter Verwendung von Werten in Registern), während Operationen ohne Arbeitsspeicherzugriff dies nicht tun (z. B. sind die Quelle und die Ziele Register). Während in einer Ausführungsform dieses Feld auch aus drei verschiedenen Wegen zum Durchführen von Arbeitsspeicheradressenberechnungen auswählt, können alternative Ausführungsformen mehr, weniger oder unterschiedliche Wege zum Durchführen von Arbeitsspeicheradressenberechnungen unterstützen.
Ergänzungsoperationsfeld 150 - Sein Inhalt unterscheidet, welche von einer Vielzahl von unterschiedlichen Operationen zusätzlich zu der Basisoperation durchgeführt werden soll. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 168, ein Alphafeld 152 und ein Betafeld 154 aufgeteilt. Das Ergänzungsoperationsfeld 150 ermöglicht, dass gemeinsame Gruppen von Operationen in einem einzelnen Befehl statt in 2, 3 oder 4 Befehlen durchgeführt werden.
Skalierungsfeld 160 - Sein Inhalt ermöglicht die Skalierung des Inhalts des Indexfelds zur Arbeitsspeicheradressgenerierung (z. B. zur Adressgenerierung, die 2^Skalierung * Index + Basis verwendet).
Offsetfeld 162A - Sein Inhalt wird als Teil der Arbeitsspeicheradressgenerierung verwendet (z. B. zur Adressgenerierung, die 2^Skalierung * Index + Basis + Offset verwendet).
Offsetfaktorfeld 162B (es ist anzumerken, dass die Nebeneinanderstellung des Offsetfelds 162A direkt über dem Offsetfaktor 162B anzeigt, dass das eine oder das andere verwendet wird) - Sein Inhalt wird als Teil der Adressengenerierung verwendet; es gibt einen Offsetfaktor an, der mit der Größe eines Arbeitsspeicherzugriffs (N) zu skalieren ist - wobei N die Anzahl der Bytes im Arbeitsspeicherzugriff ist (z. B. für eine Adressengenerierung, die 2^Skalierung * Index + Basis + skalierter Offset verwendet). Redundante Bits niedriger Ordnung werden ignoriert und deshalb wird der Inhalt des Offsetfaktorfelds mit der Gesamtgröße des Arbeitsspeicheroperanden (N), um den endgültigen Offset zu generieren, der zum Berechnen einer effektiven Adresse zu verwenden ist. Der Wert von N ist durch die Prozessor-Hardware zur Laufzeit auf Basis des Feldes des vollständigen Opcodes 174 (hierin weiter unten beschrieben) und dem Datenmanipulationsfeld 154C bestimmt. Das Offsetfeld 162A und das Offsetfaktorfeld 162B sind in dem Sinn optional, dass sie für die Befehlsvorlagen ohne Arbeitsspeicherzugriff 105 nicht verwendet werden und/oder andere Ausführungsformen nur eines oder keines der beiden implementieren können.
Datenelementbreitenfeld 164 - Sein Inhalt unterscheidet, welche einer Reihe von Datenelementbreiten verwendet werden soll (in einigen Ausführungsformen für alle Befehle; in anderen Ausführungsformen nur für einige der Befehle). Dieses Feld ist in dem Sinne optional, dass es nicht erforderlich ist, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung einiger Aspekt der Opcodes unterstützt werden.
Schreibmaskenfeld 170 - Sein Inhalt steuert für jede Datenelementposition einzeln, ob diese Datenelementposition im Zielvektoroperand das Ergebnis der Basisoperation und der Ergänzungsoperation widerspiegelt. Befehlsvorlagen der Klasse A unterstützen eine Schreimaskenanwendung mit Zusammenführen, während Befehlsvorlagen der Klasse B sowohl eine Schreibmaskenanwendung mit Zusammenführen als auch eine mit Nullsetzen unterstützen. Beim Zusammenführen ermöglichen Vektormasken, dass ein beliebiger Satz von Elementen im Ziel vor Aktualisierungen während der Ausführung einer beliebigen Operation (die durch die Basisoperation und die Zusatzoperation spezifiziert ist) geschützt ist; wobei in einer anderen Ausführungsform der alte Wert jedes Elements des Ziels geschützt wird, wo das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz dazu ermöglichen Vektormasken beim Nullsetzen, dass ein beliebiger Satz von Elementen im Ziel während der Ausführung einer beliebigen Operation (die durch die Basisoperation und die Zusatzoperation spezifiziert ist) auf null gesetzt wird; in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Eine Teilmenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der Operation, die durchgeführt wird, zu steuern (das heißt den Umfang der Elemente, die modifiziert werden, vom ersten bis zum letzten); es ist jedoch nicht notwendig, dass die Elemente, die modifiziert werden, aufeinanderfolgend sind. Deshalb ermöglicht das Schreibmaskenfeld 170 teilweise Vektoroperationen, einschließlich Lade-, Speicher-, arithmetische, logische Vorgänge usw. Während Ausführungsformen der Erfindung beschrieben werden, in denen der Inhalt des Schreibmaskenfelds 170 eines von einer Anzahl von Schreibmaskenregistern auswählt, das die zu verwendende Schreibmaske beinhaltet (und deshalb identifiziert der Inhalt des Schreibmaskenfelds 170 diese durchzuführende Maskierung indirekt), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Schreibmaskenfelds 170 direkt die durchzuführende Maskierung angibt.
Direktfeld 172 - Sein Inhalt ermöglicht die Angabe eines direkten Elements. Dieses Feld ist in dem Sinn optional, dass es in einer Implementierung des generischen vektorfreundlichen Formats nicht vorhanden ist, das keinen Direktoperanden unterstützt, und es in Befehlen nicht vorhanden ist, die keinen Direktoperanden verwenden.
Klassenfeld 168 - Sein Inhalt unterscheidet zwischen unterschiedlichen Klassen von Befehlen. Unter Bezugnahme auf die 1A-B wählen die Inhalte dieser Felder zwischen Klasse-A- und Klasse-B-Befehlen aus. In den 1A-B werden Vierecke mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein bestimmter Wert in einem Feld vorhanden ist (z. B. Klasse A 168A bzw. Klasse B 168B für das Klassenfeld 168 in den 1A-B).
Befehlsvorlagen der Klasse A
Im Falle der Befehlsvorlagen 105 der Klasse A ohne Arbeitsspeicherzugriff wird das Alpha-Feld 152 als ein RS-Feld 152A interpretiert, dessen Inhalt unterscheidet, welche der unterschiedlichen Ergänzungsoperationstypen durchgeführt werden sollen (z. B. Runden 152A.1 und Datentransformation 152A.2 sind jeweils für die Befehlsvorlagen für Operation 110 vom Rundungstyp ohne Arbeitsspeicherzugriff bzw. die Operation 115 vom Datentransformationstyp ohne Arbeitsspeicherzugriff spezifiziert), während das Beta-Feld 154 unterscheidet, welche der Operationen des angegebenen Typs durchzuführen sind. In den Befehlsvorlagen ohne Arbeitsspeicherzugriff 105 sind das Skalierungsfeld 160, das Offsetfeld 162A und das Offsetskalierungsfeld 162B nicht vorhanden.
Befehlsvorlagen ohne Arbeitsspeicherzugriff - Operation vom vollen Rundungssteuertyp
In der Befehlsvorlage für die Operation vom vollen Rundungssteuertyp ohne Arbeitsspeicherzugriff 110 wird das Beta-Feld 154 als Rundungssteuerungsfeld 154A interpretiert, dessen Inhalt(e) statisches Runden bereitstellt bzw. bereitstellen. Während in den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerungsfeld 154A ein Feld zum Unterdrücken aller Gleitkommaausnahmen (SAE) 156 und ein Rundungsoperationssteuerungsfeld 158 enthält, können alternative Ausführungsformen diese beiden Konzepte unterstützen und in das gleiche Feld codieren oder nur das eine oder das andere dieser Konzepte/Felder aufweisen (können z. B. nur das Rundungsoperationssteuerungsfeld 158 aufweisen).
SAE-Feld 156 - Sein Inhalt unterscheidet, ob die Ausnahmeereignismeldung zu deaktivieren ist oder nicht; wenn der Inhalt des SAE-Felds 156 anzeigt, das die Unterdrückung aktiviert ist, meldet ein bestimmter Befehl keine Art von Gleitkommaausnahmeflag und startet keinen Gleitkommaausnahmehandler.
Rundungsoperationssteuerungsfeld 158 - Sein Inhalt unterscheidet, welche aus einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Runden Richtung null und Runden zur nächstgelegenen Rundungszahl). Somit ermöglicht der Rundenoperationssteuerbereich 158 das Ändern des Rundungsmodus für jeden Befehl einzeln. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Angeben von Rundungsmodi enthält, ist der Inhalt des Rundungsoperationssteuerungsfelds 150 diesem Registerwert übergeordnet.
Befehlsvorlagen ohne Arbeitsspeicherzugriff - Operationen vom Datentransformationstyp
In der Befehlsvorlage ohne Arbeitsspeicherzugriff mit Operation 115 des Typs Datentransformation wird das Beta-Feld 154 als ein Datentransformationsfeld 154B interpretiert, dessen Inhalt unterscheidet, welche von einer Reihe von Datentransformationen durchgeführt werden sollen (z. B. ohne Datentransformation, Swizzeln, Broadcast).
Im Fall einer Befehlsvorlage mit Arbeitsspeicherzugriff 120 der Klasse A wird das Alpha-Feld 152 als ein Entfernungshinweisfeld 152B interpretiert, dessen Inhalt unterscheidet, welcher der Entfernungshinweise zu verwenden ist (in 1A wird zeitlich 152B.1 bzw. nicht zeitlich 152B.2 für die zeitliche ArbeitsspeicherzugriffsBefehlsvorlage 125 bzw. die nicht zeitliche ArbeitsspeicherzugriffsBefehlsvorlage 130 spezifiziert), während das Beta-Feld 154 als ein Datenmanipulationsfeld 154C interpretiert wird, dessen Inhalt unterscheidet, welche einer Anzahl von Datenmanipulationsoperationen (auch als Stammfunktionen bekannt) durchzuführen ist (z. B. keine Manipulation; Broadcast; Aufwärtskonversion einer Quelle; und Abwärtskonversion eines Ziels). Die Befehlsvorlagen mit Arbeitsspeicherzugriff 120 enthalten das Skalierungsfeld 160 und optional das Offsetfeld 162A oder das Offsetskalierungsfeld 162B.
Vektorspeicherbefehle führen ein Laden von Vektoren aus dem und ein Speichern von Vektoren in den Arbeitsspeicher mit Konvertierungsunterstützung durch. Wie bei normalen Vektorbefehlen übertragen Vektorspeicherbefehle Daten auf datenelementweise Art aus dem/in den Arbeitsspeicher, wobei die Elemente, die tatsächlich übertragen werden, durch den Inhalt der Vektormaske, die als die Schreibmaske ausgewählt ist, vorgegeben werden.
Befehlsvorlagen mit Arbeitsspeicherzugriff - zeitlich
Zeitliche Daten sind Daten, die wahrscheinlich bald genug wiederverwendet werden, um von einem Zwischenspeichern zu profitieren. Dies ist jedoch nur ein Hinweis, und unterschiedliche Prozessoren können ihn auf unterschiedliche Weise implementieren, einschließlich des vollständigen Ignorierens des Hinweises.
Befehlsvorlagen mit Arbeitsspeicherzugriff - nicht zeitlich
Nicht zeitliche Daten sind Daten, bei denen es unwahrscheinlich ist, dass sie bald genug wiederverwendet werden, um von einem Zwischenspeichern im Level-1-Zwischenspeicher zu profitieren, und denen Priorität für eine Entfernung gegeben werden sollte. Dies ist jedoch nur ein Hinweis, und unterschiedliche Prozessoren können ihn auf unterschiedliche Weise implementieren, einschließlich des vollständigen Ignorierens des Hinweises.
Befehlsvorlagen der Klasse B
Im Fall der Befehlsvorlagen der Klasse B wird das Alpha-Feld 152 als ein Feld der Schreibmaskensteuerung (Z) 152C interpretiert, dessen Inhalt unterscheidet, ob das durch das Schreibmaskenfeld 170 gesteuerte Schreibmaskieren ein Zusammenführen oder ein Nullsetzen sein soll.
Im Fall der Befehlsvorlagen 105 ohne Arbeitsspeicherzugriff der Klasse B wird ein Teil des Beta-Feldes 154 als ein RL-Feld 157A interpretiert, dessen Inhalt unterscheidet, welcher der unterschiedlichen Ergänzungsoperationstypen durchgeführt werden soll (z. B. sind Runden 157A.1 und Vektorlänge (VSIZE) 157A.2 für die Befehlsvorlage ohne Arbeitsspeicherzugriff, mit Schreibmaskensteuerung, mit Operation des Typs teilweise Rundungssteuerung 112 bzw. die Befehlsvorlage ohne Arbeitsspeicherzugriff, mit Schreibmaskensteuerung, mit Operation des Typs VSIZE 117 spezifiziert), während der Rest des Beta-Feldes 154 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. In den Befehlsvorlagen ohne Arbeitsspeicherzugriff 105 sind das Skalierungsfeld 160, das Offsetfeld 162A und das Offsetskalierungsfeld 162B nicht vorhanden.
In der Operationsbefehlsvorlage vom vollständigen Rundungssteuerungstyp ohne Arbeitsspeicherzugriff 110 wird der Rest des Beta-Felds 154 als ein Rundungsoperationsfeld 159A interpretiert und die Ausnahmeereignismeldung ist deaktiviert (ein bestimmter Befehl meldet keine Art von Gleitkommaausnahmeflag und startet keinen Gleitkommaausnahmehandler).
Rundungsoperationssteuerungsfeld 159A - Genau wie beim Rundungsoperationssteuerungsfeld 158 unterscheidet dessen Inhalt, welche einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden Richtung null und Runden zur nächstgelegenen Rundungszahl). Deshalb ermöglicht das Rundungsoperationssteuerungsfeld 159A das Ändern des Rundungsmodus pro Befehl. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Angeben von Rundungsmodi enthält, ist der Inhalt des Rundungsoperationssteuerungsfelds 150 diesem Registerwert übergeordnet.
In der Operationsbefehlsvorlage 117 ohne Arbeitsspeicherzugriff vom Schreibmaskensteuerungs-VSIZE-Typ wird der Rest des Beta-Felds 154 als ein Vektorlängenfeld 159B interpretiert, dessen Inhalt unterscheidet, an welcher einer Anzahl von Datenvektorlängen die Operation durchzuführen ist (z. B. 128, 256 oder 512 Bytes).
Im Fall einer Befehlsvorlage 120 mit Arbeitsspeicherzugriff der Klasse B wird ein Teil des Beta-Felds 154 als ein Broadcastfeld 157B interpretiert, dessen Inhalt unterscheidet, ob die Datenmanipulation vom Broadcasttyp durchzuführen ist oder nicht, während der Rest des Beta-Felds 154 als das Vektorlängenfeld 159B interpretiert wird. Die Befehlsvorlagen mit Arbeitsspeicherzugriff 120 enthalten das Skalierungsfeld 160 und optional das Offsetfeld 162A oder das Offsetskalierungsfeld 162B.
In Bezug auf das generische vektorfreundliche Befehlsformat 100 ist ein Feld des vollständigen Opcodes 174 einschließlich des Formatfeldes 140, des Basisoperationsfeldes 142 und des Datenelementbreitenfeldes 164 gezeigt. Während eine Ausführungsform gezeigt ist, in der das vollständige Opcode-Feld 174 alle dieser Felder enthält, enthält das vollständige Opcode-Feld 174 weniger als alle dieser Felder in Ausführungsformen, die nicht alle davon unterstützen. Das Feld des vollständigen Opcodes 174 stellt den Operationscode (Opcode) bereit.
Das Ergänzungsoperationsfeld 150, das Datenelementbreitenfeld 164 und das Schreibmaskenfeld 170 ermöglichen, dass diese Merkmale für jeden Befehl einzeln in dem generischen vektorfreundlichen Befehlsformat spezifiziert werden.
Die Kombination aus Schreibmaskenfeld und Datenelementbreitenfeld erzeugt dahingehend typenbehaftete Befehle, dass sie ermöglichen, die Maske auf Grundlage unterschiedlicher Datenelementbreiten anzuwenden.
Die diversen Befehlsvorlagen, die in Klasse A und Klasse B zu finden sind, sind in unterschiedlichen Situationen vorteilhaft. In einigen Ausführungsformen der Erfindung können unterschiedliche Prozessoren oder unterschiedliche Kerne in einem Prozessor nur die Klasse A, nur die Klasse B oder beide Klassen unterstützen. Ein Hochleistungs-Out-of-Order-Universalkern für Universalrechenzwecke kann zum Beispiel nur Klasse B unterstützen, ein Kern, der hauptsächlich für Grafik und/oder wissenschaftliches (Durchsatz-)Rechnen gedacht ist, kann nur Klasse A unterstützen und ein Kern, der für beides gedacht ist, kann beides unterstützen (natürlich liegt ein Kern, der eine Mischung von Vorlagen und Befehlen von beiden Klassen, aber nicht alle Vorlagen und Befehlen von beiden Klassen aufweist, innerhalb des Geltungsbereichs der Erfindung). Außerdem kann ein Einzelprozessor mehrere Kerne enthalten, die alle die gleiche Klasse enthalten oder in denen unterschiedliche Kerne unterschiedliche Klassen unterstützen. Zum Beispiel kann in einem Prozessor mit separaten Grafik- und Universalkernen einer der Grafikkerne, die primär für Grafik und/oder wissenschaftliches Rechnen gedacht sind, nur Klasse A unterstützen, während einer oder mehrere der Universalkerne Universalhochleistungskerne mit Out-of-Order-Ausführung und Registerumbenennung sein können, die für Universalrechenvorgänge gedacht sind, die nur Klasse B unterstützen. Ein anderer Prozessor, der keinen separaten Grafikkern aufweist, kann einen oder mehrere In-Order- oder Out-of-Order-Kerne enthalten, die sowohl Klasse A als auch Klasse B unterstützen. Natürlich können in anderen Ausführungsformen der Erfindung Merkmale von einer Klasse auch in der anderen Klasse implementiert sein. In einer Hochsprache geschriebene Programme werden in eine Vielzahl unterschiedlicher ausführbarer Formen gebracht (z. B. Just-in-Time-kompiliert oder statisch kompiliert), einschließlich: 1) einer Form, die nur Befehle der Klasse(n) aufweisen, die vom Zielprozessor zur Ausführung unterstützt werden; oder 2) einer Form mit alternativen Routinen, die unter Verwendung verschiedener Kombinationen der Befehle aller Klassen geschrieben sind und Ablaufsteuerungscode aufweisen, der die auszuführenden Routinen auf Grundlage der vom Prozessor unterstützten Befehle auswählt, der den Code aktuell ausführt.
VEX-Befehlsformat
Eine VEX-Codierung ermöglicht, dass Befehle mehr als zwei Operanden aufweisen, und ermöglicht, dass SIMD-Vektorregister länger als 28 Bits sind. Die Verwendung eines VEX-Präfixes stellt eine Drei-Operanden-Syntax (oder mehr) bereit. Zum Beispiel führten vorherige Zwei-Operanden-Befehle Operationen wie zum Beispiel A = A + B durch, wobei ein Quelloperand überschrieben wird. Die Verwendung eines VEX-Präfixes ermöglicht Operanden, zerstörungsfreie Operationen durchzuführen, wie zum Beispiel A = B + C.
2A stellt ein beispielhaftes AVX-Befehlsformat dar, das ein VEX-Präfix 202, ein reales Opcode-Feld 230, ein Mod-R/M-Byte 240, ein SIB-Byte 250, ein Offsetfeld 262 und ein IMM8 272 enthält. 2B veranschaulicht, welche Felder aus der 2A ein volles Opcode-Feld 274 und ein Basisoperationsfeld 241 bilden. Die 2C stellt dar, welche Felder aus der 2A ein Registerindexfeld 244 bilden.
Das VEX-Präfix (Bytes 0-2) 202 ist in einer Drei-Byte-Form codiert. Das erste Byte ist das Formatfeld 290 (VEX-Byte 0, Bits [7:0]), das einen expliziten C4-Bytewert (den eindeutigen Wert, der zum Unterscheiden des C4-Befehlsformats verwendet wird) beinhaltet. Das zweite bis dritte Byte (VEX-Bytes 1-2) enthält eine Reihe von Bitfeldern, die eine spezifische Fähigkeit bereitstellen. Insbesondere besteht REX-Feld 205 (VEX-Byte 1, Bits [7-5]) aus einem VEX.R-Bitfeld (VEX-Byte 1, Bit [7] - R), einem VEX.X-Bitfeld (VEX-Byte 1, Bit [6] - X) und einem VEX.B-Bitfeld (VEX-Byte 1, Bit[5] - B). Andere Felder der Befehle codieren die niedrigeren drei Bits der Registerindizes, wie im Fachgebiet bekannt ist (rrr, xxx und bbb), sodass Rrrr, Xxxx und Bbbb durch Addieren von VEX.R, VEX.X und VEX.B gebildet werden können. Opcode-Abbildungsfeld 215 (VEX-Byte 1, Bits [4:0] - mmmmm) enthält Inhalt zum Codieren eines implizierten führenden Opcode-Bytes. W-Feld 264 (VEX-Byte 2, Bit [7] - W) - ist durch die Notation VEX.W dargestellt und stellt unterschiedliche Funktionen in Abhängigkeit vom Befehl bereit. Die Rolle von VEX.vvvv 220 (VEX-Byte 2, Bits [6:3]-vvvv) kann das Folgende beinhalten: 1) VEX.vvvv codiert den ersten Quellenregisteroperanden, der in invertierter (1er-Komplement-)Form angegeben ist und für Anweisungen mit 2 oder mehr Quellenoperationen gültig ist; 2) VEX.vvvv codiert den Zielregisteroperanden, der in Form eines 1er-Komplements für bestimmte Vektorverschiebungen angegeben ist; oder 3) VEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b beinhalten. Wenn Größenfeld VEX.L 268 (VEX-Byte 2, Bit [2]-L) = 0, zeigt es einen 28-Bit-Vektor an; wenn VEX.L = 1, zeigt es einen 256-Bit-Vektor an. Präfixcodierfeld 225 (VEX-Byte 2, Bits [1:0]-pp) stellt zusätzliche Bits für das Basisoperationsfeld 241 bereit.
Das reale Opcode-Feld 230 (Byte 3) ist auch als das Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld angegeben.
MOD-R/M-Feld 240 (Byte 4) enthält MOD-Feld 242 (Bits [7-6]), Reg-Feld 244 (Bits [5-3]) und R/M-Feld 246 (Bits [2-0]). Die Rolle des Reg-Felds 244 kann Folgendes enthalten: Codieren entweder des Zielregisteroperanden oder eines Quellenregisteroperanden (rrr von Rrrr) oder Behandlung als eine Opcode-Erweiterung und keine Verwendung zum Codieren irgendeines Befehlsoperanden. Die Rolle des R/M-Felds 246 kann Folgendes enthalten: Codieren des Befehlsoperanden, der eine Arbeitsspeicheradresse referenziert, oder Codieren von entweder dem Zielregisteroperanden oder einem Quellenregisteroperanden.
Skalierung, Index, Basis (SIB) - der Inhalt des Skalierungsfelds 250 (Byte 5) enthält SS252 (Bits [7-6]), was zur Arbeitsspeicheradressgenerierung verwendet wird. Auf den Inhalt von SIB.xxx 254 (Bits [5-3]) und SIB.bbb 256 (Bits [2-0]) wurde bereits hinsichtlich der Registerindizes Xxxx und Bbbb Bezug genommen.
Das Verschiebungsfeld 262 und das Direktfeld (IMM8) 272 enthalten Daten.
Beispielhafte Registerarchitektur
3 ist ein Blockdiagramm einer Registerarchitektur 300 nach einer Ausführungsform der Erfindung. In der illustrierten Ausführungsform gibt es 32 Vektorregister 310, die 512 Bits breit sind; auf diese Register wird mit zmm0 bis zmm31 verwiesen. Die niederwertigen 256 Bits der unteren 6 zmm-Register sind auf den Registern ymmO-15 überlagert. Die niederwertigen 128 Bits auf den unteren 6 zmm-Registern (die niederwertigen 128 Bits des ymm-Registers) sind auf den Registern xmm0-15 überlagert.
Universalregister 325 - In der veranschaulichten Ausführungsform gibt es sechzehn 64-Bit-Universalregister, die zusammen mit den vorhandenen x86-Adressierungsmodi zum Adressieren von Arbeitsspeicheroperanden verwendet werden. Auf diese Register wird mit den Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 Bezug genommen.
Skalare Gleitkomma-Stapelregisterdatei (x87-Stapel) 345, auf der der MMX-gepackten ganzzahligen flachen Registerdatei 350 ein Alias zugewiesen ist - In der veranschaulichten Ausführungsform ist der x87-Stapel ein Stapel mit acht Elementen, der verwendet wird, um unter Verwendung der x87-Befehlssatzerweiterung skalare Gleitkommaoperationen an 32/64/80-Bit-Gleitkommadaten durchzuführen; während die MMX-Register verwendet werden, um Operationen an 64-Bit-gepackten ganzzahligen Daten durchzuführen, sowie um Operanden für einige Operationen zu halten, die zwischen den MMX- und XMM-Registern durchgeführt werden.
Alternative Ausführungsformen der Erfindung können breitere oder schmälere Register verwenden. Zusätzlich können alternative Ausführungsformen der Erfindung mehr, weniger oder unterschiedliche Registerdateien und Register verwenden.
Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen
Prozessorkerne können auf verschiedene Arten, für verschiedene Zwecke und in verschiedenen Prozessoren implementiert werden. Zum Beispiel können Implementierungen solcher Kerne Folgendes beinhalten: 1) einen Universal-In-Order-Kern, der für allgemeine Rechenzwecke gedacht ist; 2) einen Hochleistungs-Universal-Out-of-Order-Kern, der für allgemeine Rechenzwecke gedacht ist; 3) einen Kern für Sonderzwecke, der primär für Grafik- und/oder wissenschaftliches Rechnen (Durchsatzrechnen) gedacht ist. Implementierungen von verschiedenen Prozessoren können Folgendes enthalten: 1) eine CPU, die einen oder mehrere Universal-In-Order-Kerne, die für allgemeine Rechenzwecke gedacht sind, und/oder einen oder mehrere Universal-Out-of-Order-Kerne enthält, die für allgemeine Rechenzwecke gedacht sind; und 2) einen Coprozessor, der einen oder mehrere Kerne für Sonderzwecke enthält, die primär für Grafik und/oder Wissenschaft (Durchsatz) gedacht sind. Derartige unterschiedliche Prozessoren führen zu unterschiedlichen Computersystemarchitekturen, die Folgendes enthalten können: 1) den Coprozessor auf einem separaten Chip von der CPU; 2) den Coprozessor auf einem separaten Chip im gleichen Gehäuse wie eine CPU; 3) den Coprozessor auf dem gleichen Chip wie eine CPU (in diesem Fall wird ein solcher Coprozessor manchmal als Logik für Sonderzwecke bezeichnet, wie integrierte Grafik- und/oder wissenschaftliche Logik (Durchsatzlogik), oder als Kerne für Sonderzwecke); und 4) ein Ein-Chip-System, das die beschriebene CPU (manchmal als der Anwendungskern bzw. die Anwendungskerne oder der Anwendungsprozessor bzw. die Anwendungsprozessoren bezeichnet), den oben beschriebenen Coprozessor und zusätzliche Funktionalität auf dem gleichen Chip enthalten kann. Als Nächstes werden beispielhafte Kernarchitekturen beschrieben, gefolgt von Beschreibungen von beispielhaften Prozessoren und Computerarchitekturen. Hierin werden Schaltkreise (Einheiten) ausführlich besprochen, die beispielhafte Kerne, Prozessoren usw. umfassen.
Beispielhafte Kernarchitekturen
4A ist ein Blockdiagramm, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline nach Ausführungsformen der Erfindung illustriert. 4B ist ein Blockdiagramm, das sowohl ein Ausführungsbeispiel für einen In-Order-Architekturkern als auch einen beispielhaften Out-of-Order-Registerumbenennungs-Ausgabe/Ausführungs-Architekturkern, der in einem Prozessor enthalten sein soll, nach Ausführungsformen der Erfindung veranschaulicht. Die Felder mit durchgezogenen Linien in den 4A-B stellen die In-Order-Pipeline und den In-Order-Kern dar, während die optionale Hinzufügung von Feldern mit gestrichelten Linien die/den Out-of-Order-Ausgabe-/Ausführungspipeline bzw. -kern mit Registerumbenennung darstellt. Da der In-Order-Aspekt eine Teilmenge des Out-of-Order-Aspekts ist, wird der Out-of-Order-Aspekt beschrieben.
In 4A enthält eine Prozessor-Pipeline 400 eine Abrufphase 402, eine Längendecodierphase 404, eine Decodierphase 406, eine Zuteilungsphase 408, eine Umbenennungsphase 410, eine Zeitplanungsphase (auch als Versand- oder Ausgabephase bekannt) 412, eine Registerlese-/Speicherlesephase 414, eine Ausführungsphase 416, eine Zurückschreib-/Speicherschreibphase 418, eine Ausnahmebehandlungsphase 422 und eine Festschreibphase 424.
4B zeigt einen Prozessorkern 490, der eine Front-End-Einheit 430 enthält, die an eine Ausführengineeinheit 450 gekoppelt ist, und beide sind an eine Arbeitsspeichereinheit 470 gekoppelt. Der Kern 490 kann ein Reduced-Instruction-Set-Computing(RISC)-Kern, ein Complex-Instruction-Set-Computing(CISC)-Kern, ein Very-Long-Instruction-Word(VLIW)-Kern oder ein Hybrid- oder alternativer Kerntyp sein. Als noch eine weitere Option kann der Kern 490 ein Kern für Sonderzwecke sein, wie zum Beispiel ein Netzwerk- oder Kommunikationskern, eine Komprimierungsengine, ein Coprozessorkern, einen Kern einer Grafikverarbeitungseinheit für allgemeine Rechenzwecke (GPGPU), ein Grafikkern oder Ähnliches.
Die Front-End-Einheit 430 enthält eine Verzweigungsvorhersageeinheit 432, die an eine Befehls-Zwischenspeicher-Einheit 434 gekoppelt ist, die an einen Befehlsübersetzungspuffer (TLB) 436 gekoppelt ist, der an eine Befehlsabrufeinheit 438 gekoppelt ist, der an eine Decodiereinheit 440 gekoppelt ist. Die Decodiereinheit 440 (oder der Decoder) kann Befehle decodieren und als eine Ausgabe eine oder mehrere MikroOperationen, Mikrocode-Eintrittspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale generieren, die von den ursprünglichen Befehlen decodiert oder abgeleitet werden oder die diese auf andere Weise widerspiegeln. Die Decodiereinheit 440 kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Zu Beispielen für geeignete Mechanismen zählen unter anderem Umsetzungstabellen, Hardware-Implementierungen, programmierbare logische Anordnungen (PLAs), Mikrocode-Festwertspeicher (ROMs) usw. ein. In einer Ausführungsform enthält der Kern 490 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für bestimmte Makrobefehle speichert (z. B. in der Decodiereinheit 440 oder auf andere Weise in der Front-End-Einheit 430). Die Decodiereinheit 440 ist in der Ausführungsengineeinheit 450 an eine Umbenennungs-/Zuteilungseinheit 452 gekoppelt.
Die Ausführungsengineeinheit 450 enthält die an eine Stilllegungseinheit 454 gekoppelte Umbenennungs-/Zuteilungseinheit 452 und einen Satz von einer oder mehreren Planungseinheiten 456. Die Planungseinheit(en) 456 stellt bzw. stellen irgendeine Anzahl von unterschiedlichen Planern dar, einschließlich Reservierungsstationen, zentrales Befehlsfenster usw. Die Planungseinheit(en) 456 ist bzw. sind an die Einheit(en) der physischen Registerdatei(en) 458 gekoppelt. Jede der physischen Registerdateieinheit(en) 458 repräsentiert eine oder mehrere physische Registerdateien, von denen verschiedene einen oder mehrere verschiedene Datentypen speichern, wie skalare ganze Zahl, skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma, Status (z. B. einen Befehlszeiger, der die Adresse des nächsten auszuführenden Befehls ist) usw. In einer Ausführungsform umfasst die Einheit der physischen Registerdatei(en) 458 eine Vektorregistereinheit und eine skalare Registereinheit. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Universalregister bereitstellen. Die physische(n) Registerdateieinheit(en) 458 wird bzw. werden von der Stilllegungseinheit 454 überlappt, um verschiedene Arten zu veranschaulichen, auf die eine Registerumbenennung und Out-of-Order-Ausführung implementiert werden können (z. B. unter Verwendung eines Umordnungspuffers bzw. von Umordnungspuffern und (einer) Stilllegungsregisterdatei(en); unter Verwendung einer bzw. von zukünftigen Datei(en), eines Verlaufspuffers bzw. von Verlaufspuffern und einer Stilllegungsregisterdatei bzw. von Stilllegungsregisterdateien; unter Verwendung einer Registerabbildung und eines Pools von Registern; usw.). Die Stilllegungseinheit 454 und die physische(n) Registerdateieinheit(en) 458 sind an das bzw. die Ausführungscluster 460 gekoppelt. Das bzw. die Ausführungscluster 460 enthält bzw. enthalten einen Satz einer oder mehrerer Ausführungseinheiten 462 und einen Satz von einem oder mehreren Speicherzugriffseinheiten 464. Die Ausführungseinheiten 462 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und an verschiedenen Datentypen (z. B. skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma) durchführen. Während einige Ausführungsformen eine Reihe von Ausführungseinheiten enthalten können, die für spezifische Funktionen oder Funktionssätze vorgesehen sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten enthalten, die jeweils alle Funktionen durchführen. Die Planungseinheit(en) 456, physische(n) Registerdateieinheit(en) 458 und Ausführungscluster 460 sind als möglicherweise mehrzahlig gezeigt, da bestimmte Ausführungsformen separate Pipelines für bestimmte Arten von Daten/Operationen erstellen (z. B. eine Pipeline für skalare ganze Zahlen, eine Pipeline für skalares Gleitkomma/gepackte ganze Zahlen/gepacktes Gleitkomma/vektorielle ganze Zahlen/vektorielles Gleitkomma und/oder eine Arbeitsspeicherzugriffs-Pipeline, die jeweils ihre eigene Planungseinheit, physische Registerdateieinheit und/oder ihr eigenes Ausführungscluster aufweisen - und im Fall einer separaten Arbeitsspeicherzugriffs-Pipeline sind bestimmte Ausführungsformen implementiert, in denen nur das Ausführungscluster dieser Pipeline die Arbeitsspeicherzugriffseinheit(en) 464 aufweist). Es sollte auch klar sein, dass, wo separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines Out-of-Order-Ausgabe-/Ausführungs- und der Rest In-Order-Pipelines sein können.
Der Satz von Speicherzugriffseinheiten 464 ist an die Speichereinheit 470 gekoppelt, die eine Daten-TLB-Einheit 472 enthält, die an eine Datenzwischenspeichereinheit 474 gekoppelt ist, die an eine Level-2(L2)-Zwischenspeichereinheit 476 gekoppelt ist. In einer beispielhaften Ausführungsform können die Arbeitsspeicherzugriffseinheiten 464 eine Ladeeinheit, eine Adressspeichereinheit und eine Datenspeichereinheit enthalten, die alle an die Daten-TLB-Einheit 472 in der Arbeitsspeichereinheit 470 gekoppelt sind. Die Befehlszwischenspeichereinheit 434 ist ferner an eine Level-2(L2)-Zwischenspeichereinheit 476 in der Arbeitsspeichereinheit 470 gekoppelt. Die L2-Zwischenspeichereinheit 476 ist an eine oder mehrere andere Zwischenspeicher-Levels und letztendlich an einen Hauptspeicher gekoppelt.
Beispielsweise kann die beispielhafte Kernarchitektur für Registerumbenennung, Out-of-Order-Ausgabe/-Ausführung die Pipeline 400 wie folgt implementieren: 1) Der Befehlsabruf 438 führt den Abruf und die Längendecodierphasen 402 und 404 durch; 2) die Decodiereinheit 440 führt die Decodierphase 406 durch; 3) die Umbenennungs-/Zuteilungseinheit 452 führt die Zuteilungsphase 408 und die Umbenennungsphase 410 durch; 4) die Zeitplangebereinheit(en) 456 führt bzw. führen die Zeitplanungsphase 412 durch; 5) die physische(n) Registerdateieinheit(en) 458 und die Arbeitsspeichereinheit 470 führen die Registerlese-/Speicherlesephase 414 durch; das Ausführungscluster 460 führt die Ausführungsphase 416 durch; 6) die Arbeitsspeichereinheit 470 und die physische(n) Registerdateieinheit(en) 458 führen die Zurückschreib-/Speicherschreibphase 418 durch; 7) verschiedene Einheiten können an der Ausnahmebehandlungsphase 422 beteiligt sein; und 8) die Stilllegungseinheit 454 und die physische(n) Registerdateieinheit(en) 458 führen die Festschreibphase 424 durch.
Der Kern 490 kann eine oder mehrere Befehlssätze unterstützen (z. B. den x86-Befehlssatz (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden); den MIPS-Befehlssatz von MIPS Technologies in Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings in Sunnyvale, CA), die die hierin beschriebene(n) Befehl(en) enthalten. In einer Ausführungsform enthält der Kern 490 Logik, um eine gepackte Datenbefehlssatzerweiterung (z. B. AVX1, AVX2) zu unterstützen, wodurch erlaubt wird, dass die von vielen Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten durchgeführt werden.
Es versteht sich, dass der Kern Multithreading (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen kann und dies auf vielfältige Weisen vornehmen kann, was Zeitscheiben-Multithreading, simultanes Multithreading (wobei ein einzelner physischer Kern einen logischen Kern für jeden der Threads bereitstellt, welche der physische Kern simultan im Multithreading behandelt) oder eine Kombination davon (z. B. Zeitscheibenabruf und -Decodierung und simultanes Multithreading danach, wie etwa bei der Hyperthreading-Technologie von Intel®) umfasst.
Während Registerumbenennen im Kontext einer Out-of-Order-Ausführung beschrieben wird, sollte klar sein, dass das Registerumbenennen in einer In-Order-Architektur verwendet werden kann. Während die illustrierte Ausführungsform des Prozessors auch separate Befehls- und Datenzwischenspeichereinheiten 434/474 und eine gemeinsam genutzte L2-Zwischenspeichereinheit 476 enthält, können alternative Ausführungsformen einen einzigen internen Zwischenspeicher für sowohl Befehle als auch Daten aufweisen, wie zum Beispiel einen internen Level-1(L1)-Zwischenspeicher oder mehrere Levels von internem Zwischenspeicher. In einigen Ausführungsformen kann das System eine Kombination von einem internen Zwischenspeicher und einem externen Zwischenspeicher, der sich außerhalb des Kerns und/oder des Prozessors befindet, enthalten. Alternativ kann der gesamte Zwischenspeicher extern zum Kern und/oder zum Prozessor sein.
Spezifische beispielhafte In-Order-Kernarchitektur
5A-B illustrieren ein Blockdiagramm einer spezifischeren beispielhaften In-Order-Kernarchitektur, wobei der Kern einer von mehreren logischen Blöcken (die andere Kerne des gleichen Typs und/oder anderer Typen enthalten) in einem Chip wäre. Die logischen Blöcke kommunizieren über ein Verbindungsnetzwerk hoher Bandbreite (z. B. ein Ringnetzwerk) mit einiger Logik mit festen Funktionen, Arbeitsspeicher-E/A-Schnittstellen und anderer notwendiger E/A-Logik, abhängig von der Anwendung.
5A ist ein Blockschaltbild eines Einzelprozessorkerns zusammen mit seiner Verbindung zum rohchipinternen Zwischenverbindungsnetzwerk 502 und seinem lokalen Teilsatz des Level 2- (L2-) Zwischenspeicher 504, nach Ausführungsformen der Erfindung. In einer Ausführungsform unterstützt ein Befehlsdecoder 500 den x86-Befehlssatz mit einer Erweiterung für gepackte Datenbefehlssätze. Ein L1-Zwischenspeicher 506 ermöglicht Zugriffe mit geringer Latenz auf Zwischenspeicher in den Skalar- und Vektoreinheiten. Obwohl in einer Ausführungsform (um den Entwurf zu vereinfachen) eine skalare Einheit 508 und eine Vektoreinheit 510 separate Registersätze verwenden (skalares Register 512 bzw. Vektorregister 514) und zwischen ihnen übertragene Daten in Arbeitsspeicher geschrieben und dann von einem Level-1(L1)-Zwischenspeicher 506 wieder eingelesen werden, können alternative Ausführungsformen der Erfindung einen anderen Ansatz verwenden (z. B. einen einzelnen Registersatz verwenden oder einen Kommunikationspfad enthalten, der gestattet, dass Daten zwischen den beiden Registerdateien übertragen werden, ohne dass sie geschrieben und zurückgelesen werden).
Der lokale Teilsatz des L2-Zwischenspeichers 504 ist Teil eines globalen L2-Zwischenspeichers, der in separate lokale Teilsätze, einer je Prozessorkern, geteilt ist. Jeder Prozessorkern weist einen direkten Zugriffspfad zu seinem eigenen lokalen Teilsatz des L2-Zwischenspeichers 504 auf. Von einem Prozessorkern gelesene Daten werden in seinem L2-Zwischenspeicher-Teilsatz 504 gespeichert und auf sie kann schnell zugegriffen werden, parallel zu anderen Prozessorkernen, die auf ihre eigenen lokalen L2-Zwischenspeicher-Teilsätze zugreifen. Von einem Prozessorkern geschriebene Daten werden in seinem eigenen L2-Zwischenspeicher-Teilsatz 504 gespeichert und aus anderen Teilsätzen wenn nötig geleert. Das Ringnetzwerk stellt Kohärenz für gemeinsam genutzte Daten sicher. Das Ringnetzwerk ist bidirektional, um Agenten wie Prozessorkernen, L2-Zwischenspeichern und anderen Logikblöcken zu erlauben, miteinander innerhalb des Chips zu kommunizieren. Jeder Ringdatenpfad ist bei manchen Ausführungsformen je Richtung 1024 Bit breit.
5B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 5A nach Ausführungsformen der Erfindung. 5B enthält einen L1-Daten-Zwischenspeicher 506A als Teil des L1-Zwischenspeichers 504 sowie weitere Details hinsichtlich der Vektoreinheit 510 und der Vektorregister 514. Insbesondere ist die Vektoreinheit 510 eine 6-breite Vektorverarbeitungseinheit (VPU) (siehe die 16-breite ALU 528), die einen oder mehrere Ganzzahlbefehle, Gleitkommabefehle mit einfacher Genauigkeit und Gleitkommabefehle mit doppelter Genauigkeit ausführt. Die VPU unterstützt ein Swizzeln der Registereingänge mit Swizzleeinheit 520, numerische Umwandlung mit numerischen Umwandlungseinheiten 522A-B und Replizierung mit Replizierungseinheit 524 am Arbeitsspeichereingang.
Prozessor mit integrierter Arbeitsspeichersteuerung und integrierter Grafik
6 ist ein Blockdiagramm eines Prozessors 600, der nach Ausführungsformen der Erfindung mehr als einen Kern aufweisen kann, eine integrierte Arbeitsspeichersteuerung aufweisen kann und integrierte Grafik aufweisen kann. Die Kästchen mit durchgezogenen Linien in der 6 veranschaulichen einen Prozessor 600 mit einem Einzelkern 602A, einem Systemagenten 610, einem Satz von einer oder mehreren Bussteuerungseinheiten 616, während die optionale Hinzufügung der Kästchen mit gestrichelten Linien einen alternativen Prozessor 600 mit mehreren Kernen 602A-N, einen Satz von einer oder mehreren integrierten Arbeitsspeichersteuerungseinheit(en) 614 in der Systemagenteneinheit 610 und eine Speziallogik 608 veranschaulicht.
Deshalb können verschiedene Implementierungen des Prozessors 600 enthalten: 1) eine CPU, wobei die Logik für Sonderzwecke 608 integrierte Grafik- und/oder wissenschaftliche Logik (Durchsatzlogik) ist (die einen oder mehrere Kerne enthalten kann) und die Kerne 602A-N ein oder mehrere Universalkerne sind (z. B. Universal-In-Order-Kerne, Universal-Out-of-Order-Kerne, eine Kombination der zwei); 2) einen Coprozessor, wobei die Kerne 602A-N eine große Anzahl von Kernen für Sonderzwecke sind, die primär für Grafik und/oder Wissenschaft (Durchsatz) gedacht sind; und 3) einen Coprozessor, wobei die Kerne 602A-N eine große Anzahl von Universal-In-Order-Kernen sind. Deshalb kann der Prozessor 600 ein Universal-Prozessor, Coprozessor oder Prozessor für Sonderzwecke sein, wie zum Beispiel ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine Grafikverarbeitungseinheit für allgemeine Rechenzwecke (GPGPU), ein Many-Integrated-Core(MIC)-Coprozessor mit hohem Durchsatz (der 30 oder mehr Kerne enthält), ein eingebetteter Prozessor oder Ähnliches. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 600 kann ein Teil eines oder mehrerer Substrate sein und/oder kann auf einem oder mehreren Substraten unter Verwendung einer beliebigen Anzahl von Prozesstechniken wie zum Beispiel BiCMOS, CMOS oder NMOS implementiert sein.
Die Arbeitsspeicherhierarchie enthält eine oder mehrere Zwischenspeicherebenen innerhalb der Kerne 604A-N, einen Satz von einer oder mehreren gemeinsam genutzten Zwischenspeichereinheiten 606 und externen Arbeitsspeicher (nicht gezeigt), gekoppelt an den Satz von integrierten Arbeitsspeichersteuerungseinheiten 614. Der Satz der gemeinsam genutzten Zwischenspeichereinheiten 606 kann einen oder mehrere Zwischenspeicher mittlerer Levels enthalten, wie Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Zwischenspeicherlevel, einen Last-Level-Zwischenspeicher (LLC) und/oder Kombinationen davon. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 612 die integrierte Grafiklogik 608, den Satz der gemeinsam genutzten Zwischenspeichereinheiten 606 und die Systemagenteneinheit 610/den bzw. die integrierten Speichercontrollereinheit(en) 614 verbindet, können alternative Ausführungsformen eine beliebige Anzahl von gut bekannten Techniken zum Verbinden solcher Einheiten verwenden. In einer Ausführungsform wird Kohärenz zwischen einem oder mehreren Zwischenspeichereinheiten 606 und den Kernen 602-A-N beibehalten.
In manchen Ausführungsformen sind einer oder mehrere der Kerne 602A-N multithreadingfähig. Der Systemagent 610 enthält diejenigen Komponenten, die Kerne 602A-N koordinieren und betreiben. Die Systemagenteneinheit 610 kann beispielsweise eine Leistungssteuerungseinheit (PCU, Power Control Unit) und eine Anzeigeeinheit umfassen. Die PCU kann Logik und Komponenten, die zum Regeln des Leistungszustands der Kerne 602A-N und der integrierten Grafiklogik 608 benötigt werden, sein oder umfassen. Die Anzeigeeinheit dient zum Ansteuern einer oder mehrerer extern verbundener Anzeigen.
Die Kerne 602A-N können in Bezug auf einen Architekturbefehlssatz homogen oder heterogen sein; das heißt, zwei oder mehr der Kerne 602A-N können fähig sein, den gleichen Befehlssatz auszuführen, während andere fähig sein können, nur einen Teilsatz dieses Befehlssatzes oder einen anderen Befehlssatz auszuführen.
Beispielhafte Computerarchitekturen
7-10 sind Blockdiagramme von beispielhaften Computerarchitekturen. Andere Systemdesigns und -konfigurationen, die in der Technik für Laptops, Desktops, tragbare PCs, Organizer, Entwicklungs-Workstations, Server, Netzwerkeinrichtungen, Netzwerkhubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Grafikeinrichtungen, Videospieleinrichtungen, Set-Top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Mediaplayer, tragbare Geräte und verschiedene andere Elektronikgeräte bekannt sind, sind ebenfalls geeignet. Im Allgemeinen ist eine enorm große Vielfalt von Systemen oder Elektronikeinrichtungen geeignet, die einen Prozessor und/oder eine andere Ausführungslogik, wie hierin offenbart, einbinden können.
Nun Bezug nehmend auf 7 ist ein Blockdiagramm eines Systeme 700 nach einer Ausführungsform der vorliegenden Erfindung gezeigt. Das System 700 kann einen oder mehrere Prozessoren 710, 715 enthalten, die mit einem Steuerungshub 720 gekoppelt sind. In einer Ausführungsform enthält der Steuerungshub 720 einen Grafikspeicher-Steuerungshub (GMCH) 790 und einen Eingabe-/Ausgabe-Hub (IOH) 750 (die auf separaten Chips sein können); der GMCH 790 enthält Arbeitsspeicher- und Grafiksteuerungen, an die Arbeitsspeicher 740 und ein Coprozessor 745 gekoppelt sind; der IOH 750 koppelt Eingabe-/Ausgabe(E/A)-Einrichtungen 760 an den GMCH 790. Alternativ sind eine oder beide, die Arbeitsspeicher- und/oder die Grafiksteuerung, in den Prozessor integriert (wie hier beschrieben), der Arbeitsspeicher 740 und der Coprozessor 745 sind direkt mit dem Prozessor 710 gekoppelt, und der Steuerungshub 720 befindet sich in einem einzelnen Chip mit dem IOH 750.
Der optionale Charakter der zusätzlichen Prozessoren 715 wird in 7 durch unterbrochene Linien angezeigt. Jeder Prozessor 710, 715 kann einen oder mehrere der hierin beschriebenen Verarbeitungskerne enthalten und kann eine Version des Prozessors 600 sein.
Der Arbeitsspeicher 740 kann zum Beispiel dynamischer Arbeitsspeicher mit wahlfreiem Zugriff (DRAM), Phasenwechselspeicher (PCM) oder eine Kombination der zwei sein. Für wenigstens eine Ausführungsform kommuniziert der Steuerungshub 720 mit dem (den) Prozessor(en) 710, 715 über einen Multi-Drop-Bus, wie etwa einen Frontside-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle oder eine ähnliche Verbindung 795.
In einer Ausführungsform ist der Coprozessor 745 ein Prozessor für Sonderzwecke, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder Ähnliches. In einer Ausführungsform kann der Steuerungshub 720 einen integrierten Grafikbeschleuniger enthalten.
Es kann eine Vielzahl an Unterschieden hinsichtlich eines Spektrums von Leistungsmetriken, einschließlich Architektur-, Mikroarchitektur-, thermischen, Stromverbrauchseigenschaften und dergleichen, zwischen den physischen Ressourcen 710, 7155 geben.
In einer Ausführungsform führt der Prozessor 710 Befehle aus, die Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In den Befehlen können Coprozessorbefehle eingebettet sein. Der Prozessor 710 erkennt, dass diese Coprozessorbefehle von einem Typ sind, der vom angebundenen Coprozessor 745 ausgeführt werden soll. Dementsprechend gibt der Prozessor 710 diese Coprozessorbefehle (oder Steuersignale, die die Coprozessorbefehle repräsentieren) auf einem Coprozessorbus oder einer anderen Verbindung an den Coprozessor 745 aus. Der bzw. die Coprozessor(en) 745 nimmt bzw. nehmen die empfangenen Coprozessorbefehle an und führt bzw. führen diese aus.
Jetzt wird mit Bezug auf die 8 ein Blockdiagramm eines ersten spezifischeren Systems 800 nach einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 8 gezeigt, ist das Multiprozessorsystem 800 ein Punkt-zu-Punkt-Verbindungssystem und enthält einen ersten Prozessor 870 und einen zweiten Prozessor 880, die über eine Punkt-zu-Punkt-Verbindung 850 gekoppelt sind. Jeder der Prozessoren 870 und 880 kann eine Version des Prozessors 600 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 870 und 880 die Prozessoren 710 bzw. 715, während der Coprozessor 838 der Coprozessor 745 ist. In einer anderen Ausführungsform sind die Prozessoren 870 und 880 der Prozessor 710 bzw. der Coprozessor 745.
Die Prozessoren 870 und 880 sind einschließlich integrierter Arbeitsspeichersteuerungseinheiten (IMC) 872 bzw. 882 gezeigt. Der Prozessor 870 enthält auch als Teil seiner Bussteuerungseinheiten Punkt-zu-Punkt(P-P)-Schnittstellen 876 und 878; gleichermaßen enthält der zweite Prozessor 880 P-P-Schnittstellen 886 und 888. Die Prozessoren 870, 880 können Informationen über eine Punkt-zu-Punkt(P-P)-Schnittstelle 850 unter Verwendung der P-P-Schnittstellenschaltkreise 878, 888 austauschen. Wie in 8 gezeigt, koppeln die IMCs 872 und 882 die Prozessoren an jeweilige Arbeitsspeicher, nämlich einen Arbeitsspeicher 832 und einen Arbeitsspeicher 834, die Teile von Hauptspeicher sein können, die lokal an die jeweiligen Prozessoren angebunden sind.
Die Prozessoren 870, 880 können jeweils Informationen mit einem Chipsatz 890 über einzelne P-P-Schnittstellen 852, 854 unter Verwendung von Punkt-zu-Punkt-Schnittstellen-Schaltungen 876, 894, 886, 898 austauschen. Der Chipsatz 890 kann optional Informationen mit dem Coprozessor 838 über eine Hochleistungsschnittstelle 892 austauschen. In einer Ausführungsform ist der Coprozessor 838 ein Prozessor für Sonderzwecke, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder Ähnliches.
Ein gemeinsam genutzter Zwischenspeicher (nicht gezeigt) kann in einem der beiden Prozessoren oder außerhalb beider Prozessoren enthalten sein, jedoch mit den Prozessoren über eine P-P-Verbindung verbunden sein, sodass die lokalen Zwischenspeicher-Informationen von einem der beiden oder beiden Prozessoren im gemeinsam genutzten Zwischenspeicher gespeichert werden kann, wenn ein Prozessor in einen Niedrigenergiemodus versetzt wird.
Der Chipsatz 890 kann über eine Schnittstelle 896 an einen ersten Bus 816 gekoppelt sein. In einer Ausführungsform ist der erste Bus 816 ein Peripheral-Component-Interconnect(PCI)-Bus oder ein Bus wie ein PCI-Express-Bus oder ein anderer E/A-Verbindungsbus sein, obwohl der Geltungsbereich der vorliegenden Erfindung dadurch nicht eingeschränkt ist.
Wie in 8 gezeigt, können verschiedene E/A-Einrichtungen 814 zusammen mit einer Busbrücke 818, die den ersten Bus 816 an einen zweiten Bus 820 koppelt, an den ersten Bus 816 gekoppelt sein. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessoren 815 wie Coprozessoren, Hochdurchsatz-MIC-Prozessoren, GPGPUs, Beschleuniger (wie z. B. Grafikbeschleuniger oder digitale Signalverarbeitungseinheiten (DSP)), feldprogrammierbare Gatearrays oder beliebige andere Prozessoren an den ersten Bus 816 gekoppelt. In einer Ausführungsform kann der zweite Bus 820 ein Low-Pin-Count(LPC)-Bus sein. Verschiedene Einrichtungen können in einer Ausführungsform mit einem zweiten Bus 820 gekoppelt sein, einschließlich zum Beispiel eine Tastatur und/oder eine Maus 822, Kommunikationseinrichtungen 827 und eine Speichereinheit 828, wie zum Beispiel ein Festplattenlaufwerk oder eine andere Massenspeichereinrichtung, die Befehle/Code und Daten 830 enthalten kann. Ferner kann eine Audio-E/A 824 an den zweiten Bus 816 gekoppelt sein. Es sei darauf hingewiesen, dass andere Architekturen möglich sind. Anstelle der Punkt-zu-Punkt-Architektur der 8 kann ein System zum Beispiel eine Multi-Drop-Bus- oder eine andere solche Architektur implementieren.
Jetzt wird mit Bezug auf die 9 ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems 900 nach einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente in den 8 und 9 tragen gleiche Bezugsziffern, und bestimmte Aspekte von 8 wurden aus 9 weggelassen, um ein Verdecken anderer Aspekte von 9 zu vermeiden.
9 illustriert, dass die Prozessoren 870, 880 eine integrierte Speicher- und E/A-Steuerlogik („CL“) 972 bzw. 982 enthalten können. Daher enthält die CL 972, 982 integrierte Arbeitsspeichersteuerungseinheiten und E/A-Steuerlogik. 9 veranschaulicht, dass nicht nur die Arbeitsspeicher 832, 834 mit der CL 872, 882 gekoppelt sind, sondern auch, dass E/A-Geräte 914 ebenfalls mit der Steuerlogik 872, 882 gekoppelt sind. Alt-E/A-Einrichtungen 915 sind an den Chipsatz 890 gekoppelt.
Nun wird mit Bezug auf 10 ein Blockdiagramm eines SoC 1000 nach einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 6 tragen gleiche Referenzziffern. Gestrichelt umrandete Kästchen sind außerdem optionale Merkmale an hochentwickelteren SoCs. In 10 ist eine Verbindungseinheit bzw. sind Verbindungseinheiten 1002 gekoppelt an: einen Anwendungsprozessor 1010, der einen Satz von einem oder mehreren Kernen 102A-N, Zwischenspeichereinheiten 604A-N und (eine) gemeinsam genutzte Zwischenspeichereinheit(en) 606 enthält; eine Systemagenteneinheit 610; (eine) Bussteuerungseinheit(en) 616; (eine) integrierte Arbeitsspeichersteuerungseinheit(en) 614; einen Satz von einem oder mehreren Coprozessoren 1020, die integrierte Grafiklogik, einen Grafikprozessor, einen Audioprozessor und einen Videoprozessor enthalten können; eine statische Arbeitsspeichereinheit mit wahlfreiem Zugriff (SRAM-Einheit) 1030; eine direkte Arbeitsspeicherzugriffs(DMA)-Einheit 1032; und eine Anzeigeeinheit 1040 zum Koppeln an eine oder mehrere externe Anzeigen. In einer Ausführungsform enthält bzw. enthalten der bzw. die Coprozessor(en) 1020 einen Prozessor für Sonderzwecke, wie zum Beispiel einen Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, eine GPGPU, einen Hochdurchsatz-MIC-Prozessor, einen eingebetteten Prozessor oder Ähnliches.
Ausführungsformen der hier offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination derartiger Implementierungsansätze implementiert werden. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert werden, die auf programmierbaren Systemen ausgeführt werden, die mindestens einen Prozess, ein Speichersystem (das flüchtigen und nichtflüchtigen Arbeitsspeicher und/oder Speicherelemente enthält), mindestens eine Eingabeeinrichtung und mindestens eine Ausgabeeinrichtung umfassen.
Programmcode, wie zum Beispiel der in 8 veranschaulichte Code 830, kann auf Eingabebefehle angewendet werden, um die hier beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu generieren. Die Ausgabeinformationen können auf eine oder mehrere Ausgabeeinrichtungen angewandt werden, auf bekannte Weise. Für Zwecke dieser Anmeldung enthält ein Verarbeitungssystem ein beliebiges System, das einen Prozessor aufweist, wie zum Beispiel: einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor.
Der Programmcode kann in einer höheren verfahrens- oder objektorientierten Programmiersprache implementiert werden, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann, falls gewünscht, auch in einer Assembler- oder Maschinensprache implementiert werden. Tatsächlich sind die hierin beschriebenen Mechanismen im Umfang nicht auf eine beliebige bestimmte Programmiersprache beschränkt. Auf jeden Fall kann die Sprache eine compilierte oder interpretierte Sprache sein.
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentative Befehle implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logik innerhalb des Prozessors repräsentiert, die, wenn sie von einer Maschine gelesen wird, bewirkt, dass die Maschine Logik erzeugt, um die hierin beschriebenen Techniken durchzuführen. Solche Repräsentationen, als „IP-Kerne“ bekannt, können auf einem greifbaren, maschinenlesbaren Medium gespeichert und an verschiedene Kunden oder Fertigungsanlagen geliefert werden, um in die Fertigungsmaschinen geladen zu werden, die die Logik oder den Prozessor tatsächlich herstellen.
Solche maschinenlesbaren Speichermedien können nicht-transitorische, greifbare Anordnungen von einer Maschine oder Einrichtung gefertigte oder gebildete Artikel enthalten, die Speichermedien wie Festplatten, irgendeinen anderen Typ von Platte einschließlich Disketten, optische Platten, Compact Disc Read-Only Memories (CD-ROMs), wiederbeschreibbare Compact Discs (CD-RWs) und magneto-optische Platten, Halbleiterbauelemente wie schreibgeschützte Arbeitsspeicher (ROMs), Arbeitsspeicher mit wahlfreiem Zugriff (RAMs) wie dynamische Arbeitsspeicher mit wahlfreiem Zugriff (DRAMs), statische Arbeitsspeicher mit wahlfreiem Zugriff (SRAMs), löschbare programmierbare schreibgeschützte Arbeitsspeicher (EPROMs), Flashspeicher, elektrisch löschbare programmierbare schreibgeschützte Arbeitsspeicher (EEPROMs), Phasenwechselspeicher (PCM), magnetische oder optische Karten oder irgendeinen anderen, zur Speicherung von elektronischen Befehlen geeigneten Medientyp enthalten, sind jedoch nicht darauf beschränkt.
Dementsprechend enthalten Ausführungsformen der Erfindung auch nicht-transitorische, greifbare maschinenlesbare Medien, die Befehle enthalten oder die Designdaten enthalten, wie Hardwarebeschreibungssprache (HDL), die hierin beschriebene Strukturen, Schaltkreise, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
Emulation (einschließlich binärer Übersetzung, Code-Morphing usw.)
In einigen Fällen kann ein Befehlswandler verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. Zum Beispiel kann der Befehlswandler einen Befehl in einen oder mehrere andere Befehle, die vom Kern verarbeitet werden sollen, übersetzen (z. B. unter Verwendung statischer binärer Übersetzung, dynamischer binärer Übersetzung einschließlich dynamischer Kompilierung), morphen, emulieren oder auf andere Weise umwandeln. Der Befehlswandler kann in Software, Hardware, Firmware oder einer Kombination daraus implementiert sein. Der Befehlswandler kann sich auf dem Prozessor, außerhalb des Prozessors oder teilweise auf und teilweise außerhalb des Prozessors befinden.
11 ist ein Blockdiagramm, das die Verwendung eines Softwarebefehlswandlers gegenüberstellt, um binäre Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz nach Ausführungsformen der Erfindung umzuwandeln. Bei der illustrierten Ausführungsform ist der Befehlswandler ein Softwarebefehlswandler, obwohl alternativ dazu der Befehlswandler in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 11 zeigt, dass ein Programm in einer höheren Sprache 1102 unter Verwendung eines ersten Compilers 1104 compiliert werden kann, um ersten Binärcode (z. B. x86) 1106 zu generieren, der nativ von einem Prozessor mit mindestens einem ersten Befehlssatzkern 1116 ausgeführt werden kann. In einigen Ausführungsformen repräsentiert der Prozessor mit mindestens einem ersten Befehlssatzkern 1116 einen beliebigen Prozessor, der im Wesentlichen die gleichen Funktionen wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern durchführen kann, indem er Folgendes kompatibel ausführt oder anderweitig verarbeitet: (1) einen wesentlichen Teil des Befehlssatzes des Intel-x86-Befehlssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software, die auf einem Intel-Prozessor mit mindestens einem x86-Befehlssatzkern laufen sollen, um im Wesentlichen das gleiche Ergebnis wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern zu erreichen. Der erste Compiler 1104 repräsentiert einen Compiler, der betrieben werden kann, um Binärcode des ersten Befehlssatzes 1106 (z. B. Objektcode) zu generieren, der ohne oder mit zusätzlicher Verlinkungsverarbeitung auf dem Prozessor mit mindestens einem ersten Befehlssatzkern 1116 ausgeführt werden kann. Gleichermaßen zeigt 11, dass das Programm in der höheren Sprache 1102 unter Verwendung eines Compilers für einen alternativen Befehlssatz 1108 compiliert werden kann, um Binärcode eines alternativen Befehlssatzes 1110 zu generieren, der nativ von einem Prozessor ohne mindestens einen ersten Befehlssatzkern 1114 ausgeführt werden kann (z. B. einem Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies in Sunnyvale, CA und/oder die den ARM-Befehlssatz von ARM Holdings in Sunnyvale, CA ausführen). Der Befehlswandler 1112 wird verwendet, um den ersten Binärcode 1106 in Code umzuwandeln, der nativ vom Prozessor ohne einen ersten Befehlssatzkern 1114 ausgeführt werden kann. Es ist unwahrscheinlich, dass dieser umgewandelte Code der gleiche wie der Binärcode eines alternativen Befehlssatzes 1110 ist, da ein Befehlswandler, der dazu fähig ist, schwer herzustellen ist; dennoch wird der umgewandelte Code die allgemeine Operation erzielen und aus Befehlen aus dem alternativen Befehlssatz bestehen. Daher repräsentiert der Befehlswandler 1112 Software, Firmware, Hardware oder eine Kombination daraus, die durch Emulation, Simulation oder irgendeinen anderen Prozess, einem Prozessor oder einer anderen elektronischen Einrichtung, die keinen ersten Befehlssatzprozessor oder -kern hat, gestattet, den ersten Binärcode 1106 auszuführen.
ARCHITEKTUR UND VERFAHREN ZUR DATENPARALLELEN EINZELPROGRAMM-MEHRFACHDATEN(SPMD)-AUSFÜHRUNG
Befehlssatzarchitektur(ISA)-Erweiterungen zum Beschleunigen von datenparallelen Arbeitslasten erfordern, dass explizite Wortlängen in der Maschinendarstellung codiert sind. Eine Ausführungsform der Erfindung erweitert eine bestehende ISA (wie z. B. eine x86-ISA) mit einer skalaren Mikrothread-Befehlsverarbeitungsarchitektur. Insbesondere kann eine datenparallele Einzelprogramm-Mehrfachdaten(SPMD)-Mikroarchitektur verwendet werden, um skalierbare Ausführungsdatenpfadgrößen über die Einschränkungen bestehender Befehle hinaus bereitzustellen, wodurch ein größerer Befehlsausführungsdurchsatz mit reduziertem Energieverbrauch erzielt wird.
Aktuelle CPU-Architekturen haben mehrere Generationen von Sub-Wort-Einzelbefehls-Mehrfachdaten(SIMD)-Erweiterungen zum Beschleunigen von datenparallelen Operationen verwendet (z. B. einschließlich SSE2, SSE4, AVX und AVX-512 in der x86-Architektur). Jede aufeinanderfolgende Generation erweitert den Zustand und den Befehlssatz der CPU, was Leistungsprobleme mit Altcode hervorruft und eine Neucompilierung alter Codes erfordert.
Grafikverarbeitungseinheiten (GPUs) haben SPMD-Architekturen unter Verwendung von Hardware-Divergenzstapeln implementiert, um divergente Steuerflussfälle zu handhaben. Der Harwarde-Divergenzstapel wird durch explizite Befehle und/oder Steuercodes manipuliert, wie sie durch den Abschlussagenten für bestehende GPUs statisch implementiert sind.
Eine Ausführungsform der Erfindung enthält eine datenparallele SPMD-Ausführungsengine, die eine skalare Mikrothreadabstraktion verwendet, ähnlich wie beim Programmieren einer Anordnung von skalaren Prozessoren ohne Divergenzbefehle oder Steuercodes in der Architektur. Wie unten besprochen, sind diese Ausführungsformen insbesondere zur Implementierung in einer bestehenden ISA geeignet, die eine vordefinierte Anwendungsbinärsschnittstelle (ABI) enthält.
Unten beschriebene Ausführungsformen sind gegenüber dem Programmierparadigma agnostisch, das zum Codieren eines datenparallelen Kernels verwendet wird, indem die Abstraktion von skalaren Mikrothreads bereitgestellt wird, die auf einer effizienten Hardware vom Vektorstil ausgeführt werden. 12 veranschaulicht vier Beispiele von Programmierparadigmen für eine Sparse-Matrix-Vektor-Multiplikation mit unmittelbarer Post-Dominator-Rekonvergenz, die zwei manuell codierte Beispiele (Ninja-Stil und Pragma-gesteuert) 1201-1202, ein impliziert codiertes Beispiel (vom Compiler entdeckt) 1203 und ein Beispiel mit expliziter Codierung (unter Verwendung von CUDA-OpenCL im Beispiel) enthalten.
Die Ausführungsformen der Erfindung ermöglichen einem Programmierer, datenparallele Software unter Verwendung eines Programmiermodells mit parallelen Threads zu entwickeln. Die resultierenden Threads werden dann effizient auf Ausführungshardware vom Vektor-/SIMD-Stil ausgeführt. Eine größere Anzahl von pro Takt ausgeführten Anweisungen wird mit wesentlich reduzierter Energie pro Operation erreicht, während auch eine gut zugängliche Softwareabstraktion bereitgestellt wird.
13 veranschaulicht ein Beispiel eines datenparallelen Clusters (DPC) 1300, das innerhalb einer Mikroarchitektur eines Prozessors integriert sein kann und/oder als eine Beschleunigungsengine verwendet werden kann, um einen bestimmten Befehls-uops-Satz 1314 auszuführen. In einer Ausführungsform umfasst eine Front-End-Verschaltung 1307 eine Gang-Planungseinheit 1301, um eine zusammengefasste Ausführung von skalaren Mikrothreads innerhalb einer Vielzahl von skalaren Signalleitungen, wie zum Beispiel Signalleitung 1310, zu planen. Die Anzahl von skalaren Signalleitungen im datenparallelen Cluster 1300 kann ohne Auswirkungen auf Software variiert werden. In der veranschaulichten Implementierung sind 16 Signalleitungen gezeigt; es kann jedoch eine beliebige Anzahl von Signalleitungen verwendet werden, abhängig von der Implementierung. In einer unten besprochenen Ausführungsform werden 32 Signalleitungen verwendet.
In einer Ausführungsform plant die Gang-Planungseinheit 1301 den gleichen Befehl in mehreren aktiven Signalleitungen. Eine mikroarchitekturelle Maske 1313 (die z. B. aus einem Maskenregister gelesen wird) deaktiviert diejenigen Signalleitungen, bei denen nicht erforderlich ist, dass sie aktiv sind. In einer Ausführungsform liest die Gang-Planungseinheit 1301 die Maskenwerte, um zu ermitteln, welche Signalleitungen für welche Befehle/uops aktiv zu sein haben.
In einer Ausführungsform speichert eine Befehlsdecodierwarteschlange (IDQ) 1305 innerhalb des Front-Ends 1307 Mikrooperationen (uops) aus decodierten Makrobefehlen, die zur IDQ in Programmreihenfolge hinzugefügt werden (z. B. in einer FIFO-Implementierung). Wie erwähnt kann die IDQ 1305 für mehrere Operations-Gangs partitioniert werden.
Verschiedene Anordnungen zum Koppeln des DPC 1300 an einen Hostprozessor sind unten beschrieben. In einer Implementierung, in der Befehle durch einen Hostprozessor decodiert werden, enthält der DPC 1300 keinen Decodierer, um vor der Ausführung in den Signalleitungen uops zu generieren. Alternativ enthält das Front-End des DPC (z. B. die Gang-Planungseinheit 1301) in einer Implementierung, in der Makrobefehle von einem Hostprozessor weitergeleitet oder direkt durch den DPC aus dem Arbeitsspeicher gelesen werden, einen Decodierer, um Sequenzen von uops zu generieren, die dann vor der Ausführung in der IDQ gespeichert werden.
Jede Signalleitung im datenparallelen Cluster 1300 ist an die IDQ 1305 gekoppelt, von der er parallel auszuführende uops empfängt. In einer Ausführungsform enthält jede Signalleitung eine Ganzzahl-Registerdatei (IRF) 1320 und eine Gleitkomma-Registerdatei (FRF) 1330 zum Speichern von ganzzahligen bzw. Gleitkomma-Operanden. Jede Signalleitung enthält auch eine Tensor-Arithmetik-Logik-Einheit (ALU) 1340, um eine adaptive signalleitungsweise Tensorverarbeitung (wie unten ausführlicher besprochen) durchzuführen, eine skalare ALU pro Mikrothread 1350 und eine unabhängige Adressengenerierungseinheit pro Mikrothread 1360. In einer Ausführungsform bietet die unabhängige AGU 1360 eine Adressengenerierung mit hohem Durchsatz für Codes mit Sammel-/Streu-Arbeitsspeicherzugriffsmustern. Andere unabhängige funktionale Einheiten können auch jeder Signalleitung zugeteilt werden. In einer Ausführungsform ist jede Signalleitung zum Beispiel mit einer unabhängigen Sprungausführungseinheit (JEU) ausgestattet, die den Signalleitungen ermöglicht, zu divergieren und mit der mikroarchitekturellen Maske zu interagieren, um die Illusion unabhängiger Threads zu bieten.
Die veranschaulichte Architektur enthält auch einen gemeinsam genutzten Datenzwischenspeicher 1380, um lokale Kopien von Daten für jede der Signalleitungen zu speichern. In einer Ausführungsform, falls der datenparallele Cluster 1300 in einem Chip oder einem System mit einem Hostprozessor integriert ist, nimmt er am vom Hostprozessor implementierten Zwischenspeicherkohärenzprotokoll teil. Ein Seitenfehlzugriffshandler 1384 führt Seitendurchgangsoperationen durch, um virtuelle Adressen in physische (Systemarbeitsspeicher-)Adressen zu übersetzen und ein Datenübersetzungspuffer (DTLB) speichert die virtuell-zu-physischen Übersetzungen zwischen.
Wie in 14A-C veranschaulicht, kann der datenparallele Cluster 1300 auf vielfältige Weise in ein Computersystem integriert sein. In 14A ist der DPC 1300 mit einem Kern 1701a integral; in 14B befindet sich der DPC 1300 auf dem gleichen Chip und wird von einer Vielzahl von Kernen gemeinsam genutzt; und in 14C befindet sich der DPC 1300 auf einem anderen Chip (aber möglicherweise im gleichen Paket) wie die Kerne 1401a-b.
Nun zuerst in Bezug auf 14A enthalten die veranschaulichten Architekturen einen Kernbereich 1401 und einen gemeinsam genutzten oder „Nicht-Kern-“Bereich 1410. Der gemeinsam genutzte Bereich 1410 enthält Datenstrukturen und Verschaltung, die von allen oder einer Teilmenge der Kerne 1401a-b gemeinsam genutzt werden. In der veranschaulichten Ausführungsform ist die Vielzahl von Kernen 1401a-b simultane Multithreading-Kerne, die fähig sind, mehrere Befehlsströme oder Threads gleichzeitig auszuführen. Obwohl nur zwei Kerne 1401a-b der Einfachheit halber in 14A veranschaulicht sind, ist klar, dass der Kernbereich 1401 eine beliebige Anzahl von Kernen enthalten kann, von denen jeder die gleiche Architektur enthalten kann, wie sie für Kern 1401a gezeigt ist. Eine weitere Ausführungsform enthält heterogene Kerne, wie verschiedene Befehlssatzarchitekturen und/oder unterschiedliche Energie- und Leistungsmerkmale aufweisen können (z. B. Niedrigenergiekerne in Kombination mit Hochenergie-/Hochleistungskernen).
Die verschiedenen, in 14A veranschaulichten Komponenten können auf die gleiche Weise wie entsprechende Komponenten in den 1-11 implementiert sein. Der Kern 1401a kann zum Beispiel die Kachel-Sammel- und Streubefehle unter Verwendung eines der Befehlsformate in 1a-b und 2a-c und/oder unter Verwendung der in 3 veranschaulichten Registerarchitektur ausführen. Darüber hinaus können die Kerne 1401a die Komponenten des in 4b gezeigten Kerns 490 enthalten und können beliebige der anderen hierin beschriebenen Prozessor-/Kernkomponenten enthalten (z. B. 5a-b, 6 usw.).
Jeder der Kerne 1401a-b enthält Befehlspipelinekomponenten zum Durchführen einer gleichzeitigen Ausführung von Befehlsströmen, einschließlich einer Abrufverschaltung 1418, die Befehle aus dem Systemarbeitsspeicher 1460 abruft, oder des L1-Befehlszwischenspeichers 1410 und eines Decodierers 1409, um die Befehle zu decodieren. Ausführungsverschaltung 1408 führt die decodierten Befehle aus, um die zugrunde liegenden Operationen durchzuführen, wie durch die Befehlsoperanden, Opcodes und etwaige Direktwerte angegeben.
In der veranschaulichten Ausführungsform enthält der Decodierer 1409 DPC-Befehlsdecodierverschaltung 1499, um bestimmte Befehle zur Ausführung durch den DPC 1300 (der in dieser Ausführungsform in der Ausführungsverschaltung 1408 integriert ist) in uops zu decodieren. Obwohl sie in 14A als separate Blöcke illustriert sind, können die DPC-Decodierverschaltung 1499 und der DPC 1300 als funktionale Schaltkreise über den gesamten Decodierer 1409 und die Ausführungsverschaltung 1408 verteilt sein.
In einer in 14B veranschaulichten Ausführungsform ist der DPC 1300 eng über eine zwischenspeicherkohärente Zwischenverbindung (in der z. B. der Datenzwischenspeicher 1380 am gleichen Satz von zwischenspeicherkohärenten Arbeitsspeichertransaktionen wie die Kerne teilnimmt) an die Prozessorkerne 1401a-b gekoppelt. Der DPC 1300 ist als ein Peer der Kerne konfiguriert, der am gleichen Satz von zwischenspeicherkohärenten Arbeitsspeichertransaktionen wie die Kerne teilnimmt. In dieser Ausführungsform decodieren die Decodierer 1409 die Befehle, die vom DPC 1300 auszuführen sind, und die resultierenden Mikrooperationen werden zur Ausführung über die Zwischenverbindung 1406 an den DPC 1300 weitergeleitet. In einer anderen Ausführungsform enthält der DPC 1300, 1491 seine eigene Abruf- und Decodierverschaltung, um Befehle aus einem bestimmten Bereich des Systemarbeitsspeichers 1460 abzurufen bzw. zu decodieren. In beiden Implementierungen kann der Matrixbeschleuniger 1491 nach Ausführen der Befehle die Ergebnisse in den Bereich im Systemarbeitsspeicher 1460 speichern, auf den die Kerne 1401a-b zuzugreifen haben.
14C veranschaulicht eine weitere Ausführungsform, in der sich der DPC auf einem anderen Chip als die Kerne 1401a-b, aber über eine zwischenspeicherkohärente Schnittstelle 1496 an die Kerne gekoppelt ist. In einer Ausführungsform verwendet die zwischenspeicherkohärente Schnittstelle 1496 paketbasierte Transaktionen, um sicherzustellen, dass der Datenzwischenspeicher 1380 des DPC 1300 mit der Zwischenspeicherhierarchie der Kerne 1401a-c kohärent ist.
Universalregister (GPRs) 1418d, ein Satz von Vektor-/Kachelregistern 1418b, ein Satz von Maskenregistern 1418a (die Kachelmaskenregister wie unten beschrieben enthalten können) und ein Satz von Steuerregister 1418c sind ebenfalls in 14A-C veranschaulicht. In einer Ausführungsform werden mehrere Vektordatenelemente in jedes Vektorregister gepackt, das eine Breite von 512 Bit zum Speichern von zwei 256-Bit-Werten, vier 128-Bit-Werten, acht 64-Bit-Werten, sechzehn 32-Bit-Werten usw. aufweisen kann. Es können Gruppen von Vektorregistern kombiniert werden, um die hierin beschriebenen Kachelregister zu bilden. Alternativ kann ein separater Satz von 2D-Kachelregistern verwendet werden. Die zugrunde liegenden Prinzipien der Erfindung sind jedoch nicht auf eine bestimmte Größe/einen bestimmten Typ von Vektor-/Kacheldaten beschränkt. In einer Ausführungsform enthalten die Maskenregister 1407 acht 64-Bit-Operanden-Maskenregister, die zum Durchführen von Bit-Maskieroperationen bei den in dem Vektorregister 1406 gespeicherten Werten verwendet werden (z. B. als oben beschriebene Maskenregister k0-k7 implementiert). Die zugrunde liegenden Prinzipien der Erfindung sind jedoch nicht auf eine bestimmte Größe/einen bestimmten Typ von Maskenregister beschränkt. Ein Satz von einem oder mehreren Maskenregistern 1418a kann die hierin beschriebenen Kachel-Maskenregister implementieren.
Die Steuerregister 1418c speichern verschiedene Arten von Steuerbits oder „Flags“, die von ausführenden Befehlen verwendet werden, um den aktuellen Zustand des Prozessorkerns 1401a zu ermitteln. Beispielsweise enthalten die Steuerregister in einer x86-Architektur unter anderem die EFLAGS-Register.
Eine Zwischenverbindung 1406 wie eine chipinterne Zwischenverbindung (IDI) oder ein Arbeitsspeicherfabric, das ein IDI-/Kohärenzprotokoll implementiert, koppelt die Kerne 1401a-b (und möglicherweise den DPC 1300) kommunikativ aneinander und an verschiedene Komponenten innerhalb des gemeinsam genutzten Bereichs 1410. Die Zwischenverbindung 1406 koppelt zum Beispiel den Kern 1401a über die Schnittstelle 1407 an einen Level-3(L3)-Zwischenspeicher und an eine integrierte Arbeitsspeichersteuerung 1430. Darüber hinaus kann die Zwischenverbindung 1406 verwendet werden, um die Kerne 1401a-b an den DPC 1300 zu koppeln.
Die integrierte Arbeitsspeichersteuerung 1430 bietet Zugriff auf einen Systemarbeitsspeicher 1460. Ein oder mehrere Eingabe-/Ausgabe(E/A)-Schaltkreise (nicht gezeigt), wie PCI-Express-Verschaltung, können auch im gemeinsam genutzten Bereich 1410 enthalten sein.
Ein Befehlszeigerregister 1412 speichern eine Befehlszeigeradresse, die den nächsten Befehl identifiziert, der abzurufen, zu decodieren und auszuführen ist. Befehle können aus dem Systemarbeitsspeicher 1460 und/oder einem oder mehreren gemeinsam genutzten Zwischenspeicherlevels, wie einem L2-Zwischenspeicher 1413, dem gemeinsam genutzten L3-Zwischenspeicher 1420 oder dem L1-Befehlszwischenspeicher 1410 abgerufen oder vorab abgerufen werden. Darüber hinaus speichert ein L1-Datenzwischenspeicher 1402 Daten, die aus dem Systemarbeitsspeicher 1460 geladen und/oder aus einem der anderen Zwischenspeicherlevels 1413, 1420 abgerufen wurden, die sowohl Befehle als auch Daten zwischenspeichern. Ein Befehls-TLB (ITLB) 1411 speichert Übersetzungen von virtuellen Adressen in physische Adressen für die von der Abrufverschaltung 1418 abgerufenen Befehle, und ein Daten-TLB (DTLB) 1403 speichert Übersetzungen von virtuellen Adressen in physische Adressen für die von der Decodierverschaltung 1409 und der Ausführungsverschaltung 1408 verarbeiteten Daten.
Eine Verzweigungsvorhersageeinheit 1421 sagt Befehlsverzweigungsadressen und Verzweigungszielpuffer (BTBs) 1422 zum Speichern von Verzweigungsadressen und Zieladressen spekulativ vorher. In einer Ausführungsform wird eine Verzweigungsverlaufstabelle (nicht gezeigt) oder eine andere Datenstruktur für jede Verzweigungsvorhersage/Fehlvorhersage gepflegt und aktualisiert und wird von der Verzweigungsvorhersageeinheit 1402 verwendet, um nachfolgende Verzweigungsvorhersagen durchzuführen.
Es ist anzumerken, dass 14A-C keine umfassende Ansicht aller Verschaltungen und Zwischenverbindungen zeigen sollen, die innerhalb eines Prozessors eingesetzt werden. Vielmehr sind Komponenten, die nicht für die Ausführungsformen der Erfindung relevant sind, nicht gezeigt. Umgekehrt werden einige Komponenten nur zum Zweck der Bereitstellung einer beispielhaften Architektur gezeigt, in der Ausführungsformen der Erfindung implementiert werden können.
Zu 13 zurückkehrend, ist das Verarbeitungscluster 1300 in einer Vielzahl von Signalleitungen 1310 angeordnet, die Ausführungsressourcen (z. B. eine IRF 1320, eine FRF 1330, eine Tensor-ALU 1340, eine ALU 1350 und eine AGU 1360) für mehrere Mikrothreads einkapseln. Mehrere Threads nutzen die Ausführungsressourcen einer bestimmten Signalleitung, um eine Pipeline- und Arbeitsspeicherlatenz zu tolerieren. Der Zustand pro Mikrothread für eine Implementierung ist eine Teilmenge eines modernen Prozessorzustands.
15 veranschaulicht ein Beispiel eines Mikrothreadzustands 1500, der eine Teilmenge eines skalaren x86-Zustands ist. Der Mikrothreadzustand 1500 enthält einen Zustand von Universalregistern 1501 (z. B. sechzehn 64-Bit-Registern), XMM-Registern 1502 (z. B. zweiunddreißig 64-Bit-Registern), einem RFLAGS-Register 1504, einem Befehlszeigerregister 1505, Segmentselektoren 1506 und dem MXCSR-Register 1503. Die Verwendung einer Teilmenge eines skalaren x86 ist für Programmierer bequem, ist softwarekompatibel mit bestehenden x86-Codes und erfordert minimale Änderungen an aktuellen Compilern und Software-Toolketten. Die Signalleitungen dieser Ausführungsform führen skalare Befehle auf Benutzerebene aus. Natürlich sind die zugrunde liegenden Prinzipien der Erfindung nicht auf diese bestimmte Anordnung beschränkt.
In einer Ausführungsform, in 16 veranschaulicht, sind mehrere datenparallele Cluster 1300A-D gemeinsam in eine größere Skalierungseinheit angeordnet, die als eine „DPC-Kachel“ 1600 bezeichnet wird. Die verschiedenen datenparallelen Cluster 1300A-D können über eine Hochgeschwindigkeits-Fabriczwischenverbindung aneinander gekoppelt sein. Die DPC-Kachel 1600 kann innerhalb eines Prozessors oder Computersystems unter Verwendung beliebiger der mikroarchitekturellen Implementierungen integriert sein, die oben in Bezug auf das einzelne DPC 1300 in den 14A-C beschrieben sind (d. h., die DPC-Kachel 1600 kann in diesen Figuren für den DPC 1300 substituiert werden).
Die DPC-Kachel 1600 enthält einen gemeinsam genutzten Zwischenspeicher 1601 und baut auf der bestehenden Abrufeinheit 1418 und dem Decodierer 1409 eines oder mehrerer Kerne auf. Eine Vorabrufeinheit 1602 ruft Daten vorab aus dem Systemarbeitsspeicher und/oder der Zwischenspeicherhierarchie in Erwartung von uops ab, die auf den datenparallelen Clustern 1300A-D ausgeführt werden. Obwohl nicht illustriert, kann der gemeinsam genutzte Zwischenspeicher 1601 zwischen die datenparallelen Cluster 1300A-D gekoppelt sein und jeder DPC 1300A-D kann an das chipinterne Zwischenverbindungsnetzwerk (z. B. IDI) gekoppelt sein.
Die gemeinsame Nutzung der Ausführungsressourcen eines Prozessors über ein ganzes Cluster hinweg amortisiert den relativ komplexen Decodierprozess, der vom Decodierer 1409 durchgeführt wird. Eine Ausführungsform der Erfindung kann unter Verwendung eines winzigen Bruchteils der Abruf- 1418 und Decodierressourcen 1409 eines herkömmlichen Prozessordesigns Hunderte von Mikrothreads unterstützen, die Befehle ausführen.
Um bestimmte Ausführungsformen der Erfindung hervorzuheben, veranschaulicht 17 eine Sparse-Matrix-Vektor-Multiplikation. Die Sparse-Matrix-Vektor-Multiplikationsberechnung weist jeder Zeile einer dünnbesetzten Matrix einen Mikrothread zu. Die äußere Schleife (Schleife 0) verteilt Zeilen unter den Mikrothreads, während die innere Schleife (Schleife 1) ein Sparse-Skalarprodukt durchführt. Da die Anzahl von von null verschiedenen Werten pro dünnbesetzter Zeile in dünnbesetzten Matrizen sehr variabel ist, variiert die Durchlaufzahl der inneren Schleife über Mikrothreads hinweg. Am Beginn der Berechnung (vor Schleife 0) beginnen alle Mikrothreads die Ausführung am gleichen Befehlszeiger. Während alle Mikrothreads den gleichen Befehlszeiger ausführen, ist das Bereitstellen der Illusion von Mikrothreads unter Verwendung eines SIMD-Datenpfads trivial. Mit fortschreitender Ausführung führt die variable Durchlaufzahl der inneren Schleife zu einer Divergenz.
Die Divergenz tritt ein, wenn einige Mikrothreads einen unterschiedlichen Befehlszeiger ausführen. Im obigen Beispiel können die bedingten Sprünge bei 0x400d47 und 0x400d79 eine Divergenz herbeiführen. Da Divergenz mehrere Befehlszeiger bedeutet, muss die Mikroarchitektur die Abbildung zwischen Mikrothreads und ihren zugehörigen Befehlszeigern nachverfolgen. Ein Befehlszeiger mit einer Sammlung von zugehörigen Threads wird hier als ein „Fragment“ bezeichnet. Die Leistung auf einer datenparallelen Maschine hängt stark vom Rekonvergieren von Fragmenten ab, um Befehlsabrufe über die größtmögliche Anzahl von Mikrothreads hinweg zu amortisieren.
Der unmittelbare Post-Dominator einer divergenten Verzweigung ist der „nächste“ Befehl, bei dem garantiert werden kann, dass divergente Ausführungspfade wieder konvergieren. Nichtsdestoweniger kann eine Rekonvergenz von Mikrothreads vor oder nach dem unmittelbaren Post-Dominator eintreten. Im in 17 gezeigten Beispiel ist der mit „obb_0×400d7b“ gekennzeichnete Grundblock der unmittelbare Post-Dominator der Grundblöcke, die von den bedingten Sprüngen bei 0x400d47 und 0x400d79 abgeschlossen werden. Falls der bedingte Sprung bei 0x400d47 oder 0x400d79 bewirkt, dass Mikrothreads divergieren, ist der Befehl bei 0x400d7b der erste Zeitpunkt, zu dem garantiert werden kann, dass die Ausführungspfade rekonvergieren werden.
Ein bestehendes Verfahren zum Aufbau einer Maschine mit Mikrothreads unter Verwendung eines SIMD-Datenpfads ist ein explizites Erweitern von Verzweigungen mit einem Befehlszeiger (IP) zur Rekonvergenz und nachfolgendes Platzieren eines Befehls oder Steuercodes am unmittelbaren Post-Dominator. Dieser Ansatz nutzt die statische Rekonvergenzgarantie durch den unmittelbaren Post-Dominator und wird üblicherweise von einem Compiler durchgeführt. In aktuellen Ökosystemen ist ein Versuch eines compilergesteuerten Ansatzes nicht machbar. Vor allem weisen erweiterte Verzweigungen/Rekonvergenztoken außerhalb der hierin beschriebenen datenparallelen Erweiterung keine semantische Bedeutung auf und würde die Erweiterung mit bestehender Software inkompatibel machen.
Eine Ausführungsform der Erfindung enthält Verschaltung, um eine Mikrothread-Rekonvergenz dynamisch zu verwalten. Dieser Ansatz ermöglicht die Ausführung von veralteten Befehlen auf datenparallele Weise und kann eine höhere Leistung als der alternative, statisch markierte Rekonvergenzmechanismus bieten, der von vorangehenden Systemen verwendet wurde. Da dieser Ansatz nicht auf einer Compileranalyse zur Rekonvergenz aufbaut, hat die Hardware die vollständige Kontrolle über die Planung der Mikrothreads, um eine Rekonvergenz von Ausführungsfragmenten herbeizuführen.
In einer Ausführungsform findet die Gang-Planungseinheit 1301 Mikrothreads am gleichen Befehlszeiger, führt die Mikrothreads in Ausführungsfragmente zusammen, wählt eines der verfügbaren Fragmente aus und führt es dann in einem SIMD-Datenpfad aus. Die Aufgabe der Gang-Planungseinheit 1301 ist einer assoziativen Suche über alle Befehlszeiger von Mikrothreads ähnlich, die in einem Verarbeitungscluster residieren (z. B. Planen mindestens eines Fragments pro Zyklus). Die Gang-Planungseinheit 1301 kann für effiziente Planungsentscheidungen auf verschiedenen erkennbaren Eigenschaften aufbauen. In einer Ausführungsform führt die Gang-Planungseinheit 1301 eine Planung durch, indem sie sich auf bedingte Verzweigungen konzentriert, die eine Steuerdivergenz herbeiführen, auf Grundlage der Anzahl von divergenten Befehlszeigern, die von der Gesamtanzahl von Mikrothreads beschränkt werden und/oder in Übereinstimmung mit der Tatsache, dass es wahrscheinlich ist, dass eine Mikrothread-Rekonvergenz an Befehlspositionen in der Nähe des unmittelbaren Post-Dominators der Divergenzverzweigung eintritt. Schließlich wählt eine Ausführungsform der Gang-Planungseinheit das minimale IP-Fragment heuristisch aus, wenn mehrere Fragmente zur Auswahl verfügbar sind.
18 bietet ein Beispiel, in dem einige Threads einen Grundblock 1 (BB1) ausführen, während andere BB2 ausführen. Beide rekonvergieren bei BB3. Deshalb ist BB3 der Post-Dominator von {BB0, BB1, BB2}. In einer Ausführungsform führ die Gang-Planungseinheit 1301 eine Planung auf Grundlage der Tatsache durch, dass der Post-Dominator wahrscheinlich an der größeren zukünftigen Adresse gefunden wird, wenn der Kontrollflussgraph (CFG) linearisiert wird. Deshalb kann sie die niedrigeren PC-Adressen zuerst planen, um eine verbesserte Maskenkohärenz hervorzurufen. In diesem spezifischen Beispiel sollten die Grundblöcke BB1 und BB2 vor BB3 ausgeführt werden, um eine Rekonvergenz herbeizuführen.
Um die obigen Eigenschaften auszunutzen, baut eine Ausführungsform der Erfindung eine Datenstruktur (z. B. eine Tabelle oder ähnliche Struktur) auf, um Fragmente (z. B. einen Befehlszeiger (IP) und eine zugehörige Sammlung von Threads) nachzuverfolgen, unter Verwendung einer Anzahl von Einträgen, die ausreichen, um eine vollständig divergente Gang-Zusammenfassung zu halten (z. B. entweder 16 oder 32 Einträge). Die Struktur wird so verwaltet, dass eine teilweise Reihenfolgeinvarianz beibehalten wird, um die Fähigkeit bereitzustellen, das Fragment mit dem minimalen IP rasch auszuwählen.
Eine Implementierung umfasst ein binäres matrixbasiertes Schema, wobei jedem Fragment eine Zeile und eine Spalte in der binären Matrix zugeordnet wird. Ein Beispiel von Rekonvergenzverschaltung 1900, die eine Matrix 1901 enthält, ist in 19 veranschaulicht. In dieser Matrix 1901 ist ein Abhängigkeitsbit (D) im Eintrag entry(i,j) gesetzt, um anzuzeigen, dass sich Fragment i an einem größeren IP als das Fragment befindet, das Zeile j entspricht. Wenn ein neues Fragment in die Gang-Planungseinheit 1300 eingefügt wird, vergleicht die Rekonvergenzverschaltung 1900 ihren NIP mit den NIPs von bestehenden Fragmenten in der Matrix und die Zeilenabhängigkeitsbits werden entsprechend gesetzt. Das minimale IP-Fragment wird durch Berechnen von Vetobits 1905 an den zugehörigen Spalten ermittelt. Der Veto-Wert beeinflusst nur Einträge mit gesetztem Abhängigkeitsbit (höhere IPs). Dieser Prozess stellt sicher, dass die Zeile mit dem minimalen IP ausgewählt wird, wie durch eine der Auswahlsignale 1906 angezeigt, da sie die einzige Zeile ist, gegen die kein Veto eingelegt wurde.
Das illustrierte Beispiel von matrixbasierter minimaler IP-Auswahl unter Verwendung der Matrix 1901 wird durch die folgende Codesequenz definiert:

AuswahlO = NOR(Veto1 & AbhängigkeitsBit(0, 1), [= 1] Veto2 & AbhängigkeitsBit(0,2), ...... Veton & AbhängigkeitsBit (0,n))
Auswahl1 = NOR(Veto0 & AbhängigkeitsBit(0,0), [= 0] Veto2 & AbhängigkeitsBit (0,2), ...... Veton & AbhängigkeitsBit (0,n))
Auswahl2 = NOR(Veto0 & AbhängigkeitsBit(0,0), [= 0] Veto 1 & AbhängigkeitsBit (0, 1), ...... Veton & AbhängigkeitsBit (0,n))

Zusammenfassend senden bereite Fragmente, die für die Planung wetteifern, Vetosignale 1905 die zugehörigen Spalten hinunter. Das Vetosignal beeinflusst nur Einträge mit gesetztem Abhängigkeitsbit (d. h., diejenigen mit größeren IPs). Gegen die Zeile mit dem minimalen IP wird kein Veto eingelegt und sie wird deshalb von der Rekonvergenzverschaltung 1900 (Auswahl0) ausgewählt.
Eine alternative Implementierung zur Auswahl des minimalen IP verwendet einen binären Heap (auch als eine Prioritätswarteschlange bekannt), um die Fragmente zu verwalten. Ein binärer Heap ist eine Linearisierung eines binären Baums in einer Array-Struktur. Die Array-Struktur erzwingt die Invariante, dass ein übergeordneter Knoten kleiner als beide seiner untergeordneten Knoten ist. Deshalb weist die Wurzel des Baums (der erste Eintrag im Array) den minimalen IP auf und ist in O(1) Gates zugänglich, wie in 20 gezeigt. Einfügen und Löschen in den Heap benötigen im schlechtesten Fall O(Ig2(Mikrothreads)) Gates. In diesem Beispiel ist der IP der höchsten Priorität im Eintrag ganz links und kann direkt gelesen werden. Das Einfügen oder Löschen von neuen IPs erfordert für viele interessierende Tupel von Gesamtmikrothreads eine Anzahl von Gates, die in einen Zyklus oder zwei passen (und eine Frequenz auf Grundlage einer Prototypenentwicklung).
Eine Implementierung kann den Befehlszwischenspeicher des Clusters (oder den Zwischenspeicher von decodierten uops, falls vorhanden) mit Rekonvergenzhinweisen erweitern. Diese Hinweise bieten eine wesentlich höhere Maskendichte, wenn die Latenz zum Auflösen des Divergenzereignisses für diese Gang länger als die Latenz ist, mit der das Front-End zum nächsten Fragment wechselt. Durch Speichern von Rekonvergenzpositionen im I-Zwischenspeicher oder im uop-Zwischenspeicher (DSB), verbessern Ausführungsformen der Erfindung die Leistung an divergenten Codes wesentlich. In einer Ausführungsform, wenn ein Rekonvergenzereignis eintritt, wird die Position (IP) im Zwischenspeicher als ein Rekonvergenzpunkt markiert. Falls ein Ausführungsfragment später den Rekonvergenz-IP mit einer teilweisen Maske trifft, wird die Ausführung für eine kleine Anzahl an Zyklen angehalten, um eine Gelegenheit zur Rekonvergenz zu bieten. Um einen Fortschritt nach vorwärts zu garantieren, ist die Anzahl der Anhaltezyklen eingeschränkt, um eine Blockierung zu verhindern. Unter Verwendung dieser Techniken approximieren die entdeckten Rekonvergenzpunkte die Punkte dicht, die ein Compiler mit Rekonvergenzbefehlen einfügen würde (z. B. in einem statischen Rekonvergenzschema). Da die meisten datenparallelen Codes einen relativ kleinen Platzbedarf für Befehle aufweisen, kann ein herkömmlich bemessener Befehlszwischenspeicher (32 kBytes) oder uop-Zwischenspeicher (6144 uop) alle wichtigen Rekonvergenz-IPs erfassen.
Es ist auch möglich, unter Verwendung von hardwarebasierten Techniken Rekonvergenz-uops zu generieren. Bei diesem Ansatz erweitert das Befehls-Front-End Verzweigungs-uops mit dem Rekonvergenz-UIP und generiert explizite Rekonvergenz-uops am Rekonvergenz-IP. Das Erweitern von Verzweigungs-uops und das Hinzufügen von uops zum uop-Strom ist eine direkte Erweiterung eines uop-Zwischenspeichers. In einer Ausführungsform wird jedoch Hardware verwendet, um die Paare {Verzweigungs-IP, Rekonvergenz-IP}, die zur Rekonvergenz verwendet werden, folgendermaßen zu entdecken:

(a) Jeder Mikrothread verwaltet eine kleine Liste, die Paare aus {Verzweigungs-IP, Verzweigungsmaske} enthält. Der Verzweigungs-IP ist der IP der Verzweigung und die Verzweigungsmaske ist die Maske aller aktiven Threads an der gegebenen Verzweigung.
(b) Wenn Threads auf eine divergente Verzweigung treffen, zeichnet jeder aktive Mikrothread das aktuelle {Verzweigungs-IP, Maske}-Paar auf und speichert es in seine threadlokale Liste des Divergenzverlaufs.
(c) Wenn Threads rekonvergieren, berechnet die Verschaltung eine neue „aktive Maske“, die die rekonvergierte Maske widerspiegelt. Unter Verwendung der neu berechneten rekonvergierten Maske gehen alle Mikrothreads ihre lokale Divergenzverlaufsliste durch (gehen durch die Einträge), bis die folgende Invariante erfüllt ist „rekonvergenz_maske AND {IP, verzweigungs_maske}_i = = rekonvergenz_maske“. Dieser Prozess entdeckt die vorangehende Verzweigung, an der die Mikrothreads anfänglich divergierten.
(d) Nach dem Entdecken der anderen Verzweigung speichert die Hardware {Verzweigungs-IP, Rekonvergenz-IP} zur späteren Verwendung in einer Tabelle.

Darüber hinaus enthält eine Ausführungsform der Erfindung eine Vorhersageeinheit für neue Verzweigungen. Anstatt einer Vorhersage von Verzweigungen pro Mikrothread macht die Vorhersageeinheit für Verzweigungen dieser Ausführungsform Vorhersagen für ein ganzes Ausführungsfragment. Da das Verzweigungsverhalten von Mikrothreads in der Praxis stark korreliert, reduziert diese Implementierung die Hardwareanforderungen für die Verzweigungsvorhersageeinheit wesentlich.
21 veranschaulicht ein Beispiel einer mikroarchitekturellen Maskenmanipulation, die auf eine Mikroprozessor-Pipeline angewandt wird. Die veranschaulichte Pipeline enthält die Gang-Planungseinheit 1301 zum Planen von Befehlen, eine Befehlsabrufeinheit 1418 und einen Decodierer 1409 zum Decodieren von Makrobefehlen in uops. Zuteilungsverschaltung 2110 teilt Ausführungsressourcen einschließlich von Registern und funktionalen Einheiten zu, Ausführungsverschaltung 1408 führt die uops aus und Stilllegungsverschaltung 2111 legt die Befehle still, speichert den architekturellen Zustand und hebt die Zuteilung der Ausführungsressourcen auf.
Wenn ein Fragment ausgewählt ist, werden die zugehörige Abrufmaske und der zugehörige IP von der Abrufverschaltung 1418 an den Decodierer 1409 weitergeleitet. Der Decodierer 1409 generiert Mikro-Ops (uops) mit einer impliziten zusätzlichen Registerabhängigkeit auf der mikroarchitekturellen Maske, die von allen Befehlen für bedingte Verzweigungen und indirekte Sprünge beschrieben wird. Um eine Ladevorgangsdivergenz zu unterstützen, können Ladevorgänge ebenfalls die mikroarchitekturelle Maske beschreiben. Alle uops lesen die mikroarchitekturelle Maske. Deshalb wird die mikroarchitekturelle Maske ganz wie eine herkömmliche Registerabhängigkeit aus der Perspektive der Weiterleitung und Gefahrenerkennung behandelt. Wie in 21 gezeigt, führt die DPC-Mikroarchitektur ein logisches UND (Konjunktion) 2120 für dazwischen liegende abhängige Masken durch.
In einer Ausführungsform versucht die Gang-Planungseinheit 1301, ein Fragment für jeden Zyklus durch Untersuchen der verfügbaren Ausführungsfragmente und Auswählen des „besten“ (entweder durch den minimalen IP oder eine andere Heuristik) zu planen. Sobald das Fragment ausgewählt wurde, sendet die Gang-Planungseinheit 1301 das Fragment, einschließlich des IP und der mikroarchitekturellen Maske, an die Befehlsabrufverschaltung 1418. Die Befehlsabrufverschaltung 1418 erzeugt uops und eine mikroarchitekturelle Maske. Es ist anzumerken, dass die von der Befehlsabrufverschaltung 1418 erzeugte mikroarchitekturelle Maske möglicherweise nicht die gleiche wie die verteilte ist. Die Befehlsabrufverschaltung 1418 enthält mehrere Mechanismen, um eine Rekonvergenz zu erkennen, und kann eine Maskendichte erhöhen. Wenn ein Rekonvergenzereignis eintritt, erhöht sich die Dichte der mikroarchitekturellen Maske (die Füllanzahl der Bits in der mikroarchitekturellen Maske).
Da ein Fragment für mehrere Zyklen „Eigentümer“ der Befehlsabrufverschaltung 1418 ist, ist es möglich, dass der IP des Fragments mit einem anderen Fragment übereinstimmt, das sich bereits in der Gang-Planungseinheit 1301 befindet. In einer Ausführungsform, da die vorher erwähnte Rekonvergenzverschaltung 1900 nicht spekulativ arbeitet (z. B. innerhalb der Stilllegungsstufe 2111), wird ein anderer Mechanismus implementiert, um eine im Front-End entdeckte dynamische Rekonvergenz zu nutzen, was hierin als „Front-End-Fragmentzusammenführung“ bezeichnet wird. In einer Ausführungsform bietet die Front-End-Fragmentzusammenführung wesentliche Vorteile, wenn sie mit einer nicht spekulativen Gang-Planungseinheit und einer langen Befehlsabruf-zu-Stilllegungs-Latenz verwendet wird.
Eine Ausführungsform der Pipeline führt eine implizite mikroarchitekturelle Maskierung durch. Ein erster Befehl kann zum Beispiel (z. B. movq) eine implizite Abhängigkeit von einem zweiten Befehl (z. B. je) aufweisen. Durch Behandeln des Maskenregisters als eine explizite Abhängigkeit, wird ein richtiges Verhalten nach divergenten Befehlen sichergestellt.
In einer Ausführungsform erweitert der Decodierer 1409 jede uop mit einer impliziten zusätzlichen Abhängigkeit vom Erzeuger der mikroarchitekturellen Maske. Die mikroarchitekturelle Maske und zugehörige Manipulationsverschaltung ermöglicht Hardware, die Steuerabhängigkeit einer bedingten Verzweigung dynamisch in eine Datenabhängigkeit umzuwandeln. Dies verbessert die Effizienz beim Umwandeln von Parallelismus auf Thread-Ebene in eine Form, die zur Ausführung auf Hardware vom SIMD-Stil geeignet ist.
Wenn die Befehlsabrufverschaltung 1418 uops an das Back-End der Maschine erzeugt, erfolgt die Zuteilung auf ähnliche Weise wie bei einem herkömmlichen Out-of-Order-Mikroprozessor; der wesentliche Unterschied liegt jedoch darin, dass die mikroarchitekturelle Maske nun eine explizite Abhängigkeit ist (wie z. B. ein anderes Registerfeld in der uop). Alle Befehle lesen die mikroarchitekturelle Maske; nur eine kleine Teilmenge der Befehle beschreibt jedoch die mikroarchitekturelle Maske. Bedingte Verzweigungen und indirekte Sprünge müssen die mikroarchitekturelle Maske beschreiben. Eine Implementierung kann wählen, eine „Ladevorgangs-Divergenz“ zu implementieren, indem sie Ladevorgänge für den Arbeitsspeicher dazu bringen, auch die mikroarchitekturelle Maske zu beschreiben. Wenn deshalb eine uop ihre Operanden in einer Reservierungsstelle liest, tut sie das auch für die mikroarchitekturelle Maske. Die mikroarchitekturelle Maske wird jedoch anders als ein herkömmlicher Operand behandelt. Die neue mikroarchitekturelle Maske wird durch Nehmen des AND der der Reservierungsstelle präsentierten Maske mit der weitergeleiteten Maske berechnet. Dies stellt sicher, dass Mikrothreads nach einem Divergenzereignis (Verzweigung oder Ladevorgang) richtig ausgeführt werden.
Diese Datenabhängigkeit auf Grundlage der Steuerabhängigkeit einer bedingten Verzweigung könnte einer Spekulation unterzogen sein. Eine Implementierung unter Verwendung eines Neuordnungspuffers (ROB) kann wählen, Befehle spekulativ im Schatten eines Maskenerzeugers zu verteilen, um eine Nutzung in Ausführungsregimes mit niedriger Belegung oder in Implementierungen mit kleinen Anzahlen von Mikrothreads pro Signalleitung zu erhöhen. Sobald der Maskenerzeuger aufgelöst wurde, können die Befehle, die zu diesem Fragment im Schatten des Maskenerzeugers gehören, innerhalb der Pipeline oder aus dem Neuordnungspuffer (ROB) gelöscht werden.
Die Stilllegungsverschaltung 2111 aktualisiert die Gang-Planungseinheit 1301 mit neuen Fragmenten. Die mikroarchitekturelle Maske wird nicht spekulativ stillgelegt; folglich sind alle Gang-Planungseinheitsaktualisierungen nicht spekulativ. Die Gang-Planungseinheit 1301 erteilt Befehle aus einem bestimmten Fragment, bis ein bestimmtes Divergenzereignis eintritt (z. B. eine divergente Verzweigung, ein Zwischenspeicher-Fehlzugriff, ein minimaler IP-Fragmentwechsel, ein Prioritätsumkehrungsfragmentwechsel, ein Livelockabbruchsfragmentwechsel). Wenn dies eintritt, müssen ein oder mehrere Fragmente zurück in die Gang-Planungseinheit geschrieben werden. Ein neues Fragment, das von einem divergenten Befehl (z. B. einer bedingten Verzweigung) generiert wurde, wird etwas anders als ein Fragmentwechselereignis behandelt.
Wenn eine Fragmentwechseloperation eintritt, wird die assoziierte uop durch das Front-End als die letzte uop für ein bestimmtes Fragment markiert. Bei Stilllegung aktualisiert die uop die Gang-Planungseinheit 1301 mit ihrer Maske und ihrem IP, wobei er aus dem Ausführungszustand der Maschine entfernt wird.
Andere Arten von Fragmentwechseln können ein Invertieren der Priorität des Heaps der Gang-Planungseinheit, um einen Fortschritt an Fragmenten zu ermöglichen, die andernfalls nicht in der Maschine residieren, einen Livelock-Abbruch, wenn ein bestimmtes Fragment alle Ressourcen verbraucht hat, aber keine Fortschritte macht, Aufruf-/Rückgabestapel-Fragmentwechsel für indirekte Verzweigungen und vorhersagebasierte Fragmentwechsel enthalten.
In einer Ausführungsform berechnen divergente Verzweigungen zwei {Masken, IP}-Tupel. Die Ausführungshardware 1408 wählt den Ausführungspfad mit dem auszuführenden minimalen IP aus. Das aktuelle Fragment nimmt die Maske für die passende Verzweigungsrichtung an und leitet die aktualisierte Maske an alle abhängigen uops weiter. Wenn die divergente Verzweigung stillgelegt wird, aktualisiert sie die Gang-Planungseinheit mit dem nicht genommenen Fragment. In beiden Fällen bewirken Stilllegungsaktualisierungen, dass die Gang-Planungseinheit 1301 versucht, Fragmente zu rekonvergieren.
Eine Implementierung kann einen Hardwaremechanismus einsetzen, um uops einen spekulativen Maskenzustand zuzuweisen, was ermöglicht, dass dieser tatsächlich eine längere Latenz aufweist, um ein Divergenzereignis aufzulösen, und dennoch eine möglichst volle Maske bei der Verteilung aufweist, da die Maskenaktualisierung später in der Pipeline stattfindet. Dies erfordert ein Hinzufügen einer Tabelle mit Fragmentmasken, auf die jede uop Bezug nimmt. Es gibt nur einen Eintrag für jedes eindeutige Fragment, dem erlaubt ist, sich im Back-End der Maschine aufzuhalten. Jeder Tabelleneintrag entspricht einer anderen Fragmentsequenz-ID.
Die obigen Techniken sind zum Abschalten des Befehlsabrufclusters einer datenparallelen Maschine und zum Ausführen aus der IDQ 1305 nützlich. Die neue IDQ-Maskentabelle ist vom Heapzustand aus mindestens zwei Gründen separat: (1) Falls ein Fragment-Push stattfindet, nachdem die Fragmentwechsel-uop für diese Sequenz-ID zugeteilt wurde, dann kann diese Tabelle keine Fragmentzusammenführung durchführen, ohne möglicherweise eine Programmreihenfolge zu verletzen; und (2) ist jedes Fragmentbeendende Ereignis, das ein Fragment aus dem Heap entfernt, weiterhin ein Kandidat für das Zusammenführen.
Bei einem Fragment-Push, falls sich die Fragment-Sequenz-ID in der IDQ 1305 befindet und die Fragmentwechseloperation noch nicht zugeteilt wurde, dann wird ein Zusammenführen an der IDQ-Maskentabelle und dem Heap der Gang-Planungseinheit durchgeführt. Diese zusammengeführte Maske wird in jede uop-Abschlussmaske kopiert, wenn sie zugeteilt wird.
Ein Verfahren nach einer Ausführungsform ist in 22 veranschaulicht. Das Verfahren kann auf den Prozessor- und Systemarchitekturen, die oben beschrieben sind, implementiert werden, ist jedoch nicht auf eine bestimmte Architektur beschränkt.
Bei 2201 werden Befehle von einem oder mehreren Threads abgerufen und bei 2202 werden die Befehle decodiert, um uops zu generieren. Wie erwähnt, werden in einer Ausführungsform der Abruf und das Decodieren von einem Hostprozessor durchgeführt (wie z. B. einem x86-Prozessor mit einer gleichzeitigen Multithreading-/Mehrkern-Architektur). In einer anderen Ausführungsform enthält der DPC Abruf- und Decodierverschaltung, um seine eigenen Befehle abzurufen und zu decodieren, um uops zu generieren.
Bei 2203 wird eine Teilmenge von uops identifiziert, die auf dem DPC auszuführen ist. Diese uops werden dann an den DPC weitergeleitet (z. B. über eine chipinterne Zwischenverbindung, falls der DPC chipintern ist, oder eine chipexterne Zwischenverbindung, falls der DPC chipextern ist).
Bei 2204 wertet die DPC-Planungseinheit Mikrothreads von uops auf Grundlage von mit den Mikrothreads assoziierten Variablen aus. Wie erwähnt enthalten die Variablen in einer Ausführungsform die mit den Mikrothreads assoziierten Befehlszeiger(IP)-Werte. Bei 2205 führt die DPC-Planungseinheit die Mikrothreads in Fragmente zusammen und plant die Fragmente zur Ausführung in DPC-Signalleitungen auf Grundlage der Auswertung von 2204. Wie bereits beschrieben, plant die DPC-Planungseinheit die Fragmente mit dem Ziel, eine Mikrothread-Rekonvergenz herbeizuführen.
ADAPTIERBARE UND EFFIZIENTE TENSORVERARBEITUNG PRO SIGNALLEITUNG
Wie oben erwähnt enthält eine Ausführungsform des datenparallelen Clusters 1300 eine Tensor-ALU 1340 zum Verarbeiten von Tensordaten innerhalb ihrer designierten Signalleitung. Eine bestimmte Ausführungsform der Tensor-ALU 1340 ist unten beschrieben. Da vorangehende Lösungen SPMD nicht mit Tensorverarbeitung gepaart haben, sind sie weniger adaptierbar und weniger effizient als die hier beschriebene Tensor-ALU 1340.
Insbesondere ist eine Ausführungsform der Tensor-ALU (TALU) 1340 sehr adaptierbar und verwendet eine 2D-Broadcast-Implementierung, die eine hoch effiziente Tensor-Matrixmultiplikation (TGEMM) in einer SPMD-Architektur erzielt. Darüber hinaus ist die TALU 1340 neu konfigurierbar, um verschiedene Matrixdimensionen zu handhaben, und enthält Unterstützungsstrukturen (z. B. Registerdateileseports, Zwischenspeicherbandbreitenanforderungen usw.), um der TALU 1340 zu ermöglichen, mit einer hohen Effizienz zu arbeiten.
Ausführungsformen von Tensor-ALU(TALU)-Befehlen
Wie in 23 illustriert, umfasst eine Ausführungsform eines TALU-Matrixbefehls 2300 ein Opcodefeld 2301, um die durchzuführende Operation anzugeben, Operandgrößenfelder 2302-2304, um eine Größe für jeden der Operanden anzugeben, zwei 4-Register-Gruppenoperandenfelder 2304-2305 und ein Operandenfeld 2306, das vier Elemente an einer Arbeitsspeicherposition identifiziert. Die ,4' am Beginn des Opcodes 2301 zeigt die Anzahl von Elementen von A an, die bei der Operation verwendet werden. Der DBB-Abschnitt des Opcodes (2302-2304) zeigt eine Doppelwortgröße (D) für einen Operanden C und Bytegrößen (B) für Operanden A und B an. Deshalb stammen vier Elemente von srcA aus dem Arbeitsspeicher mit einer Schritteinheit von 1 Byte.
In einer Ausführungsform enthält jede TALU 1340 Matrixmultiplikationsverschaltung, um die folgende Matrixmultiplikationsoperation durchzuführen: [1x8]c += [1x4] _A *[4×8]_B. Die Mikroarchitektur der TALU 1340 in dieser Ausführungsform kann ein 4×8-INT8*INT8-Multiplikator sein, der in eine INT32-Einheit akkumulatiert. Bestehende Werte, die in einer Akkumulatorkachel/einem Vektorregister gespeichert sind, können zum Beispiel zu den vom Multiplikator generierten Produkten addiert werden. Die resultierenden Summen können dann zurück in die Akkumulatorkachel/das Vektorregister gespeichert werden.
In einer Ausführungsform sind vier Zeilen aus acht 1-Byte-Elementen von srcB in vier Registeroperanden geladen. Der Befehl kann eine Registergruppe als die Quelle dafür angeben (z. B. 4-Registergruppe 2304). Eine Zeile (8 Elemente, jeweils 4 Bytes) von C wird mit diesem Befehl gelesen und geschrieben (akkumuliert). Die Größe eines C-Elements wird aus D (was für Doppelwort steht) im Befehl decodiert.
Deshalb ist die Register- und Arbeitsspeichernutzung für diese Ausführungsform folgendermaßen:

(a) 4 Zeilen × 8 Spalten aus 1-Byte-Operanden in B erfordern insgesamt 32 Bytes (jede Zeile benötigt 8 Bytes). In einer Ausführungsform wird dies unter Verwendung von 4 DPC-Registern gespeichert, wobei jedes Register eine Größe von 8 Bytes/64 Bits hat.
(b) 1 Zeile × 8 Spalten aus 4-Byte-Operanden in C erfordern ebenfalls insgesamt 32 Bytes, was wiederum 4 DPC-Register verbraucht. Es ist anzumerken, dass C in Schritteinheiten aus 4 Bytes von zusammenhängendem Arbeitsspeicher gelesen und geschrieben wird.
(c) Zum Angeben des Beginns von srcA aus dem Arbeitsspeicher wird ein INT-Register verwendet; srcA-Zugriff erfolgt in Schritten aus 1 Byte von zusammenhängendem Arbeitsspeicher.
(d) Unter Verwendung des Befehlsformats in 23, sind 4 Register als eine Gruppe für C und B in den Feldern 2304 bzw. 2305 angegeben. In einer Ausführungsform sind die letzten zwei Bits des Registeroperanden ausgeblendet und 0b00, 0b01, 0b10 und 0b11 werden addiert, um die 4 zu verwendenden Register zu identifizieren.

Während 4TFMADBB als ein Beispiel für eine 4x8-TALU gezeigt ist, sind die zugrunde liegenden Prinzipien der Erfindung nicht auf eine bestimmte Operandengröße oder Registeranordnung beschränkt. Beispielsweise kann ein Tensorbefehl mit einem 8TFMADBB-Opcode unter anderem eine 8x4-TALU verwenden und ein Tensorbefehl mi einem 16TFMADBB-Opcode kann eine 16x2-TALU verwenden.
2D-Broadcast-Ausführungsformen
Wie erwähnt enthält eine Ausführungsform eines DPC 1300 eine 32-Signalleitungs-Implementierung mit einer 4x8-TALU in jeder Signalleitung. Vor einem 4TFMADBB-Befehl können Ladevorgänge durchgeführt werden, um die 4×8-B-Kacheln von Daten (z. B. 4 Ladevorgänge mit jeweils 8 Bytes) in vier benachbarte XMM-Register zu bewegen. Die oben erwähnte Vorabrufeinheit 1602 kann zum Beispiel Hinweise oder andere Techniken verwenden, um die Daten vorwegzunehmen und vorab in den gemeinsam genutzten Zwischenspeicher 1601 abzurufen. Gleichermaßen kann eine Vorabrufeinheit in einer Implementierung mit einem DPC 1300 (anstatt einer DPC-Kachel 1600) die Daten in den Datenzwischenspeicher 1380 vorab abrufen, sodass sie lokal für alle der Signalleitungen verfügbar sind.
In einer Ausführungsform führen alle 32 Signalleitungen diese Ladevorgänge aus und rufen benachbarte B-Kacheln in ihre entsprechenden Registerdateien ab. Jede Signalleitung enthält Registerdateien, um einen Satz pro architekturellen Registern pro Gang zu halten. Um den Durchsatz zu verbessern, wird der Ladevorgang einer B-Kachel in jeder Signalleitung innerhalb der Signalleitung als Gang-invariant markiert. Als solche wird die gleiche B-Kachel per Broadcast übermittelt und in die Registerdateien jeder Gang-Einheit innerhalb der Signalleitung geschrieben. Dies stellt eine der Dimensionen des 2D-Broadcast dar.
In einer Ausführungsform werden Ladevorgänge auch durchgeführt, um die C-Kachel (1 Zeile aus 8 Elementen mit jeweils 4 Bytes = insgesamt 32 Bytes pro Signalleitung) in vier benachbarte XMM-Register zu bewegen. Da vier von 32 XMM-Registern für die B-Kachel verwendet werden, sind 28 XMM-Register für die C-Kacheln verfügbar. Da jeder 4TFMADBB-Befehl 4 XMM-Register für die C-Kachel benötigt, können 7 solcher 4TFMADBB-Befehle in einer Gang-Einheit ausgeführt werden (d. h., bevor die XMM-Register vollständig aufgebraucht sind). Da es acht Gang-Einheiten in einer Implementierung des DPC geben kann, kann es 7x8 = 56 4TFMADBB-Register geben, bevor alle XMM-Register in allen acht Gang-Einheiten verwendet sind.
In einer Ausführungsform werden diese 56 4TFMADBB-Befehle verwendet, um eine Block-Einheit zu ermitteln. Da jeder 4TFMADBB-Befehl 8 Elemente mit C-Kacheln pro Signalleitung erzeugt und da es 32 Signalleitungen gibt, beträgt die Blockgröße, die von einer Implementierung mit 32 Signalleitungen eines DPC erzielt werden kann, das 4TFMADBB-Befehle ausführt, 56x256. Als ein weiteres Beispiel beträgt die Blockgröße, die von einer Implementierung mit 32 Signalleitungen eines DPC erzielt werden kann, das 8TFMADBB-Befehle ausführt, 112x128. Je größer die Blockgröße, desto höher die Datenwiederverwendung, und daher muss das gleiche Datenelement weniger oft gelesen werden, um eine Matrixmultiplikation abzuschließen.
Sobald die B- und C-Kacheln in jeder Signalleitung in Register geladen sind, werden die 4 Elemente von srcA aus dem Arbeitsspeicher geladen. In einer Ausführungsform wird dieser Ladevorgang mit dem 4TFMADBB-Befehl verschmolzen, sodass der Ladevorgang in ein FTMP-Register (z. B. ein temporäres oder nicht architekturelles Register) schreibt und der 4TFMADBB-Befehl dieses FTMP-Register für srcA liest. Die gleiche A-Kachel wird von allen 32 Signalleitungen gelesen, wobei tatsächlich die gleichen A-Kacheldaten an alle Signalleitungen per Broadcast übertragen werden. Dies stellt die zweite Dimension des 2D-Broadcast-Schemas dar (Wiederverwendung von A-Daten). Sowohl die A- als auch die B-Broadcasts erhöhen die Datenwiederverwendung und ermöglichen die 56x256 Blockgröße für 4TFMADBB. Es ist anzumerken, dass die gleichen B-Kacheln für jede der 56 A-Kachel-Lesevorgänge wiederverwendet werden (Wiederverwendung der B-Daten). Darüber hinaus, sobald die teilweisen Produkte eines 56x256-Blocks von C abgeschlossen sind, wird die Dimension K verarbeitet (d. h., die Eingabematrix A hat die Dimension MxK, die Eingabematrix B hat die Dimension KxN und die Ausgabematrix C hat die Dimension MxN) und die Ergebnisse werden in die gleiche C-Kachel akkumuliert (Wiederverwendung der C-Daten).
24 veranschaulicht Operationen, die in einer Ausführungsform in jeder Signalleitung geschehen. Insbesondere wird eine 1x4-A-Kachel 2401 mit einer 4×8-B-Kachel 2302 multipliziert, um das teilweise Produkt einer 1x8-C-Kachel 2403 zu erzeugen. In einer Ausführungsform multiplizieren Multiplikatoren 2404 in der Signalleitung das erste Element von A mit jedem der 8 Elemente in der oberen Zeile von B, um die 8 Elemente in der oberen Zeile von C zu erzeugen. Gleichermaßen werden die zweiten, dritten und vierten Elemente von A mit der zweiten von oben, dritten von oben bzw. der unteren Zeile von B multipliziert, um entsprechende Zeilen von C zu erzeugen. Diese teilweisen Produktzeilen von C werden durch Addierer/Akkumulatoren 2405 innerhalb der Signalleitung addiert.
25 veranschaulicht, wie die Kacheln von A, B, C bewegt werden, um die gesamte Matrixmultiplikation in einer Ausführungsform abzuschließen. Diese Operationen sind ausreichend, um einen 56x256-Block der C-Matrix zu generieren. Diese Operationen werden durch Bewegen entlang der Dimensionen M und N der Matrix C wiederholt, um den Befehl abzuschließen. Jede Signalleitung wird zuerst mit 7*G Kacheln von C (dem Akkumulatoroperanden) beladen, wobei es 7 Akkumulatoren in jeder Gang-Einheit gibt und G die Anzahl der Gang-Einheiten pro Signalleitung ist. Jede Signalleitung ist mit 1 Kachel von B (einem Gang-invarianten Ladevorgang) beladen. Das Laden der 1 Kachel von B kopiert Elemente in Register aller Gang-Einheiten in einer Signalleitung. Die TS_W-Elemente von A werden in jedem Zyklus über alle Signalleitungen via Broadcast übermittelt und Multiplikations-Akkumulations-Operationen (z. B. FMA-Operationen) werden durchgeführt, um neue TS_W-Elemente von C in jedem Zyklus zu erzeugen. Nach 7 A-Ladevorgängen wechselt eine Ausführungsform zwischen den Gang-Einheiten in einer Signalleitung. Die innere Schleife C[56Z*8S] += A[56Z*4S]*B[4Z*8S], wobei dieser 56Zeilen*8Spalten-C-Block über die Dimension K hinweg wiederverwendet wird. Insbesondere bewegt sich eine Ausführungsform in die Richtung K von A und B.
Adaptierbares Tensor-ALU-Design
Um bei stark variierenden Matrixdimensionen eine hohe Hardwarenutzung zu erzielen, verwendet eine Ausführungsform jeder TALU 1340 die gleiche Verschaltung, um unterschiedliche Blockformen unter Verwendung verschiedener Konfigurationen der 32 Multiplikatoren zu implementieren. Man betrachte zwei separate Implementierungen der TALU in 4x8 (26) bzw. 8x4 (27), die 8-Bit-A-Term-Verarbeitungselemente 2601-2701, 8-Bit-B-Term-Verarbeitungselemente (mit Multiplikatoren) 2602-2702 und 32-Bit-C-Akkumulator-Verarbeitungselemente 2603-2703 illustrieren. Die verschiedenen Verarbeitungselemente in den 26-27 werden unter Verwendung verschiedener Füllmuster identifiziert.
Falls die B-Kachel in einem Reihenfolgeformat nach Spalten zuerst gespeichert ist, kann eine Basis-4x8-Konfiguration von Multiplikatoren verwendet werden, um eine 8x4-Konfiguration durch Addieren der benachbarten geraden und ungeraden Spalten zu implementieren, wie in 28 gezeigt. Ein Satz von 2-Eingangs-32-Bit-Multiplexern 2804a-h ist in dieser Ausführungsform enthalten, um aus unterschiedlichen Eingabeoptionen auszuwählen.
In der 4x8-Konfiguration dieser Implementierung werden die ersten 4 Bytes von A 2701 via Broadcast an alle 8 Skalarproduktspalten 2802 übertragen (alle Muxe 2804a-d lenken in dieser Konfiguration ihre linke Eingabe). In der Akkumulationsstufe unten stehen die C-Eingaben dem Akkumulator (gerade Spalten) direkt zur Verfügung oder werden durch einen Multiplexer 2804e-h (ungerade Spalten) ausgewählt, wodurch die gleiche Funktion implementiert wird, wie in 26 gezeigt (d. h. 4TFMADBB).
In der 8x4-Konfiguration werden die unteren 4 Bytes von A 2701 den geraden Spalten geliefert und die hohen 4 Bytes von A 2701 werden den ungeraden Spalten geliefert. Wie illustriert lenken die Eingangsmultiplexer 2804a-d die Bytes von A 2701 zu den richtigen Spalten 2802. In der Akkumulationsstufe 2803 wird die C-Eingabe an jeder geraden Spalte zum Skalarprodukt addiert und die resultierende Summe wird durch die Multiplexer 2804e-h gelenkt, um zum Skalarprodukt der benachbarten ungeraden Spalte addiert zu werden, wodurch das Endergebnis am Ausgang jedes Addierers in den ungeraden Spalten erzeugt wird. Deshalb implementiert diese Konfiguration die gleiche Funktion wie in 27 gezeigt (d. h. 8TFMADBB).
Die Neukonfiguration der anfänglichen Matrix von Multiplikatoren, wie sie oben beschrieben wird, kann leicht auf eine 16x2-Matrixberechnung erweitert werden. Die Notwendigkeit einer derartigen Neukonfiguration ergibt sich aus der Notwendigkeit, unterschiedliche Matrixgrößen effizient zu handhaben (z. B. von einer quadratischen 2048x2048-Matrix zu einer schiefsymmetrischen 2048x128- oder 128x2048-Matrix).
Unterstützende Strukturen für eine Beibehaltung hoher Effizienz
Registerbänke:
Wenn sich der 4TFMADBB-Befehl in einer stabilen Operation befindet, muss er 4 XMM-Register für die C-Kachel lesen und schreiben. In einer Ausführungsform ist die Registerdatei in ungerade und gerade Bänke eingeteilt, um ein Hinzufügen von 4 Lese- und 4 Schreibports zur Registerdatei zu vermeiden. XMM0, XMM2, XMM4 usw. befinden sich in der geraden Bank und XMM1, XMM3, XMM5 usw. befinden sich in der ungeraden Bank. Da die C-Kachel eingeschränkt ist, 4 benachbarte Register zu umspannen (wie XMM0-XMM3 oder XMM4-XMM7 usw.), reichen 2 Leseports und 2 Schreibports in jeder Bank aus.
B-Kachel-Broadcast über Gang-Einheiten hinweg:
In einer Ausführungsform unterstützt die Registerdatei Schreiben/Broadcasten der Ergebnisse einer B-Kachel-Ladeoperation in die gleichen Register jeder Gang-Einheit. Falls zum Beispiel der erste Gang-invariante Ladevorgang die erste Zeile der B-Kachel in XMM0 abruft, werden die XMM0-Register aller 8 Gang-Einheiten mit den gleichen Daten beschrieben.
A-Kachel-Broadcast über Signalleitungen hinweg:
In einer Ausführungsform unterstützt der Datenzwischenspeicher 1380 eine Übermittlung via Broadcast der gleichen Daten an alle 32 Signalleitungen des datenparallelen Clusters 1300. In einer Ausführungsform unterstützt der Datenzwischenspeicher 1380 parallelen Hochgeschwindigkeitszugriff der B-Kachel und der C-Kachel durch alle 32 Signalleitungen.
OPTIMIERUNGEN VON GANG-INVARIANTEN DPS-OPERATIONEN
In einem Einzelprogramm-Mehrfachdaten(SPMD)-Modell wie die oben beschriebenen wird der gleiche Befehl in vielen Signalleitungen mit unterschiedlichen Daten in jeder Signalleitung ausgeführt. Wie erwähnt, bilden die verschiedenen Mikrothreads (uthreads), die den gleichen Befehl in allen Signalleitungen 1310 ausführen, eine Gang-Einheit. Manchmal kann die Gesamtheit oder eine Teilmenge der uthreads innerhalb einer Gang-Einheit oder gar alle uthreads innerhalb aller Gang-Einheiten an den gleichen Daten operieren, um die gleichen Operationen durchzuführen. Derartige Operationen werden als Gang-invariante Operationen (GIOs) bezeichnet. Die separate Ausführung von GIOs durch alle uthreads führt zu vergeudeter Energie und vergeudeter Ausführungsbandbreite.
30 veranschaulicht zusätzliche Details einer Ausführungsform eines DPC-Front-Ends 1307, das eine dynamische GIO-Erkennungsverschaltung 3005 zum Identifizieren von GIOs auf Grundlage von Informationen, die mit den uops (die z. B. in den Befehlsstrom durch den Compiler eingesetzt sind) assoziiert sind, und/oder Ausführungsrückmeldungen von den verschiedenen Signalleitungen 3030 enthält. Beispiele der von der dynamischen GIO-Erkennungsverschaltung 3005 durchgeführten Analyse werden unten bereitgestellt.
Darüber hinaus veranschaulicht 30 eine Zuteilungs- und Umbenennungsverschaltung 1301 zum Zuteilen von Ausführungsressourcen innerhalb der Signalleitungen 3030 (z. B. ALUs, TALUs usw.) und zum Durchführen einer Registerabbildung/Umbenennung innerhalb der Signalleitungen 3030 (wobei z. B. physische Register auf logische Register abgebildet werden, die während der Ausführung zu verwenden sind) für die verschiedenen Mikrothreads. Eine ALU-Reservierungsstation 3010 verteilt dann uops an freie ALU-/TALU-Ausführungsressourcen und eine Arbeitsspeicherreservierungsstation 3020 verteilt uops für Arbeitsspeicheroperationen (z. B. Lade-/Speicheroperationen).
Die unten beschriebenen Ausführungsformen der Erfindung erkennen und übermitteln GIOs an die Ausführungsverschaltung und stellen Hardwaremechanismen bereit, um GIOs mit minimalem Ressourcenverbrauch abzuschließen. Insbesondere führen diese Ausführungsformen Folgendes durch:

(i) Klassifizieren der Typen von GIOs;
(ii) statisches oder dynamisches Erkennen von GIOs;
(iii) Übermitteln von GIOs an die Ausführungshardware; und
(iv) Aufnehmen von Verschaltung, um GIOs minimal abzuschließen.

Klassifizieren der Typen von GIOs
Es gibt zwei Dimensionen, entlang derer GIOs klassifiziert werden können. Die erste Klassifizierungsdimension beruht auf der Bedingung der Invarianz. Ein Befehl kann zum Beispiel eine immer invariante Operation (AIO) oder nur eine bedingt invariante Operation (CIO) sein. Eine AIO führt immer die gleiche Arbeit über alle uthreads hinweg durch (d. h., jedes Mal, wenn auf diesen Befehl getroffen wird, zum Beispiel als Teil einer Schleife). Eine CIO führt jedoch nur dann die gleiche Arbeit über uthreads hinweg durch, wenn eine bestimmte Bedingung erfüllt ist.
Der folgende Codeausschnitt einer 2D-OpenCL-Anwendung enthält AIOs und CIOs:

      _kernel void sgemm_knh(_global float *C, _global float *A,

       _global float *B, int n, int mm, int _k) {

      1: const int m = 16 * I_BLK;
      2: int ii = get_global_id(0);
      3: int i = ii * I_BLK;
      4: int j = get_global_id(1);
      ...

      for (int k = 0; k < _k; k++) {
      float vb = B[k * m + j];
      NUM_OPS(DOFMA)
      }
      NUM_OPS(STOREC);

Die Operation in Zeile 1 generiert den gleichen m-Wert über alle uthreads hinweg, da die Operation nicht von Variablen abhängt, die über verschiedene uthreads hinweg verschieden sind (d. h., das Ergebnis hängt nur von Thread-invarianten Variablen ab). Wir bezeichnen diese Operation als eine AIO.

Im Gegensatz dazu hängt die Operation in Zeile 3 vom Threadindex in der x-Dimension ab (d. h. get_global_id(0)). Diese Operation generiert unterschiedliche Werte in unterschiedlichen uthreads innerhalb einer Gang-Einheit. Über Gang-Einheiten hinweg, falls die Threadblockgröße in der x-Dimension kleiner oder gleich der Größe der Gang-Einheit ist, erzeugt jede Gang-Einheit den gleichen Wert für jeden entsprechenden Thread, da jeder Thread den gleichen ii-Wert sieht. Als solche wird Zeile 3 zu einer GIO. Falls die Threadblockgröße in der x-Dimension jedoch größer als die Größe der Gang-Einheit ist, weisen die Threads in unterschiedlichen Gang-Einheiten, die in der gleichen Signalleitung laufen, unterschiedliche ii-Werte auf. In diesem Fall ist Zeile 3 keine GIO. Da sie manchmal Gang-invariant ist und manchmal nicht, ist diese Operation eine bedingt invariante Operation (CIO).

Die zweite Dimension der Klassifizierung stammt aus einer Hardwareperspektive, die Signalleitungen berücksichtigt, und besteht aus den folgenden Typen: (a) innerhalb einer Signalleitung über Gang-Einheiten hinweg; und (b) über Signalleitungen und über Gang-Einheiten hinweg.

Ein Beispiel einer Invarianz, die innerhalb einer Signalleitung und über Gang-Einheiten hinweg eintritt, wird gefunden, wenn eine Matrixmultiplikation (A * B = C) in SPMD implementiert wird. In dieser Implementierung lädt jede Signalleitung eine unterschiedliche B-Matrix-Kachel, wie in 29A gezeigt (z. B. als Reaktion auf Ladevorgänge von uops, die von der MEM-RS 3020 verteilt wurden). Eine einzige A-Kachel wird an alle Signalleitungen via Broadcast übermittelt. Diese A-Kachel wird mit den unterschiedlichen B-Kacheln in jeder Signalleitung multipliziert, um wie illustriert unterschiedliche C-Kacheln zu erzeugen.

Mehrere Gang-Einheiten können auch zusammenarbeiten, um die gleiche Matrixmultiplikation auf effiziente Weise abzuschließen. Hierzu ruft eine zweite Gang-Einheit eine andere A-Kachel ab, multipliziert sie mit der gleichen B-Kachel wie die erste Gang-Einheit und erzeugt eine andere B-Kachel. Die neue A-Kachel und C-Kachel, die von der zweiten Gang-Einheit bearbeitet werden, werden in 29B als die schattierten Kästchen gezeigt. In einer Ausführungsform werden hierzu die gleichen B-Kacheln in jeweiligen Signalleitungen sowohl für Gang-Einheit 1 als auch Gang-Einheit 2 benötigt. Da die Gang-Einheiten 1 und 2 separate Registerdateien aufweisen, statt dass zwei separate Ladevorgänge die gleichen B-Kacheln zweimal für die zwei Gang-Einheiten holen müssen, können die gleichen Ladevorgänge die B-Kacheln einmal bringen und diese in die Registerdateien beider Gang-Einheiten ablegen.

Statisches oder dynamisches Erkennen von GIOs

In einer Ausführungsform werden GIOs auf Grundlage von sowohl einer Compiler-Analyse als auch einer Laufzeit-Analyse identifiziert, die von der dynamischen GIO-Erkennungsverschaltung 3005 durchgeführt wird. Alle Arten von Invarianz (AIO oder CIO) werden während der Compilierphase statisch erkannt und AIOs werden immer als GIOs behandelt. In einer Ausführungsform werden CIOs jedoch von der dynamischen GIO-Erkennungsverschaltung 3005 als GIOs (oder nicht) ausgewertet, abhängig von den Informationen beim Kernelstart und aus Rückmeldungen von den Ausführungssignalleitungen 3030.

Um GIOs zu identifizieren, identifiziert der Compiler zuerst intrinsische Thread-invariante Werte (AIO) im SIMT-Programmiermodell. Beispielsweise sind konstante Werte, Kernelparameter, Threadblockdimensionen über unterschiedliche Threads in einem Threadblock gleich. Der Compiler identifiziert dann intrinsische bedingungsinvariante Variablen (CIO). Im aktuellen Gang-Abbildungsschema sind diese zum Beispiel Threadindexfunktionen/-register (z. B. get_global_id(0) oder threadIdx.x).

Nach Markieren der anfänglichen AIO- und CIO-Informationen generiert der Compiler einen Programmabhängigkeitsgraphen, von dem Abschnitte die Informationen durch Register und Befehle propagieren können. An jedem Befehl/jeder uop wird der Zieloperand einer strengeren Invarianzdefinition als die Quelloperanden zugewiesen; falls die Quelloperanden beispielsweise AIO und CIO sind, wird der Zieloperand als CIO zugewiesen. In einer Ausführungsform wird die Informationsweitergabe auf iterative Weise durchgeführt, bis sich der Typ der Invarianz für jeden Befehl nicht mehr ändert. Nach dieser Phase sind alle statischen Befehle als AIO, CIO oder NIO (keine invariante Operation) klassifiziert.

Wie bereits besprochen können CIOs nur zur Laufzeit zu GIOs werden (z. B. auf Grundlage der Threadblockgröße des Kernels). In einer Ausführungsform, wenn die dynamische GIO-Erkennungsverschaltung 3005 erkennt, dass die Anzahl von Mikrothreads unter einem Schwellenwert liegt, wandelt sie CIOs in GIOs um. In einer Implementierung wandelt die dynamische GIO-Erkennungsverschaltung die CIOs beispielsweise in GIOs um, falls die Anzahl von uthreads in der x-Dimension kleiner als die Größe der Gang-Einheit ist. In einer Ausführungsform, falls keine derartige Auslösebedingung erkannt wird, behandelt die dynamische GIO-Erkennungsverschaltung 3005 CIOs als normale SIMT-Operationen ohne Invarianz. Die genaue Bedingung kann jedoch abhängig von der architekturellen Definition geändert werden.

Übermitteln von GIOs an die Ausführungsverschattung

GIOs können der Ausführungshardware in den Signalleitungen 3030 durch Zuweisen von Befehlspräfixen oder Nutzen von Befehlssteuercodes übermittelt werden. In einer ISA, die Befehlspräfixe aufweist, (z. B. x86) kann zum Beispiel einem Präfix wie OXF1 der Wert eines bedingt invarianten Operationspräfixes zugewiesen werden. Darüber hinaus, falls die identifizierte invariante Operation der Arbeitsspeicheroperand eines x86-ModR/M-Bytes war, kann die invariante Natur des implizierten Ladevorgangs beispielsweise in den reservierten Werten des Segmentregisterfelds (0x6 und 0x7) codiert sein. In einer ISA, die Steuercodes aufweist, können Steuercodefelder verwendet werden, um die gleichen Informationen zu übermitteln.

Minimaler Abschluss von GIOs

Es gibt mehrere Wege zum Implementieren von GIOs in Hardware. In einer Ausführungsform enthält ein Schleifenstromdetektor (LSD) 3008, der mit der IDQ 1305 assoziiert ist, Verschaltung, um eine Gang-Ausführung teilweise im Gleichschritt zu implementieren. Falls ermittelt wird, dass eine oder mehrere Gang-Einheiten die gleichen IPs ausführen, nutzen die Gang-Einheiten Einträge in der IDQ 1305 gemeinsam, die uops für jede Gang-Einheit an das Back-End strömt. In einer Implementierung wechselt die Gangauswahlverschaltung des Front-End 1307 (z. B die Gang-Planungseinheit 1301) zwischen Gang-Einheiten reihum und versucht, uops von jeder Gang-Einheit so zuzuteilen, dass keine Gang-Einheit versucht, über den aktuellen gemeinsam genutzten Gang-Strom zuzuteilen, bevor alle Gang-Einheiten alle uops im Strom zugeteilt haben.

In einer Ausführungsform enthält die Hardwareunterstützung zum Verwalten von Invarianz innerhalb einer Signalleitung und über Gang-Einheiten hinweg eine Registerdateikonstruktion zum Schreiben der Ergebnisse eines Ladevorgangs in die Registerdateien mehrerer Gang-Einheiten. In einer Ausführungsform wird dies durch Platzieren der gleichen Register-ID mehrerer Gang-Einheiten nebeneinander und gleichzeitiges Durchführen eines breiten Schreibvorgangs vom Broadcast-Typ in alle Registerdateien der Gang-Einheiten erzielt.

Wenn eine Gang-invariante Operation von der dynamischen GIO-Erkennungsverschaltung 3005 erkannt wird, markiert sie die uop mit dem invarianten Abschnitt (pdst, load-op oder load-op+pdst). In einer Ausführungsform liest das Front-End 1307 diese uop-Bits und erzwingt, dass andere Gang-Einheiten gewählt werden, wenn die nächste zuzuteilende uop eine invariante op ist. Wenn alle Gang-Einheiten die uops unmittelbar vor der invarianten uop zugeteilt haben, dann teilt das Front-End 1307 die invariante uop zu. Eine gemeinsam genutzte Ausführung einer invarianten uop ist erlaubt, wenn alle Gang-Einheiten die uops unmittelbar vor der invarianten uop zugeteilt haben. Auf diese Weise werden Gefahren verhindert.

In einer Ausführungsform werden Hardwareregisterressourcen Werten dediziert zugewiesen, die von Gang-invarianten Operationen erzeugt wurden. Eine Ausführung einer GIO resultiert in einem Wert, der in diesen dedizierten Zustand geschrieben wird und das Front-End 1307 wird durch einen Broadcast benachrichtigt, dass dieser bestimmte GIO-Wert innerhalb der Maschine gespeichert ist. Jede Planungs- oder Zuteiltungsentscheidung prüft, ob es eine GIO ist, deren Wert erfolgreich von einem anderen Thread innerhalb dieser Signalleitung erzeugt wurde, und die Operation kann vor der Verteilung abgebrochen werden, falls diese Prüfung erfolgreich ist. In einer Ausführungsform werden redundante Operationen durch das Front-End 1307 eliminiert. Eine Tabelle mit IPs kann verwendet werden, um eindeutige GIO-Erzeuger im Back-End der Maschine nachzuverfolgen und das physische Register freizugeben, wenn in keinen Threads innerhalb einer Signalleitung der von der GIO erzeugte Wert sichtbar ist.

Ein Verfahren nach einer Ausführungsform der Erfindung ist in 31 veranschaulicht. Das Verfahren kann auf den verschiedenen Prozessor- und Systemarchitekturen, die oben beschrieben sind, implementiert werden, ist jedoch nicht auf eine bestimmte Architektur beschränkt.

Bei 3101 werden Makrobefehle eines oder mehrerer Threads in Mikrothreads decodiert, die Mikrooperationen umfassen. Bei 3102 werden immer invariante Operationen (AIOs) und bedingt invariante Operationen (CIOs) identifiziert. Beispielsweise kann ein Hinweis des Typs der Operation in jeder uop codiert sein oder anderweitig mit dieser assoziiert sein. Bei 3103 ist jede APO geplant, um ihre Ausführung auf eine Signalleitung oder eine Teilmenge der Signalleitungen einzuschränken.

Bei 3104 erfolgt für jede CIO eine Ermittlung, ob die CIO Gang-invariant ist. Eine Auswertung von aktuellen Variablen kann zum Beispiel durchgeführt werden, um zu ermitteln, ob die CIO im Rahmen des aktuellen Satzes von Bedingungen Gang-invariant ist. Falls nicht, wird die CIO bei 3105 zur Ausführung über Signalleitungen hinweg als eine nicht invariante Operation geplant. Falls ja, wird die CIO bei 3106 zur Ausführung über eine oder mehrere Signalleitungen hinweg als eine Gang-invariante Operation geplant.

VORRICHTUNG UND VERFAHREN FÜR EINEN PARALLELEN COPROZESSOR MIT HOHEM DURCHSATZ UND EINE ZWISCHENVERBINDUNG MIT NIEDRIGER AUSLAGERUNGSLATENZ

Wie oben in Bezug auf 14C erwähnt, kann ein datenparalleles Cluster 1300 an die Kerne 1401a-b einer Zentralverarbeitungseinheit (CPU) in einer Coprozessor-/Beschleuniger-Anordnung gekoppelt sein, über eine zwischenspeicherkohärente Hochgeschwindigkeits-Schnittstelle 1496 (die Begriffe „Coprozessor“ und „Beschleuniger“ werden hierin austauschbar verwendet). Verschiedene kohärente Coprozessor-/Beschleunigerschnittstellen finden heutzutage Verwendung, zum Beispiel NVLink, Open Coherent Accelerator Processor Interface (OpenCAPI), Cache Coherent Interconnect for Accelerators (CCIA) und UltraPath Interconnect. Jede Schnittstelle enthält Mechanismen, um Arbeit an eine Coprozessoreinrichtung zu verteilen, und Techniken, um die Kohärenz der zwischen der CPU und er Coprozessoreinrichtung gemeinsam genutzten Daten zu schützen.

Eine wesentliche Einschränkung beim Auslagern von datenparallelen Problemen von der CPU an Beschleunigereinrichtungen ist die Transferlatenz. Ausführungsformen der Erfindung bieten eine skalierbare Lösung durch Implementieren von heterogener Hardware an zwei unterschiedlichen Optimierungspunkten und transparentes Bewegen der ausgelagerten Ausführung zwischen den zwei verschiedenen Hardwareeinheiten. Während sich die unten beschriebenen Ausführungsformen auf die Wechselwirkung zwischen einem datenparallelen Cluster und einem Hostprozessor konzentrieren, sind die zugrunde liegenden Prinzipien der Erfindung nicht auf einen bestimmten Typ von Beschleunigereinrichtung beschränkt.

Eine Ausführungsform der Erfindung enthält Verschaltung und Logik zum Ausdrücken der datenparallelen Arbeit zwischen Hardwareeinheiten wie einem Hostprozessor und einer Beschleunigereinrichtung. Eine Ausführungsform enthält Befehle zum Auslagern von paralleler Arbeit von einem Prozessor, die die eingesetzten Ausführungsressourcen nicht angeben. Darüber hinaus können spezialisierte Befehle innerhalb der parallelen Ausführungsressourcen verwendet werden, die die Ausführung über eine Vielzahl von Verarbeitungselementen und/oder Signalleitungen verteilen. Ein Softwaremechanismus kann auch zum Ausdrücken von paralleler Arbeit implementiert werden (wie er z. B. in einem Compiler ausgebildet werden kann, der in den parallelen Ausführungsressourcen flexibel ist, die verwendet werden).

32 veranschaulicht eine bestimmte Implementierung, in der eine innerhalb des Hostprozessors oder Kerns 3201 (hierin nachfolgend „Prozessor 3201“) integrierte DPC-Steuerung 3200 die Energie und Besetzungssignale zum Anpassen der Energiezustände von unterschiedlichen Ausführungsressourcen innerhalb des DPC 1300 verwaltet (wobei z. B. ermittelt wird, welche Ausführungsressourcen aktiv zu halten sind). In der veranschaulichten Ausführungsform verbindet ein Host-/DPC-Kommunikationskanal 1350 den Prozessor 3201 mit dem DPC 1300. Darüber hinaus veranschaulicht 32 eine Ausführungsform, in der sowohl der Prozessor 3201 als auch der DPC 1300 unabhängige Arbeitsspeichersteuerungen, 3205 bzw. 3210, enthalten, um jede Einrichtung an den Systemarbeitsspeicher 1460 zu koppeln.

In einer Ausführungsform passt die DPC-Steuerung 3200 die Anzahl von gleichzeitigen Ausführungsressourcen für eine parallele Aufgabe, die vom Prozessor 3201 an die Ausführungssignalleitungen 3030 des DPC 1300 ausgelagert wurden, auf Grundlage von verschiedenen Variablen und Komponenten an. Die DPC-Steuerung 3200 kann zum Beispiel den effizientesten Plan für parallele Aufgaben am DPC 1300 auf Grundlage von Signalen ermitteln, die die von verteilter paralleler Arbeit verbrauchte Energie und die Breite von noch zu verteilender paralleler Arbeit anzeigen, für jede Signalleitung 3030. Sie wertet diese Signale aus, um zu ermitteln, ob eine weitere Ausführung von paralleler Arbeit in einer oder mehreren Ausführungseinheiten innerhalb einer oder mehrerer Signalleitungen 3030 anzuhalten ist und/oder Arbeit zu einer oder mehreren unterschiedlichen Ausführungseinheiten oder Signalleitungen 3030 zu migrieren ist. Beispielsweise kann die DPC-Steuerung 3200 in den hierin beschriebenen spezifischen Architekturen Arbeit von einer oder mehreren ALUs 1350 und/oder TALUs 1340 an verschiedene ALUs/TALUs neu zuteilen, möglicherweise in einer anderen Signalleitung 1310, auf Grundlage der aktuellen/erwarteten Verarbeitungsanforderungen und des Gesamtenergiebudgets des Systems.

Die Beschleunigereinrichtung kann eine oder mehrere parallele Hardwareeinheiten enthalten, die für unterschiedliche Designpunkte optimiert sind. Die Designpunkte können Frequenz, Energieeffizienz, die Gesamtmenge an Ausführungszuständen, verfügbare Arbeitsspeicherbusbandbreite und verfügbare mikroarchitekturelle Ressourcen, wie die ALUs 1350 und die TALUs 1340, enthalten.

In einer Ausführungsform führt der Hostprozessor 3201 eine Anwendung aus, die parallelen Programmcode 3271 enthält. Wenn die Anwendung 3270 gestartet wird, führt die Befehlsverarbeitungspipeline des Prozessors 3201 den primären Anwendungsthread aus. Insbesondere werden Befehle des Threads von der Arbeitsspeichersteuerung 3205 zum I-Zwischenspeicher 1410 und/oder zur Abrufeinheit 1418 weitergeleitet, vom Decodierer 1409 decodiert und von der Ausführungsverschaltung 1408 ausgeführt. Der Decodierer 1409 und/oder die Ausführungsverschaltung 1408 erkennt, wenn eine Sequenz von Befehlen im primären Thread konstruiert ist, um auf dem DPC 1300 ausgeführt zu werden, der Decodierer 1409 und/oder die Ausführungsverschaltung 1408 leitet diese Befehle an die DPC-Steuerung 3200 weiter, die eine Ausführung auf den DPC-Signalleitungen 3030 initiiert.

Die DPC-Steuerung 3200 kann anfänglich das DPC-Cluster 1300 durch Übermitteln von Anfangswerten wie der Threadkontextkennung, der Anzahl von aktiven Threads und der Anzahl von Schleifeniterationen an die Signalleitungen 3030 des DPC 1300 konfigurieren, entweder direkt oder über das DPC-FE 1307. In einer Ausführungsform leitet die DPC-Steuerung 3200 einen Befehlszeiger über den Host-/DPC-Kanal 1350 an den Parallelprogrammcode 3271 weiter. Das DPC-FE 1307 beginnt, Befehle von diesem Befehlszeiger abzurufen und die Befehle zur parallelen Ausführung über die Signalleitungen 3030 hinweg zu planen. In dieser Ausführungsform werden die Befehle des Parallelprogrammcodes 3271 von der Abrufs-/Decodierverschaltung 3202 innerhalb des DPC-FE 1307 abgerufen und decodiert. In anderen Ausführungsformen wird der Parallelprogrammcode 3271 jedoch vom Hostprozessor 3201 decodiert und im Arbeitsspeicher 1460 gespeichert oder über den Host-/DPC-Kanal 1350 gesendet. Ergebnisse 3272 der parallelen Ausführung in den Signalleitungen werden zurück in einen designierten Bereich im Arbeitsspeicher 3272 gespeichert, auf den der Prozessor 3201 zugreifen kann (z. B., sodass der primäre Thread und/oder andere Threads auf die Daten zugreifen können).

In einer Ausführungsform führt der Hostprozessor 3201 andere Operationen durch, um den DPC 1300 zu unterstützen, wie Zuteilen von arbeitsspeicherinternen Stapeln für die Mikrothreads/uops und Pushen des Zeigers auf die Basis des Stapels bzw. der Stapel und die Stapelgröße an den DPC 1300. Diese Stapel können dann von den Signalleitungen 3030 beim Ausführen der Mikrothreads verwendet werden. Darüber hinaus kann der Hostprozessor 3201 arbeitsspeicherinternen Speicher lokal zum Thread für bestimmte Programmiermodelle zuteilen.

In einer Ausführungsform, falls der Hostprozessor 3201 erkennt, dass das Ausführungsregime nicht für die aktuell ausgeführten Ausführungsressourcen der Signalleitungen geeignet ist, kann er einen Transfer des aktuellen Parallelprogrammcodes 3271 an eine andere Einheit (z. B. eine andere ALU/TALU und/oder eine andere Signalleitung) implementieren.

Ein Verfahren nach einer Ausführungsform der Erfindung ist in 33 veranschaulicht. Das Verfahren kann auf der oben beschriebenen Systemarchitektur implementiert werden, ist jedoch nicht auf eine bestimmte Prozessor- oder Systemarchitektur beschränkt.

Bei 3301 werden Anfangswerte via Push in den Parallelausführungsbeschleuniger bewegt. Wie erwähnt, kann dies die Threadkontextkennung (um z. B. die Anwendung 3270, die die Operationen initiiert, zu identifizieren), die Anzahl der aktiven Threads und die Anzahl der Schleifeniterationen enthalten. Bei 3302 wird ein Befehlszeiger zu den parallelen Ausführungsressourcen gepusht, der eine Stelle im Arbeitsspeicher identifiziert, von der die Mikrothreads auszuführen sind. In einer Ausführungsform wird dieser Bereich von Programmcode anfänglich im Arbeitsspeicher vom Hostprozessor eingerichtet, um den Zeiger zu generieren; der Hostprozessor stellt dann den Zeiger den parallelen Ausführungsressourcen zur Verfügung.

Bei 3303 werden arbeitsspeicherinterne Stapel den verschiedenen Mikrothreads zugeteilt und die Basiszeiger der verschiedenen Stapel und die Größe jedes Stapels werden an die verschiedenen Mikrothreads gepusht, wodurch den Ausführungsressourcen Einsicht in die Ausführungsstapel zum Ausführen der Mikrothreads gegeben wird. Bei 3304 wird arbeitsspeicherinterner, zum Thread lokaler Speicher zugeteilt (abhängig vom bestimmten Programmiermodell, das verwendet wird).

Bei 3305 werden die Mikrothreads auf den parallelen Ausführungsressourcen ausgeführt und die Ergebnisse gespeichert. Abhängig von der Implementierung können die parallelen Ausführungsressourcen die parallele Arbeit in Übereinstimmung mit dem von den Befehlen definierten architekturellen Schema zum Ausdrücken einer parallelen Ausführung einer Schleife segmentieren. Darüber hinaus überwacht der Hostprozessor oder Verschaltung der parallelen Ausführungsressourcen bei 3305 mit der Leitung und/oder Energienutzung der parallelen Ausführungsressourcen verbundene Variablen. Zum Beispiel können die pro Zeiteinheit verbrauchte Durchschnittsenergie, Befehlsausführungseffizienz, Arbeitslast an den parallelen Ausführungsressourcen und/oder Temperaturmesswerte gesammelt werden.

Bei 3106 werden die Leistungs-/Energievariablen ausgewertet, um zu ermitteln, ob die Mikrothreads über die Verarbeitungsressourcen auf effizientere Weise neu zugeteilt werden sollen. Falls beispielsweise das Energiebudget des Systems überschritten wird, dann können die Verarbeitungsressourcen neu zugeteilt werden, um den Energieverbrauch zu reduzieren. Falls umgekehrt eine bestimmte Leistungsmetrik nicht erfüllt wird, dann können die Verarbeitungsressourcen zugeteilt werden, um die Leistung zu erhöhen. Unterschiedliche Energie-/Leistungsrichtlinien können für unterschiedliche Systeme implementiert werden. Falls eine Neuzuteilungsentscheidung getroffen wird, dann werden ein oder mehrere Mikrothreads unterschiedlichen Ausführungsressourcen bei 3107 neu zugeteilt.

In einer Ausführungsform, falls ermittelt wird, dass das Ausführungsregime der aktuell aktiven parallelen Prozedur auf unterschiedlichen Ressourcen besser ausgeführt würde, kann die Steuerung den aktiven parallelen Ausführungsressourcen signalisieren, dass die Anzahl von aktiven Threads anders ist und/oder kann signalisieren, dass die nächsten Threadkontexte null sind (um z. B. zu bewirken, dass die aktiven parallelen Ausführungsressourcen die Ausführung beenden). Auf jeden Fall kann der Code, der auf den aktiven Ausführungsressourcen ausgeführt wird, eine Anzahl von Schleifeniterationen an definierten architekturellen Punkten beenden, die vom Compiler spezifiziert werden (z. B. in den Kontrollflussgraphen eingefügt werden). Deshalb müssen Threadkontexte nicht von einer großen Sammlung von parallelen Ausführungsressourcen gespeichert und möglicherweise unter hohen Kosten an eine andere chipinterne oder -externe Stelle gesendet werden. Nur eine kleine Anzahl von Zuständen wird gesendet, was die Übergangslatenz niedrig hält.

Eine Ausführungsform der Erfindung enthält einen Satz von Befehlen, um auf parallele Verarbeitungsressourcen zuzugreifen und diese zu verarbeiten. Tabelle A unten gibt einen bestimmten Satz von Befehlen an und enthält einen Hinweis darauf, ob die Befehle auf dem Hostprozessor oder auf der parallelen Verarbeitungseinrichtung auszuführen sind. Tabelle A

Befehle zum Verwalten von heterogener paralleler Aufgabenauslagerung	Im Host gültig	In der Einrichtung gültig
Parallelprozeduraufruf (PCALL) - Ausführung der parallelen Prozedur an der Arbeitsspeicherstelle mit der angegebenen Anzahl von Iterationen. Ergebnisse werden im Arbeitsspeicher gespeichert, möglicherweise an einer von einer Steuerstruktur angegebenen Position.	Wahr	Wahr
Parallelprozedurrückkehr (PRET) - Beenden der Ausführung einer parallelen Prozedur. Ein Signal kann an die Steuereinheit gesendet werden, um anzuzeigen, dass diese Ressource verfüqbar ist.	Falsch	Wahr
Paralleler Prozedur-Threadkontext (TCONTEXT) - Gibt eine Kennung zurück, die ein eindeutiges Segment der Schleifeniterationen der aktuellen parallelen Prozedur bereitstellt.	Falsch	Wahr
Anzahl der aktiven Threads (TOCCUPANCY) - Gibt eine vorzeichenlose ganze Zahl zurück, die die Anzahl von gleichzeitig ausgeführten Ressourcen angibt. Wird verwendet, um den nächsten Querschnitt in die Schleifeniterationen des parallelen Prozeduraufrufs zu berechnen.	Falsch	Wahr
Nächster Threadkontext (INCCONTEXT) - Gibt eine Kennung zurück, die den nächsten eindeutigen Querschnitt in die Schleifeniterationen der aktuellen parallelen Prozedur bereitstellt. Kann eine Null-Kennung zurückgeben.	Falsch	Wahr
Alle dieser Befehle können auf die Tiefe der verschachtelten parallelen Prozeduraufrufe Bezug nehmen, um einen eindeutigen Querschnitt in jeder Phase des parallelen Prozeduraufrufs zu erhalten.

In dieser Ausführungsform führt der Hostprozessor den PCALL-Befehl aus, um einen parallelen Prozeduraufruf auf den parallelen Ausführungsressourcen zu initiieren. Der parallele Prozeduraufruf identifiziert eine Arbeitsspeicherposition/einen Arbeitsspeicherzeiger, von der bzw. dem die parallelen Ausführungsressourcen den parallelen Programmcode auszuführen haben, sowie eine Anzahl von durchzuführenden Iterationen. Ergebnisse werden im Arbeitsspeicher gespeichert, möglicherweise an einer von einer Steuerstruktur angegebenen Position. In der in 32 gezeigten Ausführungsform wird der Arbeitsspeicherzeiger auf den parallelen Programmcode 3271 beispielsweise über den Host-/DPC-Kanal 1350 gesendet und die Ergebnisse 3272 werden an einer vom Hostprozessor 3201 angegebenen Arbeitsspeicherposition gespeichert (z. B. an einem Arbeitsspeicherbereich, der dem DPC 1300 vom Hostprozessor 3201 oder dem Arbeitsspeicher-Subsystem zugewiesen ist).

Die restlichen in Tabelle A aufgeführten Befehle werden von den parallelen Ausführungsressourcen ausgeführt. Insbesondere können die parallelen Ausführungsressourcen, wenn die Ausführung abgeschlossen ist und Ergebnisse generiert sind, einen parallelen Prozedurrückgabebefehl (PRET-Befehl) ausführen, der der Steuerung signalisiert, dass die Verarbeitung abgeschlossen ist (und dass diese Ausführungsressource deshalb verfügbar ist).

Der parallele Prozedur-Threadkontextbefehl (TCONTEXT) gibt eine Kennung zurück, die ein eindeutiges Segment der Schleifeniterationen der aktuellen parallelen Prozedur bereitstellt. Zum Beispiel kann TCONTEXT das Ausmaß an Arbeit anzeigen, das von den parallelen Ausführungsressourcen durchgeführt wird.

Der Befehl für die Anzahl der aktiven Threads (TOCCUPANCY) gibt einen Wert zurück, der die Anzahl von gleichzeitig ausgeführten Ressourcen anzeigt, und kann verwendet werden (z. B. vom Hostprozessor 3201), um den nächsten Querschnitt in die Schleifeniterationen des parallelen Prozeduraufrufs zu berechnen.

Der nächste Threadkontext-Befehl (INCCONTEXT) gibt eine Kennung zurück, die den nächsten eindeutigen Querschnitt in die Schleifeniterationen der aktuellen parallelen Prozedur bereitstellt. In einer Ausführungsform kann er eine Null-Kennung zurückgeben.

In einer Ausführungsform enthält der parallele Programmcode 3721 einen allgemeinen Turing-vollständigen Rechenbefehlssatz, der mit den oben hervorgehobenen Befehlen erweitert ist. Die Iterationen einer Schleife ohne Abhängigkeiten zwischen Schleifeniterationen können durch eine von Gleichzeitigkeit unabhängige Maschinenrepräsentation ausgedrückt werden, die direkt auf einer kompatiblen parallelen Beschleunigereinrichtung ohne irgendwelche Zwischenschritte ausgeführt werden kann. Der Zustand eines bestimmten Hardwarekontextes wird durch den Zustand der parallelen Ausführungsressourcen impliziert, die von der Steuerung (z. B. der DPC-Steuerung 3200) eingerichtet wurden, anstatt ausdrücklich statisch in der Auslagerungsbefehlsspezifikation definiert zu sein.

In einer Ausführungsform empfangen die parallelen Ausführungsressourcen beim Ausführen des vom Parallelprozeduraufruf identifizierten Programmcodes Werte, die sich aus den Befehlen in Tabelle A ergeben, und verwenden sie, um unterschiedliche Schleifeniterationen auf Ausführungsressourcen in Übereinstimmung mit dem in 34 genau beschriebenen Schema abzubilden. In Bezug auf die DPC-Ausführung werden die DPC-Steuerung 3200, der Parallelprogrammcode 3271 und die oben aufgelisteten Befehle beispielsweise kombiniert, um zu ermitteln, welche Schleifeniteration aktuell von jedem Hardwarekontext innerhalb der DPC-Signalleitungen 3030 ausgeführt wird.

In 34 führt ein übergeordneter Thread 3401 (der z. B. auf dem Hostprozessor ausgeführt wird) einen Parallelprozeduraufruf (PCALL) aus, der einen bestimmten Satz von auszuführenden Schleifeniterationen 3400 identifiziert. Als Reaktion auf den PCALL-Befehl werden die Schleifeniterationen 3400 über zwei unterschiedliche parallele Ausführungsressourcen 3407 geplant und ausgeführt (wie z. B. die oben besprochenen Signalleitungen). Wenn die Ausführung abgeschlossen ist, führt jeder parallele Ausführungsthread (der oben manchmal als ein Mikrothread bezeichnet wird) einen Parallelprozedurrückkehrbefehl aus, um den übergeordneten Thread 3401 zu benachrichtigen, dass die Ausführung abgeschlossen ist.

Ein weiteres Beispiel, wie Befehle dynamisch auf verfügbare Ausführungsressourcen abgebildet werden können, ist in 35 vorgesehen. Dieses Beispiel beruht auf der oben beschriebenen DPC-Architektur. Man betrachte eine Kopierschleife, die versucht, einen Puffer aus N Elementen von einer Arbeitsspeicheradresse x an eine Arbeitsspeicheradresse y zu bewegen.

for(int i=0; i<n; i++) { 

            y[i] = x[i];
      }

In diesem Beispiel bestehen die verfügbaren parallelen Ausführungsressourcen aus zwei Signalleitungen aus jeweils einem Hardwarekontext, für insgesamt zwei aktive Threads im DPC 1300.

Die von jedem Thread ausgeführte parallele Prozedur ist identisch. Der Threadkontextbefehl stellt einen Offset in das Eingabearray bereit, der von den anderen Iterationen der Schleife unabhängig ist. Danach stellt der nächste Threadkontextbefehl eine schrittweise Erhöhung der Induktionsvariable i der Schleife bereit. Der Compiler fügt einen Vergleich ein, um sicherzustellen, dass die rückgegebene Kennung nicht null ist und die Ausführung nicht beendet wurde. Der aktive Thread führt dann einen anderen Schleifenkontext aus. Jeder Thread ist für das Abrufen aller erforderlichen Zustände verantwortlich, wie Adressen für Eingabe und Ausgabe. Dies soll die beim Verteilen von neuer paralleler Arbeit an Ausführungsressourcen transferierte Datenmenge reduzieren.

Der nächste Threadkontext hängt vom aktuellen Threadkontext, den insgesamt aktiven Threads und der Anzahl der Schleifeniterationen ab. Da sich die Anzahl der aktiven Threads aufgrund der von der Hardwaresteuereinheit getroffenen Entscheidungen darüber ändert, welche parallelen Ausführungsressourcen an diesem Parallelprozeduraufruf teilnehmen. Diese Informationen, wie sie durch die neuen Befehle ausgedrückt werden, reichen aus, um eine Iteration eines Hardwarekontexts innerhalb der größeren Sammlung von aktiven parallelen Ausführungsressourcen für diese Schleife aufzufinden.

Ausführungsformen der Erfindung können Gleichzeitigkeitsanforderungen codieren, zum Beispiel durch ein Steuerregister, das anzeigt, wie viele Threads verfügbar sind, um gleichzeitig ausgeführt zu werden, um eine Synchronisierung zwischen Schleifeniterationen zu unterstützen, um Abhängigkeiten wie Vergleich-und-Austausch oder eine Barriere zu auszudrücken. Optional kann eine Implementierung einen Kontextwechsel durchführen, um eine Synchronisierung zwischen Schleifeniterationen zu unterstützen, von denen erwartet wird, dass sie gleichzeitig ausgeführt werden, aber auf weniger Hardwarekontexte abgebildet sind. Oder stattdessen könnte eine Implementierung den Parallelprozeduraufruf mit einem Befehl machen, der aufgrund unzureichender verfügbarer Ausführungsressourcen fehlschlägt, und erfordern, dass der Hostthread alternative Codepfade mit weniger für eine gleichzeitige Operation erforderlichen Threads verwendet.

In der vorstehenden Beschreibung wurden die Ausführungsformen der Erfindung unter Bezugnahme auf bestimmte Ausführungsbeispiele davon beschrieben. Es ist jedoch offensichtlich, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom allgemeinen Gedanken und Umfang der Erfindung abzuweichen, wie in den beigefügten Ansprüchen dargelegt. Die Beschreibung und die Zeichnungen sind entsprechend als veranschaulichend und nicht als einschränkend zu betrachten.

Komponenten, Merkmale und Details, die für beliebige der Vorrichtungen beschrieben wurden, können optional auch für beliebige der Verfahren gelten, die in Ausführungsformen von und/oder mit einer solchen Vorrichtung durchgeführt werden können. Alle der hierin beschriebenen Prozessoren können in beliebigen der hierin offenbarten Systeme enthalten sein. In einigen Ausführungsformen kann das Computersystem eine Zwischenverbindung, einen an die Zwischenverbindung gekoppelten Prozessor und einen an die Zwischenverbindung gekoppelten dynamischen Arbeitsspeicher mit wahlfreiem Zugriff (DRAM) enthalten. Alternativ können anstatt des DRAM andere Arten von flüchtigem Arbeitsspeicher, die nicht aufgefrischt werden müssen, oder Flashspeicher verwendet werden.

In der Beschreibung und den Ansprüchen können die Begriffe „gekoppelt“ und/oder „verbunden“ zusammen mit ihren Absignalleitungen verwendet worden sein. Diese Begriffe sind nicht als Synonyme füreinander gedacht. Vielmehr kann in Ausführungsformen „verbunden“ verwendet werden, um anzuzeigen, dass zwei oder mehr Elemente in direktem physischem und/oder elektrischem Kontakt miteinander sind. Der Ausdruck „gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physischem und/oder elektrischem Kontakt miteinander sind. Der Ausdruck „gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander stehen, aber dennoch miteinander zusammenarbeiten oder wechselwirken. Eine Ausführungseinheit kann zum Beispiel über eine oder mehrere dazwischenliegende Komponenten an ein Register und/oder eine Decodiereinheit gekoppelt sein. In den Figuren werden Pfeile verwendet, um Verbindungen und Kopplungen zu zeigen.

Der Begriff „und/oder“ kann verwendet worden sein. Wie hierin verwendet, bedeutet der Begriff „und/oder“ eines oder das andere oder beides (z. B. bedeutet A und/oder B A oder B oder sowohl A als auch B).

In der obigen Beschreibung wurden spezifische Details dargelegt, um ein gründliches Verständnis der Ausführungsformen zu ermöglichen. Andere Ausführungsformen können jedoch ohne einige dieser spezifischen Details umgesetzt werden. Der Umfang der Erfindung ist nicht durch die oben bereitgestellten spezifischen Beispiele zu ermitteln, sondern nur durch die Ansprüche unten. In anderen Fällen wurden gut bekannte Schaltkreise, Strukturen, Einrichtungen und Operationen in Blockdiagrammform und/oder ohne Detail gezeigt, um ein Verschleiern des Verständnisses der Beschreibung zu vermeiden. Wo dies als angemessen erachtet wird, wurden Bezugszeichen oder abschließende Abschnitte von Bezugszeichen in den Figuren wiederholt, um entsprechende oder analoge Elemente anzuzeigen, die gegebenenfalls ähnliche oder gleiche Merkmale aufweisen können, sofern nichts anderes angegeben oder klar ersichtlich ist.

Bestimmte Operationen können von Hardwarekomponenten ausgeführt werden oder können in maschinenausführbaren oder schaltkreisausführbaren Anweisungen ausgebildet sein, die verwendet werden können, um eine Maschine, einen Schaltkreis oder eine Hardwarekomponente (z. B. einen Prozessor, einen Abschnitt eines Prozessors, einen Schaltkreis usw.), die bzw. der mit den Befehlen programmiert ist, zu veranlassen, die Operationen durchzuführen, und/oder darin resultieren, dass diese bzw. dieser die Operationen durchführt. Die Operationen können optional auch durch eine Kombination von Hardware und Software durchgeführt werden. Ein Prozessor, eine Maschine, ein Schaltkreis oder Hardware kann bestimmte oder spezifische Verschaltung oder andere Logik (z. B. Hardware, die möglicherweise mit Firmware und/oder Software kombiniert ist) enthalten, die betreibbar ist, um den Befehl auszuführen und/oder zu verarbeiten und ein Ergebnis als Reaktion auf den Befehl zu speichern.

Einige Ausführungsformen enthalten einen Herstellungsgegenstand (z. B. ein Computerprogrammprodukt), der ein maschinenlesbares Medium enthält. Das Medium kann einen Mechanismus enthalten, der Informationen in einer Form, die von der Maschine lesbar ist, bereitstellt, zum Beispiel speichert. Das maschinenlesbare Medium kann einen Befehl oder eine Befehlssequenz bereitstellen oder darauf gespeichert aufweisen, der bzw. die bei Ausführung durch eine Maschine wirksam ist, um die Maschine zu veranlassen, eine oder hierin offenbarte Operationen, Verfahren oder Techniken durchzuführen, und/oder darin resultieren, dass die Maschine diese durchführt.

In einigen Beispielen kann das maschinenlesbare Medium ein nicht transitorisches maschinenlesbares Speichermedium enthalten. Beispielsweise kann das nicht transitorische maschinenlesbare Speichermedium eine Floppy-Diskette, ein optisches Speichermedium, eine optische Platte, eine optische Datenspeichereinrichtung, eine CD-ROM, eine Magnetplatte, eine magneto-optische Platte, einen schreibgeschützten Arbeitsspeicher (ROM), einen programmierbaren ROM (PROM), einen löschbaren und programmierbaren ROM (EPROM), einen elektrisch löschbaren und programmierbaren ROM (EEPROM), einen Arbeitsspeicher mit wahlfreiem Zugriff (RAM), einen statischen RAM (SRAM), einen dynamischen RAM (DRAM), einen Flashspeicher, einen Phasenwechselspeicher, ein Phasenwechsel-Datenspeichermaterial, einen nichtflüchtigen Arbeitsspeicher, eine nichtflüchtige Datenspeichereinrichtung, einen nicht transitorischen Arbeitsspeicher, eine nicht transitorische Datenspeichereinrichtung oder dergleichen enthalten. Das nicht transitorische maschinenlesbare Speichermedium besteht nicht aus einem transitorischen propagierten Signal. In einigen Ausführungsformen kann das Speichermedium ein greifbares Medium enthalten, das einen Festkörper enthält.

Beispiele von geeigneten Maschinen enthalten unter anderem einen Universalprozessor, einen Spezialprozessor, einen digitalen Logikschaltkreis, einen integrierten Schaltkreis oder dergleichen. Noch andere Beispiele geeigneter Maschinen enthalten ein Computersystem oder eine andere elektronische Einrichtung, die einen Prozessor, einen digitalen Logikschaltkreis oder einen integrierten Schaltkreis enthält. Beispiele derartiger Computersysteme oder elektronischer Einrichtungen enthalten unter anderem Desktop-Computer, Laptop-Computer, Notebook-Computer, Tablet-Computer, Netbooks, Smartphones, Mobiltelefone, Server, Netzwerkeinrichtungen (z. B. Router und Switches), mobile Interneteinrichtungen (MIDs), Medienabspieleinrichtungen, Smart-Fernseher, Nettops, Set-Top-Boxen und Videospielsteuerungen.

Eine Bezugnahme in dieser Beschreibung auf „eine einzige Ausführungsform“, „eine Ausführungsform“, „eine oder mehrere Ausführungsformen“, „einige Ausführungsformen“ gibt beispielsweise an, dass ein bestimmtes Merkmal in die Umsetzung der Erfindung einbezogen werden kann, dies jedoch nicht unbedingt erforderlich ist. Gleichermaßen werden in der Beschreibung verschiedene Merkmale manchmal in einer einzigen Ausführungsform, Figur oder Beschreibung derselben zusammengefasst, um die Offenbarung zu rationalisieren und das Verständnis verschiedener erfinderischer Gesichtspunkte zu unterstützen. Dieses Verfahren der Offenbarung ist jedoch nicht so auszulegen, dass sie eine Absicht widerspiegelt, dass die Erfindung mehr Merkmale erfordert, als in jedem Anspruch ausdrücklich wiedergegeben werden. Vielmehr liegen erfinderische Gesichtspunkte, wie die folgenden Ansprüche widerspiegeln, in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform. Deshalb sind die der ausführlichen Beschreibung folgenden Ansprüche hiermit ausdrücklich in diese ausführliche Beschreibung aufgenommen, wobei jeder Anspruch eigenständig als eine separate Ausführungsform der Erfindung steht.

BEISPIELE

Es folgen beispielhafte Implementierungen verschiedener Ausführungsformen der Erfindung.

Beispiel 1. Ein Prozessor, umfassend:

Befehlsabrufverschaltung zum Abrufen von Befehlen eines oder mehrerer primärer Threads; einen Decoder zum Decodieren der Befehle zum Erzeugen von uops; einen datenparallelen Cluster (DPC) zum Ausführen von Mikrothreads, die eine Teilmenge der uops umfassen, wobei der DPC ferner umfasst: eine Vielzahl von Ausführungssignalleitungen zum Durchführen einer parallelen Ausführung der Mikrothreads; eine Befehlsdecodierwarteschleife (IDQ) zum Speichern der uops vor der Ausführung; und eine Planungseinheit zum Auswerten der Mikrothreads auf Grundlage von assoziierten Variablen, die Befehlszeiger(IP)-Werte enthalten, wobei die Planungseinheit Mikrothreads auf Grundlage der Auswertung in Fragmente zur parallelen Ausführung in den Ausführungssignalleitungen zusammenzufassen hat.

Beispiel 2. Der Prozessor von Beispiel 1, wobei die Planungseinheit die Mikrothreads auf Grundlage von IP-Werten in Fragmente zusammenzufassen hat, um eine Mikrothread-Konvergenz herbeizuführen.

Beispiel 3. Der Prozessor von Beispiel 1, wobei ein Fragment eine Sammlung von zugehörigen Mikrothreads umfasst.

Beispiel 4. Der Prozessor von Beispiel 2, der ferner umfasst: Rekonvergenzverschaltung, die von der Planungseinheit zu verwenden ist, um eine Reihenfolge zu ermitteln, in der die Fragmente auszuführen sind, wobei die Rekonvergenzverschaltung eine Datenstruktur zum Speichern von zu jedem Fragment zugehörigen Variablen umfasst.

Beispiel 5. Der Prozessor von Beispiel 4, wobei die Rekonvergenzverschaltung ausgelegt ist, ein Signal zu erzeugen, um ein nächstes, auszuführendes Fragment auf Grundlage eines Vergleichs der Variablen aller Fragmente zu identifizieren.

Beispiel 6. Der Prozessor von Beispiel 5, wobei der Vergleich einen Vergleich der IP-Werte der Fragmente umfasst und wobei das Fragment mit einem minimalen IP-Wert zur Ausführung durch Ausführungssignalleitungen auszuwählen ist.

Beispiel 7. Der Prozessor von Beispiel 1, wobei der DPC ferner umfasst: Maskenspeicher, um eine Ausführungsmaske mit mindestens einem Wert zu speichern, der mit jeder parallelen Ausführungssignalleitung assoziiert ist.

Beispiel 8. Der Prozessor von Beispiel 7, wobei der DPC Ausführungssignalleitungen zum Ausführen jedes Fragments oder Mikrothreads auf Grundlage der mit den Signalleitungen assoziierten Werte zu aktivieren oder zu deaktivieren hat.

Beispiel 9. Der Prozessor von Beispiel 8, wobei die Ausführungsmaske dynamisch für jedes Fragment oder jeden Mikrothread zu aktualisieren ist, wodurch eine Anzahl von Signalleitungen aktiviert wird, die erforderlich sind, um das Fragment oder den Mikrothread auszuführen.

Beispiel 10. Der Prozessor von Beispiel 1, wobei der DPC ferner umfasst: einen Datenzwischenspeicher, um Daten zu speichern, die zu verwenden sind, um die Fragmente auszuführen; einen Übersetzungspuffer (TLB), um Adressenübersetzungen von virtuellen auf physische Adressen zum Zugriff auf Systemarbeitsspeicher zu speichern.

Beispiel 11. Der Prozessor von Beispiel 1, wobei jede Signalleitung des DPC ferner umfasst: eine Registerdatei, um Daten zu speichern, die mit einem Fragment assoziiert sind, das ausgeführt wird; eine Tensor-Arithmetik-Logik-Einheit (TALU), um Tensordaten zu verarbeiten, die mit einem Fragment assoziiert sind, das ausgeführt wird; und eine Adressengenerierungseinheit, um Adressen zu generieren, die erforderlich sind, um jedes Fragment auszuführen.

Beispiel 12. Ein Verfahren, umfassend: Abrufen von Befehlen eines oder mehrerer primärer Threads; Decodieren der Befehle zum Erzeugen von uops; Identifizieren von Mikrothreads, die eine Teilmenge der uops umfassen; Auswerten der Mikrothreads auf Grundlage von assoziierten Variablen, die Befehlszeiger(IP)-Werte enthalten; und Zusammenfassen der Mikrothreads in Fragmente zur parallelen Ausführung auf einer Vielzahl von parallelen Ausführungssignalleitungen auf Grundlage der Auswertung.

Beispiel 13. Das Verfahren von Beispiel 12, wobei die Mikrothreads auf Grundlage der IP-Werte in Fragmente zusammengefasst werden, um eine Mikrothread-Konvergenz herbeizuführen.

Beispiel 14. Das Verfahren von Beispiel 12, wobei ein Fragment eine Sammlung von zugehörigen Mikrothreads umfasst.

Beispiel 15.Das Verfahren nach Beispiel 13, ferner umfassend: Ermitteln einer Reihenfolge, in der die Fragmente auszuführen sind, unter Verwendung einer Datenstruktur, die zu jedem Fragment gehörige Variablen speichert.

Beispiel 16. Das Verfahren von Beispiel 15, ferner umfassend: Erzeugen eines Signals, um ein nächstes, auszuführendes Fragment auf Grundlage eines Vergleichs der Variablen aller Fragmente zu identifizieren.

Beispiel 17. Das Verfahren von Beispiel 16, wobei der Vergleich einen Vergleich der IP-Werte der Fragmente umfasst und wobei das Fragment mit einem minimalen IP-Wert zur Ausführung auf den parallelen Ausführungssignalleitungen auszuwählen ist.

Beispiel 18. Das Verfahren von Beispiel 12, ferner umfassend:

Speichern einer Ausführungsmaske mit mindestens einem Wert, der mit jeder der parallelen Ausführungssignalleitungen assoziiert ist.

Beispiel 19. Das Verfahren von Beispiel 18, ferner umfassend: Aktivieren oder Deaktivieren von Ausführungssignalleitungen zum Ausführen jedes Fragments oder Mikrothreads auf Grundlage der mit den Signalleitungen assoziierten Werte.

Beispiel 20. Das Verfahren von Beispiel 19, ferner umfassend: dynamisches Aktualisieren der Ausführungsmaske für jedes Fragment oder jeden Mikrothread, wodurch eine bestimmte Anzahl von Signalleitungen aktiviert wird, die erforderlich sind, um das Fragment oder den Mikrothread auszuführen.

Beispiel 21. Ein maschinenlesbares Medium mit darauf gespeichertem Programmcode, der beim Ausführen durch eine Maschine bewirkt, dass die Maschine die folgenden Operationen durchführt: Abrufen von Befehlen eines oder mehrerer primärer Threads; Decodieren der Befehle zum Erzeugen von uops; Identifizieren von Mikrothreads, die eine Teilmenge der uops umfassen; Auswerten der Mikrothreads auf Grundlage von assoziierten Variablen, die Befehlszeiger(IP)-Werte enthalten; und Zusammenfassen der Mikrothreads in Fragmente zur parallelen Ausführung auf einer Vielzahl von parallelen Ausführungssignalleitungen auf Grundlage der Auswertung.

Beispiel 22. Das maschinenlesbare Medium von Beispiel 21, wobei die Mikrothreads auf Grundlage der IP-Werte in Fragmente zusammengefasst werden, um eine Mikrothread-Konvergenz herbeizuführen.

Beispiel 23. Das maschinenlesbare Medium von Beispiel 21, wobei ein Fragment eine Sammlung von zugehörigen Mikrothreads umfasst.

Beispiel 24. Das maschinenlesbare Medium von Beispiel 22, das ferner Programmcode umfasst, um zu bewirken, dass die Maschine den Vorgang durchführt zum: Ermitteln einer Reihenfolge, in der die Fragmente auszuführen sind, unter Verwendung einer Datenstruktur, die zu jedem Fragment gehörige Variablen speichert.

Beispiel 25. Das maschinenlesbare Medium von Beispiel 24, das ferner Programmcode umfasst, um zu bewirken, dass die Maschine den Vorgang durchführt zum: Erzeugen eines Signals, um ein nächstes, auszuführendes Fragment auf Grundlage eines Vergleichs der Variablen aller Fragmente zu identifizieren.

Beispiel 26. Das maschinenlesbare Medium von Beispiel 25, wobei der Vergleich einen Vergleich der IP-Werte der Fragmente umfasst und wobei das Fragment mit einem minimalen IP-Wert zur Ausführung auf den parallelen Ausführungssignalleitungen auszuwählen ist.

Beispiel 27. Das maschinenlesbare Medium von Beispiel 21, das ferner Programmcode umfasst, um zu bewirken, dass die Maschine den Vorgang durchführt zum: Speichern einer Ausführungsmaske mit mindestens einem Wert, der mit jeder der parallelen Ausführungssignalleitungen assoziiert ist.

Beispiel 28. Das maschinenlesbare Medium von Beispiel 27, das ferner Programmcode umfasst, um zu bewirken, dass die Maschine den Vorgang durchführt zum: Aktivieren oder Deaktivieren von Ausführungssignalleitungen zum Ausführen jedes Fragments oder Mikrothreads auf Grundlage der mit den Signalleitungen assoziierten Werte.

Beispiel 29. Das maschinenlesbare Medium von Beispiel 28, das ferner Programmcode umfasst, um zu bewirken, dass die Maschine den Vorgang durchführt zum: dynamisches Aktualisieren der Ausführungsmaske für jedes Fragment oder jeden Mikrothread, wodurch eine bestimmte Anzahl von Signalleitungen aktiviert wird, die erforderlich sind, um das Fragment oder den Mikrothread auszuführen.

Ausführungsformen der Erfindung können verschieden Schritte beinhalten, die oben beschrieben worden sind. Die Schritte können in maschinenausführbaren Befehlen ausgeführt sein, die verwendet werden können, um einen universellen oder speziellen Prozessor zum Durchführen der Schritte zu veranlassen. Alternativ können diese Schritte durch spezifische Hardwarekomponenten, die fest verdrahtete Logik zum Durchführen der Schritte haben, oder durch eine beliebige Kombination aus programmierten Computerkomponenten und maßgeschneiderten Hardwarekomponenten durchgeführt werden.

Wie hierin beschrieben, können sich Befehle auf spezifische Auslegungen von Hardware, wie anwendungsspezifische integrierte Schaltungen (Application Specific Integrated Circuits, ASICs), die dazu ausgelegt sind, bestimmte Operationen durchzuführen, oder die eine vorher festgelegte Funktionalität aufweisen, oder Softwarebefehle, die in einem Arbeitsspeicher gespeichert sind, der in einem nichtflüchtigen computerlesbaren Medium ausgeführt ist, beziehen. Somit können die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten umgesetzt werden, die auf einer oder mehreren elektronischen Einrichtungen (z. B. einer Endstation, einem Netzwerkelement usw.) gespeichert und ausgeführt werden. Derartige elektronische Einrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Einrichtungen über ein Netzwerk) Code und Daten unter Verwendung von computer-maschinenlesbaren Medien, wie nicht transitorischen computer-maschinenlesbaren Speichermedien (z. B. magnetischen Platten; optischen Platten; Arbeitsspeicher mit wahlfreiem Zugriff; schreibgeschütztem Arbeitsspeicher; Flashspeichereinrichtungen; Phasenwechselspeicher) und transitorischen computer-maschinenlesbaren Kommunikationsmedien (z. B. elektrischen, optischen, akustischen oder einer anderen Form von propagierten Signalen - wie Trägerwellen, Infrarotsignalen, Digitalsignalen usw.). Außerdem enthalten diese elektronischen Einrichtungen üblicherweise einen Satz von einem oder mehreren Prozessoren, die an eine oder mehrere andere Komponenten, wie eine oder mehrere Speichereinrichtungen (nichtflüchtige maschinenlesbare Speichermedien), Benutzereingabe/- ausgabevorrichtungen (z. B. eine Tastatur, ein Touchscreen und/oder eine Anzeige), gekoppelt sind, und Netzwerkverbindungen. Das Koppeln des Satzes von Prozessoren und anderen Komponenten erfolgt üblicherweise durch eine/n oder mehrere Busse und Brücken (auch als Bussteuerungen bezeichnet). Die Speichereinrichtung bzw. die Signale, die den Netzwerkverkehr tragen, stellen ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien dar. Somit speichert die Speichereinrichtung einer gegebenen elektronischen Einrichtung typischerweise Code und/oder Daten zur Ausführung auf dem Satz von einem oder mehreren Prozessoren dieser elektronischen Einrichtung. Natürlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung unterschiedlicher Kombinationen von Software, Firmware und/oder Hardware implementiert sein.

In dieser ausführlichen Beschreibung sind zur Erklärung durchweg zahlreiche spezifische Details dargelegt worden, um ein gründliches Verständnis der vorliegenden Erfindung bereitzustellen. Es ist jedoch für Fachleute ersichtlich, dass die Erfindung ohne einige dieser spezifischen Details ausgeführt werden kann. In bestimmten Fällen wurden hinlänglich bekannte Strukturen und Funktionen nicht in ausführlichem Detail beschrieben, um zu verhindern, dass der Gegenstand der vorliegenden Erfindung unverständlich wird. Entsprechend sind der Geltungsbereich und der Gedanke der Erfindung mittels der nachfolgenden Ansprüche zu beurteilen.

Claims

Beansprucht wird:
Prozessor, umfassend: Befehlsabrufverschaltung zum Abrufen von Befehlen eines oder mehrerer primärer Threads; einen Decoder zum Decodieren der Befehle zum Erzeugen von uops; einen datenparallelen Cluster (DPC) zum Ausführen von Mikrothreads, die eine Teilmenge der uops umfassen, wobei der DPC ferner umfasst: eine Vielzahl von Ausführungssignalleitungen zum Durchführen einer parallelen Ausführung der Mikrothreads; eine Befehlsdecodierwarteschleife (IDQ) zum Speichern der uops vor der Ausführung; und eine Planungseinheit zum Auswerten der Mikrothreads auf Grundlage von assoziierten Variablen, die Befehlszeiger(IP)-Werte enthalten, wobei die Planungseinheit Mikrothreads auf Grundlage der Auswertung in Fragmente zur parallelen Ausführung in den Ausführungssignalleitungen zusammenzufassen hat.
Prozessor nach Anspruch 1, wobei die Planungseinheit die Mikrothreads auf Grundlage von IP-Werten in Fragmente zusammenzufassen hat, um eine Mikrothread-Konvergenz herbeizuführen.
Prozessor nach Anspruch 1, wobei ein Fragment eine Sammlung von zugehörigen Mikrothreads umfasst.
Prozessor nach Anspruch 2 oder 3, ferner umfassend: Rekonvergenzverschaltung, die von der Planungseinheit zu verwenden ist, um eine Reihenfolge zu ermitteln, in der die Fragmente auszuführen sind, wobei die Rekonvergenzverschaltung eine Datenstruktur zum Speichern von zu jedem Fragment zugehörigen Variablen umfasst.
Prozessor nach Anspruch 4, wobei die Rekonvergenzverschaltung ausgelegt ist, ein Signal zu erzeugen, um ein nächstes, auszuführendes Fragment auf Grundlage eines Vergleichs der Variablen aller Fragmente zu identifizieren.
Prozessor nach Anspruch 5, wobei der Vergleich einen Vergleich der IP-Werte der Fragmente umfasst und wobei das Fragment mit einem minimalen IP-Wert zur Ausführung durch Ausführungssignalleitungen auszuwählen ist.
Prozessor nach Anspruch 1 oder 6, wobei der DPC ferner umfasst: Maskenspeicher, um eine Ausführungsmaske mit mindestens einem Wert zu speichern, der mit jeder parallelen Ausführungssignalleitung assoziiert ist.
Prozessor nach Anspruch 7, wobei der DPC Ausführungssignalleitungen zum Ausführen jedes Fragments oder Mikrothreads auf Grundlage der mit den Signalleitungen assoziierten Werte zu aktivieren oder zu deaktivieren hat.
Prozessor nach Anspruch 8, wobei die Ausführungsmaske dynamisch für jedes Fragment oder jeden Mikrothread zu aktualisieren ist, wodurch eine Anzahl von Signalleitungen aktiviert wird, die erforderlich sind, um das Fragment oder den Mikrothread auszuführen.
Prozessor nach Anspruch 1 oder 9, wobei der DPC ferner umfasst: einen Datenzwischenspeicher, um Daten zu speichern, die zu verwenden sind, um die Fragmente auszuführen; einen Übersetzungspuffer (TLB), um Adressenübersetzungen von virtuellen auf physische Adressen zum Zugriff auf Systemarbeitsspeicher zu speichern.
Prozessor nach Anspruch 1 oder 10, wobei jede Signalleitung des DPC ferner umfasst: eine Registerdatei, um Daten zu speichern, die mit einem Fragment assoziiert sind, das ausgeführt wird; eine Tensor-Arithmetik-Logik-Einheit (TALU), um Tensordaten zu verarbeiten, die mit einem Fragment assoziiert sind, das ausgeführt wird; und eine Adressengenerierungseinheit, um Adressen zu generieren, die erforderlich sind, um jedes Fragment auszuführen.
Verfahren, umfassend: Abrufen von Befehlen eines oder mehrerer primärer Threads; Decodieren der Befehle zum Erzeugen von uops; Identifizieren von Mikrothreads, die eine Teilmenge der uops umfassen; Auswerten der Mikrothreads auf Grundlage von assoziierten Variablen, die Befehlszeiger(IP)-Werte enthalten; und Zusammenfassen der Mikrothreads in Fragmente zur parallelen Ausführung auf einer Vielzahl von parallelen Ausführungssignalleitungen auf Grundlage der Auswertung.
Verfahren nach Anspruch 12, wobei die Mikrothreads auf Grundlage der IP-Werte in Fragmente zusammengefasst werden, um eine Mikrothread-Konvergenz herbeizuführen.
Verfahren nach Anspruch 12, wobei ein Fragment eine Sammlung von zugehörigen Mikrothreads umfasst.
Verfahren nach Anspruch 13 oder 14, ferner umfassend: Ermitteln einer Reihenfolge, in der die Fragmente auszuführen sind, unter Verwendung einer Datenstruktur, die zu jedem Fragment gehörige Variablen speichert.
Verfahren nach Anspruch 15, ferner umfassend: Erzeugen eines Signals, um ein nächstes, auszuführendes Fragment auf Grundlage eines Vergleichs der Variablen aller Fragmente zu identifizieren.
Verfahren nach Anspruch 16, wobei der Vergleich einen Vergleich der IP-Werte der Fragmente umfasst und wobei das Fragment mit einem minimalen IP-Wert zur Ausführung auf den parallelen Ausführungssignalleitungen auszuwählen ist.
Verfahren nach Anspruch 12 oder 17, ferner umfassend: Speichern einer Ausführungsmaske mit mindestens einem Wert, der mit jeder der parallelen Ausführungssignalleitungen assoziiert ist.
Verfahren nach Anspruch 18, ferner umfassend: Aktivieren oder Deaktivieren von Ausführungssignalleitungen zum Ausführen jedes Fragments oder Mikrothreads auf Grundlage der mit den Signalleitungen assoziierten Werte.
Verfahren nach Anspruch 19, ferner umfassend: dynamisches Aktualisieren der Ausführungsmaske für jedes Fragment oder jeden Mikrothread, wodurch eine bestimmte Anzahl von Signalleitungen aktiviert wird, die erforderlich sind, um das Fragment oder den Mikrothread auszuführen.
Maschinenlesbares Medium mit darauf gespeichertem Programmcode, der beim Ausführen durch eine Maschine bewirkt, dass die Maschine die folgenden Operationen durchführt: Abrufen von Befehlen eines oder mehrerer primärer Threads; Decodieren der Befehle zum Erzeugen von uops; Identifizieren von Mikrothreads, die eine Teilmenge der uops umfassen; Auswerten der Mikrothreads auf Grundlage von assoziierten Variablen, die Befehlszeiger(IP)-Werte enthalten; und Zusammenfassen der Mikrothreads in Fragmente zur parallelen Ausführung auf einer Vielzahl von parallelen Ausführungssignalleitungen auf Grundlage der Auswertung.
Maschinenlesbares Medium nach Anspruch 21, wobei die Mikrothreads auf Grundlage der IP-Werte in Fragmente zusammengefasst werden, um eine Mikrothread-Konvergenz herbeizuführen.
Vorrichtung, umfassend: Mittel zum Abrufen von Befehlen eines oder mehrerer primärer Threads; Mittel zum Decodieren der Befehle zum Erzeugen von uops; Mittel zum Identifizieren von Mikrothreads, die eine Teilmenge der uops umfassen; Mittel zum Auswerten der Mikrothreads auf Grundlage von assoziierten Variablen, die Befehlszeiger(IP)-Werte enthalten; und Mittel zum Zusammenfassen der Mikrothreads in Fragmente zur parallelen Ausführung auf einer Vielzahl von parallelen Ausführungssignalleitungen auf Grundlage der Auswertung.
Verfahren nach Anspruch 23, wobei die Mikrothreads auf Grundlage der IP-Werte in Fragmente zusammengefasst werden, um eine Mikrothread-Konvergenz herbeizuführen.
Verfahren nach Anspruch 24, wobei ein Fragment eine Sammlung von zugehörigen Mikrothreads umfasst.
Verfahren nach Anspruch 24 oder 25, ferner umfassend: Ermitteln einer Reihenfolge, in der die Fragmente auszuführen sind, unter Verwendung einer Datenstruktur, die zu jedem Fragment gehörige Variablen speichert.
Verfahren nach Anspruch 26, ferner umfassend: Erzeugen eines Signals, um ein nächstes, auszuführendes Fragment auf Grundlage eines Vergleichs der Variablen aller Fragmente zu identifizieren.
Verfahren nach Anspruch 27, wobei der Vergleich einen Vergleich der IP-Werte der Fragmente umfasst und wobei das Fragment mit einem minimalen IP-Wert zur Ausführung auf den parallelen Ausführungssignalleitungen auszuwählen ist.
Verfahren nach Anspruch 23 oder 28, ferner umfassend: Speichern einer Ausführungsmaske mit mindestens einem Wert, der mit jeder der parallelen Ausführungssignalleitungen assoziiert ist.
Verfahren nach Anspruch 29, ferner umfassend: Aktivieren oder Deaktivieren von Ausführungssignalleitungen zum Ausführen jedes Fragments oder Mikrothreads auf Grundlage der mit den Signalleitungen assoziierten Werte.
Verfahren nach Anspruch 30, ferner umfassend: dynamisches Aktualisieren der Ausführungsmaske für jedes Fragment oder jeden Mikrothread, wodurch eine bestimmte Anzahl von Signalleitungen aktiviert wird, die erforderlich sind, um das Fragment oder den Mikrothread auszuführen.