DE112013005188B4

DE112013005188B4 - Prozessor und vefrahren zur vektorisierung von zusammengeführten, mehrfach geschachtelten schleifen

Info

Publication number: DE112013005188B4
Application number: DE112013005188.5T
Authority: DE
Inventors: Mikhail Plotnikov; Andrey Naraikin; Elmoustapha Ould-Ahmed-Vall
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2012-12-27
Filing date: 2013-06-29
Publication date: 2023-08-03
Anticipated expiration: 2033-06-30
Also published as: US20140188961A1; WO2014105208A1; KR101722645B1; DE112013005188T5; CN104838357B; KR20150079809A; CN104838357A

Abstract

Prozessor (100) umfassend:ein Ausführungsmittel (103-1, ..., 103_N), das eine Vektoreinheit und eine Skalareinheit beinhaltet;wobei die Vektoreinheit dazu eingerichtet ist, eine aus einer Vielzahl von Schleifen gebildete, zusammengeführte Schleife auszuführen, um einen Vektor mit Offsets, Offset-Vector, zu erhalten;gekennzeichnet dadurch, dassdie Vektoreinheit dazu eingerichtet ist, für die Ausführung der zusammengeführten Schleife mehrere Iterationen der zusammengeführten Schleife durchzuführen, wobei jede der Iterationen der zusammengeführten Schleife folgende Operationen umfasst:ein Kalkulieren eines skalaren Offsets in eine mehrdimensionale Datenstruktur, wobei die Kalkulation des skalaren Offsets in Form eines absoluten Werts eines Index umfasst, wobei der absolute Wert des Index unter Verwendung eines Schleifenzählerwerts eines Vektors mit Zählerwerten für die Vielzahl von Schleifen, MDLC-Vektors, sowie eines Anfangswerts, der aus einem Vektor von Anfangswerten, Anfangswert-Vektor, erhalten wird, bestimmt wird,ein Speichern des skalaren Offsets in einem Datenelement eines ersten Vektors, der in einem Vektorregister des Prozessors gespeichert ist,ein Aktualisieren mindestens eines Schleifenzählerwerts des MDLC-Vektors, und anschließend:ein Laden einer Vielzahl von Datenelementen aus der mehrdimensionalen Datenstruktur in einen weiteren, zweiten Vektor unter Verwendung eines Basiswerts und von Indizes aus dem Offset-Vector,ein Durchführen mindestens einer Berechnung mit den geladenen Datenelementen im zweiten Vektor, um eine Vielzahl von Ergebnissen zu erhalten, undein Speichern der Vielzahl von Ergebnissen in der mehrdimensionalen Datenstruktur unter Verwendung des Basiswerts und der Indizes aus dem Offset-Vector;wobei die Vektoreinheit dazu eingerichtet ist, den MDLC-Vektor in Reaktion auf einen Aktualisierungsbefehl zu aktualisieren, wobei der Aktualisierungsbefehl beinhaltet:einen ersten Operanden, der den MDLC-Vektor identifiziert,einen zweiten Operanden, der einen Vektor von De- oder Inkrementierungs-Faktoren identifiziert, undeinen dritten Operanden, der einen Vektor von Differenzen zwischen einem Anfangswert und einem Endwert für jeden der Schleifenzählerwerte des MDLC-Vektors identifiziert.

Description

Gebiet der Technik
Die vorliegende Offenbarung betrifft allgemein Rechnerplattformen und insbesondere Schleifenzusammenführungsverfahren, -vorrichtungen und -befehle und Schleifenvektorisierungsverfahren.
Stand der Technik
Geschachtelte Schleifen, die z. B. zwei- bis fünffach geschachtelt sind, kommen beispielsweise sehr häufig in High-Performance-Computing (HPC)-Code vor. Die Schleifenzusammenführung verbessert die Leistung durch eine Verringerung der Zahl von Verzweigungen und mithin der Wahrscheinlichkeit falscher Verzweigungsvorhersagen. Eine herkömmliche Möglichkeit zum Zusammenführen von mehrfach geschachtelten Schleifen besteht darin, dass eine Schleife ohne Schachtelungen erzeugt wird, gesteuert von einem neuen Schleifenzähler, der bei jeder Iteration der zusammengeführten Schleife inkrementiert wird. Der neue Schleifenzähler wird insgesamt (tc_n-1*tc_n-2*...*tc₀) Mal inkrementiert, wobei tc_j eine Schleifenanzahl der Schleife über i_j ist. Jedoch müssen die Informationen zu individuellen Schleifenzählern für Berechnungen innerhalb der Schleife und zur Verwendung als Indizes für den Zugriff auf mehrdimensionale Arrays beibehalten werden.
Auch können derzeitige Compiler, obwohl die Schleifenzusammenführung in manchen Fällen die Leistung verbessern kann, Schleifen selten effizient zusammenführen. Ein paar der am häufigsten beobachteten Gründe, die einer Zusammenführung entgegenstehen, sind: Speicherzugriffe ohne Schrittweiten in einem n-dimensionalen Array A (nach der Zusammenführung); das Vorkommen von Zugriffen auf ein subdimensionales Array B (m Dimensionen, m<n); und das Vorkommen von Berechnungen über separate Schleifenzähler (i_j). Die Erfindung zielt darauf ab, mindestens einen dieser Nachteile im Stand der Technik auszuräumen.
US 2009/0307472 A1 offenbart ein Verfahren und eine Vorrichtung zum Ausführen einer verschachtelten Programmschleife auf einem Vektorprozessor. Eine Eingangsstromeinheit des Vektorprozessors liefert einen Datenwert an einen Datenpfad und setzt ein zugeordnetes Datengültigkeitskennzeichen einmal pro Iteration der äußeren Schleife auf „gültig“, wie durch einen inneren Zähler der Eingangsstromeinheit angezeigt. Das Tag wird in anderen Iterationen auf „ungültig“ gesetzt. Funktionale Einheiten des Vektorprozessors bearbeiten Datenwerte im Datenpfad, wobei jede funktionale Einheit ein gültiges Ergebnis erzeugt, wenn die den Eingangsdatenwerten zugeordneten Datengültigkeitskennzeichen auf „gültig“ gesetzt sind. Eine Ausgabestromeinheit des Vektorprozessors senkt einen Datenwert des Datenpfads einmal pro Iteration der äußeren Schleife, wenn ein zugeordnetes Datengültigkeitskennzeichen anzeigt, dass der Datenwert gültig ist.
US 5,802,375 A offenbart ein Verfahren zum Vektorisieren einer nicht-innersten Schleife einer verschachtelten Schleife. Iterative Schleifen einer verschachtelten Schleife werden analysiert, um festzustellen, ob sie vektorisiert werden können. Wenn mehr als eine iterative Schleife vektorisiert werden kann, wird ein Auswahlkriterium angewendet, um diejenige iterative Schleife auszuwählen, die die größte Leistungssteigerung mittels der Vektorisierung realisieren kann.
US 2012/0254847 A1 offenbart ein Verfahren zum Zuordnen physikalischer Register zu Variablen. Diese Verfahren umfasst das Identifizieren einer partiellen Definition einer Variablen in einem interprozeduralen Kontrollflussdiagramm. Auf der Grundlage der partiellen Definition kann bestimmt werden, ob die Lebensdauer der Variablen zu beenden ist. Zusätzlich kann der Variablen basierend zumindest teilweise auf ihrer Lebensdauer ein physisches Register zugewiesen werden.
WO 2012/151822 A1 offenbart eine Loopback-Struktur und ein Daten-Loopback-Verarbeitungsverfahren für einen Prozessor, wobei die Loopback-Struktur eine Registerdateieinheit, eine Datenspeichereinheit und eine Datenleseeinheit umfasst. Die Datenleseeinheit ist mit der Registerdateieinheit und der Datenspeichereinheit verbunden und führt eine Datentransformation an den von der Datenspeichereinheit zurückgeführten Daten durch und schreibt dann die Daten über deren Schreibport in die Registerdateieinheit.
Zusammenfassung der Erfindung
Die Erfindung wird durch den Gegenstand der unabhängigen Patentansprüche definiert. Vorteilhafte Ausführungsformen der Erfindung sind Gegenstand der abhängigen Patentansprüche.
Figurenliste

1 ist ein Blockschema einer Prozessor-Pipeline gemäß einer Ausführungsform der vorliegenden Erfindung.
Die 2A und 2B sind Blockschemata von Skalaroperationen im Vergleich zu Vektoroperationen gemäß einer Ausführungsform der vorliegenden Erfindung.
3A ist ein Blockschema eines Vektors eines Zählers für mehrdimensionale Schleifen (nachfolgend: MDLC-Vektor) und einer assoziierten Maske gemäß einer Ausführungsform der vorliegenden Erfindung.
3B ist ein Blockschema von mit einem Schleifenzähleraktualisierungsbefehl assoziierten Werten gemäß einer Ausführungsform der vorliegenden Erfindung.
4 ist ein Ablaufschema eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
5 ist ein Blockschema eines Abschnitts einer Vektorausführungseinheit gemäß einer Ausführungsform der vorliegenden Erfindung.
5A ist ein Ablaufschema eines Verfahrens zum Vektorisieren eines Codesegments gemäß einer Ausführungsform der vorliegenden Erfindung.
5B ist ein Ablaufschema eines Verfahrens gemäß einer anderen Ausführungsform der vorliegenden Erfindung.
6A ist eine Abbildung eines beispielhaften AVX-Befehlsformats gemäß einer Ausführungsform der vorliegenden Erfindung.
6B ist eine Abbildung, in der Felder aus 6A ein vollständiges Opcode-Feld und ein Basisoperationsfeld gemäß einer Ausführungsform der vorliegenden Erfindung bilden.
6C ist eine Abbildung, in der Felder aus 6A ein Registerindexfeld gemäß einer Ausführungsform der vorliegenden Erfindung bilden.
Die 7A und 7B sind Blockschemata, die ein allgemeines vektorfreundliches Befehlsformat und Befehlsmodelle davon gemäß Ausführungsformen der Erfindung veranschaulichen.
8 ist ein Blockschema, das ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß Ausführungsformen der Erfindung veranschaulicht.
9 ist ein Blockschema einer Registerarchitektur gemäß einer Ausführungsform der Erfindung.
10A ist ein Blockschema, das sowohl eine beispielhafte In-order-Pipeline als auch eine beispielhafte Registerumbenennung-, Out-of-order-Zuteilung/Ausführung-Pipeline gemäß Ausführungsformen der Erfindung veranschaulicht.
10B ist ein Blockschema, das sowohl ein Ausführungsbeispiel für einen In-order-Architekturkern als auch einen beispielhaften Registerumbenennung-, Out-oforder-Zuteilung/Ausführung-Architekturkern zur Aufnahme in einen Prozessor gemäß Ausführungsformen der Erfindung veranschaulicht.
Die 11A-B veranschaulichen ein Blockschema einer spezifischeren beispielhaften In-order-Kernarchitektur, deren Kern einer von mehreren logischen Bausteinen (einschließlich anderer Kerne vom selben Typ und/oder von unterschiedlichen Typen) in einem Chip wäre.
12 ist ein Blockschema eines Prozessors, der mehr als einen Kern aufweisen kann, einen integrierten Speichercontroller aufweisen kann und integrierte Grafiken gemäß Ausführungsformen der Erfindung aufweisen kann.
13 ist ein Blockschema eines beispielhaften Systems gemäß einer Ausführungsform der vorliegenden Erfindung.
14 ist ein Blockschema eines ersten spezifischeren beispielhaften Systems gemäß einer Ausführungsform der vorliegenden Erfindung.
15 ist ein Blockschema eines zweiten spezifischeren beispielhaften Systems gemäß einer Ausführungsform der vorliegenden Erfindung.
16 ist ein Blockschema eines SoC gemäß einer Ausführungsform der vorliegenden Erfindung.
17 ist ein Blockschema, das Verwendungen eines Softwarebefehlsumwandlers zum Umwandeln von Binärbefehlen in einem Quellbefehlssatz in Binärbefehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung einander gegenüberstellt.

Ausführliche Beschreibung
In verschiedenen Ausführungsformen können Schleifenzähler für geschachtelte Schleifen in einem Vektorformat aufrechterhalten werden. Diese Mehrfachschleifenzähler können am Ende jeder Iteration einer zusammengeführten Schleife, die aus den geschachtelten Schleifen ausgebildet ist, entsprechend modifiziert werden. In unterschiedlichen Ausführungsformen können nach Berechnungen vorgenommene Schleifenzähleraktualisierungen in der Hardware eines Prozessors ansprechend auf einen einzelnen Befehl durchgeführt werden.
Ausführungsformen können somit Schleifenzähler von geschachtelten Schleifen als einzelnen Zähler für mehrdimensionale Schleifen speichern, welcher in einem Speicherelement in Vektorgröße, wie einem Vektorregister eines Prozessors oder am Ort eines Speichers in Vektorgröße, gespeichert ist. Der Wert in diesem Speicherelement lässt sich über einen oder mehrere Befehle zum Steuern des Zählers für mehrdimensionale Schleifen steuern. Es können unterschiedliche Varianten solcher Befehle zum Inkrementieren und Dekrementieren der Zähler in steuerbarer Weise sowie zum Aktualisieren verschiedener Statusflags eines Prozessors bereitgestellt werden. Darüber hinaus kann ein Befehl, der Offsets innerhalb mehrdimensionaler Arrays kalkuliert, verwendet werden, um Schleifenzusammenführungen durchzuführen. Dieser Ansatz ermöglicht die Zusammenführung von mehrfach geschachtelten Schleifen und die Verwendung von Schleifenzählern von geschachtelten Schleifen als Indizes für Zugriffe auf mehrdimensionale Arrays (einschließlich subdimensionaler Arrays) oder andere Berechnungen über Schleifenzähler von geschachtelten Schleifen.
1 zeigt ein grobes Schema eines Verarbeitungskerns 100, der mit einer Logikschaltungsanordnung auf einem Halbleiterchip implementiert ist. Der Verarbeitungskern beinhaltet eine Pipeline 101. Die Pipeline besteht aus mehreren Stufen, die je ausgelegt sind zum Durchführen eines spezifischen Schritts im Mehrschrittprozess, der zum vollständigen Ausführen eines Programmcodebefehls benötigt wird. Diese beinhalten typischerweise mindestens Folgendes: 1) Befehl holen und decodieren; 2) Daten holen; 3) ausführen; 4) zurückschreiben. In der Ausführungsstufe wird eine spezifische Operation durchgeführt, die durch einen Befehl identifiziert wird, der in (einer) vorherigen Stufe(n) (z. B. bei Schritt 1) oben) geholt und decodiert wurde, nachdem Daten in einer anderen vorherigen Stufe (z. B. bei Schritt 2) oben) durch den gleichen Befehl identifiziert und geholt worden sind. Die Daten, die bearbeitet werden, werden typischerweise von einem (Universal-) Registerspeicherplatz 102 geholt. Neue Daten, die beim Abschluss der Operation erzeugt werden, werden typischerweise auch in den Registerspeicherplatz „zurückgeschrieben“ (z. B. in der Stufe 4) oben).
Die mit der Ausführungsstufe assoziierte Logikschaltungsanordnung ist typischerweise zusammengesetzt aus mehreren „Ausführungseinheiten“ oder „Funktionseinheiten“ 103_1 bis 103_N, die je dafür ausgelegt sind, ihre eigenen eindeutigen Teilmengen von Operationen durchzuführen (z. B. führt eine erste Funktionseinheit ganzzahlige mathematische Operationen durch, eine zweite Funktionseinheit führt Gleitkommabefehle durch, eine dritte Funktionseinheit führt Operationen zum Laden/Speichern aus einem/in einen Cache/Speicher durch etc.). Die Gesamtheit der Operationen, die von allen Funktionseinheiten durchgeführt werden, korrespondiert mit dem vom Verarbeitungskern 100 unterstützten „Befehlssatz“.
Zwei Typen von Prozessorarchitekturen sind auf dem Gebiet der Informatik weithin anerkannt: „Skalar“ und „Vektor“. Ein Skalarprozessor ist ausgelegt für die Ausführung von Befehlen, die Operationen an einem einzelnen Satz von Daten durchführen, während ein Vektorprozessor ausgelegt ist für die Ausführung von Befehlen, die Operationen an mehreren Sätzen von Daten durchführen. Die 2A und 2B stellen ein Vergleichsbeispiel dar, das den grundlegenden Unterschied zwischen einem Skalarprozessor und einem Vektorprozessor demonstriert.
2A zeigt ein Beispiel für einen skalaren UND-Befehl, durch den ein einzelner Operandensatz, A und B, nach UND verknüpft wird, um ein singuläres (oder „skalares“) Ergebnis C (d. h. AB=C) zu liefern. Im Gegensatz dazu zeigt 2B ein Beispiel für einen Vektor-UND-Befehl, durch den zwei Operandensätze, A/B und D/E, jeweils parallel nach UND verknüpft werden, um gleichzeitig ein Vektorergebnis C, F (d. h. A.UND.B=C und D.UND.E=F) zu liefern. Was die Terminologie betrifft, ist ein „Vektor“ ein Datenelement mit mehreren „Elementen“. Zum Beispiel weist ein Vektor V = Q, R, S, T, U fünf unterschiedliche Elemente auf: Q, R, S, T und U. Der beispielhafte Vektor V hat die „Größe“ fünf (denn er hat fünf Elemente).
1 zeigt auch das Vorhandensein eines Vektorregisterplatzes 107, der sich vom Universalregisterplatz 102 unterscheidet. Insbesondere wird der Universalregisterplatz 102 prinzipiell verwendet, um Skalarwerte zu speichern. Demzufolge verwenden beliebige der Ausführungseinheiten beim Durchführen von Skalaroperationen prinzipiell Operanden, die vom Universalregisterspeicherplatz 102 abgerufen werden (und in den sie Ergebnisse zurückschreiben). Im Gegensatz dazu verwenden beliebige der Ausführungseinheiten beim Durchführen von Vektoroperationen prinzipiell Operanden, die vom Vektorregisterplatz 107 abgerufen werden (und in den sie Ergebnisse zurückschreiben). Unterschiedliche Regionen eines Speichers können ebenfalls für die Speicherung von Skalarwerten und Vektorwerten alloziert werden.
Auch das Vorhandensein einer Maskierungslogik 104_1 bis 104_N und 105_1 bis 105_N an den jeweiligen Eingängen zu und Ausgängen von den Funktionseinheiten 103_1 bis 103_N ist zu beachten. In verschiedenen Implementierungen ist für Vektoroperationen nur eine dieser Schichten tatsächlich implementiert - auch wenn dies keine zwingende Voraussetzung ist (auch wenn dies in 1 nicht abgebildet ist, müssen Ausführungseinheiten, die nur Skalar- und keine Vektoroperationen durchführen, nachvollziehbarerweise keine Maskierungsschicht haben). Für alle Vektorbefehle, die von einer Maskierung Gebrauch machen, können eine Eingangsmaskierungslogik 104_1 bis 104_N und/oder eine Ausgangsmaskierungslogik 105_1 bis 105_N verwendet werden, um zu steuern, welche Elemente für den Vektorbefehl effektiv bearbeitet werden. Hier wird ein Maskenvektor von einem Maskenregisterplatz 106 gelesen (z. B. nebst Eingangsoperandenvektoren, die vom Vektorregisterspeicherplatz 107 gelesen werden) und wird mindestens einer der Schichten der Maskierungslogik 104, 105 präsentiert.
Im Verlauf der Ausführung des Vektorprogrammcodes ist nicht für jeden Vektorbefehl ein vollständiges Datenwort erforderlich. Zum Beispiel bestehen die Eingangsvektoren für manche Befehle möglicherweise nur aus 8 Elementen, die Eingangsvektoren für andere Befehle aus 16 Elementen, die Eingangsvektoren für andere Befehle aus 32 Elementen etc. Die Maskierungsschichten 104/105 werden deshalb verwendet, um eine Menge von Elementen eines vollständigen Vektordatenworts, die für einen konkreten Befehl gelten, zu identifizieren, um unter den Befehlen unterschiedliche Vektorgrößen herbeizuführen. Typischerweise wird für jeden Vektorbefehl eine spezifische Maskenvorlage, die am Maskenregisterplatz 106 geführt wird, durch den Befehl ausgerufen, vom Maskenregisterplatz geholt und für eine oder beide der Maskenschichten 104/105 bereitgestellt, um die richtige Menge von Elementen für die konkrete Vektoroperation zu „aktivieren“.
Vektormaschinen können ausgelegt sein für die Verarbeitung „mehrdimensionaler“ Datenstrukturen, in denen jedes Element des Vektors mit einer eindeutigen Dimension der Datenstruktur korrespondiert. Falls zum Beispiel eine Vektormaschine unter Berücksichtigung einer dreidimensionalen Struktur (wie eines „Kubus“) programmiert würde, könnte ein Vektor erzeugt werden, der ein erstes Element, das mit der Breite des Kubus korrespondiert, ein zweites Element, das mit der Länge des Kubus korrespondiert, und ein drittes Element, das mit der Höhe des Kubus korrespondiert, aufweist.
Der Durchschnittsfachmann erkennt, dass eine Berechnung mehrdimensionaler Strukturen in einem Rechnersystem Strukturen mit zwei oder mehr Dimensionen, einschließlich mehr als drei Dimensionen, mit sich bringen kann. Der Einfachheit halber führt jedoch die vorliegende Anmeldung überwiegend Beispiele an.
Tabelle 1 ist eine beispielhafte geschachtelte Schleife, die unter Verwendung von hierin beschriebenen Befehlen zusammengeführt werden kann. Es ist zu beachten, dass die Schleifenzusammenführung von einem Benutzer oder einem Compiler wie einem statischen Compiler oder einem Laufzeitcompiler, etwa einem Just-In-Time(JIT)-Compiler, durchgeführt werden kann. Im Allgemeinen zeigt Tabelle 1 eine geschachtelte Schleife, in der an einem ersten mehrdimensionalen Array A Aktualisierungen basierend auf Berechnungen vorgenommen werden, die an Schleifenzählern von geschachtelten Schleifen (i_j) und an Datenelementen durchgeführt werden, die aus einem zweiten mehrdimensionalen Array B erhalten werden, wobei Offsets gemäß verschiedenen Schleifenzählerwerten zugrunde gelegt werden.
Nunmehr wird unter Bezugnahme auf 3A ein Blockschema eines MDLC-Vektors, gezeigt, der eine Vielzahl von Offsets beinhaltet. Es ist zu beachten, dass wie hier, wenn KL größer als n ist, Werte der Offsets, die größer als oder gleich n sind, undefiniert sind und durch eine Maske k1 in Berechnungen ausmaskiert werden können. Im Folgenden wird angenommen, dass die Zahl der Schleifenschachtelungen (n) nicht größer ist als die Zahl der Elemente in einem Vektor (KL), und wenn n<KL, wird angenommen, dass obere Elemente, angefangen beim Offset n, in Berechnungen zur Aktualisierung eines Zählers für mehrdimensionale Schleifen durch eine zweckdienliche Eingabemaske k1 ausmaskiert werden.
In manchen Ausführungsformen modifizieren diese Befehle zur Aktualisierung eines Zählers für mehrdimensionale Schleifen Werte des Zählers für mehrdimensionale Schleifen, um zur nächsten Iteration einer zusammengeführten Schleife überzugehen. Mehrere Implementierungen sind möglich, jedoch sollen alle von ihnen eines tun - zur nächsten Iteration einer zusammengeführten Schleife übergehen oder, was die zusammengeführte Schleife betrifft, eine Inkrementieroperation durchführen.
Nunmehr werden unter Bezugnahme auf 3B Werte gezeigt, die mit einem Schleifenzähleraktualisierungsbefehl gemäß einer Ausführungsform der vorliegenden Erfindung assoziiert sind. Wie in 3B gezeigt, liegen verschiedene Operanden und Maskenwerte vor. Es ist zu beachten, dass, während diese Werte in konkreten Beispielen in einem Befehl möglicherweise als Operanden oder Maskenwert identifiziert sind, in anderen Implementierungen möglicherweise auch ein Immediate-Wert mit einem Befehl zum Identifizieren eines oder mehrerer Werte zur Verwendung bei der Ausführung des Befehls assoziiert ist.
Wie in 3B ersichtlich, identifiziert ein erster Operand einen ersten Speicherort 110 (z. B. ein Vektorregister ZMM0), der in einer Ausführungsform möglicherweise ein KL breites Register zur Speicherung von KL individuellen Datenelementen ist. KL kann beispielsweise 8, 16, 32 oder eine andere Zahl von individuellen Datenelementen sein. Falls ein Vektorregister zum Beispiel 512 Bit breit ist und jede Schleifenzählergröße 32 Bit beträgt, so gilt KL=512/32=16. Es ist zu beachten, dass Elemente mit einem Offset von null, z. B. zmm[0], auf die innerste Schleife bezogen sind, ein nächster Offset, z. B. zmm[1], mit einer einmaligen äußeren Schleife korrespondiert und schließlich zmm[n] mit der äußersten Schleife korrespondiert. In einem beispielhaften Befehl wie einem Schleifenzähleraktualisierungsbefehl kann dieses Register die momentanen Werte für jeden der individuellen Schleifenzähler des MDLC-Vektors speichern.
Anschließend identifiziert ein zweiter Operand einen zweiten Speicherort 120 (z. B. ein Vektorregister ZMM1), der in einer Ausführungsform möglicherweise ein KL breites Register zur Speicherung von KL individuellen Datenelementen ist. In einem beispielhaften Schleifenzähleraktualisierungsbefehl kann dieses Register die Anfangswerte für jeden der individuellen Schleifenzähler des MDLC-Vektors speichern.
Anschließend identifiziert ein dritter Operand einen zweiten Speicherort 130 (z. B. ein Vektorregister ZMM2), der in einer Ausführungsform möglicherweise ein KL breites Register zur Speicherung von KL individuellen Datenelementen ist. In einem beispielhaften Schleifenzähleraktualisierungsbefehl kann dieses Register die Endwerte für jeden der individuellen Schleifenzähler des MDLC-Vektors speichern.
Schließlich zeigt 3B einen zusätzlichen Speicherort 140, etwa ein anderes Vektorregister, das eine Maske k1 speichert, die eine Vielzahl von Elementen beinhaltet, die je verwendet werden, um zu identifizieren, ob während der Ausführung des Schleifenzähleraktualisierungsbefehls ein konkreter Schleifenzählerwert des Schleifenzählervektors zu maskieren ist. Eine Maske kann auch verwendet werden, wenn die Zahl der Elemente, die in ein Vektorregister passen (KL), größer ist als die Zahl der geschachtelten Schleifen (n). In diesem Fall können obere Elemente von Operanden, die beim Offset n anfangen, in Berechnungen ausmaskiert werden.
Nunmehr wird unter Bezugnahme auf 4 ein Ablaufschema eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Spezieller zeigt 4 ein Verfahren zum Ausführen eines Schleifenzähleraktualisierungsbefehls, wie hierin beschrieben. In einer Ausführungsform lässt sich ein Verfahren 300 durch verschiedene Ausführungslogiken eines Vektorprozessors wie eine oder mehrere Logikeinheiten innerhalb einer Vektorausführungseinheit und/oder einer Skalarausführungseinheit eines Prozessorkerns eines Mehrkernprozessors durchführen. In der Ausführungsform von 4 beginnt das Verfahren 300 dadurch, dass ein decodierter Befehl und mit dem Befehl assoziierte Operanden empfangen werden (Block 305). Optional können auch eine Maske und/oder ein oder mehrere mit dem Befehl assoziierte Immediate-Werte empfangen werden. Als Nächstes wechselt die Steuerung zur Raute 310, um zu bestimmen, ob ein konkretes Element eines Maskenvektors darauf hinweist, dass die Maske für dieses Element aktiv ist.
Falls nein, wechselt die Steuerung zum Block 360, wo eine Inkrementierung einer Elementanzahl stattfindet. Falls alle Elemente des Schleifenzählervektors verarbeitet wurden (an der Raute 370 bestimmt), gelangt die Ausführung dann zum Block 340, wo die Aktualisierungsoperation möglicherweise endet, was auf einen Übergang zu einer nächsten Iteration der zusammengeführten Schleife oder das Ende der zusammengeführten Schleife hinweist. Sonst kehrt die Ausführung zur Raute 310 zurück.
Falls die Antwort an der Raute 310 ja lautet, wechselt die Steuerung zur Raute 320, wo bestimmt werden kann, ob ein momentanes Schleifenzählerwertelement eines Schleifenzählervektors kleiner ist als das korrespondierende Endwertelement eines Endwertvektors. Mit anderen Worten, es wird bestimmt, ob der Schleifenzählerwert nicht der letzte aus dem Bereich der möglichen Werte in einer zugehörigen geschachtelten Schleife ist. Falls er nicht der letzte Wert ist, gelangt die Ausführung zum Block 330, wo das momentane Schleifenzählerwertelement auf seinen Wert bei der nächsten Iteration der zugehörigen geschachtelten Schleife aktualisiert wird. In einer Ausführungsform, in welcher der Schleifenzähleraktualisierungsbefehl ein Inkrementierbefehl ist, kann diese Aktualisierung durch eine Inkrementierung des Werts erfolgen, z. B. um 1 gemäß einer Variante des Befehls oder um einen konfigurierbaren Betrag gemäß einer anderen Variante des Befehls. Die Steuerung wechselt als Nächstes zum Block 340, wo die Aktualisierungsoperation möglicherweise endet, was auf einen Übergang zu einer nächsten Iteration der zusammengeführten Schleife hinweist. In einer Ausführungsform kann eine Verzweigungsoperation erfolgen, um die Steuerung somit an einen Zielort zu übergeben.
Falls nach wie vor unter Bezugnahme auf 4 an der Raute 320 stattdessen bestimmt wird, dass der gegebene Schleifenzähler nicht auf den Wert der nächsten Iteration der zugehörigen geschachtelten Schleife aktualisiert werden kann, wechselt die Steuerung zum Block 350, wo das momentane Schleifenzählerwertelement auf ein korrespondierendes Anfangswertelement eines Anfangswertvektors aktualisiert wird. Es ist zu beachten, dass, falls alle Schleifenzählerwerte auf ihren Anfangswert gesetzt sind und keine Aktualisierung eines Schleifenzählers auf einen Wert bei einer nächsten Iteration einer zugehörigen geschachtelten Schleife stattgefunden hat (Inkrementieroperation), die zusammengeführte Schleife, zu der dieser Befehl gehört, dann beendet wird. Vom Block 350 wechselt die Steuerung zum Block 360, wo eine Elementanzahl für diese Aktualisierungsoperation inkrementiert werden kann, und dementsprechend kann das Verfahren die nächste geschachtelte Schleife durchlaufen. Auch wenn dies in der Ausführungsform von 4 nur grob gezeigt wird, versteht es sich, dass der Schutzbereich der vorliegenden Erfindung in dieser Hinsicht nicht begrenzt ist.
Nunmehr wird unter Bezugnahme auf 5 ein Blockschema eines Abschnitts einer Vektorausführungseinheit gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 5 gezeigt, beinhaltet eine Vektorausführungseinheit 400 verschiedene Logikelemente zum Durchführen von Operationen an Daten, um somit ein gewünschtes Ergebnis zu erzielen. In der in 5 gezeigten Implementierung ist eine Maskendetektionslogik 410 derart gekoppelt, dass sie eingehende Werte, die mit einem Befehl assoziiert sind, empfängt. Im Zusammenhang mit einem Schleifenzähleraktualisierungsbefehl können diese Werte in einer Implementierung so sein wie oben beschrieben, nämlich momentane Werte der Schleifenzähler, Anfangs- und Endwerte für die Schleifenzähler und eine Maske. Die Maskendetektionslogik 410 kann somit für jedes Element des Vektors bestimmen, ob eine Operation durchzuführen ist oder das gegebene Element maskiert werden soll. Falls eine Operation durchzuführen ist, kann eine Vergleichslogik 420 einen Vergleich (zum Beispiel) zwischen einem momentanen Wert eines Schleifenzählerelements und einem gegebenen Anfangs- oder Endwert durchführen.
Nach wie vor unter Bezugnahme auf 5 kann eine Schleifenzähler-/ Steueraktualisierungslogik 430 basierend auf einem Ergebnis des Vergleichs ein Schleifenzählerwertelement aktualisieren, z. B. durch Inkrementieren oder Dekrementieren. Außerdem können auch ein oder mehrere Steuerungswerte aktualisiert werden. Schließlich kann eine Verzweigungslogik 440 bewirken, dass eine Verzweigungsoperation erfolgt, sobald eine Aktualisierung eines Schleifenzählerwertelements erfolgt ist. Es versteht sich ohne Weiteres, dass eine Vektorausführungseinheit eine Logik in größerem Umfang beinhalten kann, um Schleifenzähler- und andere Vektorbefehle durchzuführen.
In einer Ausführungsform kann ein Vektorbefehl auf Benutzerebene verwendet werden, um Zähler für mehrdimensionale Schleifen von einer zusammengeführten, mehrfach geschachtelten Schleife zu inkrementieren. In einer Ausführungsform hat dieser Befehl diese Form: MDLCINC zmm0{k1},zmm1,zmm2. Hier ist zmm1 ein Vektor von Anfangswerten der Schleifenzähler in jeder geschachtelten Schleife (istart_n-1, istart_n-2,..., istart₀), zmm2 ist ein Vektor von Endwerten der Schleifenzähler in jeder geschachtelten Schleife (iend_n-1, iend_n-2, ..., iend₀), zmm0 ist ein Vektor von momentanen Werten der Schleifenzähler (i_n-1, i_n-2, ... , i₀) (und in denen Aktualisierungen gespeichert werden), und k1 ist eine Maske, die eine Teilmenge von Schleifenzählern zum Inkrementieren wählt. Somit wird der Befehl an Elementen des Vektors von momentanen Werten der Schleifenzähler mit einem korrespondierenden Element der Maske k1 eines ersten Werts (z. B. einer Logik 1) durchgeführt, und ein Ergebnis, z. B. kein Inkrement, ein Inkrement oder ein Anfangswert, wird in das korrespondierende Element von zmm0 gespeichert.
Ein Pseudocode des Befehls findet sich in der folgenden Tabelle 2.
Im Allgemeinen arbeitet der Pseudocode von Tabelle 2 somit eine für Schleife, in der für Werte von i, die kleiner sind als die Zahl der Vektorelemente (korrespondierend mit KL), eine bitweise logische UND-Verknüpfung von einem Element aus der Maske und einem Inkrementbitwert (Inc) (am Anfang auf eins gesetzt) überprüft wird. Falls dieses bitweise UND gleich 1 ist, wird ein Vergleich des korrespondierenden Elements des Schleifenzählervektors (korrespondierend mit einem konkreten momentanen Schleifenzählerwert) mit dem korrespondierenden Endwertelement verglichen. Falls der momentane Schleifenzählerwert kleiner als dieser Endzählerwert ist, wird der momentane Schleifenzählerwert inkrementiert und dieser Inkrementbitwert (inc) auf null gesetzt, wodurch bewirkt werden kann, dass weitere Iterationen der Schleife vermieden werden. Alternativ, wie in Tabelle 2 gezeigt, kann hier eine Verzweigungsoperation durchgeführt werden, um weitere Berechnungen von Schleifenzählerwerten zu verhindern.
Falls hingegen der momentane Schleifenzählerwert nicht kleiner als dieser Endzählerwert ist, wird der Anfangswert für das korrespondierende Element im momentanen Schleifenzählervektorelement gespeichert.
Die Maske k1 kann verwendet werden, um zu steuern, welche Schleifenanzahlen inkrementiert werden. In einem Beispiel mit 3 Schleifenzählern, i, j, k, kann eine k1-Maske von „101“ verwendet werden, um Schleifen nur über den i- und den k-Zähler zusammenzuführen. Um zu vermeiden, dass eine der Quellen (z. B. zmm0) überschrieben wird, kann eine implizite Quelle mit dem Befehl verwendet werden, sodass Anfangswerte der Schleifenzähler implizit aus einem anderen Vektorregister, z. B. zmm5, übernommen werden. Alternativ kann eine 4-Operanden-Befehlscodierung verwendet werden, die diese zusätzliche Operandenreferenz beinhaltet.
Mit dem oben angeführten Schleifenzählerinkrementierbefehl kann eine beispielhafte 3-fach geschachtelte Schleife so aussehen wie in Tabelle 3.
Es ist zu beachten, dass in der obigen Schleife der Extrahierbefehl, extract(position,zmm0), verwendet wird, um ein Element des Vektors zmm0, das bei einem Offset gleich der Position steht, zurückzugeben. Daher lautet er einfach zmm0[position].
Ausführungsformen können somit einen Overhead von Verzweigungen innerhalb zusammengeführter Schleifen vermeiden. Einer der Zwecke der Schleifenzusammenführung besteht darin, dass die Gesamtzahl von Verzweigungen und falschen Verzweigungsvorhersagen verringert wird. Eine Verwendung von Verzweigungen mit Bezug auf die Steuerung, welche Schleifenzähler zu inkrementieren sind, kann eventuelle Leistungssteigerungen infolge einer Zusammenführung zunichte machen. Auch vermeiden Ausführungsformen einen Overhead von Speicherreferenzen innerhalb der zusammengeführten Schleife, da alle geschachtelten Schleifenzähler in einem Vektorregister liegen und z. B. durch einen einzelnen Befehl (z. B. einen vpcompress-Befehl) ohne die Referenzierung des Speichers extrahiert werden können. Außerdem kann der MDLC-Vektor im bestehenden Zustand von einem Befehl verwendet werden, um Offsets innerhalb eines mehrdimensionalen Arrays zu kalkulieren. Dadurch wird der Overhead für Zugriffe auf mehrdimensionale Arrays verringert. Ausführungsformen können auch die Gesamtzahl der zum Implementieren der Schleifenzusammenführung verwendeten Befehle verringern.
In manchen Fällen weisen zusammengeführte Schleifen möglicherweise Schleifenzählerwerte auf, die unterschiedlich zu inkrementieren sind, indem zu jedem Schleifenzähler eine andere Zahl addiert wird. Ein Beispiel für eine geschachtelte Schleife mit unterschiedlich inkrementierten Schleifenzählerwerten kann Tabelle 4 entnommen werden.
Eine 3-Operanden-Form des obigen Inkrementierbefehls, der ein sogenanntes Schrittweite-Inkrement für den Schleifenzählervektor bereitstellt, lautet wie folgt: MDLCINCSTR zmm0{k1},zmm1,zmm2. Hier ist zmm0 ein Vektor von momentanen Werten von Schleifenzählern (i_n-1, i_n-2, ..., i₀), zmm1 ist ein Vektor von Inkrementfaktoren (auch als Schrittweitewerte bezeichnet) in jeder Dimension (str_n-1,str_n-2,... ,str₀), zmm2 ist ein Vektor von Differenzen zwischen End- und Anfangswerten von Schleifenzählern in jeder geschachtelten Schleife (iend_n-1, istart_n-1, etc.), und k1 ist eine Maske, die eine Teilmenge von Schleifenzählern zum Inkrementieren wählt. Es ist zu beachten, dass ein Vektor der Anzahl von Iterationen aus diesen Werten als (zmm2/zmm1+zmm_ones) erhalten werden kann, wobei zmm_ones ein Vektor von Einsen ist.
Ein Pseudocode dieses Befehls findet sich in der folgenden Tabelle 5.
Um die genauen Werte der Indizes (Schleifenzähler) für weitere Berechnungen zu erhalten, kann ein Vektor von Anfangsindizes zum Ergebnis addiert werden, zum Beispiel können Anfangsindizes zum resultierenden Schleifenzählervektor wie folgt addiert werden (zmm_start=(istart_n-1, istart_n-2, ..., istart₀)). In einer Ausführungsform kann ein Vektoradditionsbefehl verwendet werden: VPADD zmm4,zmm_start,zmm0.
Der Overhead in Bezug auf die Verschiebung von Schleifenzählerwerten auf die Basis null kann unter Verwendung einer Befehlsform mit 4 Operanden eliminiert werden. Dieser Befehl kann folgende Form haben: MDLCINSCSTR zmm0{k1}, zmm1, zmm2, zmm3, wobei zmm0 = momentane Werte, zmm1 = Schrittweiten, zmm2 = Anfangswerte und zmm3 = Endwerte, und k1 ist eine Maske. Diese Form wird in Tabelle 5.1 gezeigt:
Mit der oben dargelegten Form einer Codierung mit 3 Operanden kann ein Beispiel für eine 3-fach geschachtelte Schleife so aussehen wie in Tabelle 6.
Die Zusammenführung von mehrfach geschachtelten Schleifen kann auch unter Verwendung eines Befehls erleichtert werden, der einen Zähler für mehrdimensionale Schleifen dekrementiert. Ein Beispiel für eine geschachtelte Schleife mit unterschiedlich dekrementierten Schleifenzählerwerten kann Tabelle 7 entnommen werden.
In einer Ausführungsform kann dieser Befehl folgende Form haben: MDLCDEC zmm0{k1},zmm1,zmm2, wobei zmm1 ein Vektor von Anfangswerten von Schleifenzählern ist (istart_n-1,istart_n-2,...,istart₀), zmm2 ein Vektor von Endwerten von Schleifenzählern ist (iend_n-1,iend_n-2,...,iend₀), zmm0 ein Vektor von momentanen Werten von Schleifenzählern ist (i_n-1,i_n-2,...,i₀) und k1 eine Maske ist, die eine Teilmenge von Schleifenzählern zum Dekrementieren wählt. Der resultierende zmm0-Vektor enthält Werte von Schleifenzählern für die nächste Iteration der zusammengeführten Schleife. Ein Pseudocode dieses Befehls findet sich in der folgenden Tabelle 8.
Dieser Dekrementierbefehl kann zum Beispiel für eine 3-fach geschachtelte skalare Schleife wie in der folgenden Tabelle 9 verwendet werden.
Falls nur eine Teilmenge der Schleifen zusammengeführt werden soll, kann eine andere k-Maske verwendet werden. Im obigen Beispiel kann die Schleifenzusammenführung über i und k mit den gleichen Vektoren zmm0, zmm1, zmm2 durch eine Binärmaske k1= 101 erfolgen.
Das Erhalten des Werts eines individuellen Zählers (falls nötig) kann durch Vektorextraktionsbefehle erfolgen, z. B. einen vpextr-Befehl. Im obigen Beispiel kann der j-Zähler durch folgenden Befehl extrahiert werden: vpextr r64, zmm0,1. Hier ist 1 ein Offset des j-Werts innerhalb des Zählers für mehrdimensionale Schleifen zmm0, der j-Wert befindet sich im skalaren r64-Register.
In anderen Beispielen weist eine geschachtelte Schleife möglicherweise Zählerwerte auf, die gemäß einer Variable oder Schrittweitedekrementierwerten dekrementiert werden. Nunmehr wird unter Bezugnahme auf Tabelle 10 ein Beispiel für eine geschachtelte Schleife mit unterschiedlich dekrementierten Schleifenzählerwerten gezeigt.
In einer Ausführungsform hat ein Dekrementierschrittweitebefehl zum Dekrementieren ausgewählter Datenelemente durch einen individuell steuerbaren Schrittweitebetrag möglicherweise folgende Form: MDLCDECSTR zmm0{k1},zmm1,zmm2. In diesem Fall speichert zmm0 die momentanen Schleifenzählerwerte, zmm1 speichert den Schrittweitewert, und zmm2 speichert die Differenzen zwischen Anfangswerten und Endwerten (istart_j - iend_j).
Ein Pseudocode dieses Befehls findet sich in der folgenden Tabelle 11.
Eine Form dieses Befehls mit 4 Operanden sieht aus wie in der folgenden Tabelle 11.1 gezeigt.
Eine beispielhafte zusammengeführte Schleife für eine 3-fach geschachtelte Schleife unter Verwendung dieses Dekrementierschrittweitebefehls kann aussehen wie in der folgenden Tabelle 12 gezeigt.
Allgemeiner kann ein Befehl in manchen Ausführungsformen eine individuelle Inkrementier- oder Dekrementiersteuerung von Schleifenzählerwerten eines Schleifenzählerwertvektors (in beiden Fällen von steuerbaren Faktoren) gewährleisten. Auf diese Weise lassen sich die unterschiedlichen Anzahlen einer zusammengeführten Schleife individuell inkrementieren oder dekrementieren, indem zu jeder eine andere Zahl addiert wird. Insbesondere müssen nicht alle Schleifen inkrementiert oder dekrementiert werden, vielmehr können manche der Schleifen dekrementiert werden, während andere inkrementiert werden. Der Fall, dass alle Schleifen gleichmäßig inkrementiert oder dekrementiert werden, kann eintreten, wenn andere Varianten eines Befehls zur Steuerung eines Zählers für mehrdimensionale Schleifen, wie oben beschrieben, verwendet werden.
Unter Verwendung eines solchen Befehls können manche Schleifen ein Inkrement und andere Schleifen ein Dekrement aufweisen, ohne separate Befehle zum Eingehen auf jede Gruppe zu verwenden, was mit der Erstellung einer zweckdienlichen Maske einherginge, um die Schleifen, in denen inkrementiert wird, und diejenigen, in denen dekrementiert wird, zu isolieren.
Dieser verallgemeinerte Inkrementier-/Dekrementierbefehl kann in Situationen wie in Tabelle 13 nützlich sein, in denen manche Schleifen inkrementiert und manche Schleifen dekrementiert werden.
In einer Ausführungsform hat dieser verallgemeinerte Befehl zum Bereitstellen entweder eines Inkrements oder eines Dekrements von ausgewählten Schleifenzählern möglicherweise die Form MDLCINCDEC zmm0{k1},zmm1,zmm2,imm, wobei zmm0 die momentanen Werte für den Schleifenzählervektor ist, zmm1 Anfangswerte beinhaltet, zmm2 Endwerte beinhaltet, imm ein unmittelbarer Operand von n-Bits ist (n - Anzahl geschachtelter Schleifen), wodurch gezeigt wird, welche Schleifen inkrementiert (imm[i]=1) und welche dekrementiert (imm[i]=0) werden. Ein Pseudocode für diesen Befehl findet sich in der folgenden Tabelle 14.
Für die 3-fach geschachtelte Schleife von Tabelle 15 unten kann dieser verallgemeinerte Inkrementier-/Dekrementierbefehl verwendet werden.
Die zusammengeführte Schleife hat wieder die gleiche Form:
Es ist zu beachten, dass die Inkrementier-/Dekrementiersteuerung auf unterschiedliche Weisen codiert werden kann. Zum Beispiel kann ein 8-Bit-Immediate verwendet werden, der die Anzahl der zu inkrementierenden oder dekrementierenden Schleife auf 8 begrenzt. Dies ist sinnvoll, da selten mehr als 8 Schleifen geschachtelt sind. Alternativ kann ein dritter Operand diese Steuerung codieren, oder dies kann unter Verwendung einer Maske oder eines Universalregisters (GPR) erfolgen. Sie kann auch als implizite Quelle (z. B. RAX) codiert werden.
Alternative Implementierungen, mittels deren sich ein Überschreiben von zmm0 (Vektor momentaner Werte) vermeiden lässt, beinhalten die Codierung einer dritten Quelle (wird zu einem 4-Operanden-Befehl) oder die Übernahme einer impliziten Quelle, z. B. implizites Inkrementieren von Anzahlen in ZMM5.
In anderen Implementierungen können verallgemeinerte Befehle für Inkrementierungen/Dekrementierungen um eine Schrittweite bereitgestellt werden, sodass manche Schleifen um steuerbare Beträge inkrementiert und manche Schleifen um steuerbare Beträge dekrementiert werden. Solche Situationen können im folgenden Code von Tabelle 16 eintreten.
In einer Ausführungsform kann dieser verallgemeinerte Befehl zum Bereitstellen entweder einer Inkrementierung oder einer Dekrementierung eines ausgewählten Betrags für ausgewählte Datenelemente folgende Form haben: MDLCINCDECSTR zmm0{k1},zmm1,zmm2,imm, wobei zmm0 die momentanen Schleifenzählerwerte bereitstellt, zmm1 Schrittweitewerte sind, zmm2 Werte von Differenzen zwischen End- und Anfangswerten sind, imm ein unmittelbarer Operand von n-Bits ist (n - Anzahl geschachtelter Schleifen), wodurch gezeigt wird, welche Schleifen inkrementiert (imm[i]=1) und welche dekrementiert (imm[i]=0) werden. Ein Pseudocode für diesen Befehl findet sich in der folgenden Tabelle 17.
Die folgende geschachtelte Schleife von Tabelle 18 kann unter Verwendung eines oder mehrerer Befehle gemäß einer Ausführungsform der vorliegenden Erfindung in eine zusammengeführte Form umgewandelt werden.
Die zusammengeführte Schleife hat wieder die gleiche Form:
Ausführungsformen stellen ein Verfahren zum Zusammenführen von mehrfach geschachtelten Schleifen durch Verwendung eines Zählers für mehrdimensionale Schleifen und von Inkrementierbefehlen bereit. In einer Ausführungsform kann eine Berechnung von Anzahlen von Iterationen der zusammengeführten Schleife bereitgestellt werden, die bei der Berechnung zu verwendenden Schleifenzählerwerte können extrahiert werden, und dann wird ein Inkrementierbefehl, wie hierin beschrieben, ausgeführt, wie in Tabelle 19 ersichtlich.
In noch einer anderen Ausführungsform kann der Schleifenzählerbefehl in Verbindung mit einer Aktualisierung eines oder mehrerer Flags eines Statusregisters wie eines Flagregisters verwendet werden. Zum Beispiel erfolgt eine Aktualisierung eines Zero-Flags (ZF) oder eines Carry-Flags (CF) eines Flagregisters eines Prozessors möglicherweise wie folgt: if (inc == 0) ZF=1; if (inc ==1) CF=1. Dies ist auf alle Typen von Inkrementierbefehlen anwendbar. Falls (inc==0), bedeutet dies, dass eine Inkrementierung vorgenommen wurde und die Schleife erfolgreich zur nächsten Iteration der zusammengeführten Schleife übergegangen ist. Falls (inc ==1), bedeutet dies, dass alle Schleifenzähler auf Anfangswerte aktualisiert wurden, jedoch keine Inkrementierung vorgenommen wird, mit anderen Worten, die zusammengeführte Schleife ist vorbei. Eine solche Steuerung kann für die Steuerung des Endes einer zusammengeführten Schleife verwendet werden. Inkrementierbefehle mit einer Flagmodifikation können verwendet werden, um Schleifen zusammenzuführen, wie in Tabelle 20 ersichtlich.
und der Schleifenzählervektor (mdlc) bereits gleich 3:3:3 ist, tritt nach dem Inkrementieren von MDLCINCFLAG(mdlc) das Ergebnis mdlc=1:1:1 ein und CF==1 (ZF==1).
Ausführungsformen können auch verwendet werden, um zusammengeführte Schleifen mit Berechnungen über Schleifenzähler von geschachtelten Schleifen (i_k) und Zugriffen auf mehrdimensionale Arrays zu vektorisieren.
Durch die Zusammenführung von Schleifen und die Vektorisierung der zusammengeführten Schleife kann auf eine Menge individueller Datenelemente aus einer mehrdimensionalen Datenstruktur zugegriffen werden, welche bei einer oder mehreren Vektorberechnungen verwendet werden können. Die Ergebnisse dieser Berechnungen können dann wieder an den ursprünglichen Orten der Datenstruktur gespeichert werden, oder an anderen Orten in dieser Datenstruktur oder einer anderen mehrdimensionalen Datenstruktur.
Um derartige Schleifenzusammenführungs- und -vektorisierungsoperationen effizient durchzuführen, können sich Ausführungsformen sowohl die hierin beschriebenen Befehle zum Inkrementieren eines Zählers für mehrdimensionale Schleifen als auch einen Offsetkalkulationsbefehl zunutze machen. Im Allgemeinen kann dieser Befehl dazu dienen, einen Vektor von Offsets für den Zugriff auf individuelle Datenelemente effizient zu berechnen. In anderen Ausführungsformen können andere Typen von vektorbasierten Befehlen wie Broadcast-, Vektoradditions- und Vektormultiplikationsbefehle verwendet werden, um einen Vektor von Offsets für den Zugriff auf individuelle Datenelemente eines mehrdimensionalen Arrays zu berechnen.
Es ist zu beachten, dass die Vektorisierung der innersten Schleife bei einer geringen Anzahl von Iterationen ineffizient sein kann, und in diesem Fall ist eine Schleifenzusammenführung insofern hilfreich, als sich die Schleifengesamtzahl erhöht. Als Beispiel sei eine 3-fach geschachtelte Schleife angeführt: $\begin{array}{l} for (k = 1; k < = 100; k + +) for (j = 1; j < = 7; j + = 2) for (i = 0; i < = 2 i + +) \\ A [k] [j] [i] = computation (i,j,k); \end{array}$
Es gibt keine Abhängigkeiten zwischen Iterationen und die innere Schleife kann vektorisiert werden. Angenommen, es gilt KL=8. Daraufhin berechnen wir 3 Iterationen der inneren Schleife durch Vektorbefehle mit einer zweckdienlichen Maske k2=00000111. Insgesamt erfolgen 400 (100*4) Vektorberechnungen mit einer Effizienz von 3/8. Die Vektoreffizienz ist definierbar als Anzahl von Elementen, für die das Ergebnis der Berechnung als Ausgabe gespeichert wird, dividiert durch die Anzahl von Elementen, für die die Berechnung ausgeführt wurde. Um eine bessere Vektoreffizienz zu bewerkstelligen, wird bei diesem Beispiel a) erstens die Schleife mit einem der hierin beschriebenen Verfahren zusammengeführt, welches eine Anzahl von Iterationen mit dem Wert 1200 (100*4*3) bereitstellt, und b) zweitens die zusammengeführte Schleife mit einem der hierin beschriebenen Verfahren vektorisiert, um 150 (1200/8) Vektorberechnungen je mit einer Effizienz von 100% bereitzustellen.
Nunmehr wird unter Bezugnahme auf 5A ein Ablaufschema eines Verfahrens zum Vektorisieren eines Codesegments, wie hierin beschrieben, gezeigt. Wie in 5A ersichtlich, kann das Verfahren 470 damit beginnen, dass eine Schleifentransformation durchgeführt wird, um eine N-fach geschachtelte Schleife zu einer Einzelschleife zusammenzuführen. In einer Ausführungsform kann diese Schleifenzusammenführungsoperation wie oben beschrieben durchgeführt werden. Danach kann die zusammengeführte Schleife vektorisiert werden (Block 490). Diese Vektorisierung kann unter Verwendung bestimmter Vektorbefehle, die hierin beschrieben werden, durchgeführt werden, um einen effizienten Zugriff auf ausgewählte Datenelemente aus einer mehrdimensionalen Datenstruktur und eine effiziente Aktualisierung dieser Datenelemente zu ermöglichen. Auch wenn dies in der Ausführungsform von 5A nur grob gezeigt wird, versteht es sich, dass der Schutzbereich der vorliegenden Erfindung in dieser Hinsicht nicht begrenzt ist.
Die bei der Vektorisierung von zusammengeführten Schleifen verwendeten Basisterme sind die folgenden Vektoren. 1) Ein Vektor zmm_i_k, der eine Menge von Werten von i_k pro Iteration eines Vektorblocks ist (zmm_i_k[j] = zmm_mdlk_on_j_iteration[k]). Dieser Vektor kann auf unterschiedliche Weisen verwendet werden: direkt durch Vektorbefehle bei Vektorberechnungen, als Vektor von Offsets innerhalb 1-dimensionaler Arrays (B[i_k]) oder für Berechnungen von Offsets innerhalb mehrdimensionaler Arrays. 2) Ein Vektor von Offsets innerhalb mehrdimensionaler Arrays. Dieser Vektor kann direkt als Vektor von Indizes für Gather/Scatter-Datenelemente verwendet werden. Ein Modell für eine Schleife mit Zugriff auf ein m-dimensionales Array A (m<=n), deklariert als A[N_m-1][N_m-2]..[N₁][N₀], sieht so aus wie in Tabelle 21 gezeigt.
Das Verfahren zum Vektorisieren dieser Berechnungen innerhalb einer mehrfach geschachtelten Schleife beinhaltet zwei Phasen. 1) Generieren einer zusammengeführten Schleife, die aus einer Vielzahl von Schleifen ausgebildet wird, durch eines der oben beschriebenen Verfahren. Nach der Zusammenführung kann die Schleife folgendermaßen aussehen:
2) Angenommen, es bestehen keine Datenabhängigkeiten zwischen Iterationen der zusammengeführten Schleife, und angenommen, die Anzahl der Iterationen der zusammengeführten Schleife ist durch KL dividierbar, lassen sich Berechnungen wie im folgenden Beispiel für eine zusammengeführte Schleife vektorisieren. Die innere Schleife über den Elementoffset innerhalb des Vektors ist vorgesehen zum Generieren einer Menge von Vektoren von extrahierten Zählern für eindimensionale Schleifen und Offsets zum Zugreifen auf ein Array A, wie in Tabelle 22 gezeigt. Nach der Ausführung dieser Schleife erfolgen Operationen, bei denen Datenelemente aus dem Array geladen, Kalkulationen durchgeführt und die Ergebnisse dann wieder im Array (oder in einem anderen Array) gespeichert werden.
In anderen Ausführungsformen kann die Vektorisierung von zusammengeführten Schleifen mit Zugriffen auf mehrdimensionale Arrays unter Verwendung eines MDOFFSET-Befehls bewerkstelligt werden. Der Unterschied zum gerade beschriebenen Verfahren besteht darin, wie ein Vektor von Offsets zum Zugreifen auf Arrays generiert wird, wie in Tabelle 24 unten gezeigt.
Wie in Tabelle 24 ersichtlich sein wird, kann MDOFFSET verwendet werden, um eine Segmentadresse automatisch zu kalkulieren, nämlich die Adresskomponente für ein speziell anvisiertes Segment einer mehrdimensionalen Struktur. In einer Ausführungsform hat dieser Befehl diese Form: MDOFFSET V1; V2. Speziell akzeptiert der MDOFFSET-Befehl zwei Eingangsvektoroperanden: 1) einen ersten Eingangsvektoroperanden V1, der das spezifische Segment der mehrdimensionalen Struktur, dessen Adresse gewünscht wird, definiert; und 2) einen zweiten Eingangsvektoroperanden V2, der die Dimensionen und die jeweiligen Größen der Dimensionen der anvisierten mehrdimensionalen Struktur definiert.
Speziell wird V1 gemäß einer Ausführungsform so ausgedrückt: V1 = i_n-1, i_n-2, ...., i0 für eine mehrdimensionale Struktur mit n Dimensionen. Hier korrespondiert V1 mit den Koordinaten des Segments der mehrdimensionalen Struktur, die anvisiert wird. Gemäß einer Ausführungsform wird V2 so ausgedrückt: V2 = N_n-1, N_n-2, ... N₀. Hier korrespondiert jedes N_i-Element von V2 mit der Länge der mehrdimensionalen Struktur in der i. Dimension. Gemäß einem Ansatz korrespondiert eines der Segmente mit dem „Ursprung“ der mehrdimensionalen Struktur und die Segmentkoordinaten sind als segmentweiser Offset vom Ursprung in jeder Dimension spezifiziert.
Bei einer beispielhaften Ausführung lässt sich MDOFFSET wie folgt durchführen:
Falls zum Beispiel innerhalb einer n-fach geschachtelten Schleife (B[I₄][I₂][I₀]) auf ein 3-dimensionales Array B[N₄][N₂][N₀] zugegriffen werden soll, könnte dies durch MDOFFSET über die gleichen n-dimensionalen Vektoren geschehen, jedoch mit einer Maske k1=10101: MDOFFSET [(i_n-1,i_n-2,...,i₀), (N_n-1,N_{n- 2},...,N₀), k₁]=
i₄*( N₂*N₀)+
i₂*(N₀)+
i₀)
Tabelle 24 ist eine beispielhafte Vektorisierung einer zusammengeführten Schleife unter Verwendung eines MDOFFSET-Befehls.
Eine andere Ausführungsform eines Vektorisierungsverfahrens beinhaltet die Verwendung von Zustandsflags zur Steuerung des Schleifendurchlaufs. Durch die Verwendung einer solchen Ausführungsform kann die Berechnung der Anzahl von Iterationen einer zusammengeführten Schleife und die Möglichkeit zum Umgang mit Fällen, in denen die Anzahl von Iterationen einer zusammengeführten Schleife nicht durch die Zahl der Elemente in einem Vektor (KL) dividierbar ist, eliminiert werden. Eine beispielhafte zusammengeführte Schleife in dieser Form wird in Tabelle 25 gezeigt.
Um ein weiteres Beispiel zu nennen, falls Berechnungen über Schleifenzähler erfolgen, sieht eine vektorisierte Schleife mit einer Steuerung über Zustandsflags so aus wie in Tabelle 26 gezeigt.
Nunmehr wird unter Bezugnahme auf 5B ein Ablaufschema eines Verfahrens gemäß einer anderen Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 5B ersichtlich, fängt die Ausführung bei Block 500 an. Zunächst werden alle erforderlichen Werte im Block 510 initialisiert, etwa indem eine Maske von Berechnungen (k1) auf alle Einsen (eine vollständige Maske) gesetzt wird. Am Block 515 werden Werte aus einem Zähler für mehrdimensionale Schleifen, zmm_mdlc, extrahiert. Die extrahierten Werte werden dann in einem Vektorspeicher bei einem momentanen Offset j gespeichert. In einer Ausführungsform kann diese Operation beinhalten, dass Offsets in mehrdimensionalen Strukturen kalkuliert werden, falls ein MDOFFSET-Befehl verwendet wird, wie oben beschrieben.
Nach wie vor unter Bezugnahme auf 5B wird am Block 520 ein Zähler für mehrdimensionale Schleifen inkrementiert, z. B. um eins. In einer Ausführungsform lässt sich diese Inkrementierung durch die Ausführung eines Inkrementierbefehls realisieren, wie hierin anhand einer Zustandsflagaktualisierung beschrieben. Als Nächstes kann an der Raute 525 bestimmt werden, ob ein Durchlauf durch eine zusammengeführte Schleife erfolgt ist. In einer Ausführungsform kann diese Bestimmung auf einem oder mehreren aktualisierten Zustandsflags basieren.
Wenn die Schleife durchlaufen ist, gelangt die Ausführung zum Block 530, wo eine Maske von Berechnungen (k1) aktualisiert wird, um einen nicht vollständigen Block von Iterationen zu verarbeiten (in einer Ausführungsform kann dies durch die Sequenz k1 = 1 <<(j+1)-1 oder irgendeine andere äquivalente Sequenz vorgenommen werden). Als Nächstes wechselt die Steuerung zum Block 535, wo Vektorberechnungen gemäß der Rechenmaske k1 vorgenommen werden. In verschiedenen Ausführungsformen beinhalten diese Operationen möglicherweise das Zugreifen auf mehrdimensionale Strukturen, das Durchführen von Berechnungen über einen Vektor von Schleifenzählern und andere mögliche Berechnungen.
Falls an der Raute 525 bestimmt wird, dass die Schleife noch nicht durchlaufen ist, wechselt die Ausführung zur Raute 550, wo bestimmt werden kann, ob alle Blöcke der KL Iterationen verarbeitet wurden. Falls ja (also falls der gesamte Block verarbeitet wurde), wechselt die Ausführung zum Block 535, wo Vektorberechnungen über eine Vielzahl von Vektoren gemäß der Rechenmaske k1 vorgenommen werden. Es ist zu beachten, dass, wenn die Steuerung von der Raute 550 ausgeht, die Maske k1 vollständig ist (im Gegensatz dazu, wenn sie vom Block 530 mit einer Restmaske herstammt). Falls an der Raute 550 nicht alle Iterationen des Blocks verarbeitet wurden, wird am Block 555 der momentane Offset inkrementiert und die Ausführung gelangt wieder zum Block 515.
Nachdem am Block 535 Vektorberechnungen vorgenommen worden sind, wechselt die Steuerung zur Raute 540, wo bestimmt werden kann, ob die zusammengeführte Schleife durchlaufen wurde, was in dieser Ausführungsform auf dem aktualisierten Flag basieren kann. Falls die Schleife durchlaufen wurde, wie an der Raute 540 bestimmt, endet das Verfahren 500 am Endblock 545. Falls die Schleife hingegen nicht durchlaufen wurde, wie an der Raute 540 bestimmt, wird der momentane Offset (am Block 560) auf null gesetzt, und ein nächster Block von KL Iterationen wird angegangen, wobei zum Block 515 zurückgekehrt wird. Der Block 515 hat somit 3 Einträge und der Block 535 hat 2 Einträge. Auch wenn dies anhand dieser konkreten Implementierung beschrieben wird, versteht es sich, dass der Schutzbereich der vorliegenden Erfindung in dieser Hinsicht nicht begrenzt ist.
Die hierin beschriebenen Befehlsvariationen können zusammen mit einem Befehl zum Kalkulieren von Offsets in mehrdimensionalen Arrays verwendet werden. Durch die Verwendung solcher Kombinationen können Komprimierungs-/ Extraktionsbefehle, um je individuelle Zählerwerte für den Zugriff auf ein Array zu erhalten, vermieden werden. Statt dieser Offsetkalkulation verwendet der Befehl den Vektor der momentanen Schleifenzähler, um den Offset aus einer Anfangsadresse des Arrays zu berechnen.
Beispielhafte Befehlsformate
Ausführungsformen des/der hierin beschriebenen Befehls/Befehle können in unterschiedlichen Formaten ausgeführt sein. Der/die hierin beschriebene(n) Befehl(e) ist/sind zum Beispiel möglicherweise in einem VEX-, einem allgemeinen vektorfreundlichen oder einem anderen Format ausgeführt. Einzelheiten zu einem VEX- und zu einem allgemeinen vektorfreundlichen Format werden unten erörtert. Des Weiteren wird unten ausführlich auf beispielhafte Systeme, Architekturen und Pipelines eingegangen. Ausführungsformen des Befehls/der Befehle können in derartigen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf diejenigen begrenzt, auf die ausführlich eingegangen wird.
VEX-Befehlsformat
Die VEX-Codierung erlaubt, dass Befehle mehr als zwei Operanden aufweisen, und erlaubt, dass SIMD-Vektorregister länger als 128 Bits sind. Die Verwendung eines VEX-Präfixes gewährleistet eine Syntax mit drei (oder mehr) Operanden. Zum Beispiel haben zwei vorangehende Befehle mit zwei Operanden Operationen wie A = A + B durchgeführt, wodurch ein Quelloperand überschrieben wurde. Die Verwendung eines VEX-Präfixes ermöglicht, dass Operanden nicht zerstörende Operationen wie A = B + C durchführen.
6A veranschaulicht ein beispielhaftes AVX-Befehlsformat, das ein VEX-Präfix 602, ein reales Opcode-Feld 630, ein Mod-R/M-Byte 640, ein SIB-Byte 650, ein Verschiebungsfeld 662 und IMM8 672 beinhaltet. 6B veranschaulicht, welche Felder aus 6A ein vollständiges Opcode-Feld 674 und ein Basisoperationsfeld 642 bilden. 6C veranschaulicht, welche Felder aus 6A ein Registerindexfeld 644 bilden.
Das VEX-Präfix (Bytes 0-2) 602 ist in einer Form mit drei Bytes codiert. Das erste Byte ist das Format-Feld 640 (VEX-Byte 0, Bits [7:0]), das einen expliziten C4-Byte-Wert enthält (den eindeutigen Wert, der zum Unterscheiden des C4-Befehlsformats verwendet wird). Das zweite und das dritte Byte (VEX-Bytes 1-2) beinhalten eine Zahl von Bitfeldern, die eine spezifische Fähigkeit bereitstellen. Speziell besteht ein REX-Feld 605 (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 unteren drei Bits der Registerindizes, wie aus dem Stand der Technik bekannt ist (rrr, xxx und bbb), sodass Rrrr, Xxxx und Bbbb ausgebildet werden können, indem VEX.R, VEX.X und VEX.B hinzugefügt werden. Ein Opcode-Map-Feld 615 (VEX-Byte 1, Bits [4:0] - mmmmm) beinhaltet Inhalt zum Codieren eines implizierten führenden Opcode-Bytes. Ein W-Feld 664 (VEX-Byte 2, Bit [7] - W) wird durch die Notation VEX.W dargestellt und stellt unterschiedliche Funktionen abhängig vom Befehl bereit. VEX.vvvv 620 (VEX-Byte 2, Bits [6:3]-vvvv) kann folgende Funktion erfüllen: 1) VEX.vvvv codiert den ersten Quellregisteroperanden, der in invertierter (Einerkomplement-)Form spezifiziert und für Befehle mit 2 oder mehr Quelloperanden gültig ist ; 2) VEX.vvvv codiert den Zielregisteroperanden, der in Einerkomplement-Form für bestimmte Vektorverschiebungen spezifiziert ist; oder 3) VEX.vvvv codiert gar keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Falls VEX.L 668 Größe-Feld (VEX-Byte 2, Bit [2]-L) = 0, wird dadurch ein 128-Bit-Vektor angegeben; falls VEX.L = 1, wird dadurch ein 256-Bit-Vektor angegeben. Das Präfixcodierfeld 625 (VEX-Byte 2, Bits [1:0]-pp) stellt zusätzliche Bits für das Basisoperationsfeld bereit.
Das reale Opcode-Feld 630 (Byte 3) ist auch als Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert.
Ein MOD-R/M-Feld 640 (Byte 4) beinhaltet ein MOD-Feld 642 (Bits [7-6]), ein Reg-Feld 644 (Bits [5-3]) und ein R/M-Feld 646 (Bits [2-0]). Die Funktion des Reg-Felds 644 kann Folgendes beinhalten: Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden (des rrr von Rrrr) oder Behandlung als Opcode-Erweiterung und Nichtverwendung zum Codieren von Befehlsoperanden. Die Funktion des R/M-Felds 646 kann Folgendes beinhalten: Codieren des Befehlsoperanden, der eine Speicheradresse referenziert, oder Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden.
Scale, Index, Base (SIB) - Der Inhalt des Skalierfelds 650 (Byte 5) beinhaltet SS652 (Bits [7-6]), das für die Speicheradressengenerierung verwendet wird. Auf die Inhalte von SIB.xxx 654 (Bits [5-3]) und SIB.bbb 656 (Bits [2-0]) wurde bisher im Zusammenhang mit den Registerindizes Xxxx und Bbbb eingegangen.
Das Verschiebungsfeld 662 und das Immediate-Feld (IMM8) 672 enthalten Adressdaten.
Allgemeines vektorfreundliches Befehlsformat
Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das für Vektorbefehle geeignet ist (z. B. gibt es bestimmte Felder, die speziell für Vektoroperationen vorgesehen sind). Wenngleich Ausführungsformen beschrieben werden, in denen sowohl Vektor- als auch Skalaroperationen durch das vektorfreundliche Befehlsformat unterstützt werden, verwenden alternative Ausführungsformen nur Vektoroperationen das vektorfreundliche Befehlsformat.
Die 7A und 7B sind Blockschemata, die ein allgemeines vektorfreundliches Befehlsformat und Befehlsmodelle dazu gemäß Ausführungsformen der Erfindung veranschaulichen. 7A ist ein Blockschema, das ein allgemeines vektorfreundliches Befehlsformat und Klasse-A-Befehlsmodelle davon gemäß Ausführungsformen der Erfindung veranschaulicht; während 7B ein Blockschema ist, das das allgemeine vektorfreundliche Befehlsformat und Klasse-B-Befehlsmodelle davon gemäß Ausführungsformen der Erfindung veranschaulicht. Speziell ein allgemeines vektorfreundliches Befehlsformat 700, für das Klasse-A- und Klasse-B-Befehlsmodelle definiert sind, die beide Nichtspeicherzugriff(705)-Befehlsmodelle und Speicherzugriff(720)-Befehlsmodelle beinhalten. Der Begriff allgemein bezieht sich im Zusammenhang mit dem vektorfreundlichen Befehlsformat auf das Befehlsformat, das an keinen spezifischen Befehlssatz gebunden ist.
Es werden Ausführungsformen der Erfindung beschrieben, in denen das vektorfreundliche Befehlsformat Folgendes unterstützt: eine 64-Byte-Vektoroperandenlänge (oder -größe) mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte) oder 64 Bit (8 Byte) (und somit ein 64-Byte-Vektor entweder aus 16 Elementen in Doppelwortgröße oder alternativ aus 8 Elementen in Vierfachwortgröße besteht); eine 64-Byte-Vektoroperandenlänge (oder -größe) mit Datenelementbreiten (oder -größen) von 16 Bit (2 Byte) oder 8 Bit (1 Byte); eine 32-Byte-Vektoroperandenlänge (oder -größe) mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte); und eine 16-Byte-Vektoroperandenlänge (oder -größe) mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte); alternative Ausführungsformen können jedoch auch mehr, weniger und/oder andere Vektoroperandengrößen (z. B. 256-Byte-Vektoroperanden) mit mehr, weniger oder anderen Datenelementbreiten (z. B. Datenelementbreiten von 128 Bit (16 Byte)) unterstützen.
Die Klasse-A-Befehlsmodelle in 7A beinhalten Folgendes: 1) innerhalb der Nichtspeicherzugriff(705)-Befehlsmodelle gezeigt sind ein Nichtspeicherzugriff-, Ganzrundungssteuerungstypoperation(710)-Befehlsmodell und ein Nichtspeicherzugriff-, Datentransformationstypoperation(715)-Befehlsmodell; und 2) innerhalb der Speicherzugriff(720)-Befehlsmodelle gezeigt sind ein Speicherzugriff-, Temporal(725)-Befehlsmodell und ein Speicherzugriff-, Nichttemporal(730)-Befehlsmodell. Die Klasse-B-Befehlsmodelle in 7B beinhalten Folgendes: 1) innerhalb der Nichtspeicherzugriff(705)-Befehlsmodelle gezeigt sind ein Nichtspeicherzugriff-, Schreibmaskensteuerung-, Teilrundungssteuerungstypoperation(712)-Befehlsmodell und ein Nichtspeicherzugriff-, Schreibmaskensteuerung-, vsize-Typoperation(717)-Befehlsmodell; und 2) innerhalb der Speicherzugriff(720)-Befehlsmodelle gezeigt ist ein Speicherzugriff-, Schreibmaskensteuerung(727)-Befehlsmodell.
Das allgemeine vektorfreundliche Befehlsformat 700 beinhaltet die folgenden Felder, die in der in den 7A-7B veranschaulichten Reihenfolge unten aufgeführt sind. In Verbindung mit den Erörterungen oben kann in einer Ausführungsform, wobei auf die in den 7A-B und 8 unten dargelegten Formatdetails Bezug genommen wird, entweder ein Nichtspeicherzugriff-Befehlstyp 705 oder ein Speicherzugriff-Befehlstyp 720 eingesetzt werden. Adressen für den/die Eingangsvektoroperanden und das Ziel können in einem Registeradressfeld 744, das unten beschrieben wird, identifiziert werden. Die oben erörterte optionale Ausführungsform beinhaltet auch eine skalare Eingabe, die ebenfalls im Adressfeld 744 spezifiziert werden kann.
Format-Feld 740 - ein spezifischer Wert (ein Befehlsformatbezeichnerwert) in diesem Feld identifiziert eindeutig das vektorfreundliche Befehlsformat und somit die Häufigkeit von Befehlen im vektorfreundlichen Befehlsformat in Befehlsströmen. Demzufolge ist dieses Feld insofern optional, als es nicht für einen Befehlssatz benötigt wird, der nur das allgemeine vektorfreundliche Befehlsformat aufweist.
Basisoperationsfeld 742 - sein Inhalt unterscheidet zwischen unterschiedlichen Basisoperationen.
Registerindexfeld 744 - sein Inhalt spezifiziert direkt oder durch Adressengenerierung die Orte der Quell- und der Zieloperanden, sei es in Registern oder in einem Speicher. Diese beinhalten eine hinreichend hohe Zahl von Bits, um N Register aus einer PxQ-Registerbank (z. B. 32x512, 16x128, 32x1024, 64x1024) auszuwählen. Während N in einer Ausführungsform bis zu drei Quellen und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quellen und Zielregister unterstützen (können z. B. bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel fungiert, können bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel fungiert, können bis zu zwei Quellen und ein Ziel unterstützen).
Modifiziererfeld 746 - sein Inhalt unterscheidet zwischen Vorkommnissen von Befehlen im allgemeinen Vektorbefehlsformat, die den Speicherzugriff von denjenigen spezifizieren, die dies nicht tun; das heißt zwischen Nichtspeicherzugriff(705)-Befehlsmodellen und Speicherzugriff(720)-Befehlsmodellen. Speicherzugriffsoperationen lesen und/oder schreiben in die Speicherhierarchie (und spezifizieren in manchen Fällen die Quell- und/oder die Zieladressen unter Verwendung von Werten in Registern), während Nichtspeicherzugriffsoperationen dies nicht tun (die Quelle und die Ziele sind z. B. Register). Während dieses Feld in einer Ausführungsform auch zwischen drei unterschiedlichen Möglichkeiten zum Durchführen von Speicheradresskalkulationen auswählt, können alternative Ausführungsformen mehr, weniger oder andere Möglichkeiten zum Durchführen von Speicheradresskalkulationen unterstützen.
Zusatzoperationsfeld 750 - sein Inhalt erkennt, welche von vielfältigen unterschiedlichen Operationen zusätzlich zur Basisoperation durchzuführen sind. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld unterteilt in ein Klassenfeld 768, ein Alphafeld 752 und ein Betafeld 754. Das Zusatzoperationsfeld 750 erlaubt, dass häufige Gruppen von Operationen statt in 2, 3 oder 4 Befehlen in einem einzigen Befehl durchgeführt werden.
Skalierfeld 760 - sein Inhalt erlaubt die Skalierung des Inhalts des Indexfelds zur Speicheradressengenerierung (z. B. für eine Adressengenerierung, die 2scale * index + base verwendet).
Verschiebungsfeld 762A - sein Inhalt wird im Rahmen der Speicheradressengenerierung verwendet (z. B. für eine Adressengenerierung, die 2scale * index + base + displacement verwendet).
Verschiebungsfaktorfeld 762B (es ist zu beachten, dass die Anordnung des Verschiebungsfelds 762A direkt über dem Verschiebungsfaktorfeld 762B darauf hinweist, dass das eine oder das andere verwendet wird) - sein Inhalt wird im Rahmen der Adressengenerierung verwendet; er spezifiziert einen Verschiebungsfaktor, der um die Größe eines Speicherzugriffs (N) zu skalieren ist - wobei N die Zahl der Bytes beim Speicherzugriff ist (z. B. für eine Adressengenerierung, die 2scale * index + base + scaled displacement verwendet). Redundante niederwertige Bits werden ignoriert und der Inhalt des Verschiebungsfaktorfelds wird mithin mit der Speicheroperandengesamtgröße (N) multipliziert, um die abschließende Verschiebung zu generieren, die beim Kalkulieren einer effektiven Adresse verwendet werden soll. Der Wert von N wird von der Prozessorhardware zur Laufzeit basierend auf dem vollständigen Opcode-Feld 774 (später hierin beschrieben) und dem Datenmanipulationsfeld 754C bestimmt. Das Verschiebungsfeld 762A und das Verschiebungsfaktorfeld 762B sind insofern optional, als sie nicht für die Nichtspeicherzugriff (705)-Befehlsmodelle verwendet werden, und/oder unterschiedliche Ausführungsformen implementieren möglicherweise nur eines oder keines von beiden.
Datenelementbreitefeld 764 - sein Inhalt erkennt, welche von einer Zahl von Datenelementbreiten zu verwenden ist (in manchen Ausführungsformen für alle Befehle; in anderen Ausführungsformen nur für manche der Befehle). Dieses Feld ist insofern optional, als es nicht benötigt wird, falls nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung irgendeines Aspekts der Opcodes unterstützt werden.
Schreibmaskenfeld 770 - sein Inhalt prüft pro Datenelementposition, ob die betreffende Datenelementposition im Zielvektoroperanden das Ergebnis der Basisoperation und der Zusatzoperation widerspiegelt. Klasse-A-Befehlsmodelle unterstützen merging-writemasking, während Klasse-B-Befehlsmodelle sowohl merging-writemasking als auch zeroing-writemasking unterstützen. Beim Mischen (merging) erlauben Vektormasken, dass eine beliebige Menge von Elementen am Ziel vor Aktualisierungen während der Ausführung irgendeiner Operation geschützt wird (spezifiziert von der Basisoperation und der Zusatzoperation); in einer anderen Ausführungsform das Beibehalten des alten Werts jedes Elements des Ziels, wobei das korrespondierende Maskenbit eine 0 aufweist. Im Gegensatz dazu erlauben Vektormasken bei der Nullsetzung (zeroing), dass eine beliebige Menge von Elementen am Ziel während der Ausführung irgendeiner Operation auf null gesetzt wird (spezifiziert von der Basisoperation und der Zusatzoperation); in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das korrespondierende Maskenbit einen 0-Wert aufweist. Eine Teilmenge dieser Funktionalität ist die Fähigkeit zum Steuern der Vektorlänge der durchgeführten Operation (das heißt des Abstands der modifizierten Elemente, vom ersten bis zum letzten); jedoch müssen die Elemente, die modifiziert werden, nicht unbedingt aufeinanderfolgen. Somit erlaubt das Schreibmaskenfeld 770 partielle Vektoroperationen, einschließlich Ladungen, Speicherungen, arithmetisch, logisch etc. Auch wenn Ausführungsformen der Erfindung beschrieben werden, in denen der Inhalt des Schreibmaskenfelds 770 eines von einer Zahl von Schreibmaskenregistern 770 auswählt, das die zu verwendende Schreibmaske enthält (und der Inhalt des Schreibmaskenfelds 770 somit indirekt diese durchzuführende Maskierung identifiziert), lassen alternative Ausführungsformen stattdessen oder zusätzlich zu, dass der Inhalt des Schreibmaskenfelds 770 direkt die durchzuführende Maskierung spezifiziert.
Immediate-Feld 772 - sein Inhalt erlaubt die Spezifikation eines Immediate. Dieses Feld ist insofern optional, als es in einer Implementierung des allgemeinen vektorfreundlichen Formats, das Immediates nicht unterstützt, nicht vorhanden ist und in Befehlen, die kein Immediate verwenden, nicht vorhanden ist.
Klassenfeld 768 - sein Inhalt unterscheidet zwischen unterschiedlichen Klassen von Befehlen. Mit Bezug auf die 7A-B wählen die Inhalte dieses Felds zwischen Klasse-A- und Klasse-B-Befehlen. In den 7A-B werden Quadrate mit abgerundeten Ecken verwendet, um anzugeben, dass in einem Feld ein spezifischer Wert vorhanden ist (in den 7A-B z. B. Klasse A 768A bzw. Klasse B 768B für das Klassenfeld 768).
Befehlsmodelle der Klasse A
Im Fall der Nichtspeicherzugriff(705)-Befehlsmodelle der Klasse A wird das Alphafeld 752 als RS-Feld 752A interpretiert, dessen Inhalt erkennt, welcher der unterschiedlichen Zusatzoperationstypen durchgeführt werden soll (z. B. werden eine Rundung 752A.1 und eine Datentransformation 752A.2 jeweils für die Nichtspeicherzugriff-, Rundungstypoperation(710)-Modelle und die Nichtspeicherzugriff-, Datentransformationstypoperation(715)-Befehlsmodelle spezifiziert), während das Betafeld 754 erkennt, welche der Operationen des spezifizierten Typs durchgeführt werden soll. In den Nichtspeicherzugriff (705)-Befehlsmodellen sind das Skalierfeld 760, das Verschiebungsfeld 762A und das Verschiebungsskalierfeld 762B nicht vorhanden.
Nichtspeicherzugriff-Befehlsmodelle - Ganzrundungssteuerungstypoperation
Im Nichtspeicherzugriff-Ganzrundungssteuerungstypoperation (710)-Befehlsmodell wird das Betafeld 754 als Rundungssteuerungsfeld 754A interpretiert, dessen Inhalt(e) statische Rundungen bereitstellt/bereitstellen. Während in den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerungsfeld 754A ein Feld zum Unterdrücken aller Gleitkommaausnahmen (SAE), 756, und ein Rundungsoperationssteuerungsfeld 758 enthält, können alternative Ausführungsformen diese beiden Konzepte unterstützen codieren in dasselbe Feld oder nur eines oder das andere dieser Konzepte/Felder aufweisen (können z. B. nur das Rundungsoperationssteuerungsfeld 758 aufweisen).
SAE-Feld 756 - sein Inhalt erkennt, ob das Melden von Ausnahmeereignissen deaktiviert werden soll oder nicht; wenn der Inhalt des SAE-Felds 756 angibt, dass eine Unterdrückung aktiviert ist, meldet ein gegebener Befehl keinerlei Gleitkommaausnahme-Flag und ruft keinen Gleitkommaausnahmebehandler auf.
Rundungsoperationssteuerungsfeld 758 - sein Inhalt erkennt, welche von einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden Richtung Null und Runden auf den nächsten Wert). Somit erlaubt das Rundungsoperationssteuerungsfeld 758, dass der Rundungsmodus je nach Befehl geändert wird. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi beinhaltet, hat der Inhalt des Rundungsoperationssteuerungsfelds 750 Vorrang vor diesem Registerwert.
Nichtspeicherzugriff-Befehlsmodelle - Datentransformationstypoperation
Im Nichtspeicherzugriff-Datentransformationstypoperation (715)-Befehlsmodell wird das Betafeld 754 als Datentransformationsfeld 754B interpretiert, dessen Inhalt erkennt, welche von einer Zahl von Datentransformationen durchgeführt werden soll (z. B. nicht Datentransformation, Swizzeln, Broadcast).
Im Fall eines Speicherzugriff(720)-Befehlsmodells der Klasse A wird das Alphafeld 752 als Entfernungshinweisfeld 752B interpretiert, dessen Inhalt erkennt, welcher der Entfernungshinweise verwendet werden soll (in 7A werden jeweils ein temporales Element 752B.1 und ein nichttemporales Element 752B.2 für das Speicherzugriff-, Temporal(725)-Befehlsmodell und das Speicherzugriff-, Nichttemporal(730)-Befehlsmodell spezifiziert), während das Betafeld 754 als Datenmanipulationsfeld 754C interpretiert wird, dessen Inhalt erkennt, welche von einer Zahl von Datenmanipulationsoperationen (auch als Primitive bekannt) durchgeführt werden soll (z. B. keine Manipulation; Broadcast; Aufwärtsumwandlung einer Quelle; und Abwärtsumwandlung eines Ziels). Die Speicherzugriff (720)-Befehlsmodelle beinhalten das Skalierfeld 760 und optional das Verschiebungsfeld 762A oder das Verschiebungsskalierfeld 762B.
Vektorspeicherbefehle führen Vektorladungen aus einem Speicher und Vektorspeicherungen in einen Speicher mit Umwandlungsunterstützung durch. Wie bei regulären Vektorbefehlen übertragen Vektorspeicherbefehle Daten datenelementweise aus einem Speicher/in einen Speicher, wobei die Elemente, die tatsächlich übertragen werden, durch den Inhalt der Vektormaske, die als Schreibmaske ausgewählt ist, vorgegeben sind.
Speicherzugriff-Befehlsmodelle - Temporal
Temporale Daten sind Daten, die wahrscheinlich so bald wiederverwendet werden, dass sie von Caching profitieren. Dabei handelt es sich jedoch um einen Hinweis, und unterschiedliche Prozessoren können diesen auf unterschiedliche Weisen implementieren, auch etwa indem sie den Hinweis ganz ignorieren.
Speicherzugriff-Befehlsmodelle - Nichttemporal
Nichttemporale Daten sind Daten, die wahrscheinlich nicht so bald wiederverwendet werden, dass sie von Caching im Level-1-Cache profitieren, und ihnen sollte bei der Entfernung Vorzug eingeräumt werden. Dabei handelt es sich jedoch um einen Hinweis, und unterschiedliche Prozessoren können diesen auf unterschiedliche Weisen implementieren, auch etwa indem sie den Hinweis ganz ignorieren.
Befehlsmodelle der Klasse B
Im Fall der Befehlsmodelle der Klasse B wird das Alphafeld 752 als Schreibmaskensteuerungs(Z)-Feld 752C interpretiert, dessen Inhalt erkennt, ob das Schreibmaskieren, das durch das Schreibmaskenfeld 770 gesteuert wird, ein Mischen oder eine Nullsetzung sein soll.
Im Fall der Nichtspeicherzugriff(705)-Befehlsmodelle der Klasse B wird ein Teil des Betafelds 754 als RL-Feld 757A interpretiert, dessen Inhalt erkennt, welcher der unterschiedlichen Zusatzoperationstypen durchgeführt werden soll (z. B. werden eine Rundung 757A.1 und eine Vektorlänge (VSIZE) 757A.2 jeweils für das Nichtspeicherzugriff-, Schreibmaskensteuerung-, Teilrundungssteuerungstypoperation(712)-Befehlsmodell und das Nichtspeicherzugriff-, Schreibmaskensteuerung-, VSIZE-Typoperation(717)-Befehlsmodell spezifiziert), während das übrige Betafeld 754 erkennt, welche der Operationen des spezifizierten Typs durchgeführt werden soll. In den Nichtspeicherzugriff(705)-Befehlsmodellen sind das Skalierfeld 760, das Verschiebungsfeld 762A und das Verschiebungsskalierfeld 762B nicht vorhanden.
Im Nichtspeicherzugriff-, Schreibmaskensteuerung-, Teilrundungssteuerungstypoperation(710)-Befehlsmodell wird das übrige Betafeld 754 als Rundungsoperationsfeld 759A interpretiert, und das Melden von Ausnahmeereignissen ist deaktiviert (ein gegebener Befehl meldet keinerlei Gleitkommaausnahme-Flag und ruft keinen Gleitkommaausnahmebehandler auf).
Rundungsoperationssteuerungsfeld 759A - genau wie beim Rundungsoperationssteuerungsfeld 758 erkennt sein Inhalt, welche von einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden Richtung Null und Runden auf den nächsten Wert). Somit erlaubt das Rundungsoperationssteuerungsfeld 759A, dass der Rundungsmodus je nach Befehl geändert wird. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi beinhaltet, hat der Inhalt des Rundungsoperationssteuerungsfelds 750 Vorrang vor diesem Registerwert.
Im Nichtspeicherzugriff-, Schreibmaskensteuerung-, VSIZE-Typoperation(717)-Befehlsmodell wird das übrige Betafeld 754 als Vektorlängefeld 759B interpretiert, dessen Inhalt erkennt, welche von einer Zahl von Datenvektorlängen bearbeitet werden soll (z. B. 128, 256 oder 512 Byte).
Im Fall eines Speicherzugriff(720)-Befehlsmodells der Klasse B wird ein Teil des Betafelds 754 als Broadcast-Feld 757B interpretiert, dessen Inhalt erkennt, ob die Broadcasttypdatenmanipulationsoperation durchgeführt werden soll, während das übrige Betafeld 754 als das Vektorlängefeld 759B interpretiert wird. Die Speicherzugriff(720)-Befehlsmodelle beinhalten das Skalierfeld 760 und optional das Verschiebungsfeld 762A oder das Verschiebungsskalierfeld 762B.
Hinsichtlich des allgemeinen vektorfreundlichen Befehlsformats 700 wird ein vollständiges Opcode-Feld 774 gezeigt, welches das Format-Feld 740, das Basisoperationsfeld 742 und das Datenelementbreitefeld 764 beinhaltet. Wenngleich eine Ausführungsform gezeigt wird, in der das vollständige Opcode-Feld 774 all diese Felder beinhaltet, beinhaltet das vollständige Opcode-Feld 774 in Ausführungsformen, die nicht alle von ihnen unterstützen, weniger als all diese Felder. Das vollständige Opcode-Feld 774 stellt den Operationscode (Opcode) bereit.
Das Zusatzoperationsfeld 750, das Datenelementbreitefeld 764 und das Schreibmaskenfeld 770 erlauben, dass diese Merkmale je nach Befehl im allgemeinen vektorfreundlichen Befehlsformat spezifiziert werden.
Die Kombination aus dem Schreibmaskenfeld und dem Datenelementbreitefeld erzeugt getypte Befehle, insofern als sie eine Anwendung der Maske basierend auf unterschiedlichen Datenelementbreiten erlaubt.
Die verschiedenen innerhalb der Klassen A und B vorzufindenden Befehlsmodelle sind in unterschiedlichen Situationen vorteilhaft. In manchen Ausführungsformen der Erfindung unterstützen unterschiedliche Prozessoren oder unterschiedliche Kerne innerhalb eines Prozessors möglicherweise nur die Klasse A, nur die Klasse B oder beide Klassen. Beispielsweise unterstützt ein Hochleistungs-Universal-Out-of-order-Kern, der für universelle Rechenvorgänge vorgesehen ist, möglicherweise nur die Klasse B, ein Kern, der in erster Linie für Grafiken und/oder wissenschaftliche (Durchsatz-)Rechenvorgänge vorgesehen ist, unterstützt möglicherweise nur die Klasse A, und ein Kern, der für beides vorgesehen ist, unterstützt möglicherweise beides (selbstverständlich fällt ein Kern, der irgendeine Mischung aus Modellen und Befehlen aus beiden Klassen, jedoch nicht alle Modelle und Befehle aus beiden Klassen aufweist, in den Bereich der Erfindung). Auch kann ein Einzelprozessor mehrere Kerne beinhalten, die alle dieselbe Klasse unterstützen oder in denen unterschiedliche Kerne unterschiedliche Klassen unterstützen. Beispielsweise unterstützt in einem Prozessor mit separaten Grafik- und Universalkernen einer der Grafikkerne, der in erster Linie für Grafiken und/oder wissenschaftliche Rechenvorgänge vorgesehen ist, möglicherweise nur die Klasse A, während einer oder mehrere der Universalkerne möglicherweise Hochleistungs-Universalkerne mit einer Out-of-order-Ausführung und einer Registerumbenennung sind, die für universelle Rechenvorgänge vorgesehen sind, welche nur die Klasse B unterstützen. Ein anderer Prozessor, der keinen separaten Grafikkern aufweist, beinhaltet möglicherweise einen oder mehrere Universal-In-order- oder -Out-of-order-Kerne, welche sowohl die Klasse A als auch die Klasse B unterstützen. Selbstverständlich können Merkmale aus einer Klasse in anderen Ausführungsformen der Erfindung auch in der anderen Klasse implementiert sein. In einer Hochsprache geschriebene Programme würden in vielfältige unterschiedliche ausführbare Formen gebracht (z. B. von einem Just-In-Time-Compiler kompiliert oder statisch kompiliert), die Folgendes beinhalten: 1) eine Form nur mit Befehlen der Klasse(n), die vom Zielprozessor zur Ausführung unterstützt wird/werden; oder 2) eine Form mit alternativen Routinen, die unter Verwendung unterschiedlicher Kombinationen der Befehle aller Klassen geschrieben wurden, und mit Steuerungsablaufcode, der die Routinen zum Ausführen basierend auf den Befehlen auswählt, die vom Prozessor unterstützt werden, der den Code gerade ausführt.
Beispielhaftes spezifisches vektorfreundliches Befehlsformat
8 ist ein Blockschema, das ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß Ausführungsformen der Erfindung veranschaulicht. 8 zeigt ein spezifisches vektorfreundliches Befehlsformat 800, das insofern spezifisch ist, als es den Ort, die Größe, die Interpretation und die Reihenfolge der Felder sowie Werte für manche dieser Felder spezifiziert. Das spezifische vektorfreundliche Befehlsformat 800 kann verwendet werden, um den x86-Befehlssatz zu erweitern, und somit ähneln oder entsprechen manche der Felder denjenigen, die im bestehenden x86-Befehlssatz und in Erweiterungen davon (z. B. AVX) verwendet werden. Dieses Format steht weiter im Einklang mit dem Präfixcodierfeld, dem realen Opcode-Byte-Feld, dem MOD-R/M-Feld, dem SIB-Feld, dem Verschiebungsfeld und Immediate-Feldern des bestehenden x86-Befehlssatzes mit Erweiterungen. Die Felder aus 7, in welche die Felder aus 8 abgebildet sind, werden veranschaulicht.
Es versteht sich, dass, obgleich Ausführungsformen der Erfindung mit Bezug auf das spezifische vektorfreundliche Befehlsformat 800 zu Veranschaulichungszwecken im Zusammenhang mit dem allgemeinen vektorfreundlichen Befehlsformat 700 beschrieben werden, die Erfindung nicht auf das spezifische vektorfreundliche Befehlsformat 800 begrenzt ist, es sei denn, dies wird beansprucht. Das allgemeine vektorfreundliche Befehlsformat 700 berücksichtigt zum Beispiel diverse mögliche Größen für die verschiedenen Felder, während das spezifische vektorfreundliche Befehlsformat 800 mit Feldern mit spezifischen Größen gezeigt wird. Wenngleich das Datenelementbreitefeld 764 in einem spezifischen Beispiel als Ein-Bit-Feld im spezifischen vektorfreundlichen Befehlsformat 800 veranschaulicht wird, wird die Erfindung dadurch nicht begrenzt (das heißt, das allgemeine vektorfreundliche Befehlsformat 700 berücksichtigt auch andere Größen des Datenelementbreitefelds 764).
Das allgemeine vektorfreundliche Befehlsformat 700 beinhaltet die folgenden Felder, die in der in 8A veranschaulichten Reihenfolge aufgeführt sind.
EVEX-Präfix (Bytes 0-3) 802 - ist in einer Vier-Byte-Form codiert.
Format-Feld 740 (EVEX-Byte 0, Bits [7:0]) - das erste Byte (EVEX-Byte 0) ist das Format-Feld 740 und enthält 0x62 (den eindeutigen Wert, der in einer Ausführungsform der Erfindung zum Unterscheiden des vektorfreundlichen Befehlsformats verwendet wird).
Das zweite, das dritte und das vierte Byte (EVEX-Bytes 1-3) beinhalten eine Zahl von Bitfeldern, die eine spezifische Fähigkeit bereitstellen.
REX-Feld 805 (EVEX-Byte 1, Bits [7-5]) - besteht aus einem EVEX. R-Bitfeld (EVEX-Byte 1, Bit [7] - R), EVEX.X-Bitfeld (EVEX-Byte 1, Bit [6] - X) und 757BEX-Byte 1, Bit [5] - B). Das EVEX.R-, das EVEX.X- und das EVEX.B-Bitfeld stellen die gleiche Funktionalität bereit wie die korrespondierenden VEX-Bitfelder und werden unter Verwendung einer Einerkomplement-Form codiert, d. h. ZMM0 ist als 1111B und ZMM15 als 0000B codiert. Andere Felder der Befehle codieren die unteren drei Bits der Registerindizes, wie aus dem Stand der Technik bekannt ist (rrr, xxx und bbb), sodass Rrrr, Xxxx und Bbbb ausgebildet werden können, indem EVEX. R, EVEX.X und EVEX. B hinzugefügt werden.
REX'-Feld 710 - dies ist der erste Teil des REX'-Felds 710 und das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4]-R'), das verwendet wird, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Registersatzes zu codieren. In einer Ausführungsform der Erfindung wird dieses Bit gemeinsam mit anderen, wie unten angegeben, in einem bitinvertierten Format gespeichert, um (im wohl bekannten x86-32-Bitmodus) vom BOUND-Befehl zu unterscheiden, dessen reales Opcode-Byte 62 ist, akzeptiert jedoch im MOD-R/M-Feld (unten beschrieben) nicht den Wert 11 im MOD-Feld; alternative Ausführungsformen der Erfindung speichern dieses und die anderen angegebenen Bits unten nicht im invertierten Format. Der Wert 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten, R'Rrrr wird ausgebildet, indem EVEX.R', EVEX.R und die anderen RRR aus anderen Feldern kombiniert werden.
Opcode-Map-Feld 815 (EVEX-Byte 1, Bits [3:0] - mmmm) - sein Inhalt codiert ein impliziertes führendes Opcode-Byte (0F, 0F 38 oder 0F 3).
Datenelementbreitefeld 764 (EVEX-Byte 2, Bit [7] - W) - wird durch die Notation EVEX.W dargestellt. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps zu definieren (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente).
EVEX.vvvv 820 (EVEX-Byte 2, Bits [6:3]-vvvv) - EVEX.vvvv kann folgende Funktion haben: 1) EVEX.vvvv codiert den ersten Quellregisteroperanden, der in invertierter (Einerkomplement-)Form spezifiziert und gültig ist für Befehle mit 2 oder mehr Quelloperanden; 2) EVEX.vvvv codiert den Zielregisteroperanden, der in Einerkomplement-Form für bestimmte Vektorverschiebungen spezifiziert ist; oder 3) EVEX.vvvv codiert gar keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Somit codiert das EVEX.vvvv-Feld 820 die 4 niedrigwertigen Bits des ersten Quellregisterbezeichners, der in invertierter (Einerkomplement-)Form gespeichert ist. Abhängig vom Befehl wird ein zusätzliches anderes EVEX-Bitfeld verwendet, um die Bezeichnergröße auf 32 Register zu erweitern.
EVEX.U-768-Klassenfeld (EVEX-Byte 2, Bit [2]-U) - Falls EVEX.U = 0, wird dadurch die Klasse A oder EVEX.U0 angegeben; falls EVEX.U = 1, wird dadurch die Klasse B oder EVEX.U1 angegeben.
Präfixcodierfeld 825 (EVEX-Byte 2, Bits [1:0]-pp) - stellt zusätzliche Bits für das Basisoperationsfeld bereit. Neben der Bereitstellung von Unterstützung für die älteren SSE-Befehle im EVEX-Präfixformat hat dies auch den Vorteil, dass das SIMD-Präfix kompakt dargestellt wird (statt dass ein Byte benötigt wird, um das SIMD-Präfix auszudrücken, benötigt das EVEX-Präfix nur 2 Bits). In einer Ausführungsform werden diese älteren SIMD-Präfixe, um ältere SSE-Befehle zu unterstützen, die ein SIMD-Präfix (66H, F2H, F3H) sowohl im älteren Format als auch im EVEX-Präfixformat verwenden, in das SIMD-Präfixcodierfeld codiert; und zur Laufzeit in das ältere SIMD-Präfix ausgedehnt, bevor sie für die PLA des Decodierers bereitgestellt werden (sodass die PLA sowohl das ältere als auch das EVEX-Format dieser älteren Befehle ohne Modifizierung ausführen kann). Obwohl neuere Befehle den Inhalt des EVEX-Präfixcodierfelds direkt als Opcode-Erweiterung verwenden könnten, haben bestimmte Ausführungsformen der Einheitlichkeit halber eine ähnliche Ausdehnung, erlauben jedoch eine Spezifizierung unterschiedlicher Bedeutungen durch diese älteren SIMD-Präfixe. In einer alternativen Ausführungsform kann die PLA so umgestaltet werden, dass die 2-Bit-SIMD-Präfixcodierungen unterstützt werden und die Ausdehnung hierfür somit nicht erforderlich ist.
Alphafeld 752 (EVEX-Byte 3, Bit [7] - EH; auch als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.write mask control und EVEX.N bekannt; auch veranschaulicht mit α) - wie bereits beschrieben, ist dieses Feld kontextspezifisch.
Betafeld 754 (EVEX-Byte 3, Bits [6:4]-SSS; auch als EVEX.s2-0, EVEX.r2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB bekannt; auch veranschaulicht mit βββ) - wie bereits beschrieben, ist dieses Feld kontextspezifisch.
REX'-Feld 710 - dies ist der übrige Teil des REX'-Felds und das EVEX.V'-Bitfeld (EVEX-Byte 3, Bit [3] - V'), das verwendet werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Registersatzes zu codieren. Dieses Bit ist im bitinvertierten Format gespeichert. Ein Wert 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten, V'VVVV wird ausgebildet, indem EVEX.V', EVEX.vvvv kombiniert werden.
Schreibmaskenfeld 770 (EVEX-Byte 3, Bits [2:0]-kkk) - sein Inhalt spezifiziert den Index eines Registers in den Schreibmaskenregistern, wie bereits beschrieben. In einer Ausführungsform der Erfindung weist der spezifische Wert EVEX.kkk=000 ein spezielles Verhalten auf, das darauf schließen lässt, dass für den betreffenden Befehl keine Schreibmaske verwendet wird (dies ist auf vielfältige Weisen implementierbar, auch etwa durch die Verwendung einer Schreibmaske, die fest mit allen Einsen verdrahtet ist, oder von Hardware, die die Maskierhardware umgeht).
Das reale Opcode-Feld 830 (Byte 4) ist auch als Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert.
Ein MOD-R/M-Feld 840 (Byte 5) beinhaltet ein MOD-Feld 842, ein Reg-Feld 844 und ein R/M-Feld 846. Wie bereits beschrieben, unterscheidet der Inhalt des MOD-Felds 842 zwischen Speicherzugriffs- und Nichtspeicherzugriffsoperationen. Die Funktion des Reg-Felds 844 lässt sich in zwei Situationen zusammenfassen: Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden oder Behandlung als Opcode-Erweiterung und Nichtverwendung zum Codieren eines beliebigen Befehlsoperanden. Die Funktion des R/M-Felds 846 kann Folgendes beinhalten: Codieren des Befehlsoperanden, der eine Speicheradresse referenziert, oder Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden.
Scale-Index-Base(SIB)-Byte (Byte 6) - Wie bereits beschrieben, wird der Inhalt des Skalierfelds 750 für die Speicheradressengenerierung verwendet. SIB.xxx 854 und SIB.bbb 856 - auf die Inhalte dieser Felder wurde im Zusammenhang mit den Registerindizes Xxxx und Bbbb bereits eingegangen.
Verschiebungsfeld 762A (Bytes 7-10) - wenn das MOD-Feld 842 10 enthält, sind die Bytes 7-10 das Verschiebungsfeld 762A, und es arbeitet genauso wie die ältere 32-Bit-Verschiebung (disp32) und arbeitet bei Bytegranularität.
Verschiebungsfaktorfeld 762B (Byte 7) - wenn das MOD-Feld 842 01 enthält, ist das Byte 7 das Verschiebungsfaktorfeld 762B. Der Ort dieses Felds entspricht demjenigen der 8-Bit-Verschiebung (disp8) des älteren x86-Befehlssatzes, das bei Bytegranularität arbeitet. Weil disp8 vorzeichenerweitert ist, kann es nur zwischen -128 und 127 Byte-Offsets adressieren; was 64-Byte-Cachezeilen angeht, so verwendet disp8 8 Bits, die nur auf vier wirklich nützliche Werte, -128, -64, 0 und 64, gesetzt werden können; weil oft ein größerer Bereich benötigt wird, wird disp32 verwendet; für disp32 sind jedoch 4 Bytes erforderlich. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 762B eine Neuinterpretation von disp8; wenn das Verschiebungsfaktorfeld 762B verwendet wird, wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfelds multipliziert mit der Größe des Speicheroperandenzugriffs (N) bestimmt. Dieser Typ einer Verschiebung wird als disp8*N bezeichnet. Dadurch wird die durchschnittliche Befehlslänge verringert (ein einzelnes Byte, das für die Verschiebung verwendet wird, jedoch mit einem viel größeren Bereich). Eine solche komprimierte Verschiebung beruht auf der Annahme, dass die effektive Verschiebung ein Vielfaches der Granularität des Speicherzugriffs ist, und mithin müssen die redundanten niedrigwertigen Bits des Adress-Offsets nicht codiert werden. Mit anderen Worten, das Verschiebungsfaktorfeld 762B ersetzt die 8-Bit-Verschiebung des älteren x86-Befehlssatzes. Somit wird das Verschiebungsfaktorfeld 762B genauso codiert wie eine 8-Bit-Verschiebung des x86-Befehlssatzes (also ohne Änderungen an den ModRM/SIB-Codierungsregeln), wobei eine einzige Ausnahme darin besteht, dass disp8 auf disp8*N überladen wird. Mit anderen Worten, es erfolgen keine Änderungen an den Codierungsregeln oder den Codierungslängen, sondern nur in der Interpretation des Verschiebungswerts durch Hardware (die die Verschiebung um die Größe des Speicheroperanden skalieren muss, um einen byteweisen Adress-Offset zu erhalten).
Das Immediate-Feld 772 arbeitet so wie bereits beschrieben.
Vollständiges Opcode-Feld
8B ist ein Blockschema, das die Felder des spezifischen vektorfreundlichen Befehlsformats 800, aus denen sich das vollständige Opcode-Feld 774 zusammensetzt, gemäß einer Ausführungsform der Erfindung veranschaulicht. Speziell beinhaltet das vollständige Opcode-Feld 774 das Format-Feld 740, das Basisoperationsfeld 742 und das Datenelementbreite(W)-Feld 764. Das Basisoperationsfeld 742 beinhaltet das Präfixcodierfeld 825, das Opcode-Map-Feld 815 und das reale Opcode-Feld 830.
Registerindexfeld
8C ist ein Blockschema, das die Felder des spezifischen vektorfreundlichen Befehlsformats 800, aus denen sich das Registerindexfeld 744 zusammensetzt, gemäß einer Ausführungsform der Erfindung veranschaulicht. Speziell beinhaltet das Registerindexfeld 744 das REX-Feld 805, das REX'-Feld 810, das MODR/M.reg-Feld 844, das MODR/M.r/m-Feld 846, das VVVV-Feld 820, das xxx-Feld 854 und das bbb-Feld 856.
Zusatzoperationsfeld
8D ist ein Blockschema, das die Felder des spezifischen vektorfreundlichen Befehlsformats 800, aus denen sich das Zusatzoperationsfeld 750 zusammensetzt, gemäß einer Ausführungsform der Erfindung veranschaulicht. Wenn das Klassen(U)-Feld 768 0 enthält, bedeutet dies EVEX.U0 (Klasse A 768A); wenn es 1 enthält, bedeutet dies EVEX.U1 (Klasse B 768B). Wenn U=0 und das MOD-Feld 842 11 enthält (was eine Nichtspeicherzugriffsoperation bedeutet), wird das Alphafeld 752 (EVEX-Byte 3, Bit [7] - EH) als das rs-Feld 752A interpretiert. Wenn das rs-Feld 752A eine 1 enthält (Rundung 752A.1), wird das Betafeld 754 (EVEX-Byte 3, Bits [6:4]- SSS) als das Rundungssteuerungsfeld 754A interpretiert. Das Rundungssteuerungsfeld 754A beinhaltet ein Ein-Bit-SAE-Feld 756 und ein Zwei-Bit-Rundungsoperationsfeld 758. Wenn das rs-Feld 752A eine 0 enthält (Datentransformation 752A.2), wird das Betafeld 754 (EVEX-Byte 3, Bits [6:4]- SSS) als ein Drei-Bit-Datentransformationsfeld 754B interpretiert. Wenn U=0 und das MOD-Feld 842 00, 01 oder 10 enthält (was eine Speicherzugriffsoperation bedeutet), wird das Alphafeld 752 (EVEX-Byte 3, Bit [7] - EH) als das Entfernungshinweis(EH)-Feld 752B und das Betafeld 754 (EVEX-Byte 3, Bits [6:4]- SSS) als ein Drei-Bit-Datenmanipulationsfeld 754C interpretiert.
Wenn U=1, wird das Alphafeld 752 (EVEX-Byte 3, Bit [7] - EH) als das Schreibmaskensteuerungs(Z)-Feld 752C interpretiert. Wenn U=1 und das MOD-Feld 842 11 enthält (was eine Nichtspeicherzugriffsoperation bedeutet), wird ein Teil des Betafelds 754 (EVEX-Byte 3, Bit [4]- S0) als das RL-Feld 757A interpretiert; wenn es eine 1 enthält (Rundung 757A.1), wird das übrige Betafeld 754 (EVEX-Byte 3, Bit [6-5]- S2-1) als das Rundungsoperationsfeld 759A interpretiert, während, wenn das RL-Feld 757A eine 0 enthält (VSIZE 757.A2), das übrige Betafeld 754 (EVEX-Byte 3, Bit [6-5]- S2-1) als das Vektorlängefeld 759B (EVEX-Byte 3, Bit [6-5]- L1-0) interpretiert wird. Wenn U=1 und das MOD-Feld 842 00, 01 oder 10 enthält (was eine Speicherzugriffsoperation bedeutet), wird das Betafeld 754 (EVEX-Byte 3, Bits [6:4]-SSS) als das Vektorlängefeld 759B (EVEX-Byte 3, Bit [6-5]- L1-0) und das Broadcast-Feld 757B (EVEX-Byte 3, Bit [4]- B) interpretiert.
Beispielhafte Registerarchitektur

9 ist ein Blockschema einer Registerarchitektur 900 gemäß einer Ausführungsform der Erfindung. In der veranschaulichten Ausführungsform finden sich 32 Vektorregister 910, die 512 Bit breit sind; diese Register werden mit zmm0 bis zmm31 bezeichnet. Die niedrigwertigen 256 Bits der unteren 16 zmm-Register werden an die Register ymm0-16 angelegt. Die niedrigwertigen 128 Bits der unteren 16 zmm-Register (die niedrigwertigen 128 Bits der ymm-Register) werden an die Register xmm0-15 angelegt. Das spezifische vektorfreundliche Befehlsformat 800 arbeitet auf dieser angelegten Registerbank, wie in den Tabellen unten veranschaulicht.

Anpassbare Vektorlänge	Klasse	Operationen	Register
Befehlsmodelle, die das Vektorlängefeld 759B nicht beinhalten	A (7A; U=0)	710, 715, 725, 730	zmm-Register (die Vektorlänge beträgt 64 Byte)
	B (7B; U=1)	712	zmm-Register (die Vektorlänge beträgt 64 Byte)
Befehlsmodelle, die das Vektorlängefeld 759B beinhalten	B (7B; U=1)	717, 727	zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Byte, 32 Byte oder 16 Byte) abhängig vom Vektorlängefeld 759B

Mit anderen Worten, das Vektorlängefeld 759B wählt aus zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen, wobei jede dieser kürzeren Längen halb so lang wie die vorhergehende Länge ist; und Befehlsmodelle ohne das Vektorlängefeld 759B arbeiten mit der maximalen Vektorlänge. Weiter arbeiten die Klasse-B-Befehlsmodelle des spezifischen vektorfreundlichen Befehlsformats 800 in einer Ausführungsform mit gepackten oder skalaren Gleitkommadaten mit einfacher/doppelter Präzision und gepackten oder skalaren ganzzahligen Daten. Skalare Operationen sind Operationen, die an der niedrigstwertigen Datenelementposition in einem zmm-/ymm-/xmm-Register durchgeführt werden; die höherwertigen Datenelementpositionen werden abhängig von der Ausführungsform entweder so beibehalten, wie sie vor dem Befehl waren, oder auf null gesetzt.
Schreibmaskenregister 915 - in der veranschaulichten Ausführungsform finden sich 8 Schreibmaskenregister (k0 bis k7), die je eine Größe von 64 Bit haben. In einer alternativen Ausführungsform haben die Schreibmaskenregister 915 eine Größe von 16 Bit. Wie bereits beschrieben, kann das Vektormaskenregister k0 in einer Ausführungsform der Erfindung nicht als Schreibmaske verwendet werden; wenn die Codierung, die normalerweise k0 angäbe, für eine Schreibmaske verwendet wird, wählt sie eine fest verdrahtete Schreibmaske von 0×FFFF aus, wobei sie Schreibmaskieren für diesen Befehl effektiv deaktiviert.
Universalregister 925 - in der veranschaulichten Ausführungsform finden sich sechzehn 64-Bit-Universalregister, die gemeinsam mit den bestehenden x86-Adressiermodi verwendet werden, um Speicheroperanden zu adressieren. Diese Register werden mit den Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 bezeichnet.
Skalargleitkommastapelregisterbank (x87-Stapel) 945, auf der die MMXgepackte Ganzzahl-Flach-Registerbank 950 per Alias verbunden ist - in der veranschaulichten Ausführungsform ist der x87-Stapel ein Stapel aus acht Elementen, der verwendet wird, um skalare Gleitkommaoperationen an 32/64/80-Bit-Gleitkommadaten unter Verwendung der x87-Befehlssatzennreiterung durchzuführen; während die MMX-Register verwendet werden, um Operationen an 64-Bit-gepackten ganzzahligen Daten durchzuführen sowie um Operanden für manche Operationen, die zwischen den MMX- und XMM-Registern durchgeführt werden, aufzunehmen.
Alternative Ausführungsformen der Erfindung können auch breitere oder schmalere Register verwenden. Des Weiteren können alternative Ausführungsformen der Erfindung auch mehr, weniger oder andere Registerbanken und Register verwenden.
Beispielhafte Kernarchitekturen, Prozessoren und Rechnerarchitekturen
Prozessorkerne lassen sich auf unterschiedliche Weisen, zu unterschiedlichen Zwecken und in unterschiedlichen Prozessoren implementieren. Beispielsweise können Implementierungen solcher Kerne Folgendes beinhalten: 1) einen Universal-In-order-Kern, der für universelle Rechenvorgänge vorgesehen ist; 2) einen Hochleistungs-Universal-Out-of-order-Kern, der für universelle Rechenvorgänge vorgesehen ist; 3) einen Spezialkern, der in erster Linie für Grafiken und/oder wissenschaftliche (Durchsatz-)Rechenvorgänge vorgesehen ist. Implementierungen unterschiedlicher Prozessoren können Folgendes beinhalten: 1) eine CPU, die einen oder mehrere Universal-In-order-Kerne, die für universelle Rechenvorgänge vorgesehen sind, und/oder einen oder mehrere Universal-Out-of-order-Kerne, die für universelle Rechenvorgänge vorgesehen sind, beinhaltet; 2) einen Coprozessor, der einen oder mehrere Spezialkerne, die in erster Linie für Grafiken und/oder wissenschaftliche (Durchsatz-)Rechenvorgänge vorgesehen sind, beinhaltet. Solche unterschiedlichen Prozessoren führen zu unterschiedlichen Rechnersystemarchitekturen, die Folgendes beinhalten können: 1) den Coprozessor auf einem von der CPU separaten Chip; 2) den Coprozessor auf einem separaten Einzelchip im selben Gehäuse wie eine CPU; 3) den Coprozessor auf demselben Einzelchip wie eine CPU (ein solcher Coprozessor wird in diesem Fall manchmal als Speziallogik bezeichnet, etwa als integrierte Grafik- und/oder wissenschaftliche (Durchsatz-)Logik oder als Spezialkerne); und 4) ein System auf einem Chip, das auf demselben Einzelchip die beschriebene CPU (manchmal bezeichnet als Anwendungskern(e) oder Anwendungsprozessor(en)), den oben beschriebenen Coprozessor und zusätzliche Funktionalität beinhalten kann. Als Nächstes werden beispielhafte Kernarchitekturen beschrieben, woran sich Beschreibungen beispielhafter Prozessoren und Rechnerarchitekturen anschließen.
Beispielhafte Kernarchitekturen
In-order- und Out-of-order-Kern-Blockschema
10A ist ein Blockschema, das sowohl eine beispielhafte In-order-Pipeline als auch eine beispielhafte Registerumbenennung-, Out-of-order-Zuteilung/Ausführung-Pipeline gemäß Ausführungsformen der Erfindung veranschaulicht. 10B ist ein Blockschema, das sowohl ein Ausführungsbeispiel für einen In-order-Architekturkern als auch einen beispielhaften Registerumbenennung-, Out-of-order-Zuteilung/Ausführung-Architekturkern zur Aufnahme in einen Prozessor gemäß Ausführungsformen der Erfindung veranschaulicht. Die Kästen mit den durchgezogenen Linien in den 10A-B veranschaulichen die In-order-Pipeline und den In-order-Kern, während die optionale Hinzufügung der Kästen mit den gestrichelten Linien die Registerumbenennung-, Out-of-order-Zuteilung/Ausführung-Pipeline und den Kern dafür veranschaulichen. Da der In-order-Aspekt eine Teilmenge des Out-of-order-Aspekts ist, wird der Out-of-order-Aspekt beschrieben.
In 10A beinhaltet eine Prozessor-Pipeline 1000 eine Holstufe 1002, eine Längendecodierstufe 1004, eine Decodierstufe 1006, eine Allokationsstufe 1008, eine Umbenennungsstufe 1010, eine Stufe für Scheduling (auch als Dispatch oder Issue bekannt) 1012, eine Registerlese-/Speicherlesestufe 1014, eine Ausführungsstufe 1016, eine Zurückschreib-/Speicherschreibstufe 1018, eine Ausnahmebehandlungsstufe 1022 und eine Freigabestufe 1024.
10B zeigt einen Prozessorkern 1090, der eine Front-End-Einheit 1030 beinhaltet, die an eine Ausführungsengine-Einheit 1050 gekoppelt ist, und beide sind an eine Speichereinheit 1070 gekoppelt. Der Kern 1090 ist möglicherweise ein Kern für Rechenvorgänge mit reduziertem Befehlssatz (RISC), ein Kern für Rechenvorgänge mit komplexem Befehlssatz (CISC), ein Kern für sehr lange Befehlswörter (VLIW) oder ein hybrider oder alternativer Kerntyp. Eine noch andere Option ist, dass der Kern 1090 möglicherweise ein Spezialkern ist, zum Beispiel ein Netz- oder ein Kommunikationskern, eine Komprimierungsengine, ein Coprozessorkern, ein General-Purpose-Computing-Graphics-Processing-Unit(GPGPU)-Kern, ein Grafikkern oder dergleichen.
Die Front-End-Einheit 1030 beinhaltet eine Verzweigungsvorhersageeinheit 1032, die an eine Befehlscache-Einheit 1034 gekoppelt ist, welche an einen Befehlsübersetzungslookasidepuffer (TLB) 1036 gekoppelt ist, welcher an eine Befehlsholeinheit 1038 gekoppelt ist, welche an eine Decodiereinheit 1040 gekoppelt ist. Die Decodiereinheit 1040 (oder der Decodierer) kann Befehle decodieren und als Ausgabe eine oder mehrere Mikrooperationen, einen oder mehrere Mikrocodeeinstiegspunkte, einen oder mehrere Mikrobefehle, einen oder mehrere andere Befehle oder ein oder mehrere andere Steuersignale generieren, die aus den ursprünglichen Befehlen decodiert wurden oder die die ursprünglichen Befehle auf andere Weise widerspiegeln oder von ihnen abgeleitet sind. Die Decodiereinheit 1040 ist unter Verwendung vielerlei unterschiedlicher Mechanismen implementierbar. Beispiele für geeignete Mechanismen beinhalten unter anderem Verweistabellen, Hardware-Implementierungen, programmierbare logische Anordnungen (PLAs), Mikrocode-Festspeicher (ROMs) etc. In einer Ausführungsform beinhaltet der Kern 1090 ein Mikrocode-ROM oder ein anderes Medium, das Mikrocode für bestimmte Makrobefehle speichert (z. B. in der Decodiereinheit 1040 oder sonst innerhalb der Front-End-Einheit 1030). Die Decodiereinheit 1040 ist an eine Umbenennungs-/ Allokatoreinheit 1052 in der Ausführungsengine-Einheit 1050 gekoppelt.
Die Ausführungsengine-Einheit 1050 beinhaltet die Umbenennungs-/ Allokatoreinheit 1052, die an eine Rückordnungseinheit 1054 und eine Menge von einer oder mehreren Scheduler-Einheiten 1056 gekoppelt ist. Die Scheduler-Einheiten) 1056 steht/stehen für beliebig viele unterschiedliche Scheduler, die Reservierungsstationen, ein zentrales Befehlsfenster etc. beinhalten. Die Scheduler-Einheiten) 1056 ist/sind an die physische Register-File(s)-Einheit(en) 1058 gekoppelt. Jede der physischen Register-File(s)-Einheiten 1058 steht für eine oder mehrere physische Registerbanken, von denen unterschiedliche einen oder mehrere unterschiedliche Datentypen speichern, etwa skalare Ganzzahl, skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektorganzzahl, Vektorgleitkomma, Status (z. B. einen Befehlszeiger, das heißt die Adresse des nächsten auszuführenden Befehls) etc. In einer Ausführungsform umfasst die physische Register-File(s)-Einheit 1058 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine Skalarregistereinheit. Diese Registereinheiten können Architekturvektorregister, Vektormaskenregister und Universalregister bereitstellen. Die physische(n) Register-File(s)-Einheit(en) 1058 wird/werden von der Rückordnungseinheit 1054 überlappt, um zu veranschaulichen, auf welche verschiedenen Weisen sich die Registerumbenennung und die Out-of-order-Ausführung implementieren lassen (z. B. unter Verwendung eines Neuordnungspuffers bzw. von Neuordnungspuffern und eines Retirement Register File bzw. von Retirement Register Files; unter Verwendung eines Future File bzw. von Future Files, eines Verlaufspuffers bzw. von Verlaufspuffern und eines Retirement Register File bzw. von Retirement Register Files; unter Verwendung von Registerzuordnungen und eines Pools von Registern; etc.). Die Rückordnungseinheit 1054 und die physische(n) Register-File(s)-Einheit(en) 1058 sind an den/die Ausführungscluster 1060 gekoppelt. Der/die Ausführungscluster 1060 beinhaltet/beinhalten eine Menge von einer oder mehreren Ausführungseinheiten 1062 und eine Menge von einer oder mehreren Speicherzugriffseinheiten 1064. Die Ausführungseinheiten 1062 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) an verschiedenen Typen von Daten (z. B. skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektorganzzahl, Vektorgleitkomma) durchführen. Wenngleich manche Ausführungsformen etliche für spezifische Funktionen oder Mengen von Funktionen bestimmte Ausführungseinheiten beinhalten können, können andere Ausführungsformen auch nur eine Ausführungseinheit oder mehrere Ausführungseinheiten, die jeweils alle Funktionen durchführen, beinhalten. Die Scheduler-Einheit(en) 1056, die physische(n) Register-File(s)-Einheit(en) 1058 und der/die Ausführungscluster 1060 werden so gezeigt, als seien sie mehrfach vorhanden, denn bestimmte Ausführungsformen erzeugen separate Pipelines für bestimmte Typen von Daten/Operationen (z. B. eine für Skalarganzzahlen vorgesehene Pipeline, eine für Skalargleitkommata/gepackte Ganzzahlen/gepackte Gleitkommata/Vektorganzzahlen/Vektorgleitkommata vorgesehene Pipeline und/oder eine Speicherzugriffspipeline, die je ihre eigenen Scheduler-Einheiten, physischen Register-File(s)-Einheiten und/oder Ausführungscluster aufweisen - und im Fall einer separaten SpeicherzugriffsPipeline werden bestimmte Ausführungsformen implementiert, in denen nur der Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 1064 aufweist). Es versteht sich auch, dass bei einer Verwendung separater Pipelines eine oder mehrere dieser Pipelines Out-of-order-Zuteilung/Ausführung-Pipelines und die übrigen von ihnen In-order-Pipelines sein können.
Die Menge der Speicherzugriffseinheiten 1064 ist an die Speichereinheit 1070 gekoppelt, welche eine Daten-TLB-Einheit 1072 beinhaltet, die an eine Datencache-Einheit 1074 gekoppelt ist, die an eine Level-2(L2)-Cache-Einheit 1076 gekoppelt ist. In einem Ausführungsbeispiel können die Speicherzugriffseinheiten 1064 eine Ladeeinheit, eine Adressspeichereinheit und eine Datenspeichereinheit, die je an die Daten-TLB-Einheit 1072 in der Speichereinheit 1070 gekoppelt sind, beinhalten. Die Befehlscache-Einheit 1034 ist weiter an eine Level-2(L2)-Cache-Einheit 1076 in der Speichereinheit 1070 gekoppelt. Die L2-Cache-Einheit 1076 ist an einen oder mehrere Cache-Levels und schließlich an einen Hauptspeicher gekoppelt.
Beispielhaft kann die beispielhafte Registerumbenennungs-, Out-of-order-Zuteilung/Ausführung-Kernarchitektur die Pipeline 1000 wie folgt implementieren: 1) Die Befehlsholeinheit 1038 führt die Hol- und Längendecodierstufen 1002 und 1004 durch; 2) die Decodiereinheit 1040 führt die Decodierstufe 1006 durch; 3) die Umbenennungs-/ Allokatoreinheit 1052 führt die Allokationsstufe 1008 und die Umbenennungsstufe 1010 durch; 4) die Scheduler-Einheit(en) 1056 führt/führen die Scheduling-Stufe 1012 durch; 5) die physische(n) Register-File(s)-Einheit(en) 1058 und die Speichereinheit 1070 führen die Registerlese-/Speicherlesestufe 1014 durch; der Ausführungscluster 1060 führt die Ausführungsstufe 1016 durch; 6) die Speichereinheit 1070 und die physische(n) Register-File(s)-Einheit(en) 1058 führen die Zurückschreibe-/ Speicherlesestufe 1018 durch; 7) verschiedene Einheiten können an der Ausnahmebehandlungsstufe 1022 beteiligt sein; und 8) die Rückordnungseinheit 1054 und die physische(n) Register-File(s)-Einheit(en) 1058 führen die Freigabestufe 1024 durch.
Der Kern 1090 kann einen oder mehrere Befehlssätze (z. B. den x86-Befehlssatz mit manchen Erweiterungen, die in neueren Versionen hinzugefügt wurden) unterstützen; den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings aus Sunnyvale, CA, einschließlich des hierin beschriebenen Befehls/der hierin beschriebenen Befehle. In einer Ausführungsform beinhaltet der Kern 1090 eine Logik, um eine Befehlssatzerweiterung für gepackte Daten zu unterstützen (z. B. AVX1, AVX2 und/oder irgendeine Form des allgemeinen vektorfreundlichen Befehlsformats (U=0 und/oder U=1), das bereits beschrieben wurde), sodass die von vielen Multimediaanwendungen verwendeten Operationen unter Verwendung gepackter Daten durchgeführt werden können.
Es versteht sich, dass der Kern Multithreading (wenn zwei oder mehr parallele Mengen von Operationen oder Programmpfaden ausgeführt werden) unterstützen und dies auf vielfältige Weisen tun kann, unter anderem über zeitlich aufgeteiltes Multithreading, gleichzeitiges Multithreading (wobei ein einziger physischer Kern einen logischen Kern für jeden der Programmpfade bereitstellt, die der physische Kern in einem gleichzeitigen Multithreading ausführt) oder eine Kombination daraus (z. B. zeitlich aufgeteiltes Holen und Decodieren und gleichzeitiges Multithreading danach, etwa bei der Intel®-Hyperthreading-Technologie).
Wenngleich die Registerumbenennung im Zusammenhang mit einer Out-of-order-Ausführung beschrieben wird, versteht es sich, dass die Registerumbenennung auch in einer In-order-Architektur verwendet werden kann. Wenngleich die veranschaulichte Ausführungsform des Prozessors auch separate Befehls- und Datencache-Einheiten 1034/1074 und eine gemeinsam genutzte L2-Cache-Einheit 1076 beinhaltet, können alternative Ausführungsformen nur einen Primär-Cache sowohl für Befehle als auch für Daten, zum Beispiel einen Level-1(L1)-Primär-Cache, oder mehrere Primär-Cache-Level aufweisen. In manchen Ausführungsformen beinhaltet das System möglicherweise eine Kombination aus einem Primär-Cache und einem Sekundär-Cache, der sich außerhalb des Kerns und/oder des Prozessors befindet. Alternativ kann sich der gesamte Cache außerhalb des Kerns und/oder des Prozessors befinden.
Spezifische beispielhafte In-order-Kernarchitektur
Die 11A-B veranschaulichen ein Blockschema einer spezifischeren beispielhaften In-order-Kernarchitektur, deren Kern einer von mehreren logischen Bausteinen (einschließlich anderer Kerne vom selben Typ und/oder von unterschiedlichen Typen) in einem Chip wäre. Die logischen Bausteine kommunizieren durch ein Zusammenschaltungsnetz mit hoher Bandbreite (z. B. ein Ringnetz) abhängig von der Anwendung mit irgendeiner festen Funktionslogik, Speicher-E/A-Schnittstellen und anderer notwendiger E/A-Logik.
11A ist ein Blockschema eines einzelnen Prozessorkerns, nebst seiner Verbindung zum auf einem Einzelchip untergebrachten Zusammenschaltungsnetz 1102 und mit seiner lokalen Teilmenge des Level-2(L2)-Cache 1104, gemäß Ausführungsformen der Erfindung. In einer Ausführungsform unterstützt ein Befehlsdecodierer 1100 den x86-Befehlssatz mit einer Befehlssatzerweiterung für gepackte Daten. Ein L1-Cache 1106 erlaubt Zugriffe mit geringer Latenz auf den Cache-Speicher in den Skalar- und Vektoreinheiten. Wenngleich in einer Ausführungsform (um den Aufbau zu vereinfachen) eine Skalareinheit 1108 und eine Vektoreinheit 1110 separate Registersätze (die Skalarregister 1112 bzw. die Vektorregister 1114) verwenden und zwischen ihnen übertragene Daten in einen Speicher geschrieben und dann aus einem Level-1(L1)-Cache 1106 wieder eingelesen werden, können alternative Ausführungsformen der Erfindung auch einen anderen Ansatz verwenden (z. B. einen einzelnen Registersatz verwenden oder einen Kommunikationsweg beinhalten, der erlaubt, dass Daten zwischen den zwei Registerbanken übertragen werden, ohne geschrieben und wieder eingelesen zu werden).
Die lokale Teilmenge des L2-Cache 1104 ist ein Teil eines globalen L2-Cache, der in separate lokale Teilmengen, einen pro Prozessorkern, unterteilt ist. Jeder Prozessorkern weist einen direkten Zugangsweg zu seiner eigenen lokalen Teilmenge des L2-Cache 1104 auf. Von einem Prozessorkern gelesene Daten werden in seiner L2-Cache-Teilmenge 1104 gespeichert und es kann schnell auf sie zugegriffen werden, parallel dazu, wenn andere Prozessorkerne auf ihre eigenen lokalen L2-Cache-Teilmengen zugreifen. Von einem Prozessorkern geschriebene Daten werden in seiner eigenen L2-Cache-Teilmenge 1104 gespeichert und, falls notwendig, von anderen Teilmengen entfernt. Das Ringnetz stellt Kohärenz für gemeinsam genutzte Daten sicher. Das Ringnetz ist bidirektional, sodass Agenten wie Prozessorkerne, L2-Caches und andere logische Bausteine innerhalb des Chips miteinander kommunizieren können. Jeder Ringdatenweg ist pro Richtung 1012 Bit breit.
11B ist eine erweiterte Ansicht von einem Teil des Prozessorkerns in 11A gemäß Ausführungsformen der Erfindung. 11B beinhaltet einen L1-Datencache 1106A, der ein Teil des L1-Cache 1104 ist, sowie weitere Details hinsichtlich der Vektoreinheit 1110 und der Vektorregister 1114. Speziell ist die Vektoreinheit 1110 eine 16 breite Vektorverarbeitungseinheit (VPU) (siehe 16 breite ALU 1128), die einen oder mehrere Ganzzahl-, Single-Precision-Float- oder Double-Precision-Float-Befehle ausführt. Die VPU unterstützt das Swizzeln der Registereingaben mit einer Swizzle-Einheit 1120, numerische Konvertierungen mit für numerische Konvertierungen vorgesehenen Einheiten 1122A-B und Replikationen mit einer Replikationseinheit 1124 an der Speichereingabe. Schreibmaskenregister 1126 erlauben das Darstellen der resultierenden Vektorschreibungen als Prädikate.
Prozessor mit integriertem Speichercontroller und Grafiken
12 ist ein Blockschema eines Prozessors 1200, der mehr als einen Kern aufweisen kann, einen integrierten Speichercontroller aufweisen kann und integrierte Grafiken aufweisen kann, gemäß Ausführungsformen der Erfindung. Die Kästen mit den durchgezogenen Linien in 12 veranschaulichen einen Prozessor 1200 mit einem einzelnen Kern 1202A, einem Systemagenten 1210, einer Menge von einer oder mehreren Buscontrollereinheiten 1216, während die optionale Hinzufügung der Kästen mit den gestrichelten Linien einen alternativen Prozessor 1200 mit mehreren Kernen 1202A-N, einer Menge von einer oder mehreren integrierten Speichercontrollereinheiten 1214 in der Systemagenteneinheit 1210 und einer Speziallogik 1208 veranschaulicht.
Somit können unterschiedliche Implementierungen des Prozessors 1200 Folgendes beinhalten: 1) eine CPU, deren Speziallogik 1208 eine integrierte Grafik- und/oder wissenschaftliche (Durchsatz-)Logik ist (welche einen oder mehrere Kerne beinhalten kann), und deren Kerne 1202A-N einer oder mehrere Universalkerne sind (z. B. Universal-In-order-Kerne, Universal-Out-of-order-Kerne, eine Kombination aus den beiden); 2) einen Coprozessor, dessen Kerne 1202A-N eine große Anzahl von Spezialkernen sind, die in erster Linie für Grafiken und wissenschaftliche (Durchsatz-) Rechenvorgänge vorgesehen sind; und 3) einen Coprozessor, dessen Kerne 1202A-N eine große Anzahl von Universal-In-order-Kernen sind. Somit ist der Prozessor 1200 möglicherweise ein Universalprozessor, ein Coprozessor oder ein Spezialprozessor, zum Beispiel ein Netz- oder ein Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU (General Purpose Graphics Processing Unit), ein Many-Integrated-Core(MIC)-Coprozessor mit hohem Durchsatz (der 30 oder mehr Kerne beinhaltet), ein eingebetteter Prozessor oder dergleichen. Der Prozessor kann auf einem oder mehreren Chips implementiert werden. Der Prozessor 1200 kann ein Teil von einem oder mehreren Substraten sein und/oder kann mittels beliebiger diverser Prozesstechniken wie zum Beispiel BiCMOS, CMOS oder NMOS darauf implementiert werden.
Die Speicherhierarchie beinhaltet einen oder mehrere Cache-Level innerhalb der Kerne, eine Menge oder eine oder mehrere gemeinsam genutzte Cache-Einheiten 1206 und einen externen Speicher (nicht gezeigt), der an die Menge der integrierten Speichercontrollereinheiten 1214 gekoppelt ist. Die Menge der gemeinsam genutzten Cache-Einheiten 1206 beinhaltet möglicherweise einen oder mehrere Mid-Level-Caches, etwa Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cache-Level, einen Last-Level-Cache (LLC) und/oder Kombinationen daraus. Wenngleich in einer Ausführungsform eine ringbasierte Zusammenschalteinheit 1212 die integrierte Grafiklogik 1208, die Menge der gemeinsam genutzten Cache-Einheiten 1206 und die Systemagenteneinheit 1210/die integrierte(n) Speichercontrollereinheit(en) 1214 untereinander verbindet, können alternative Ausführungsformen beliebig viele wohl bekannte Techniken zum Verbinden solcher Einheiten untereinander verwenden. In einer Ausführungsform wird die Kohärenz zwischen einer oder mehreren Cache-Einheiten 1206 und einem oder mehreren Kernen 1202-A-N aufrechterhalten.
In manchen Ausführungsformen sind einer oder mehrere der Kerne 1202AN multithreadingfähig. Der Systemagent 1210 beinhaltet diejenigen Komponenten, die die Kerne 1202A-N koordinieren und betreiben. Die Systemagenteneinheit 1210 beinhaltet zum Beispiel möglicherweise eine Energiesteuerungseinheit (PCU) und eine Anzeigeeinheit. Die PCU ist oder beinhaltet möglicherweise eine Logik und Komponenten, die zum Regeln des Energiezustands der Kerne 1202A-N und der integrierten Grafiklogik 1208 benötigt werden. Die Anzeigeeinheit dient zum Ansteuern einer oder mehrerer extern verbundener Anzeigen.
Die Kerne 1202A-N können bezüglich des Architekturbefehlssatzes homogen oder heterogen sein; das heißt, zwei oder mehr der Kerne 1202A-N können zum Ausführen des gleichen Befehlssatzes fähig sein, während andere nur zum Ausführen einer Teilmenge dieses Befehlssatzes oder eines anderen Befehlssatzes fähig sein können.
Beispielhafte Rechnerarchitekturen
Die 13-16 sind Blockschemata von beispielhaften Rechnerarchitekturen. Andere Systemaufbauten und -konfigurationen, die aus dem Stand der Technik für Laptops, Desktops, Handheld-PCs, Personal Digital Assistants, Engineering Workstations, Server, Netzgeräte, Netzhubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Grafikgeräte, Videospielgeräte, Settop-Boxen, Mikrocontroller, Handys, tragbare Medienwiedergabegeräte, Handheld-Geräte und verschiedene andere elektronische Geräte bekannt sind, sind ebenfalls geeignet. Im Allgemeinen sind äußerst viele Systeme oder elektronische Geräte, in die ein Prozessor und/oder eine andere Ausführungslogik, wie hierin offenbart, eingefügt werden können, allgemein geeignet.
Nunmehr wird unter Bezugnahme auf 13 ein Blockschema eines Systems 1300 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das System 1300 kann einen oder mehrere Prozessoren 1310, 1315 beinhalten, die an einen Controllerhub 1320 gekoppelt sind. In einer Ausführungsform beinhaltet der Controllerhub 1320 einen Graphics Memory Controller Hub (GMCH) 1390 und einen Input/Output Hub (IOH) 1350 (die sich auf separaten Chips befinden können); der GMCH 1390 beinhaltet einen Speicher und Grafikcontroller, an die ein Speicher 1340 und ein Coprozessor 1345 gekoppelt sind; der IOH 1350 koppelt Eingabe/Ausgabe(E/A)-Geräte 1360 an den GMCH 1390. Alternativ sind einer oder beide der Speicher- und Grafikcontroller innerhalb des Prozessors integriert (wie hierin beschrieben), der Speicher 1340 und der Coprozessor 1345 sind direkt an den Prozessor 1310 gekoppelt, und der Controllerhub 1320 ist in einem einzelnen Chip mit dem IOH 1350.
Dass zusätzliche Prozessoren 1315 optional sind, wird in 13 anhand gestrichelter Linien dargestellt. Jeder Prozessor 1310, 1315 kann einen oder mehrere der hierin beschriebenen Verarbeitungskerne beinhalten und kann irgendeine Version des Prozessors 1200 sein.
Der Speicher 1340 ist zum Beispiel möglicherweise ein Dynamic Random Access Memory (DRAM), ein Phase Change Memory (PCM) oder eine Kombination aus beiden. Für mindestens eine Ausführungsform kommuniziert der Controllerhub 1320 mit dem/den Prozessor(en) 1310, 1315 über einen Multidrop-Bus wie einen Frontside-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle wie QuickPath Interconnect (QPI) oder eine ähnliche Verbindung 1395.
In einer Ausführungsform ist der Coprozessor 1345 ein Spezialprozessor wie zum Beispiel ein MIC-Coprozessor mit hohem Durchsatz, ein Netz- oder ein Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann der Controllerhub 1320 einen integrierten Grafikbeschleuniger beinhalten.
Es können vielfältige Unterschiede zwischen den physischen Ressourcen 1310, 1315 bezüglich eines Spektrums von Leistungsmetriken bestehen, welche Architektur-, Mikroarchitektur-, Wärme-, Energieverbrauchseigenschaften und dergleichen beinhalten.
In einer Ausführungsform führt der Prozessor 1310 Befehle aus, die Datenverarbeitungsoperationen von einem allgemeinen Typ steuern. Innerhalb der Befehle können Coprozessorbefehle eingebettet sein. Der Prozessor 1310 erkennt, dass diese Coprozessorbefehle von einem Typ sind, der vom angeschlossenen Coprozessor 1345 ausgeführt werden soll. Dementsprechend gibt der Prozessor 1310 diese Coprozessorbefehle (oder Steuersignale, die Coprozessorbefehle darstellen) auf einem Coprozessorbus oder über eine andere Zwischenverbindung an den Coprozessor 1345 aus. Der/die Coprozessor(en) 1345 akzeptiert/akzeptieren und führt/führen die empfangenen Coprozessorbefehle aus.
Nunmehr wird unter Bezugnahme auf 14 ein Blockschema eines ersten spezifischeren beispielhaften Systems 1400 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 14 gezeigt, ist das Mehrprozessorsystem 1400 ein Punkt-zu-Punkt-Verbindungssystem und beinhaltet einen ersten Prozessor 1470 und einen zweiten Prozessor 1480, die über eine Punkt-zu-Punkt-Verbindung 1450 gekoppelt sind. Jeder der Prozessoren 1470 und 1480 kann irgendeine Version des Prozessors 1200 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 1470 und 1480 jeweils Prozessoren 1310 und 1315, während der Coprozessor 1438 ein Coprozessor 1345 ist. In einer anderen Ausführungsform sind die Prozessoren 1470 und 1480 ein Prozessor 1310 bzw. ein Coprozessor 1345.
Es werden Prozessoren 1470 und 1480 gezeigt, die Integrated-Memory-Controller(IMC)-Einheiten 1472 bzw. 1482 beinhalten. Der Prozessor 1470 beinhaltet als Teil seiner Buscontrollereinheiten auch Punkt-zu-Punkt(P-P)-Schnittstellen 1476 und 1478; ähnlich beinhaltet der zweite Prozessor 1480 P-P-Schnittstellen 1486 und 1488. Die Prozessoren 1470, 1480 können Informationen unter Verwendung von P-P-Schnittstellenschaltungen 1478, 1488 über eine Punkt-zu-Punkt(P-P)-Schnittstelle 1450 austauschen. Wie in 14 gezeigt, koppeln die IMCs 1472 und 1482 die Prozessoren an jeweilige Speicher, nämlich einen Speicher 1432 und einen Speicher 1434, bei denen es sich um Abschnitte eines lokal an die jeweiligen Prozessoren angeschlossenen Hauptspeichers handeln kann.
Die Prozessoren 1470, 1480 können je Informationen unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1476, 1494, 1486, 1498 über individuelle P-P-Schnittstellen 1452, 1454 mit einem Chipsatz 1490 austauschen. Der Chipsatz 1490 kann optional Informationen über eine Hochleistungsschnittstelle 1439 mit dem Coprozessor 1438 austauschen. In einer Ausführungsform ist der Coprozessor 1438 ein Spezialprozessor wie zum Beispiel ein MIC-Coprozessor mit hohem Durchsatz, ein Netz- oder ein Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.
Ein gemeinsam genutzter Cache (nicht gezeigt) kann in jedem oder außerhalb von beiden Prozessoren beinhaltet und dennoch über eine P-P-Zwischenverbindung mit den Prozessoren verbunden sein, sodass lokale Cache-Informationen von einem oder beiden Prozessoren im gemeinsam genutzten Cache gespeichert werden können, falls ein Prozessor in einen Niedrigenergiemodus geschaltet wird.
Der Chipsatz 1490 kann über eine Schnittstelle 1496 an einen ersten Bus 1416 gekoppelt sein. In einer Ausführungsform ist der erste Bus 1416 möglicherweise ein Peripheral-Component-Interconnect(PCI)-Bus oder ein Bus wie ein PCI-Express-Bus oder ein anderer E/A-Verbindungsbus einer dritten Generation, wenngleich der Schutzbereich der vorliegenden Erfindung dadurch nicht begrenzt wird.
Wie in 14 gezeigt, können verschiedene E/A-Geräte 1414 an den ersten Bus 1416 gekoppelt sein, nebst einer Busbrücke 1418, die den ersten Bus 1416 an einen zweiten Bus 1420 koppelt. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessoren 1415, etwa Coprozessoren, MIC-Prozessoren mit hohem Durchsatz, GPGPUs, Beschleuniger (wie z. B. Grafikbeschleuniger oder Digitalsignalverarbeitungs(DSP)-Einheiten), feldprogrammierbare Gate Arrays oder beliebige andere Prozessoren, an den ersten Bus 1416 gekoppelt. In einer Ausführungsform ist der zweite Bus 1420 möglicherweise ein Low-Pin-Count(LPC)-Bus. An einen zweiten Bus 1420 können in einer Ausführungsform verschiedene Geräte gekoppelt sein, die zum Beispiel eine Tastatur und/oder eine Maus 1422, Kommunikationsgeräte 1427 und eine Speichereinheit 1428 wie ein Plattenlaufwerk oder ein anderes Massenspeichergerät, die Befehle/Code und Daten 1430 beinhalten kann, beinhalten. Weiter kann an den zweiten Bus 1420 ein Audio-E/A-Baustein 1424 gekoppelt sein. Es ist zu beachten, dass andere Architekturen möglich sind. Zum Beispiel kann ein System statt der Punkt-zu-Punkt-Architektur von 14 einen Multidrop-Bus oder eine andere derartige Architektur implementieren.
Nunmehr wird unter Bezugnahme auf 15 ein Blockschema eines zweiten spezifischeren beispielhaften Systems 1500 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente in den 14 und 15 tragen gleiche Bezugszeichen, und bestimmte Aspekte von 14 wurden in 15 weggelassen, um die Verständlichkeit anderer Aspekte von 15 nicht zu erschweren.
15 veranschaulicht, dass die Prozessoren 1470, 1480 einen integrierten Speicher und eine E/A-Steuerlogik („CL“) 1472 bzw. 1482 beinhalten können. Somit beinhaltet die CL 1472, 1482 integrierte Speichercontrollereinheiten und eine E/A-Steuerlogik. 15 veranschaulicht, dass nicht nur die Speicher 1432, 1434 an die CL 1472, 1482 gekoppelt, sondern auch E/A-Geräte 1514 an die Steuerlogik 1472, 1482 gekoppelt sind. Ältere E/A-Geräte 1515 sind an den Chipsatz 1490 gekoppelt.
Nunmehr wird unter Bezugnahme auf 16 ein Blockschema eines SoC 1600 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 12 tragen gleiche Bezugszeichen. Zudem sind Kästen mit gestrichelten Linien optionale Merkmale in weiterentwickelten SoCs. In 16 ist eine Zusammenschalteinheit 1602 an Folgendes gekoppelt: einen Anwendungsprozessor 1610, der eine Menge von einem oder mehreren Kernen 202A-N und (eine) gemeinsam genutzte Cache-Einheit(en) 1206 beinhaltet; eine Systemagenteneinheit 1210; (eine) Buscontrollereinheit(en) 1216; (eine) integrierte Speichercontrollereinheit(en) 1214; eine Menge oder einen oder mehrere Coprozessoren 1620, die eine integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor beinhalten; eine Static-Random-Access-Memory(SRAM)-Einheit 1630; eine Direct-Memory-Access(DMA)-Einheit 1632; und eine Anzeigeeinheit 1640 zum Koppeln an eine oder mehrere externe Anzeigen. In einer Ausführungsform beinhaltet/beinhalten der/die Coprozessor(en) 1620 einen Spezialprozessor wie zum Beispiel einen Netz- oder einen Kommunikationsprozessor, eine Komprimierungsengine, eine GPGPU, einen MIC-Coprozessor mit hohem Durchsatz, einen eingebetteten Prozessor oder dergleichen.
Ausführungsformen der hierin offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination aus solchen Implementierungsansätzen implementiert werden. Ausführungsformen der Erfindung sind implementierbar als Rechnerprogramme oder Programmcode zur Ausführung in programmierbaren Systemen, die mindestens einen Prozessor, ein Speichersystem (einschließlich flüchtiger und nichtflüchtiger Speicher und/oder Speicherelemente), mindestens ein Eingabegerät und mindestens ein Ausgabegerät umfassen.
Ein Programmcode wie der in 14 veranschaulichte Code 1430 kann auf Eingabebefehle zum Durchführen der hierin beschriebenen Funktionen und zum Generieren von Ausgabeinformationen angewendet werden. Die Ausgabeinformationen können auf bekannte Art auf ein oder mehrere Ausgabegeräte angewendet werden. Für die Zwecke dieser Anmeldung beinhaltet ein Verarbeitungssystem ein beliebiges System, das einen Prozessor wie zum Beispiel einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor aufweist.
Der Programmcode kann in einer höheren prozeduralen oder objektorientierten Programmiersprache für die Kommunikation mit einem Verarbeitungssystem implementiert werden. Der Programmcode kann, falls gewünscht, auch in einer Assembler- oder Maschinensprache implementiert werden. Grundsätzlich sind die hierin beschriebenen Mechanismen, was ihren Schutzbereich betrifft, auf keine konkrete Programmiersprache begrenzt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentative Befehle implementiert werden, die in einem maschinenlesbaren Medium gespeichert sind, das unterschiedliche Logiken innerhalb des Prozessors darstellt, welches, wenn es von einer Maschine gelesen wird, bewirkt, dass die Maschine eine Logik zum Durchführen der hierin beschriebenen Techniken herstellt. Solche Darstellungen, bekannt als „IP-Cores“, können in einem physischen, maschinenlesbaren Medium gespeichert und an verschiedene Kunden oder Produktionsanlagen geliefert werden, um damit Herstellungsmaschinen zu beschicken, welche die Logik oder den Prozessor letztlich fertigen.
Dementsprechend beinhalten Ausführungsformen der Erfindung auch nicht transiente, physische, maschinenlesbare Medien, die Befehle enthalten oder Auslegungsdaten enthalten, etwa die Hardware-Beschreibungssprache (HDL), die Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert, die hierin beschrieben werden. Solche Ausführungsformen werden gegebenenfalls auch als Programmprodukte bezeichnet.
Emulation (einschließlich Binärübersetzung, Codeumsetzung etc.)
In manchen Fällen wird möglicherweise ein Befehlsumwandler verwendet, um einen Befehl aus einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. Der Befehlsumwandler kann zum Beispiel einen Befehl in einen oder mehrere andere vom Kern zu verarbeitende Befehle übersetzen (z. B. mittels statischer Binärübersetzung, dynamischer Binärübersetzung, die eine dynamische Kompilierung beinhaltet), umsetzen, emulieren oder auf andere Weise umwandeln. Der Befehlsumwandler kann in Software, Hardware, Firmware oder einer Kombination daraus implementiert sein. Der Befehlsumwandler kann sich innerhalb des Prozessors, außerhalb des Prozessors oder teilweise innerhalb und teilweise außerhalb des Prozessors befinden.
17 ist ein Blockschema, das Verwendungen eines Softwarebefehlsumwandlers zum Umwandeln von Binärbefehlen in einem Quellbefehlssatz in Binärbefehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung einander gegenüberstellt. In der veranschaulichten Ausführungsform ist der Befehlsumwandler ein Software-Befehlsumwandler, obgleich der Befehlsumwandler alternativ auch in Software, Firmware, Hardware oder verschiedenen Kombinationen daraus implementiert sein kann. 17 zeigt, wie ein Programm in einer höheren Sprache 1702 unter Verwendung eines x86-Compilers 1704 kompiliert werden kann, um einen x86-Binärcode 1706, der von einem Prozessor mit mindestens einem x86-Befehlssatzkern 1716 nativ ausgeführt werden kann, zu generieren. Der Prozessor mit mindestens einem x86-Befehlssatzkern 1716 steht für einen beliebigen Prozessor, der im Wesentlichen die gleichen Funktionen wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern durchführen kann, indem er (1) einen wesentlichen Abschnitt des Befehlssatzes des Intel-x86-Befehlssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software zur Ausführung auf einem Intel-Prozessor mit mindestens einem x86-Befehlssatzkern kompatibel ausführt oder auf andere Weise verarbeitet, um im Wesentlichen das gleiche Ergebnis zu erzielen wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern. Der x86-Compiler 1704 steht für einen Compiler, der zum Generieren eines x86-Binärcodes 1706 (z. B. eines Objektcodes) eingesetzt werden kann, der mit oder ohne zusätzliche Bindungsverarbeitung auf dem Prozessor mit mindestens einem x86-Befehlssatzkern 1716 ausgeführt werden kann. Ebenso zeigt 17, wie das Programm in der höheren Sprache 1702 unter Verwendung eines für einen alternativen Befehlssatz vorgesehenen Compilers 1708 kompiliert werden kann, um einen alternativen Befehlssatzbinärcode 1710 zu generieren, der von einem Prozessor ohne mindestens einen x86-Befehlssatzkern 1714 (z. B. einem Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, CA, ausführen und/oder die den ARM-Befehlssatz von ARM Holdings aus Sunnyvale, CA, ausführen) nativ ausgeführt werden kann. Der Befehlsumwandler 1712 wird verwendet, um den x86-Binärcode 1706 in einen Code umzuwandeln, der vom Prozessor ohne einen x86-Befehlssatzkern 1714 nativ ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht der gleiche wie der alternative Befehlssatzbinärcode 1710, denn die Herstellung eines Befehlsumwandlers, der dazu fähig ist, ist schwierig; der umgewandelte Code bewerkstelligt jedoch den allgemeinen Ablauf und setzt sich aus Befehlen aus dem alternativen Befehlssatz zusammen. Somit stellt der Befehlsumwandler 1712 Software, Firmware, Hardware oder eine Kombination daraus dar, die durch Emulation, Simulation oder irgendeinen anderen Prozess erlaubt, dass ein Prozessor oder ein anderes elektronisches Gerät ohne einen x86-Befehlssatzprozessor oder -kern den x86-Binärcode 1706 ausführt.
Ausführungsformen können in vielen unterschiedlichen Typen von Systemen verwendet werden. In einer Ausführungsform kann ein Kommunikationsgerät zum Beispiel angeordnet sein, um die verschiedenen hierin beschriebenen Verfahren und Techniken durchzuführen. Selbstverständlich ist der Schutzbereich der vorliegenden Erfindung nicht auf ein Kommunikationsgerät begrenzt, und andere Ausführungsformen können stattdessen auf andere Typen von Vorrichtungen zum Verarbeiten von Befehlen oder ein oder mehrere maschinenlesbare Medien abzielen, welche Befehle beinhalten, die in Ansprechen darauf, dass sie in einem Rechnergerät ausgeführt werden, bewirken, dass das Gerät eines oder mehrere der Verfahren und eine oder mehrere der Techniken, die hierin beschrieben werden, ausführt.
Ausführungsformen sind in Code implementierbar und können in einem nicht transienten Speichermedium gespeichert werden, in dem Befehle gespeichert sind, die verwendet werden können, um ein System so zu programmieren, dass es die Befehle durchführt. Das Speichermedium kann, ohne jedoch darauf begrenzt zu sein, beliebige Typen von Platten beinhalten, einschließlich Disketten, optischer Speicherplatten, Solid-State-Laufwerken (SSDs), Compact-Disk-Festwertspeichern (CD-ROMs), wiederbeschreibbarer Compact Disks (CD-RWs) und magnetooptischer Speicherplatten, Halbleiterbauelementen wie Festwertspeichern (ROMs), Arbeitsspeichern (RAMs) wie Dynamic Random Access Memorys (DRAMs), Static Random Access Memorys (SRAMs), löschbarer programmierbarer Nurlesespeicher (EPROMs), Flashspeichern, elektrisch löschbarer programmierbarer Nurlesespeicher (EEPROMs), magnetischer oder optischer Speicherkarten oder beliebiger anderer Typen von Medien, die zum Speichern elektronischer Befehle geeignet sind.

Claims

Prozessor (100) umfassend: ein Ausführungsmittel (103-1, ..., 103_N), das eine Vektoreinheit und eine Skalareinheit beinhaltet; wobei die Vektoreinheit dazu eingerichtet ist, eine aus einer Vielzahl von Schleifen gebildete, zusammengeführte Schleife auszuführen, um einen Vektor mit Offsets, Offset-Vector, zu erhalten; gekennzeichnet dadurch, dass die Vektoreinheit dazu eingerichtet ist, für die Ausführung der zusammengeführten Schleife mehrere Iterationen der zusammengeführten Schleife durchzuführen, wobei jede der Iterationen der zusammengeführten Schleife folgende Operationen umfasst: ein Kalkulieren eines skalaren Offsets in eine mehrdimensionale Datenstruktur, wobei die Kalkulation des skalaren Offsets in Form eines absoluten Werts eines Index umfasst, wobei der absolute Wert des Index unter Verwendung eines Schleifenzählerwerts eines Vektors mit Zählerwerten für die Vielzahl von Schleifen, MDLC-Vektors, sowie eines Anfangswerts, der aus einem Vektor von Anfangswerten, Anfangswert-Vektor, erhalten wird, bestimmt wird, ein Speichern des skalaren Offsets in einem Datenelement eines ersten Vektors, der in einem Vektorregister des Prozessors gespeichert ist, ein Aktualisieren mindestens eines Schleifenzählerwerts des MDLC-Vektors, und anschließend: ein Laden einer Vielzahl von Datenelementen aus der mehrdimensionalen Datenstruktur in einen weiteren, zweiten Vektor unter Verwendung eines Basiswerts und von Indizes aus dem Offset-Vector, ein Durchführen mindestens einer Berechnung mit den geladenen Datenelementen im zweiten Vektor, um eine Vielzahl von Ergebnissen zu erhalten, und ein Speichern der Vielzahl von Ergebnissen in der mehrdimensionalen Datenstruktur unter Verwendung des Basiswerts und der Indizes aus dem Offset-Vector; wobei die Vektoreinheit dazu eingerichtet ist, den MDLC-Vektor in Reaktion auf einen Aktualisierungsbefehl zu aktualisieren, wobei der Aktualisierungsbefehl beinhaltet: einen ersten Operanden, der den MDLC-Vektor identifiziert, einen zweiten Operanden, der einen Vektor von De- oder Inkrementierungs-Faktoren identifiziert, und einen dritten Operanden, der einen Vektor von Differenzen zwischen einem Anfangswert und einem Endwert für jeden der Schleifenzählerwerte des MDLC-Vektors identifiziert.
Prozessor nach Anspruch 1, wobei die Vektoreinheit dazu eingerichtet ist, die Vielzahl von Schleifen in der zusammengeführten Schleife zusammenzuführen.
Prozessor nach Anspruch 1 oder 2, wobei die wobei die Vektoreinheit dazu eingerichtet ist, die zusammengeführte Schleife zu vektorisieren, wobei die Anzahl der Iterationen der zusammengeführten Schleife dem Produkt einer Anzahl von Iterationen von jeder der Vielzahl von Schleifen entspricht.
Prozessor nach einem der Ansprüche 1 bis 3, wobei das Ausführungsmittel dazu eingerichtet ist, die Ausführung der Iterationen der zusammengeführten Schleife in Reaktion auf einen ersten Zustand eines Flags, das durch die Ausführung des Aktualisierungsbefehls aktualisiert wird, vorzunehmen, ohne alle Iterationen auszuführen.
Prozessor nach Anspruch 4, wobei das Ausführungsmittel weiter dazu eingerichtet ist, mindestens eine Vektorberechnung gemäß einer Vektormaske durchzuführen.
Prozessor nach Anspruch 5, wobei ein erstes Element der Vektormaske einen ersten Wert aufweist, falls eine erste Iteration der Vielzahl von Iterationen durch das Ausführungsmittel ausgeführt wurde, und ein zweites Element der Vektormaske einen zweiten Wert aufweist, falls eine zweite Iteration der Vielzahl von Iterationen nicht durch das Ausführungsmittel ausgeführt wurde.
Verfahren, das von einer Vektoreinheit eines Prozessors ausgeführt wird und das Folgendes umfasst: Ausführen einer zusammengeführten Schleife, die aus einer Vielzahl von Schleifen ausgebildet ist, um einen Offset-Vector zu erhalten, gekennzeichnet dadurch, dass das Ausführen der zusammengeführten Schleife mehrere Iterationen der zusammengeführten Schleife beinhaltet, wobei jede der Iterationen folgende Operationen umfasst: Kalkulieren eines skalaren Offsets in eine mehrdimensionale Datenstruktur, wobei die Kalkulation des skalaren Offsets in Form eines absoluten Werts eines Index umfasst, wobei der absolute Wert des Index unter Verwendung eines Schleifenzählerwerts eines Vektors mit Zählerwerten für die Vielzahl von Schleifen, MDLC-Vektors, sowie eines Anfangswerts, der aus einem Vektor von Anfangswerten, Anfangswert-Vektor, erhalten wird, bestimmt wird, Speichern des skalaren Offsets in einem Datenelement eines ersten Vektors, der in einem Vektorregister des Prozessors gespeichert ist, Aktualisieren mindestens eines Schleifenzählerwerts eines MDLC-Vektors beinhaltet; und anschließend: Laden einer Vielzahl von Datenelementen aus der mehrdimensionalen Datenstruktur in einen weiteren, zweiten Vektor unter Verwendung eines Basiswerts und von Indizes aus dem Offset-Vector; Durchführen mindestens einer Berechnung mit den geladenen Datenelementen, um eine Vielzahl von Ergebnissen zu erhalten; und Speichern der Ergebnisse in der mehrdimensionalen Datenstruktur unter Verwendung des Basiswerts und der Indizes aus dem Offset-Vector, wobei der MDLC-Vektor in Reaktion auf einen Aktualisierungsbefehl aktualisiert wird, wobei der Aktualisierungsbefehl beinhaltet: einen ersten Operanden, der den MDLC-Vektor identifiziert, einen zweiten Operanden, der einen Vektor von De- oder Inkrementierungs-Faktoren identifiziert, und einen dritten Operanden, der einen Vektor von Differenzen zwischen einem Anfangswert und einem Endwert für jeden der Schleifenzählerwerte des MDLC-Vektors identifiziert.