DE112011105818T5

DE112011105818T5 - Systeme, Vorrichtungen und Verfahren zum Expandieren einer Speicherquelle in ein Zielregister und komprimieren eines Quellenregisters in eine Zielspeicherstelle

Info

Publication number: DE112011105818T5
Application number: DE112011105818.7T
Authority: DE
Inventors: Roger Espasa Sans; Sridhar Samudrala; Jesus Corbal San Adrian; Robert C. Valentine; Santiago Galan Duran; Jeffrey G. Wiedemeier; Milind Baburao Girkar; Viktor W. Lee; Andrew Thomas Forsyth
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2011-04-01
Filing date: 2011-12-09
Publication date: 2014-10-23
Also published as: TW201523441A; GB201317058D0; GB2503827B; JP2014513341A; US20120254592A1; JP6109910B2; KR20160130320A; CN103562855A; WO2012134558A1; TWI550512B; KR20130137698A; KR101851487B1; TW201241744A; GB2503827A; TWI470542B; CN103562855B; JP2016029598A

Abstract

Es werden Ausführungsformen von Systemen, Vorrichtungen und Verfahren zum Ausführen einer Expandier- und/oder Komprimieranweisung in einem Computerprozessor beschrieben. Bei bestimmten Ausführungsformen bewirkt Die Ausführung einer Expandieranweisung die Auswahl von Elementen aus einer Quelle, die spärlich in einem Ziel zu speichern sind, auf der Basis von Werten der Schreibmaske, und Speichern jedes ausgewählten Datenelements der Quelle als spärliches Datenelement in einer Zielspeicherstelle, wobei die Zielspeicherstellen jeweils Schreibmasken-Bitpositionen entsprechen, die angeben, dass das entsprechende Datenelement der Quelle zu speichern ist.

Description

TECHNISCHES GEBIET
Das Gebiet der Erfindung betrifft allgemein Computerprozessorarchitektur und insbesondere Anweisungen, die, wenn sie ausgeführt werden, ein bestimmtes Ergebnis bewirken.
STAND DER TECHNIK
Es gibt viele Weisen zur Verbesserung der Speicherauslastung durch Manipulieren des Datenstrukturlayouts. Für bestimmte Algorithmen, wie 3D-Transformationen und Beleuchtung, gibt es zwei grundlegende Weisen zur Anordnung der Vertexdaten. Das traditionelle Verfahren ist die Array-von-Strukturen- bzw. AoS-Anordnung mit einer Struktur für jeden Vertex. Ein anderes ordnet die Daten in einem Array für jede Koordinate in einer Struktur-von-Arrays- bzw. SoA-Anordnung an.
Es gibt zwei Möglichkeiten zur Berechnung von Daten im AoS-Format: Ausführen der Operation an den Daten, sowie sie in einer AoS-Anordnung stehen, oder Umordnen (”Swizzle”) dieser zu einer SoA-Anordnung. Das Ausführen von SIMD-Operationen an der ursprünglichen AoS-Anordnung kann mehr Berechnungen erfordern und bestimmte der Operationen nutzen nicht alle verfügbaren SIMD-Elemente aus. Diese Möglichkeit ist deshalb im Allgemeinen weniger effizient.
Die SoA-Anordnung erlaubt eine effizientere Verwendung des Parallelismus der SIMD-Technologien (Single Instruction, Multiple Data), weil die Daten für Berechnung auf optimalere vertikale Weise bereit sind.
Im Gegensatz dazu kann eine direkte Datenverarbeitung an AoS-Daten zu horizontalen Operationen führen, die SIMD-Ausführungsschlitze verbrauchen, aber nur ein einziges skalares Ergebnis produzieren, wie durch die in der vorherigen Codeprobe gezeigten vielen DC-Schlitze (”don't care”) gezeigt wird.
Mit dem Aufkommen der SIMD-Technologien wird die Wahl der Datenorganisation wichtiger und sollte sorgfältig auf den an den Daten auszuführenden Operationen basieren. Bei bestimmten Anwendungen führen traditionelle Datenanordnungen möglicherweise nicht zu der maximalen Leistungsfähigkeit. Anwendungsentwickler wurden ermutigt, verschiedene Datenanordnungen und Datensegmentierungsrichtlinien für effiziente Datenverarbeitung zu erkunden. Das kann Verwendung einer Kombination von AoS, SoA und sogar Hybrid-SoA in einer gegebenen Anwendung bedeuten.
Kurze Beschreibung der Zeichnungen
Die vorliegende Erfindung wird in den Figuren der beigefügten Zeichnungen, in denen gleiche Bezugszeichen ähnliche Elemente angeben, beispielhaft und nicht beschränkend dargestellt. Es zeigen:
1 ein Beispiel für die Ausführung einer Expandieranweisung.
2 ein Beispiel für die Ausführung einer Expandieranweisung mit einem Registeroperanden als Quelle.
3 ein Beispiel für Pseudocode zum Ausführen einer Expandieranweisung.
4 eine Ausführungsform der Verwendung einer Expandieranweisung in einem Prozessor.
5 eine Ausführungsform eines Verfahrens zum Verarbeiten einer Expandieranweisung.
6 ein Beispiel für die Ausführung einer Komprimieranweisung in einem Prozessor.
7 ein anderes Beispiel für die Ausführung einer Komprimieranweisung in einem Prozessor.
8 ein Beispiel für Pseudocode zum Ausführen einer Expandieranweisung.
9 eine Ausführungsform der Verwendung einer Komprimieranweisung in einem Prozessor.
10 ein Beispiel für eine Ausführungsform eines Verfahrens zum Verarbeiten einer Komprimieranweisung.
11A ein Blockdiagramm eines generischen vektorfreundlichen Anweisungsformats und von Klasse-A-Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung.
11B ein Blockdiagramm des generischen vektorfreundlichen Anweisungsformats und von Klasse-B-Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung.
12A–C ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat gemäß Ausführungsformen der Erfindung.
13 ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform der Erfindung.
14A ein Blockdiagramm eines Einzel-CPU-Kerns zusammen mit seiner Verbindung mit dem Auf-Chip-Verbindungsnetzwerk und mit seiner lokalen Teilmenge des Level-2- bzw. L2-Cache gemäß Ausführungsformen der Erfindung.
14B eine Explosionsansicht eines Teils des CPU-Kerns in 14A gemäß Ausführungsformen der Erfindung.
15 ein Blockdiagramm einer beispielhaften Außerreihenfolge-Architektur gemäß Ausführungsformen der Erfindung.
16 ein Blockdiagramm eines Systems gemäß einer Ausführungsform der Erfindung.
17 ein Blockdiagramm eines zweiten Systems gemäß einer Ausführungsform der Erfindung.
18 ein Blockdiagramm eines dritten Systems gemäß einer Ausführungsform der Erfindung.
19 ein Blockdiagramm eines SoC gemäß einer Ausführungsform der Erfindung.
20 ein Blockdiagramm eines Einzel-Kern-Prozessors und eines Mehrkern-Prozessors mit integriertem Speichercontroller und Grafik gemäß Ausführungsformen der Erfindung.
21 ein Blockdiagramm, das die Verwendung eines Software-Anweisungsumsetzers zum Umsetzen von binären Anweisungen in einem Quellenanweisungssatz binären Anweisungen in einem Zielanweisungssatz gemäß Ausführungsformen der Erfindung gegenüberstellt.
AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt. Es versteht sich jedoch, dass Ausführungsformen der Erfindung ohne diese spezifischen Einzelheiten ausgeübt werden können. In anderen Fällen wurden wohlbekannte Schaltungen, Strukturen und Techniken nicht im Detail gezeigt, um das Verständnis der vorliegenden Beschreibung nicht zu verschleiern.
Erwähnungen in der Beschreibung von ”einer Ausführungsform”, ”einer beispielhaften Ausführungsform” usw. geben an, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine bestimmte Struktur oder ein bestimmtes Charakteristikum enthalten kann, aber nicht unbedingt jede Ausführungsform das bestimmte Merkmal, die bestimmte Struktur oder das bestimmte Charakteristikum enthält. Darüber hinaus beziehen sich solche Ausdrücke nicht unbedingt auf dieselbe Ausführungsform. Wenn ein bestimmtes Merkmal, eine bestimmte Struktur oder ein bestimmtes Charakteristikum in Verbindung mit einer Ausführungsform beschrieben wird, versteht sich ferner, dass es innerhalb der Kenntnis von Fachleuten liegt, ein solches Merkmal, eine solche Struktur oder ein solches Charakteristikum in Verbindung mit anderen Ausführungsformen zu bewirken, gleichgültig, ob es explizit beschrieben wird oder nicht.
Im Folgenden werden mehrere Ausführungsformen von ”Expandier”- und ”Komprimier”-Anweisungen und Ausführungsformen von Systemen, Architekturen, Anweisungsformaten usw., die zur Ausführung solcher Anweisungen verwendet werden können, erläutert. Expandierung und Komprimierung sind in mehreren verschiedenen Gebieten nützlich, darunter Umsetzung von AoS- und SoA-Anordnungen. Zum Beispiel der Übergang von Mustern XYZW XYZW XYZW ... XYZW zu Mustern der Art XXXXXXXX YYYYYYYY ZZZZZZZZZZ WWWWWWWW. Ein anderes solches Gebiet ist die Matrixtransponierung. Ein Vektor mit einer Länge 16 könnte als 4x4-Array von Elementen angesehen werden. Mit einer Expandieranweisung könnte eine Zeile von vier aufeinanderfolgenden Elementen M[0], M[1], M[2] und M[3] abgerufen und (mit Zusammenführung, um das Array weiter aufzubauen) in eine der 4x4-Arrayzeilen (zum Beispiel die Vektorelemente 1, 3, 7 und 11) expandiert werden.
Zusätzlich würde Vielzweckcode, der Speicher auf der Basis einer dynamischen Bedingung in aufeinanderfolgenden Speicherstellen speichert, aus Komprimier- und Expandieranweisungen Nutzen ziehen. Zum Beispiel ist es in bestimmten Fällen vorteilhaft, seltene Elemente, die eine außerordentliche Bedingung aufweisen, in einen zeitlichen Speicherplatz zu komprimieren. Diese zusammengepackt zu speichern vergrößert die Dichte der Berechnung. Eine Möglichkeit hierfür ist die Verwendung der Komprimierung, die nachfolgend erläutert wird. Nach dem Verarbeiten von zeitlichem Speicherplatz (oder FIFO) kann Expandierung verwendet werden, um diese seltenen Elemente wieder auf ihre ursprüngliche Position wiederherzustellen. Expandierung wird auch zur Neuexpandierung von Daten, die in eine Warteschlange gepackt wurden, verwendet.
Expandierung
Beginnend mit der Expandierung bewirkt die Ausführung der Expandierung, dass ein Prozessor aufeinanderfolgende Datenelemente aus einem Quellenoperanden (einem Speicher- oder Registeroperanden) auf der Basis der durch den Schreibmaskenoperanden bestimmten aktiven Elemente in (spärliche) Datenelementpositionen in einem Zieloperanden (typischerweise einem Registeroperanden) schreibt. Zusätzlich können die Datenelemente des Quellenoperanden abhängig von ihrer Größe und wie große Datenelemente sich in dem Zielregister befinden, aufwärts umgesetzt werden. Wenn zum Beispiel der Quellenoperand ein Speicheroperand ist und seine Datenelemente 16 Bit groß sind und die Datenelemente des Zielregisters 32 Bit aufweisen, werden die im Ziel zu speichernden Datenelemente des Speicheroperanden aufwärts umgesetzt, um 32 Bit aufzuweisen. Beispiele für Aufwärtsumsetzung und wie sie zu einem Anweisungsformat codiert werden, werden später erläutert.
Ein Format dieser Anweisung ist ”VEXPANDS zmm1 {k1} zmm2/U(mem)”, wobei zmm1 und zmm2 ein Ziel- bzw. Quellenvektorregisteroperand (wie etwa ein 128-, 256-, 512-Bit-Register usw.) sind, k1 ein Schreibmaskenoperand (wie etwa ein 16-Bit-Register) ist und U(mem) ein Quellenspeicherstellenoperand ist. Was auch immer aus dem Speicher abgerufen wird, ist eine Ansammlung aufeinanderfolgender Bits, beginnend von der Speicherstartadresse, und kann abhängig von der Größe des Zielregisters eine von mehreren Größen (128-, 256-, 512-Bit usw.) aufweisen – die Größe ist im Allgemeinen dieselbe Größe wie das Zielregister. Bei bestimmten Ausführungsformen weist die Schreibmaske auch eine andere Größe (8 Bit, 32 Bit usw.) auf. Zusätzlich werden bei bestimmten Ausführungsformen nicht alle Bit der Schreibmaske von der Anweisung benutzt (z. B. werden nur die unteren acht niedrigstwertigen Bit verwendet). Natürlich ist VEXPANDPS der Opcode der Anweisung. Typischerweise wird jeder Operand explizit in der Anweisung definiert. Die Größe der Datenelemente kann im ”Präfix” der Anweisung definiert werden, wie etwa durch Verwendung einer Angabe des Datengranularitätsbit wie ”W” (später beschrieben). Bei den meisten Ausführungsformen gibt W an, dass Datenelemente jeweils entweder 32 oder 64 Bit aufweisen. Wenn die Datenelemente alle 32 Bit groß sind und die Quellen 512 Bit groß sind, gibt es sechzehn (16) Datenelemente pro Quelle.
Diese Anweisung wird normalerweise einer Schreibmaske unterzogen, so dass nur die Elemente mit dem gesetzten entsprechenden Bit in einem Schreibmaskenregister (k1 in dem obigen Beispiel) im Zielregister modifiziert werden. Elemente im Zielregister mit gelöschtem entsprechendem Bit in dem Schreibmaskenregister behalten ihre vorherigen Werte. Wenn keine Schreibmaske (oder eine auf durchweg Einsen gesetzte Schreibmaske) verwendet wird, kann diese Anweisung für Vektorladevorgänge höherer Leistungsfähigkeit verwendet werden, wobei eine hohe Konfidenz besteht, dass die Speicherreferenz eine Cache-Linienaufteilung produziert.
Ein Beispiel für die Ausführung einer Expandieranweisung ist in 1 dargestellt. In diesem Beispiel ist die Quelle Speicher, adressiert an eine Adresse, die im RAX-Register gefunden wird. Die Speicheradresse kann natürlich auch in anderen Registern gespeichert oder unmittelbar in der Anweisung gefunden werden. Die Schreibmaske ist in diesem Beispiel als 0x4DB1 gezeigt. Für jede Bitposition der Schreibmaske mit einem Wert ”1” wird ein Datenelement aus der Speicherquelle an der entsprechenden Position im Zielregister gespeichert. Zum Beispiel ist die erste Position der Schreibmaske (z. B. k2[0]) ”1”, wodurch angegeben wird, dass an der entsprechenden Zieldatenelementposition (z. B. dem ersten Datenelement des Zielregisters) ein Datenelement aus dem Quellenspeicher gespeichert wird. In diesem Fall wäre es das Datenelement, das mit der RAX-Adresse assoziiert ist. Die nächsten drei Bit der Maske sind ”0”, wodurch angegeben wird, dass die entsprechenden Datenelemente des Zielregisters alleine gelassen werden (was in der Figur als ”Y” gezeigt ist). Der nächste ”1”-Wert in der Schreibmaske ist an der fünften Bitposition (z. B. k2[4]). Dadurch wird angegeben, dass das Datenelement, das dem mit dem RAX-Register assoziierten Datenelement nachfolgend (aufeinanderfolgend) ist, in dem fünften Datenelementschlitz des Zielregisters zu speichern ist. Die verbleibenden Schreibmasken-Bitpositionen werden verwendet, um zu bestimmen, welche zusätzlichen Datenelemente der Speicherquelle im Zielregister zu speichern sind (in diesem Fall werden acht Gesamtdatenelemente gespeichert, es könnte aber abhängig von der Schreibmaske weniger oder mehr geben). Zusätzlich können die Datenelemente aus der Speicherquelle aufwärts umgesetzt werden, um auf die Datenelementgröße des Ziels zu passen, wie etwa Übergang von einem 16-Bit-Floating-Point-Wert zu einem 32-Bit-Wert vor Speicherung im Ziel. Beispiele für Aufwärtsumsetzung und wie sie in ein Anweisungsformat zu codieren sind, wurden oben erläutert. Zusätzlich werden bei bestimmten Ausführungsformen die aufeinanderfolgenden Datenelemente des Speicheroperanden vor der Expansion in einem Register gespeichert.
2 zeigt ein Beispiel für die Ausführung einer Expandieranweisung mit einem Registeroperanden als Quelle. Wie bei der vorherigen Figur ist die Schreibmaske in diesem Beispiel 0x4DB1. Für jede Bitposition der Schreibmaske mit einem ”1”-Wert wird ein Datenelement aus der Registerquelle an der entsprechenden Position in dem Zielregister gespeichert. Zum Beispiel ist die erste Position der Schreibmaske (z. B. k2[0]) ”1”, wodurch angegeben wird, dass an der entsprechenden Zieldatenelementposition (z. B. dem ersten Datenelement des Zielregisters) ein Datenelement aus dem Quellenregister gespeichert wird. In diesem Fall wäre es das erste Datenelement des Quellenregisters. Die nächsten drei Bit der Maske sind ”0”, wodurch angegeben wird, dass die entsprechenden Datenelemente des Zielregisters alleine gelassen werden (in der Figur als ”Y” gezeigt). Der nächste ”1”-Wert in der Schreibmaske ist an der fünften Bitposition (z. B. k2[4]). Dadurch wird angegeben, dass das Datenelement, das den ersten gespeicherten Daten des Quellenregisters nachfolgend (aufeinanderfolgend) ist, im fünften Datenelementschlitz des Zielregisters zu speichern ist. Die verbleibenden Schreibmasken-Bitpositionen werden verwendet, um zu bestimmen, welche zusätzlichen Datenelemente der Registerquelle im Zielregister zu speichern sind (in diesem Fall werden acht Gesamtdatenelemente gespeichert, es könnte aber abhängig von der Schreibmaske weniger oder mehr geben).
3 zeigt ein Beispiel für Pseudocode zum Ausführen einer Expandieranweisung.
4 zeigt eine Ausführungsform der Verwendung einer Expandieranweisung in einem Prozessor. Bei 401 wird eine Expandieranweisung mit einem Zieloperanden, einem Quellenoperanden (Speicher oder Register), einer Schreibmaske und einem Offset (falls vorgesehen) abgerufen. Bei bestimmten Ausführungsformen ist der Zieloperand ein 512-Bit-Vektorregister (wie etwa ZMM1) und die Schreibmaske ein 16-Bit-Register (wie etwa k1). Wenn es einen Speicherquellenoperanden gibt, kann er ein Register sein, der eine Adresse (oder einen Teil davon) oder etwas Unmittelbares, das eine Adresse oder einen Teil davon repräsentiert, sein. Typischerweise weisen Ziel- und Quellenoperanden dieselbe Größe auf. Bei bestimmten Ausführungsformen sind sie alle 512-Bit groß. Bei anderen Ausführungsformen können sie alle jedoch verschiedene Größen aufweisen, wie etwa 128 oder 256 Bit.
Bei 403 wird die Expandieranweisung decodiert. Abhängig von dem Format der Anweisung können in dieser Phase vielfältige Daten interpretiert werden, wie etwa ob eine Aufwärtsumsetzung (oder andere Datentransformation) stattfinden soll, welche Register zu beschreiben und abzurufen sind, wie die Speicheradresse aus der Quelle lautet usw.
Bei 405 werden die Quellenoperandenwerte abgerufen/gelesen. Bei den meisten Ausführungsformen werden zu diesem Zeitpunkt die mit der Speicherquellenstellenadresse und aufeinanderfolgenden (nachfolgenden) Adressen (und ihren Datenelementen) assoziierten Datenelemente gelesen (z. B. wird eine gesamte Cache-Linie gelesen). Bei Ausführungsformen, bei denen die Quelle ein Register ist, wird es zu diesem Zeitpunkt gelesen.
Wenn irgendeine Datenelementtransformation (wie etwa eine Aufwärtsumsetzung) durchzuführen ist, kann sie bei 407 durchgeführt werden. Zum Beispiel kann ein 16-Bit-Datenelement aus dem Speicher in ein 32-Bit-Datenelement aufwärts umgesetzt werden.
Die Expandieranweisung (oder eine solche Anweisung umfassende Operationen, wie etwa Mikrooperationen) wird durch Ausführungsbetriebsmittel bei 409 ausgeführt. Diese Ausführung bewirkt die Bestimmung auf der Basis der ”aktiven” Elemente (Bitpositionen) der Schreibmaske, welche Werte aus dem Quellenoperanden als spärliche Datenelemente im Ziel zu speichern sind. Ein Beispiel für eine solche Bestimmung wurde in 1 und 2 dargestellt.
Die entsprechenden Datenelemente des Quellenoperanden werden bei 411 im Zielregister an Speicherstellen gespeichert, die den ”aktiven” Elementen der Schreibmaske entsprechen. Wieder sind Beispiele hierfür in 1 und 2 gezeigt. Obwohl 409 und 411 getrennt dargestellt wurden, können sie bei bestimmten Ausführungsformen zusammen als Teil der Ausführung der Anweisung durchgeführt werden.
5 zeigt eine Ausführungsform eines Verfahrens zum Verarbeiten einer Expandieranweisung. Bei dieser Ausführungsform wird angenommen, dass bestimmte oder sogar alle Operationen 401–407 zuvor durchgeführt wurden. Sie sind jedoch nicht gezeigt, um die nachfolgend angegebenen Einzelheiten nicht zu verschleiern. Zum Beispiel sind das Abrufen und Decodieren nicht gezeigt, und auch nicht das Abrufen des Operanden (Quellen und Schreibmaske).
Bei 501 erfolgt eine Bestimmung, ob die Schreibmaske an der ersten Bitposition angibt, dass eine entsprechende Quellenspeicherstelle in einer entsprechenden Datenelementspeicherstelle des Zielregisters gespeichert werden soll. Zum Beispiel: weist die Schreibmaske an der ersten Position einen Wert, wie etwa ”1”, auf, der angibt, dass die erste Datenelementposition des Zielregisters mit einem Wert aus der Quelle überschrieben werden soll (in diesem Fall dem ersten Datenelement der aufeinanderfolgenden Datenelemente, auf die durch den Quellenoperanden zugegriffen wird)?
Wenn die Schreibmaske an der ersten Bitposition nicht angibt, dass eine Änderung im Zielregister erfolgen soll, wird die nächste Bitposition in der Schreibmaske ausgewertet, und es wird keine Änderung vorgenommen. Wenn die Schreibmaske an der ersten Bitposition angibt, dass eine Änderung in dieser ersten Datenelementposition des Ziels stattfinden soll, wird das erste Quellendatenelement (z. B. das niedrigstwertige Datenelement der Speicherstelle oder des Quellenregisters) bei 507 in der ersten Datenelementposition gespeichert. Abhängig von der Implementierung wird das Speicherdatenelement bei 505 in die Datenelementgröße des Ziels umgesetzt. Dies könnte auch vor der Auswertung von 501 stattgefunden haben. Das nachfolgende (aufeinanderfolgende) Datenelement aus der Quelle, das in das Zielregister geschrieben werden kann, wird bei 511 fertig gemacht.
Bei 513 erfolgt eine Bestimmung, ob die ausgewertete Schreibmaskenposition die letzte der Schreibmaske war oder ob alle Datenelementpositionen des Ziels gefüllt wurden. Wenn es wahr ist, ist die Operation vorüber.
Wenn es nicht wahr ist, ist die nächste Bitposition in der Schreibmaske bei 515 auszuwerten. Diese Auswertung geschieht bei 503 und ist der Bestimmung von 501 ähnlich, ist aber nicht für die erste Bitposition der Schreibmaske. Wenn die Bestimmung ein Ja ist, wird das Datenelement gespeichert usw. (507, 509 und 511), und wenn die Bestimmung ein Nein ist, wird das Datenelement bei 505 alleine gelassen.
Obwohl diese Figur und obige Beschreibung die jeweiligen ersten Positionen als die niedrigstwertigen Positionen betrachtet, sind zusätzlich bei bestimmten Ausführungsformen die ersten Positionen die höchstwertigen Positionen.
Komprimierung
Die Ausführung einer Komprimieranweisung bewirkt, dass ein Prozessor Datenelemente aus einem Quellenoperanden (typischerweise einem Registeroperanden) in aufeinanderfolgenden Elementen in einem Zieloperanden (einem Speicher- oder Registeroperanden) auf der Basis der durch den Schreibmaskenoperanden bestimmten aktiven Elemente speichert (packt). Zusätzlich können die Datenelemente des Quellenoperanden abhängig von ihrer Größe und wie groß Datenelemente sind, wenn die Quelle Speicher ist, abwärts umgesetzt werden. Wenn zum Beispiel die Datenelemente des Speicheroperanden 16 Bit groß sind und die Datenelemente des Quellenregisters 32 Bit aufweisen, werden die im Speicher zu speichernden Datenelemente des Registers auf 16 Bit abwärts umgesetzt. Beispiele für Abwärtsumsetzung und wie sie zu einem Anweisungsformat codiert werden, werden später erläutert. Die Ausführung der Komprimierung könnte auch als Erzeugung eines Byte-Wort-Doppelwort-Stroms betrachtet werden, der beginnend an einer elementausgerichteten Adresse logisch abgebildet wird. Die Länge des Stroms hängt von der Schreibmaske ab, da durch die Maske deaktivierte Elemente nicht zu dem Strom hinzugefügt werden. Komprimierung wird typischerweise zum Komprimieren von spärlichen Daten in eine Warteschlange verwendet. Außerdem kann sie, wenn keine Schreibmaske (oder eine Schreibmaske, die auf durchweg Einsen gesetzt ist) verwendet wird, für Vektorspeichervorgänge höherer Leistungsfähigkeit verwendet werden, wobei eine hohe Konfidenz besteht, dass die Speicherreferenz eine Cache-Leitungsaufteilung produziert.
Ein Format dieser Anweisung ist ”VCOMPRESSPS zmm2/mem {k1}, D (zmm1)”, wobei zmm1 und zmm2 ein Quellen- bzw. Ziel-Vektorregisteroperand (wie etwa ein 128-, 246-, 512-Bit-Register) sind, k1 ein Schreibmaskenoperand (wie etwa ein 16-Bit-Register) ist und mem eine Speicherstelle ist. Es kann auch ein Offset für einen Speicheroperanden in der Anweisung vorgesehen sein. Was auch immer im Speicher gespeichert wird, ist eine Ansammlung aufeinanderfolgender Bit beginnend von der Speicheradresse und kann eine von mehreren Größen (128-, 256-, 512-Bit usw.) aufweisen. Bei bestimmten Ausführungsformen weist die Schreibmaske auch eine andere Größe (8 Bit, 32 Bit usw.) auf. Außerdem werden bei bestimmten Ausführungsformen nicht alle Bit der Schreibmaske von der Anweisung benutzt (z. B. werden nur die unteren acht niedrigstwertigen Bit verwendet). Natürlich ist VCOMPRESSPS der Opcode der Anweisung. Typischerweise wird jeder Operand explizit in der Anweisung definiert. Die Größe der Datenelemente kann im ”Präfix” der Anweisung definiert werden, wie etwa durch Verwendung eines Datengranularitäts-Angabebit wie das hier beschriebene ”W”. Bei den meisten Ausführungsformen gibt W an, dass Datenelemente jeweils entweder 32 oder 64 Bit aufweisen. Wenn die Datenelemente 32 Bit groß sind und die Quellen 512 Bit groß sind, gibt es sechzehn (16) Datenelemente pro Quelle.
Ein Beispiel für die Ausführung einer Komprimieranweisung in einem Prozessor ist in 6 dargestellt. In diesem Beispiel wird der Zielspeicher an einer Adresse adressiert, die mit der im RAX-Register gefundenen assoziiert ist. Natürlich kann die Speicheradresse in anderen Registern gespeichert oder als etwas Unmittelbares in der Anweisung gefunden werden. Die Schreibmaske ist in diesem Beispiel 0x4DB1. Für jeden Fall, dass die Schreibmaske einen ”1”-Wert aufweist, wird ein Datenelement aus der Quelle (wie etwa einem ZMM-Register) aufeinanderfolgend in dem Speicher gespeichert (gepackt). Zum Beispiel ist die erste Position der Schreibmaske (z. B. k2[0]) ”1”, wodurch angegeben wird, dass die entsprechende Quellendatenelementposition (z. B. das erste Datenelement des Quellenregisters) in den Speicher geschrieben werden soll. In diesem Fall würde sie als das mit der RAX-Adresse assoziierte Datenelement gespeichert. Die nächsten drei Bit der Maske sind ”0”, wodurch angegeben wird, dass die entsprechenden Datenelemente des Quellenregisters nicht im Speicher gespeichert werden (wie in der Figur als ”Y” gezeigt). Der nächste ”1”-Wert in der Schreibmaske ist an der fünften Bitposition (z. B. k2[4]). Dadurch wird angegeben, dass bei der Datenelementposition, die dem mit dem RAX-Register assoziierten Datenelement nachfolgend (aufeinanderfolgend) ist, dort der fünfte Datenelementschlitz des Quellenregisters gespeichert werden soll. Die verbleibenden Schreibmasken-Bitpositionen werden verwendet, um zu bestimmen, welche zusätzlichen Datenelemente des Quellenregisters im Speicher zu speichern sind (in diesem Fall werden acht Gesamtdatenelemente gespeichert, es könnte aber abhängig von der Schreibmaske mehr oder weniger geben). Zusätzlich können die Datenelemente aus der Registerquelle abwärts umgesetzt werden, um auf die Datenelementgröße des Speichers zu passen, wie zum Beispiel Übergang von einem 32-Bit-Floating-Point-Wert zu einem 16-Bit-Wert vor der Speicherung.
7 zeigt ein weiteres Beispiel für die Ausführung der Komprimieranweisung in einem Prozessor. In diesem Beispiel ist das Ziel ein Register. Die Schreibmaske ist in diesem Beispiel wieder 0x4DB1. Für jeden Fall, dass die Schreibmaske einen ”1”-Wert aufweist, wird ein Datenelement aus der Quelle (wie etwa einem ZMM-Register) aufeinanderfolgend in dem Zielregister gespeichert (gepackt). Zum Beispiel ist die erste Position der Schreibmaske (z. B. k2[0]) ”1”, wodurch angegeben wird, dass die entsprechende Quellendatenelementposition (z. B. das erste Datenelement des Quellenregisters) in das Zielregister geschrieben werden soll. In diesem Fall würde sie als das erste Datenelement des Zielregisters gespeichert. Die nächsten drei Bit der Maske sind ”0”, wodurch angegeben wird, dass die entsprechenden Datenelemente des Quellenregisters nicht in dem Zielregister gespeichert werden (in der Figur als ”Y” gezeigt). Der nächste ”1”-Wert in der Schreibmaske befindet sich an der fünften Bitposition (z. B. k2[4]). Dadurch wird angegeben, dass bei der Datenelementposition, die dem ersten Datenelement nachfolgend (aufeinanderfolgend) ist, der fünfte Datenelementschlitz des Quellenregisters dort gespeichert werden soll. Die verbleibenden Schreibmasken-Bitpositionen werden verwendet, um zu bestimmen, welche zusätzlichen Datenelemente des Quellenregisters im Zielregister zu speichern sind (in diesem Fall werden acht Gesamtdatenelemente gespeichert, es könnte aber abhängig von der Schreibmaske mehr oder weniger geben).
8 zeigt ein Beispiel für Pseudocode zum Ausführen einer Expandieranweisung.
9 zeigt eine Ausführungsform der Verwendung einer Komprimieranweisung in einem Prozessor. Eine Komprimieranweisung mit einem Zieloperanden, einem Quellenoperanden und einer Schreibmaske wird bei 901 abgerufen. Bei bestimmten Ausführungsformen ist der Quellenoperand ein 512-Bit-Vektorregister (wie etwa ZMM1) und die Schreibmaske ein 16-Bit-Register (wie etwa k1). Das Ziel kann eine in einem Register oder als etwas Unmittelbares gespeicherte Speicherstelle oder ein Registeroperand sein. Zusätzlich kann die Komprimieranweisung ein Offset für eine Speicheradresse enthalten.
Die Komprimieranweisung wird bei 903 decodiert. Abhängig von dem Format der Anweisung können in dieser Phase vielfältige Daten interpretiert werden, wie etwa, ob eine Abwärtsumsetzung stattfinden soll, welche Register abzurufen sind und wie die Speicheradresse aus dem Zieloperanden lautet (und etwaiges Offset usw.).
Die Quellenoperandenwerte werden bei 905 abgerufen/gelesen. Zum Beispiel wird mindestens das erste Datenelement des Quellenregisters gelesen.
Wenn irgendeine Datenelementtransformation (wie etwa eine Abwärtsumsetzung) durchzuführen ist, kann sie bei 907 durchgeführt werden. Zum Beispiel kann ein 32-Bit-Datenelement aus dem Register in ein 16-Bit-Datenelement abwärts umgesetzt werden.
Die Komprimieranweisung (oder eine solche Anweisung umfassende Operationen, wie etwa Mikrooperationen) wird bei 909 durch Ausführungsbetriebsmittel ausgeführt. Diese Ausführung bewirkt die Bestimmung auf der Basis der ”aktiven” Elemente (Bitpositionen) der Schreibmaske, welche Werte aus dem Quellenoperanden als gepackte Datenelemente in dem Ziel zu laden sind. Ein Beispiel für eine solche Analyse wurde in 6 dargestellt.
Die entsprechenden Datenelemente des Quellenoperanden, die den ”aktiven” Elementen der Schreibmaske entsprechen, werden bei 911 im Ziel gespeichert. Wieder ist ein Beispiel hierfür in 6 und 7 gezeigt. Obwohl 909 und 911 getrennt dargestellt wurden, werden sie bei bestimmten Ausführungsformen als Teil der Ausführung der Anweisung durchgeführt.
10 zeigt ein Beispiel für eine Ausführungsform eines Verfahrens zum Verarbeiten einer Komprimieranweisung. Bei dieser Ausführungsform wird angenommen, dass bestimmte oder sogar alle Operationen 901–907 zuvor durchgeführt wurden. Sie sind jedoch nicht gezeigt, um die nachfolgend dargelegten Einzelheiten nicht zu verschleiern. Zum Beispiel sind das Abrufen und Decodieren nicht gezeigt, und auch nicht das Abrufen des Operanden (Quellen und Schreibmaske).
Bei 1001 eine Bestimmung, ob die Schreibmaske an der ersten Bitposition angibt, dass ein entsprechendes Quellendatenelement in einer anfänglich durch den Zieloperanden angegebenen Zielspeicherstelle (niedrigstwertigen Speicherstelle) gespeichert werden soll. Zum Beispiel: hat die Maske an der ersten Position einen Wert wie etwa ”1”, der angibt, dass die erste Datenelementposition des Quellenregisters in den Speicher geschrieben werden soll?
Wenn die Schreibmaske an der ersten Bitposition nicht angibt, dass eine Änderung im Ziel stattfinden soll (das erste Datenelement soll durch das erste Datenelement des Quellenregisters unverändert bleiben), wird die nächste Bitposition in der Schreibmaske (wenn es eine gibt) ausgewertet und es erfolgt keine Änderung. Wenn die Schreibmaske an der ersten Bitposition angibt, dass eine Änderung in dieser ersten Datenelementposition des Ziels stattfinden soll, wird das Quellendatenelement bei 1007 in der ersten Datenelementposition des Ziels gespeichert. Abhängig von der Implementierung wird das Quellendatenelement bei 1005 in die Datenelementgröße des Ziels umgesetzt. Dies könnte auch vor der Auswertung von 1001 stattgefunden haben. Die nachfolgende (aufeinanderfolgende) Zielspeicherstelle, in die geschrieben werden kann, wird bei 1009 fertig gemacht.
Bei 1011 erfolgt eine Bestimmung, ob die ausgewertete Schreibmaskenposition die letzte der Schreibmaske war oder ob alle Datenelementpositionen des Ziels gefüllt wurden. Wenn es wahr ist, ist die Operation vorüber. Wenn es nicht wahr ist, ist die nächste Bitposition in der Schreibmaske bei 1013 auszuwerten. Diese Auswertung geschieht bei 1003 und ist der Bestimmung von 1001 ähnlich, dennoch ist sie nicht die erste Bitposition der Schreibmaske. Wenn die Bestimmung ein Ja ist, wird das Datenelement gespeichert usw. (1005, 1007 und 1009).
Obwohl diese Figur und obige Beschreibung die jeweiligen ersten Positionen als die niedrigstwertigen Positionen betrachtet, sind außerdem bei bestimmten Ausführungsformen die ersten Positionen die höchstwertigen Positionen.
Ausführungsformen der Anweisung(en), die oben erläutert werden, werden realisiert und können in einem ”generischen vektorfreundlichen Anweisungsformat” realisiert werden, das nachfolgend erläutert wird. Bei anderen Ausführungsformen wird kein solches Format benutzt und es wird ein anderes Anweisungsformat verwendet. Die nachfolgende Beschreibung der Schreibmaskenregister, verschiedenen Datentransformationen (Swizzle, Broadcast usw.), Adressierung usw. gilt jedoch im Allgemeinen für die Beschreibung der obigen Ausführungsformen der Anweisung(en). Zusätzlich werden nachfolgend beispielhafte Systeme, Architekturen und Pipelines erläutert. Ausführungsformen der Anweisung(en) von oben können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind aber nicht auf diese erläuterten beschränkt.
Ein vektorfreundliches Anweisungsformat ist ein Anweisungsformat, das sich für Vektoranweisungen eignet (z. B. es gibt bestimmte Felder, die für Vektoroperationen spezifisch sind). Obwohl Ausführungsformen beschrieben werden, bei denen sowohl Vektor- als auch Skalaroperationen durch das vektorfreundliche Anweisungsformat unterstützt werden, verwenden alternative Ausführungsformen nur Vektoroperationen des vektorfreundlichen Anweisungsformats.
Beispielhaftes generisches vektorfreundliches Anweisungsformat – Fig. 11A–B
11A–B sind Blockdiagramme eines generischen vektorfreundlichen Anweisungsformats und von Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung. 11A ist ein Blockdiagramm, das ein generisches vektorfreundliches Anweisungsformat und Klasse-A-Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung darstellt; dagegen ist 11B ein Blockdiagramm, das das generische vektorfreundliche Anweisungsformat und Klasse-B-Anweisungsvorlagen gemäß Ausführungsformen der Erfindung darstellt. Genauer gesagt, ein generisches vektorfreundliches Anweisungsformat 1100, für das Klasse-A- und Klasse-B-Anweisungsvorlagen definiert sind, die beide Anweisungsvorlagen für keinen Speicherzugriff 1105 und Anweisungsvorlagen für Speicherzugriff 1120 umfassen. Der Ausdruck generisch im Kontext des vektorfreundlichen Anweisungsformats bezieht sich darauf, dass das Anweisungsformat nicht an irgendeinen spezifischen Anweisungssatz gebunden ist. Obwohl Ausführungsformen beschrieben werden, bei denen Anweisungen im vektorfreundlichen Anweisungsformat an Vektoren operieren, die entweder aus Registern (Anweisungsvorlagen für keinen Speicherzugriff 1105) oder Registern/Speicher (Anweisungsvorlagen für Speicherzugriff 1120) entnommen werden, können alternative Ausführungsformen der Erfindung nur eine dieser unterstützen. Obwohl Ausführungsformen der Erfindung beschrieben werden, bei denen Lade- und Speicheranweisungen im Vektoranweisungsformat vorliegen, weisen außerdem alternative Ausführungsformen stattdessen oder zusätzlich Anweisungen in einem anderen Anweisungsformat auf, die Vektoren in und aus Registern bewegen (z. B. aus Speicher in Register, aus Registern in Speicher, zwischen Registern). Obwohl Ausführungsformen der Erfindung beschrieben werden, die zwei Klassen von Anweisungsvorlagen unterstützen, können alternative Ausführungsformen ferner nur eine dieser oder mehr als zwei unterstützen.
Obwohl Ausführungsformen der Erfindung beschrieben werden, bei denen das vektorfreundliche Anweisungsformat 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 besteht ein 64-Byte-Vektor entweder aus 16 Doppelwort großen Elementen oder als Alternative 8 Quadwort großen Elementen); 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); können alternative Ausführungsformen mehr, weniger und/oder andere Vektoroperandengrößen (z. B. 1156-Byte-Vektoroperanden) mit größeren, kleineren oder anderen Datenelementbreiten (z. B. Datenelementbreiten von 128 Bit (16 Byte)) unterstützen.
Die Klasse-A-Anweisungsvorlagen in 11A umfassen Folgendes: 1) in den Anweisungsvorlagen für keinen Speicherzugriff 1105 sind eine Anweisungsvorlage für keinen Speicherzugriff, Vollrundungssteuertyp-Operation 1110 und eine Anweisungsvorlage für keinen Speicherzugriff, Datentransformtypoperation 1115; und 2) in den Anweisungsvorlagen für Speicherzugriff 1120 sind eine Anweisungsvorlage für Speicherzugriff, zeitlich 1125 und eine Anweisungsvorlage für Speicherzugriff (nicht zeitlich) 1130 gezeigt. Die Klasse-B-Anweisungsvorlagen in 11B umfassen Folgendes: 1) in den Anweisungsvorlagen für keinen Speicherzugriff 1105 sind eine Anweisungsvorlage für keinen Speicherzugriff, Schreibmaskensteuerung, Partialrundungssteuertypoperation 1112 und eine Anweisungsvorlage für keinen Speicherzugriff, Schreibmaskensteuerung, vsize-Typoperation 1117 gezeigt; und 2) in den Anweisungsvorlagen für Speicherzugriff 1120 ist eine Anweisungsvorlage für Speicherzugriff, Schreibmaskensteuerung 1127 gezeigt.
Format
Das generische vektorfreundliche Anweisungsformat 1100 umfasst die folgenden nachfolgend in der in 11A–B dargestellten Reihenfolge aufgelisteten Felder.
Das Formatfeld 1140 – ein spezifischer Wert (ein Anweisungsformat-Kennungswert) in diesem Feld identifiziert das vektorfreundliche Anweisungsformat eindeutig und somit Vorkommnisse von Anweisungen in dem vektorfreundlichen Anweisungsformat in Anweisungsströmen. Somit unterscheidet der Inhalt des Formatfelds 1140 Vorkommnisse von Anweisungen in dem ersten Anweisungsformat von Vorkommnissen von Anweisungen in anderen Anweisungsformaten, um dadurch die Einführung des vektorfreundlichen Anweisungsformats in einen Anweisungssatz, der andere Anweisungsformate aufweist, zu erlauben. Dementsprechend ist dieses Feld in dem Sinne optional, als es für einen Anweisungssatz, der nur das generische vektorfreundliche Anweisungsformat aufweist, nicht benötigt wird.
Das Basisoperationsfeld 1142 – sein Inhalt unterscheidet verschiedene Basisoperationen. Wie hier später beschrieben werden wird, kann das Basisoperationsfeld 1142 ein Opcode-Feld umfassen und/oder Teil dieses sein.
Das Registerindexfeld 1144 – sein Inhalt spezifiziert direkt oder durch Adressenerzeugung die Speicherstellen der Quellen- und Zieloperanden, ob sie in Registern oder Speichern liegen. Dazu gehören ausreichend viele Bit zur Auswahl von N Registern au einem PxQ-(z. B. 32x1312-)Registerfile. Obwohl bei einer Ausführungsform N bis zu drei Quellen und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quellen und Zielregister unterstützen (können z. B. bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel wirkt, können bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel wirkt, können bis zu zwei Quellen und ein Ziel unterstützen). Obwohl bei einer Ausführungsform P = 32 ist, können alternative Ausführungsformen mehr oder weniger Register (z. B. 16) unterstützen. Obwohl bei einer Ausführungsform Q = 1312 Bit ist, können alternative Ausführungsformen mehr oder weniger Bit unterstützen (z. B. 128, 1024).
Das Modifiziererfeld 1146 – sein Inhalt unterscheidet Vorkommnisse von Anweisungen in dem generischen Vektoranweisungsformat, die Speicherzugriff spezifizieren, von denen, die dies nicht tun; das heißt, zwischen Anweisungsvorlagen für keinen Speicherzugriff 1105 und Anweisungsvorlagen für Speicherzugriff 1120. Speicherzugriffsoperationen lesen und/oder beschreiben die Speicherhierarchie (wobei in bestimmten Fällen die Quellen- und/oder Zieladressen unter Verwendung von Werten in Registern spezifiziert werden), während Nicht-Speicherzugriffsoperationen dies nicht tun (z. B. Quelle und Ziele sind Register). Obwohl bei einer Ausführungsform dieses Feld auch zwischen drei verschiedenen Weisen zur Durchführung von Speicheradressenberechnungen auswählt, können alternative Ausführungsformen mehr, weniger oder andere Weisen zum Durchführen von Speicheradressenberechnungen unterstützen.
Das Ergänzungsoperationsfeld 1150 – sein Inhalt unterscheidet, welche einer Vielfalt von verschiedenen Operationen zusätzlich zu der Basisoperation durchzuführen ist. Dieses Feld ist kontextspezifisch. Bei einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 1168, ein Alphafeld 1152 und ein Betafeld 1154 aufgeteilt. Das Ergänzungsoperationsfeld erlaubt die Durchführung üblicher Gruppen von Operationen in einer einzigen Anweisung statt 2, 3 oder 4 Anweisungen. Es folgen einige Beispiele für Anweisungen (deren Nomenklatur später ausführlicher erläutert werden wird), die das Ergänzungsfeld 1150 verwenden, um die Anzahl erforderlicher Anweisungen zu verringern.
Dabei ist [rax] der für Adressenerzeugung zu verwendende Basiszeiger und {} gibt eine Umsetzungsoperation an, die durch das (hier später ausführlicher erläuterte) Datenmanipulationsfeld spezifiziert wird.
Das Skalenfeld 1160 – sein Inhalt erlaubt die Skalierung des Inhalts des Indexfelds für Speicheradressenerzeugung (z. B. für Adressenerzeugung, die 2^Skala*Index + Basis verwendet).
Das Verschiebungsfeld 1162A – sein Inhalt wird als Teil der Speicheradressenerzeugung verwendet (z. B. zur Adressenerzeugung, die 2^Skala*Index + Basis + Verschiebung verwendet).
Das Verschiebungsfaktorfeld 1162B (man beachte, dass Überlagerung des Verschiebungsfelds 1162A direkt über dem Verschiebungsfaktorfeld 1162B angibt, dass das eine oder andere verwendet wird) – sein Inhalt wird als Teil der Adressenerzeugung verwendet; es spezifiziert einen Verschiebungsfaktor, der durch die Größe eines Speicherzugriffs (N) zu skalieren ist – wobei N die Anzahl der Byte beim Speicherzugriff ist (z. B. zur Adressenerzeugung, die 2^Skala*Index + Basis + skalierte Verschiebung verwendet). Redundante Bit niedriger Ordnung werden ignoriert, und daher wird der Inhalt des Verschiebungsfaktorfelds mit der Speicheroperanden-Gesamtgröße (N) multipliziert, um die beim Berechnen einer effektiven Adresse zu verwendende Endverschiebung zu erzeugen. Der Wert von N wird durch die Prozessorhardware zur Laufzeit auf der Basis des vollen Opcode-Felds 1174 (hier später beschrieben) und des hier später beschriebenen Datenmanipulationsfelds 1154C bestimmt. Das Verschiebungsfeld 1162A und das Verschiebungsfaktorfeld 1162B sind in dem Sinne optional, als sie für die Anweisungsvorlagen für keinen Speicherzugriff 1105 nicht verwendet werden und/oder andere Ausführungsformen nur eines oder keines der beiden implementieren können.
Das Datenelementbreitenfeld 1164 – sein Inhalt unterscheidet, welche einer Anzahl von Datenelementbreiten zu verwenden ist (bei bestimmten Ausführungsformen für alle Anweisungen; bei anderen Ausführungsformen nur für bestimmte der Anweisungen). Dieses Feld ist in dem Sinne optional, als es nicht benötigt wird, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung eines gewissen Aspekts der Opcodes unterstützt werden.
Das Schreibmaskenfeld 1170 – sein Inhalt steuert datenelementpositionsweise, ob diese Datenelementposition in dem Zielvektoroperanden das Ergebnis der Basisoperation und Ergänzungsoperation widerspiegelt. Klasse-A-Anweisungsvorlagen unterstützen Zusammenführungs-Schreibmaskierung, während Klasse-B-Anweisungsvorlagen sowohl Zusammenführungs- als auch Nullungs-Schreibmaskierung unterstützen. Beim Zusammenführen erlauben Vektormasken einen Schutz einer beliebigen Menge von Elementen im Ziel vor Aktualisierungen während der Ausführung irgendeiner Operation (spezifiziert durch die Basisoperation und die Ergänzungsoperation); bei einer anderen Ausführungsform Bewahrung des alten Werts jedes Elements des Ziels, wenn das entsprechende Maskenbit eine 0 aufweist. Bei der Nullung erlauben dagegen Vektormasken eine Nullung einer beliebigen Menge von Elementen im Ziel während der Ausführung irgendeiner Operation (spezifiziert durch die Basisoperation und die Ergänzungsoperation); und bei einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Eine Teilmenge dieser Funktionalität ist die Möglichkeit, die Vektorlänge der durchgeführten Operation (das heißt, die Spanne von modifizierten Elementen vom ersten zum letzten) zu steuern; es ist jedoch nicht notwendig, dass die Elemente, die modifiziert werden, aufeinanderfolgend sind. Das Schreibmaskenfeld 1170 erlaubt somit teilweise Vektoroperationen, darunter Ladevorgänge, Speichervorgänge, Arithmetik, Logik usw. Außerdem kann diese Maskierung zur Fehlerunterdrückung verwendet werden (d. h. durch Maskieren der Datenelementpositionen des Ziels, um Empfang des Ergebnisses irgendeiner Operation zu verhindern, die einen Fehler bewirken kann/wird – z. B. nehme man an, dass ein Vektor im Speicher eine Seitengrenze überschreitet und dass die erste Seite, aber nicht die zweite Seite einen Seitenfehler verursachen würde, und der Seitenfehler kann ignoriert werden, wenn alle Datenelemente des Vektors, die auf der ersten Seite liegen, durch die Schreibmaske maskiert werden). Ferner erlauben Schreibmasken ”Vektorisierungsschleifen”, die bestimmte Arten von Bedingungsaussagen enthalten. Obwohl Ausführungsformen der Erfindung beschrieben werden, bei denen der Inhalt des Schreibmaskenfelds 1170 eines einer Anzahl von Schreibmaskenregister auswählt, das die zu verwendende Schreibmaske enthält (und somit der Inhalt des Schreibmaskenfelds 1170 indirekt identifiziert, dass Maskierung durchzuführen ist), erlauben alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Maskenschreibfelds 1170 direkt die durchzuführende Maskierung spezifiziert. Ferner erlaubt Nullung Leistungsfähigkeitsverbesserungen wenn 1) Registerumbenennung an Anweisungen verwendet wird, deren Zieloperand nicht auch eine Quelle ist (auch nicht-ternäre Anweisungen genannt), weil während der Registerumbenennungs-Pipelinephase das Ziel nicht mehr eine implizite Quelle ist (keine Datenelemente aus dem aktuellen Zielregister müssen in das umbenannte Zielregister kopiert werden oder irgendwie zusammen mit der Operation geführt werden, weil irgendein Datenelement, das nicht das Ergebnis der Operation ist (ein beliebiges maskiertes Datenelement) genullt wird); und 2) während der Rückschreibphase, weil Nullen geschrieben werden.
Das Unmittelbares-Feld 1172 – sein Inhalt erlaubt die Spezifikation von etwas Unmittelbarem. Dieses Feld ist in dem Sinne optional, als es bei einer Implementierung des generischen vektorfreundlichen Formats, die nichts Unmittelbares unterstützt, nicht anwesend ist und in Anweisungen, die nichts Unmittelbares verwenden, nicht anwesend ist.
Anweisungsvorlagen-Klassenauswahl
Das Klassenfeld 1168 – sein Inhalt unterscheidet zwischen verschiedenen Klassen von Anweisungen. Mit Bezug auf 2A–B wählt der Inhalt dieses Felds zwischen Anweisungen der Klasse A und Klasse B. In 11A–B werden Rechtecke mit gerundeten Ecken verwendet, um anzugeben, dass ein spezifischer Wert in einem Feld anwesend ist (z. B. Klasse A 1168A und Klasse B 1168B jeweils für das Klassenfeld 1168 in 11A–B).
Anweisungsvorlagen für keinen Speicherzugriff der Klasse A
Im Fall der Anweisungsvorlagen für keinen Speicherzugriff 1105 der Klasse A wird das Alphafeld 1152 als ein RS-Feld 1152A interpretiert, dessen Inhalt unterscheidet, welche der verschiedenen Ergänzungsoperationsarten durchzuführen ist (z. B. Rundung 1152A.1 und Datentransformation 1152A.2 werden jeweils für die Anweisungsvorlagen für keinen Speicherzugriff, Rundungstypoperation 1110 bzw. keinen Speicherzugriff, Datentransformationstypoperation 1115 spezifiziert), während das Betafeld 1154 unterscheidet, welche der Operationen der spezifizierten Art durchzuführen ist. In 11 werden Blöcke mit gerundeten Ecken verwendet, um anzugeben, dass ein spezifischer Wert anwesend ist (z. B. kein Speicherzugriff 1146A in dem Modifiziererfeld 1146; Rundung 1152A.1 und Datentransformation 1152A.2 für das Alphafeld 1152/rs-Feld 1152A). In den Anweisungsvorlagen für keinen Speicherzugriff 1105 sind das Skalenfeld 1160, das Verschiebungsfeld 1162A und das Verschiebungsskalenfeld 1162B nicht anwesend.
Anweisungsvorlagen für keinen Speicherzugriff – Vollrundungssteuertypoperation
Bei der Anweisungsvorlage für keinen Speicherzugriff, Vollrundungssteuertypoperation 1110 wird das Betafeld 1154 als ein Rundungssteuerfeld 1154A interpretiert, dessen Inhalt(e) statische Rundung bereitstellen. Obwohl bei den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerfeld 1154A ein Feld 1156 zur Unterdrückung aller Floating-Point-Programmfehler (SAE) und ein Rundungsoperationssteuerfeld 1158 umfasst, können alternative Ausführungsformen beide diese Konzepte im selben Feld unterstützen bzw. codieren oder nur eines oder das andere dieser Konzepte/Felder aufweisen (können z. B. nur das Rundungsoperationssteuerfeld 1158 aufweisen).
Das SAE-Feld 1156 – sein Inhalt unterscheidet, ob die Programmfehlerereignismeldung zu deaktivieren ist oder nicht; wenn Inhalt des SAE-Felds 1156 angibt, dass Unterdrückung freigegeben ist, meldet eine gegebene Anweisung keinerlei Art von Floating-Point-Programmfehlerflag und ruft keinen Floating-Point-Programmfehler-Handler hervor.
Das Rundungsoperationssteuerfeld 1158 – sein Inhalt unterscheidet, welche einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Runden in Richtung von null und Runden zum Nächsten). Das Rundungsoperationssteuerfeld 1158 erlaubt somit eine anweisungsweise Änderung des Rundungsmodus und ist daher besonders nützlich, wenn dies erforderlich ist. Bei einer Ausführungsform der Erfindung, bei der ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi umfasst, übersteuert Inhalt des Rundungsoperationssteuerfelds 1150 diesen Registerwert (in der Lage zu sein, den Rundungsmodus zu wählen, ohne ein Abspeichern-Modifizieren-Wiederherstellen an einem solchen Steuerregister ausführen zu müssen, ist vorteilhaft).
Anweisungsvorlagen für keinen Speicherzugriff – Datentransformationstypoperation
Bei der Anweisungsvorlage für keinen Speicherzugriff, Datentransformationstypoperation 1115 wird das Betafeld 1154 als ein Datentransformationsfeld 1154B interpretiert, dessen Inhalt unterscheidet, welche einer Anzahl von Datentransformationen durchzuführen ist (z. B. keine Datentransformation, Swizzle, Broadcast).
Anweisungsvorlagen für Speicherzugriff der Klasse A
Im Fall einer Anweisungsvorlage für Speicherzugriff 1120 der Klasse A wird das Alphafeld 1152 als ein Räumungshinweisfeld 1152B interpretiert, dessen Inhalt unterscheidet, welcher der Räumungshinweise zu verwenden ist (in 11A werden zeitlich 1152B.1 bzw. nicht zeitlich 1152B.2 für die Anweisungsvorlage für Speicherzugriff, zeitlich 1125 und die Anweisungsvorlage für Speicherzugriff, nicht zeitlich 1130 spezifiziert), während das Betafeld 1154 als ein Datenmanipulationsfeld 1154C interpretiert wird, dessen Inhalt unterscheidet, welche einer Anzahl von Datenmanipulationsoperationen (die auch als Primitive bekannt sind) durchzuführen ist (z. B. keine Manipulation; Broadcast; Aufwärtsumsetzung einer Quelle; und Abwärtsumsetzung eines Ziels). Die Anweisungsvorlagen für Speicherzugriff 1120 umfassen das Skalenfeld 1160 und gegebenenfalls das Verschiebungsfeld 1162A oder das Verschiebungsskalierungsfeld 1162B.
Vektorspeicheranweisungen führen Vektorladevorgänge aus und Vektorspeichervorgänge in Speicher mit Umsetzungsunterstützung durch. Wie bei regulären Vektoranweisungen transferieren Vektorspeicheranweisungen Daten von/zu Speicher in einem datenelementweisen Verfahren, wobei die Elemente, die tatsächlich transferiert werden, durch den Inhalt der Vektormaske vorgeschrieben werden, die als die Schreibmaske ausgewählt ist. In 11A werden Rechtecke mit gerundeten Ecken verwendet, um anzugeben, dass ein spezifischer Wert in einem Feld anwesend ist (z. B. Speicherzugriff 1146B für das Modifiziererfeld 1146; zeitlich 1152B.1 und nicht zeitlich 1152B.2 für das Alphafeld 1152/Räumungshinweisfeld 1152B).
Anweisungsvorlagen für Speicherzugriff – Zeitlich
Zeitliche Daten sind Daten, die wahrscheinlich bald genug wiederverwendet werden, um aus Cache-Speicherung Nutzen zu ziehen. Dies ist jedoch ein Hinweis und verschiedene Prozessoren können ihn auf verschiedene Weisen implementieren, darunter völliges Ignorieren des Hinweises.
Anweisungsvorlagen für Speicherzugriff – Nicht Zeitlich
Nicht zeitliche Daten sind Daten, die unwahrscheinlich bald genug wiederverwendet werden, um aus Cache-Speicherung im 1. Level-Cache Nutzen zu ziehen, und sollten Priorität für Räumung erhalten. Dies ist jedoch ein Hinweis und verschiedene Prozessoren können ihn auf verschiedene Weisen implementieren, darunter völliges Ignorieren des Hinweises.
Anweisungsvorlagen der Klasse B
Im Fall der Anweisungsvorlagen der Klasse B wird das Alphafeld 1152 als Feld 1152C zur Schreibmaskensteuerung (Z) interpretiert, dessen Inhalt unterscheidet, ob die durch das Schreibmaskenfeld 1170 gesteuerte Schreibmaskierung eine Zusammenführung oder eine Nullung sein soll.
Anweisungsvorlagen für keinen Speicherzugriff der Klasse B
Im Fall der Anweisungsvorlagen für keinen Speicherzugriff 1105 der Klasse B wird ein Teil des Betafelds 1154 als ein RL-Feld 1157A interpretiert, dessen Inhalt unterscheidet, welche der verschiedenen Ergänzungsoperationsarten durchzuführen ist (z. B. Rundung 1157A.1 und Vektorlänge (VSIZE) 1157A.2 werden jeweils für die Anweisungsvorlage für keinen Speicherzugriff, Schreibmaskensteuerung, Teilrundungssteuertypoperation 1112 bzw. die Anweisungsvorlage für keinen Speicherzugriff, Schreibmaskensteuerung, VSIZE-Typ-Operation 1117 spezifiziert), während der Rest des Betafelds 1154 unterscheidet, welche der Operationen der spezifizierten Art durchzuführen ist. In 11 werden Blöcke mit gerundeten Ecken verwendet, um anzugeben, dass ein spezifischer Wert anwesend ist (z. B. kein Speicherzugriff 1146A im Modifiziererfeld 1146; Rundung 1157A.1 und VSIZE 1157A.2 für das RL-Feld 1157A). In den Anweisungsvorlagen für keinen Speicherzugriff 1105 sind das Skalenfeld 1160, das Verschiebungsfeld 1162A und das Verschiebungsskalierungsfeld 1162B nicht anwesend.
Anweisungsvorlagen für keinen Speicherzugriff – Schreibmaskensteuerung, Partialrundungssteuerungstypoperation
Bei der Anweisungsvorlage für keinen Speicherzugriff, Schreibmaskensteuerung, Partialrundungssteuertypoperation 1110 wird der Rest des Betafelds 1154 als ein Rundungsoperationsfeld 1159A interpretiert und Programmfehlerereignismeldung wird deaktiviert (eine gegebene Anweisung meldet keinerlei Art von Floating-Point-Programmfehler-Flag und ruft keinen Floating-Point-Programmfehler-Handler hervor).
Das Rundungsoperationssteuerfeld 1159A – genau wie beim Rundungsoperationssteuerfeld 1158 unterscheidet sein Inhalt, welche einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Runden in Richtung von null und Runden auf das Nächste). Somit erlaubt das Rundungsoperationssteuerfeld 1159A die anweisungsweise Änderung des Rundungsmodus und ist somit besonders nützlich, wenn dies erforderlich ist. Bei einer Ausführungsform der Erfindung, bei der der Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi umfasst, übersteuert der Inhalt des Rundungsoperationssteuerfelds 1150 diesen Registerwert (in der Lage zu sein, den Rundungsmodus zu wählen, ohne ein Abspeicher-Modifizieren-Wiederherstellen an einem solchen Steuerregister durchführen zu müssen, ist vorteilhaft).
Anweisungsvorlagen für keinen Speicherzugriff – Schreibmaskensteuerung, VSIZE-Typ-Operation
Bei der Anweisungsvorlage für keinen Speicherzugriff, Schreibmaskensteuerung, VSIZE-Typ-Operation 1117 wird der Rest des Betafelds 1154 als ein Vektorlängenfeld 1159B interpretiert, dessen Inhalt unterscheidet, an welcher von mehreren Datenvektorlängen durchzuführen ist (z. B. 128, 1156 oder 1312 Byte).
Anweisungsvorlagen für Speicherzugriff der Klasse B
Im Fall einer Anweisungsvorlage für Speicherzugriff 1120 der Klasse A wird ein Teil des Betafelds 1154 als ein Broadcast-Feld 1157B interpretiert, dessen Inhalt unterscheidet, ob die Broadcast-Typ-Datenmanipulationsoperation durchzuführen ist oder nicht, während der Rest des Betafelds 1154 als Vektorlängenfeld 1159B interpretiert wird. Die Anweisungsvorlagen für Speicherzugriff 1120 umfassen das Skalenfeld 1160 und gegebenenfalls das Verschiebungsfeld 1162A oder das Verschiebungsskalenfeld 1162B.
Zusätzliche Bemerkungen bezüglich Feldern
Mit Bezug auf das generische vektorfreundliche Anweisungsformat 1100 ist ein Voll-Opcode-Feld 1174 gezeigt, dass das Formatfeld 1140, das Basisoperationsfeld 1142 und das Datenelementbreitenfeld 1164 umfasst. Obwohl eine Ausführungsform gezeigt ist, bei der das Voll-Opcode-Feld 1174 alle diese Felder umfasst, umfasst das Voll-Opcode-Feld 1174 bei Ausführungsformen, die nicht alle diese unterstützen, weniger als alle diese Felder. Das Voll-Opcode-Feld 1174 stellt den Operationscode bereit.
Das Ergänzungsoperationsfeld 1150, das Datenelementbreitenfeld 1164 und das Schreibmaskenfeld 1170 erlauben eine anweisungsweise Spezifikation dieser Merkmale in dem generischen vektorfreundlichen Anweisungsformat.
Die Kombination aus Schreibmaskenfeld und Datenelementbreitenfeld erzeugt insofern typisierte Anweisungen, als sie eine Anwendung der Maske auf der Basis verschiedener Datenelementbreiten erlaubt.
Das Anweisungsformat erfordert eine relativ kleine Anzahl von Bit, da es verschiedene Felder für verschiedene Zwecke auf der Basis der Inhalte anderer Felder wiederverwendet. Zum Beispiel besteht eine Perspektive darin, dass der Inhalt des Modifiziererfelds zwischen den Anweisungsvorlagen für keinen Speicherzugriff 1105 in 11A–B und den Anweisungsvorlagen für Speicherzugriff 11250 in 11A–B wählt; während der Inhalt des Klassenfelds 1168 innerhalb dieser Anweisungsvorlagen für keinen Speicherzugriff 1105 zwischen den Vorlagen 1110/1115 von 11A und 1112/1117 von 11B wählt; und während der Inhalt des Klassenfelds 1168 innerhalb dieser Anweisungsvorlagen für Speicherzugriff 1120 zwischen den Anweisungsvorlagen 1125/1130 von 11A und 1127 von 11B wählt. Von einer anderen Perspektive aus gesehen wählt der Inhalt des Klassenfelds 1168 zwischen Anweisungsvorlagen der Klasse A bzw. Klasse B von 11A und B; während der Inhalt des Modifiziererfelds innerhalb dieser Anweisungsvorlagen der Klasse A zwischen den Anweisungsvorlagen 1105 und 1120 von 11A wählt; und während der Inhalt des Modifiziererfelds innerhalb dieser Anweisungsvorlagen der Klasse B zwischen den Anweisungsvorlagen 1105 und 1120 von 11B wählt. Falls der Inhalt des Klassenfelds eine Anweisungsvorlage der Klasse A angibt, wählt der Inhalt des Modifiziererfelds 1146 die Interpretation des Alphafelds 1152 (zwischen dem rs-Feld 1152A und dem EH-Feld 1152B). Auf verwandte Weise wählen die Inhalte des Modifiziererfelds 1146 und des Klassenfelds 1168, ob das Alphafeld als das rs-Feld 1152A, das EH-Feld 1152B oder das Schreibmaskensteuer(Z)-Feld 1152C interpretiert wird. Falls das Klassen- und Modifiziererfeld eine Operation für keinen Speicherzugriff der Klasse A angeben, ändert sich die Interpretation des Betafelds des Ergänzungsfelds auf der Basis des Inhalts des rs-Felds; während, falls das Klassen- und Modifiziererfeld eine Operation für keinen Speicherzugriff der Klasse B angeben, die Interpretation des Betafelds von dem Inhalt des RL-Felds abhängt. Falls das Klassen- und Modifiziererfeld eine Operation für Speicherzugriff der Klasse A angeben, ändert sich die Interpretation des Betafelds des Ergänzungsfelds auf der Basis des Inhalts des Basisoperationsfelds; während sich, falls das Klassen- und Modifiziererfeld eine Operation für Speicherzugriff der Klasse B angeben, die Interpretation des Broadcast-Felds 1157B des Betafelds des Ergänzungsfelds auf der Basis des Inhalts des Basisoperationsfelds ändert. Die Kombination aus dem Basisoperationsfeld, Modifiziererfeld und Ergänzungsoperationsfeld erlaubt somit die Spezifikation einer sogar noch größeren Vielfalt von Ergänzungsoperationen.
Die in Klasse A und Klasse B zu findenden verschiedenen Anweisungsvorlagen sind in verschiedenen Situationen nützlich. Klasse A ist nützlich, wenn aus Leistungsfähigkeitsgründen Nullungs-Schreibmaskierung oder kleinere Vektorlängen erwünscht sind. Zum Beispiel erlaubt Nullung die Vermeidung von falschen Abhängigkeiten, wenn Umbenennung verwendet wird, da man nicht mehr künstlich mit dem Ziel zusammenführen muss; als ein anderes Beispiel vermindert Vektorlängensteuerung Speicherungs-Lade-Weiterleitungsprobleme beim Emulieren von kürzeren Vektorgrößen mit der Vektormaske. Klasse B ist nützlich, wenn Folgendes erwünscht ist: 1) Erlauben von Floating-Point-Programmfehlern (d. h. wenn der Inhalt des SAE-Felds Nein angibt), während zur selben Zeit Rundungsmodussteuerelemente verwendet werden; 2) in der Lage zu sein, Aufwärtsumsetzung, Swizzling, Überwechsel und/oder Abwärtsumsetzung zu verwenden; 3) Operieren an dem Grafikdatentyp. Zum Beispiel verringern Aufwärtsumsetzung, Swizzling, Überwechsel, Abwärtsumsetzung und der Grafikdatentyp die Anzahl der erforderlichen Anweisungen beim Arbeiten mit Quellen in einem verschiedenen Format; als ein anderes Beispiel gewährleistet die Möglichkeit, Programmfehler zu erlauben, volle IEEE-Einhaltung mit gerichteten Rundungsmodi.
Ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat
12A–C zeigen ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat gemäß Ausführungsformen der Erfindung. 12A–C zeigen ein spezifisches vektorfreundliches Anweisungsformat 1200, das in dem Sinne spezifisch ist, dass es Ort, Größe, Interpretation und Reihenfolge der Felder sowie Werte für bestimmte dieser Felder spezifiziert. Das spezifische vektorfreundliche Anweisungsformat 1200 kann verwendet werden, um den x86-Anweisungssatz zu erweitern, und somit sind bestimmte der Felder denen ähnlich, die im existierenden x86-Anweisungssatz und seinen Erweiterungen (z. B. AVX) verwendet werden, oder stimmen mit diesen überein. Dieses Format bleibt mit dem Präfix-Codierungsfeld, dem Real-Opcode-Bytefeld, dem MOD-R/M-Feld, dem SIB-Feld, Verschiebungsfeld und Unmittelbar-Feldern des existierenden x86-Anweisungssatzes mit Erweiterungen vereinbar. Es sind die Felder aus 11 dargestellt, auf die die Felder aus 12A–C abgebildet werden.
Es versteht sich, dass, obwohl Ausführungsformen der Erfindung mit Bezug auf das spezifische vektorfreundliche Anweisungsformat 1200 zur Veranschaulichung im Kontext des generischen vektorfreundlichen Anweisungsformat 1100 beschrieben werden, die Erfindung nicht auf das spezifische vektorfreundliche Anweisungsformat 1200 beschränkt ist, außer wenn dies beansprucht wird. Zum Beispiel zieht das generische vektorfreundliche Anweisungsformat 1100 vielfältige mögliche Größen für die verschiedenen Felder in Betracht, während das spezifische vektorfreundliche Anweisungsformat 1200 mit Feldern spezifischer Größen gezeigt ist. Als spezifisches Beispiel ist, obwohl das Datenelementbreitenfeld 1164 in dem spezifischen vektorfreundlichen Anweisungsformat 1200 als ein Ein-Bit-Feld dargestellt ist, die Erfindung nicht darauf beschränkt (das heißt, das generische vektorfreundliche Anweisungsformat 1100 zieht andere Größen des Datenelementbreitenfelds 1164 in Betracht).
Das Format Fig. 12A–C
Das generische vektorfreundliche Anweisungsformat 1100 umfasst die folgenden Felder, die nachfolgend in der in 12A–C dargestellten Reihenfolge aufgelistet sind.
EVEX Präfix (Byte 0-3)
EVEX Präfix 1202 – wird in einer Vier-Byte-Form codiert.
Formatfeld 1140 (EVEX-Byte 0, Bit [7:0] – das erste Byte (EVEX-Byte 0) ist das Formatfeld 1140 und es enthält 0x62 (den einzigartigen Wert, der bei einer Ausführungsform der Erfindung zur Unterscheidung des vektorfreundlichen Anweisungsformats verwendet wird).
Die zweiten vierten Byte (EVEX-Byte 1-3) umfassen eine Anzahl von Bitfeldern, die spezifische Fähigkeit bereitstellen.
Das REX-Feld 1205 (EVEX-Byte 1, Bit [7-5] – besteht aus einem EVEX.R-Bitfeld (EVEX-Byte 1, Bit [7] – R), EVEX.X-Bitfeld (EVEX-Byte 1, Bit [6] – X) und 1157BEX-Byte 1, Bit[5] – B). Die Bitfelder EVEX.R, EVEX.X und EVEX.B stellen dieselbe Funktionalität wie die entsprechenden VEX-Bitfelder bereit und werden unter Verwendung der 1er-Komplementform codiert, d. h. ZMM0 wird als 1111B codiert, ZMM15 wird als 0000B codiert. Andere Felder der Anweisungen codieren die unteren drei Bit der Registerindizes, wie in der Technik bekannt (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Addieren von EVEX.R, EVEX.X und EVEX.B gebildet werden können.
REX'-Feld 1210 – Dies ist der erste Teil des REX'-Felds 1210 und ist das EVEX.R'-Bitfeld (EVEX Byte 1, Bit [4] – R'), das zum Codieren entweder der oberen 16 oder unteren 16 des erweiterten 32-Register-Satzes verwendet wird. Bei einer Ausführungsform der Erfindung wird dieses Bit zusammen mit anderen wie nachfolgend angegeben im Bit-invertierten Format gespeichert, zur Unterscheidung (im wohlbekannten x86-32-Bit-Modus) von der BOUND-Anweisung, deren Real-Opcode-Byte 62 ist, aber in dem MOD-R/M-Feld (später beschrieben) den Wert von 11 im MOD-Feld nicht akzeptiert; alternative Ausführungsformen der Erfindung speichern dieses und die anderen angegebenen Bit nachfolgend im invertierten Format nicht. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Anders ausgedrückt, wird R'Rrrr durch Kombinieren von EVEX.R', EVEX.R und dem anderen RRR aus anderen Feldern gebildet.
Opcode-Abbildungsfeld 1215 (EVEX-Byte 1, Bit [3:0] – mmmm) – sein Inhalt codiert ein impliziertes vorderes Opcode-Byte (0F, 0F, 38 oder 0F 3).
Datenelementbreitenfeld 1164 (EVEX-Byte 2, Bit [7] – W) – wird durch die Notation EVEX.W repräsentiert. EVEX.W dient zum Definieren der Granularität (Größe) des Datentyps (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente).
EVEX.vvvv 1220 (EVEX-Byte 2, Bit [6:3]-vvvv) – die Rolle von EVEX.vvvv kann Folgendes umfassen: 1) EVEX.vvvv codiert den ersten Quellenregisteroperanden, spezifiziert in invertierter (1er-Komplement-)Form und ist für Anweisungen mit 2 oder mehr Quellenoperanden gültig; 2) EVEX.vvvv codiert den Zielregisteroperanden, spezifiziert in 1er-Komplementform für bestimmte Vektorverschiebungen; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Somit codiert das EVEX.vvvv-Feld 1220 die 4-Bit niedriger Ordnung des ersten Quellenregisterspezifizierers, gespeichert in invertierter (1er-Komplement-)Form. Abhängig von der Anweisung wird ein zusätzliches verschiedenes EVEX-Bitfeld verwendet, um die Spezifizierergröße auf 32 Register zu erweitern.
EVEX.U-1168-Klassenfeld (EVEX-Byte 2, Bit [2]-U) – Im Fall EVEX.0 = 0, gibt es Klasse A oder EVEX.U0 an; im Fall EVEX.0 = 1 gibt es Klasse B oder EVEX.U1 an.
Präfixcodierungsfeld 1225 (EVEX-Byte 2, Bits [1:0]-pp) – stellt zusätzliche Bit für das Basisoperationsfeld bereit. Zusätzlich zu der Bereitstellung von Unterstützung für die veralteten SSE-Anweisungen im EVEX-Präfixformat hat dies auch den Vorteil, das SIMD-Präfix zu kompaktieren (statt ein Byte zu erfordern, um das SIMD-Präfix auszudrücken, erfordert das EVEX-Präfix nur 2 Bit). Bei einer Ausführungsform werden zur Unterstützung von veralteten SSE-Anweisungen, die ein SIMD-Präfix (66H, F2H, F3H) sowohl im veralteten Format als auch im EVEX-Präfixformat verwenden, diese veralteten SIMD-Präfixe in das SIMD-Präfixcodierungsfeld codiert; und werden zur Laufzeit in das veraltete SIMD-Präfix expandiert, bevor sie dem PLA des Decodierers zugeführt werden (so dass der PLA sowohl das veraltete als auch das EVEX-Format dieser veralteten Anweisungen ohne Modifikation ausführen kann). Obwohl neuere Anweisungen den Inhalt des EVEX-Präfixcodierungsfelds direkt als eine Opcode-Erweiterung verwenden könnten, expandieren bestimmte Ausführungsformen auf ähnliche Weise aus Gründen der Einheitlichkeit, erlauben aber die Spezifikation verschiedener Bedeutungen durch diese veralteten SIMD-Präfixe. Eine alternative Ausführungsform kann den PLA umentwerfen, um die 2-Bit-SIMD-Präfixcodierungen zu unterstützen, und erfordern somit die Expansion nicht.
Alphafeld 1152 (EVEX-Byte 3, Bit [7] – EH; auch als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.Schreibmaskensteuerung und EVEX.N bekannt; auch mit a dargestellt) – wie zuvor beschrieben, ist dieses Feld kontextspezifisch. Eine zusätzliche Beschreibung wird hier später gegeben.
Betafeld 1154 (EVEX-Byte 3, Bit [6:4]-SSS, auch als EVEX.s_2-0, EVEX.r_2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB bekannt; auch mit βββ dargestellt) – wie zuvor beschrieben, ist dieses Feld kontextspezifisch. Eine zusätzliche Beschreibung wird hier später gegeben.
REX'-Feld 1210 – dies ist der Rest des REX'-Felds und ist das EVEX.V'-Bitfeld (EVEX-Byte 3, Bit [3] – V'), das zur Codierung entweder der oberen 16 oder unteren 16 des erweiterten 32-Registersatzes verwendet werden kann. Dieses Bit wird im bitinvertierten Format gespeichert. Ein Wert von 1 wird zur Codierung der unteren 16 Register verwendet. Anders ausgedrückt wird V'VVVV durch Kombinieren von EVEX.V', EVEX.vvvv gebildet.
Schreibmaskenfeld 1170 (EVEX-Byte 3, Bit [2:0]-kkk) – sein Inhalt spezifiziert den Index eines Registers in den Schreibmaskenregistern wie zuvor beschrieben. Bei einer Ausführungsform der Erfindung weist der spezifische Wert EVEX.kkk=000 ein spezielles Verhalten auf, woraus folgt, dass keine Schreibmaske für die bestimmte Anweisung verwendet wird (dies kann auf vielfältige Weisen implementiert werden, darunter Verwendung einer auf durchweg Einsen festverdrahteten Schreibmaske oder von Hardware, die die Maskierungshardware umgeht).
Real Opcode-Feld 1230 (Byte 4)
Dies ist auch als das Opcode-Byte bekannt. Ein Teil des Opcodes wird in diesem Feld spezifiziert.
MOD-R/M-Feld 1240 (Byte 5)
Modifiziererfeld 1146 (MODR/M.MOD, Bit [7-6) – MOD-Feld 1242) – Wie zuvor beschrieben, unterscheidet der Inhalt des MOD-Felds 1242 zwischen Operationen für Speicherzugriff und für keinen Speicherzugriff. Dieses Feld wird hier später beschrieben.
MODR/M.reg-Feld 1244, Bit [5-3] – die Rolle des ModR/M.reg-Felds kann auf 2 Situationen zusammengefasst werden: ModR/M.reg codiert entweder den Zielregisteroperanden oder einen Quellenregisteroperanden oder ModR/M.reg wird als Opcode-Erweiterung behandelt und nicht zur Codierung irgendeines Anweisungsoperanden verwendet.
MODR/M.r/m-Feld 1246, Bit [2-0] – die Rolle des ModR/M.r/m-Felds kann Folgendes umfassen: ModR/M.r/m codiert den Anweisungsoperanden, der eine Speicheradresse referenziert, oder ModR/M.r/m codiert entweder den Zielregisteroperanden oder einen Quellenregisteroperanden.
Das Byte für Skala, Index, Basis (SIB) (Byte 6).
Das Skalenfeld 1160 (SIB.SS, Bit [7-6] – wie zuvor beschrieben, wird der Inhalt des Skalenfelds 1160 zur Speicheradressenerzeugung verwendet. Dieses Feld wird hier später beschrieben.
SIB.xxx 1254 (Bit [5-3] und SIB.bbb 1256 (Bit [2-0]) – die Inhalte dieser Felder wurden zuvor mit Bezug auf die Registerindizes Xxxx und Bbbb erwähnt.
Verschiebungs-Byte(s) (Byte 7 oder Bytes 7-10)
Verschiebungsfeld 1162A (Byte 7-10 – wenn das MOD-Feld 1242 10 enthält, sind die Byte 7-10 das Verschiebungsfeld 1162A, und es funktioniert genauso wie die veraltete 32-Bit-Verschiebung (disp32) und arbeitet auf Bytegranularität.
Verschiebungsfaktorfeld 1162B (Byte 7) – wenn das MOD-Feld 1242 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 1162B. Die Speicherstelle dieses Felds ist dieselbe wie die der veralteten x86-Anweisungssatz-8-Bit-Verschiebung (disp8), die auf Bytegranularität arbeitet. Da disp8 vorzeichenerweitert ist, kann es nur Offsets zwischen –1228 und 127 Byte adressieren; im Hinblick auf 64-Byte-Cachelinien verwendet disp8 8 Bit, die auf nur vier wirklich nützliche Werte gesetzt werden können: –128, –64, 0 und 64; da oft ein größerer Bereich benötigt wird, wird disp32 verwendet; disp32 erfordert jedoch vier Byte. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 1162B eine Uminterpretierung von dips8; bei Verwendung des Verschiebungsfaktorfelds 1162B wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfelds, multipliziert mit der Größe des Speicheroperandenzugriffs (N), bestimmt. Diese Art von Verschiebung wird als disp8*N bezeichnet. Dies verringert die mittlere Anweisungslänge (es wird ein einziges Byte für die Verschiebung verwendet, aber mit viel größerem Umfang). Eine solche komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung ein Vielfaches der Granularität des Speicherzugriffs ist und daher die redundanten Bit niedriger Ordnung des Adressenoffsets nicht codiert werden müssen. Anders ausgedrückt, ersetzt das Verschiebungsfaktorfeld 1162B die veraltete x86-Anweisungssatz-8-Bit-Verschiebung. Somit wird das Verschiebungsfaktorfeld 1162B auf dieselbe Weise wie eine x86-Anweisungssatz-8-Bit-Verschiebung codiert (also keine Änderungen an den ModRM/SIB-Codierungsregeln), mit der einzigen Ausnahme, dass disp8 auf disp8*N überladen wird. Anders ausgedrückt, gibt es keine Änderungen an den Codierungsregeln oder Codierungslängen, sondern nur an der Interpretation des Verschiebungswerts durch Hardware (die die Verschiebung mit der Größe des Speicheroperanden skalieren muss, um ein byteweises Adressenoffset zu erhalten).
Unmittelbar
Das Unmittelbar-Feld 1172 operiert wie zuvor beschrieben.
Eine beispielhafte Registerarchitektur – Fig. 13

13 ist ein Blockdiagramm einer Registerarchitektur 1300 gemäß einer Ausführungsform der Erfindung. Die Registerfiles und Register der Registerarchitektur sind nachfolgend aufgelistet:
Vektorregisterfile 1310 – bei der dargestellten Ausführungsform gibt es 32 Vektorregister, die 1312 Bit breit sind; diese Register werden als zmm0 bis zmm31 bezeichnet. Die 1156 Bit niedrigerer Ordnung der unteren 16 zmm-Register werden den Registern ymm0-16 überlagert. Die 128 Bit niedrigerer Ordnung der unteren 16 zmm-Register (die 128 Bit niedrigerer Ordnung der ymm-Register) werden den Registern xmm0-15 überlagert. Das spezifische vektorfreundliche Anweisungsformat 1200 operiert an diesem überlagerten Registerfile wie in den nachfolgenden Tabellen dargestellt.

Einstellbare Vektorlänge	Klasse	Operationen	Register
Anweisungsvorlagen, die das Vektorlängenfeld 1159B nicht enthalten	A(Fig. 11A; U=0)	1110, 1115, 1125, 1130	zmm-Register (die Vektorlänge ist 64 Byte)
	B (Fig. 11B; U=1)	1112	zmm-Register (die Vektorlänge ist 64 Byte)
Anweisungsvorlagen, die das Vektorlängenfeld 1159B nicht enthalten	B (Fig. 11B; U=1)	1117, 1127	zmm-, ymm- oder xmm-Register (die Vektorlänge ist 64 Byte, 32 Byte oder 16 Byte), abhängig von dem Vektorlängenfeld 1159B

Anders ausgedrückt, wählt das Vektorlängenfeld 1159B zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen aus, wobei jede solche kürzere Länge die Hälfte der Länge der vorausgehenden Länge aufweist; und Anweisungsvorlagen ohne das Vektorlängenfeld 1159B operieren an der maximalen Vektorlänge. Ferner operieren bei einer Ausführungsform die Klasse-B-Anweisungsvorlagen des spezifischen vektorfreundlichen Anweisungsformats 1200 an gepackten oder skalaren Einzel-/Doppelpräzisions-Floating-Point-Daten und gepackten oder skalaren Integer-Daten. Skalare Operationen sind Operationen, die an der Datenelementposition niedrigster Ordnung in einem zmm-/ymm-/xmm-Register ausgeführt werden; die Datenelementpositionen höherer Ordnung werden abhängig von der Ausführungsform entweder so gelassen, wie sie vor der Anweisung waren, oder genullt.
Schreibmaskenregister 1315 – bei der dargestellten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), die jeweils 64 Bit groß sind. Wie zuvor beschrieben, kann bei einer Ausführungsform der Erfindung das Vektormaskenregister k0 nicht als Schreibmaske verwendet werden; wenn die Codierung, die normalerweise k0 angeben würde, für eine Schreibmaske verwendet wird, wählt sie eine festverdrahtete Schreibmaske von 0xFFFF, wodurch Schreibmaskierung für diese Anweisung effektiv deaktiviert wird.
Multimediaerweiterungs-Steuerstatusregister (MXCSR) 1320 – bei der dargestellten Ausführungsform stellt dieses 32-Bit-Register Status- und Steuerbit bereit, die bei Floating-Point-Operationen verwendet werden.
Vielzweckregister 1325 – bei der dargestellten Ausführungsform gibt es sechzehn 64-Bit-Vielzweckregister, die zusammen mit den existierenden x86-Adressierungsmodi 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.
Register 1330 erweiterter Flags (EFLAGS) – bei der dargestellten Ausführungsform wird dieses 32-Bit-Register zum Aufzeichnen der Ergebnisse vieler Anweisungen verwendet.
Register 1335 des Floating-Point-Steuerworts (FCW) und Register 1340 des Floating-Point-Statusworts (FSW) – bei der dargestellten Ausführungsform werden diese Register von x87-Anweisungssatzerweiterungen verwendet, um im Fall von FCW Rundungsmodi, Programmfehlermasken und Flags zu setzen und im Fall von FSW Programmfehler mitzuverfolgen.
Skalar-Floating-Point-Stapelregisterfile (x87-Stapel) 1345, worauf das MMX-Packed-Integer-Flachregisterfile 1350 anders benannt wird – bei der dargestellten Ausführungsform ist der x87-Stapel ein Acht-Element-Stapel, der zum Durchführen von skalaren Floating-Point-Operationen an 32-/64-/80-Bit-Floating-Point-Daten unter Verwendung der x87-Anweisungssatzerweiterung verwendet wird; während die MMX-Register zum Ausführen von Operationen an 64-Bit-Packed-Integer-Daten sowie zum Halten von Operanden für bestimmte zwischen den MMX- und XMM-Registern ausgeführten Operationen verwendet werden.
Segmentregister 1355 – bei der dargestellten Ausführungsform gibt es sechs 16-Bit-Register zur Verwendung zum Speichern von zur segmentierten Adressenerzeugung verwendeten Daten.
RIP-Register 1365 – bei der dargestellten Ausführungsform dieses 64-Bit-Register, das den Anweisungszeiger speichert.
Alternative Ausführungsformen der Erfindung können breitere oder schmälere Register verwenden. Zusätzlich können alternative Ausführungsformen der Erfindung mehr, weniger oder andere Registerfiles und Register verwenden.
Eine beispielhafte In-Reihenfolge-Prozessorarchitektur – Fig. 14A–Fig. 14B
14A–B zeigen ein Blockdiagramm einer beispielhaften In-Reihenfolge-Prozessorarchitektur. Diese beispielhaften Ausführungsformen sind um mehrfache Instanziierungen eines In-Reihenfolge-CPU-Kerns, der mit einem Breitvektorprozessor (VPU) ergänzt ist, herum entworfen. Kerne kommunizieren durch ein Verbindungsnetzwerk hoher Bandbreite abhängig von der e16t-Anwendung mit bestimmter Festfunktionslogik, Speicher-E-/A-Schnittstellen und anderer notwendiger E/A-Logik. Zum Beispiel würde eine Implementierung dieser Ausführungsform als selbstständige GPU typischerweise einen PCIe-Bus umfassen.
14A ist ein Blockdiagramm eines Einzel-CPU-Kerns zusammen mit seiner Verbindung mit dem Verbindungsnetzwerk 1402 auf dem Chip und mit seiner lokalen Teilmenge des Level-2-(L2-)Cache 1404 gemäß Ausführungsformen der Erfindung. Ein Anweisungsdecoder 1400 unterstützt den x86-Anweisungssatz mit einer Erweiterung, die das spezifische Vektoranweisungsformat 1200 umfasst. Obwohl bei einer Ausführungsform der Erfindung (zur Vereinfachung des Entwurfs) eine Skalareinheit 1408 und eine Vektoreinheit 1410 getrennte Registersätze verwenden (z. B. Skalarregister 1412 bzw. Vektorregister 1414) und zwischen ihnen transferierte Daten in Speicher geschrieben und dann aus einem Level-1-(L1-)Cache 1406 wieder ausgelesen werden, können alternative Ausführungsformen der Erfindung einen anderen Ansatz verwenden (z. B. Verwendung eines einzigen Registersatzes oder Vorsehen eines Kommunikationspfads, der den Transfer von Daten zwischen den zwei Registerfiles erlaubt, ohne dass sie geschrieben und wieder ausgelesen werden).
Der L1-Cache 1406 erlaubt latenzarme Zugriffe auf Cache-Speicher in die Skalar- und Vektoreinheiten. Zusammen mit Lade-OP-Anweisungen im vektorfreundlichen Anweisungsformat bedeutet dies, dass der L1-Cache 1406 im gewissen Sinne wie ein erweitertes Registerfile behandelt werden kann. Dies verbessert die Leistungsfähigkeit vieler Algorithmen, insbesondere mit dem Räumungshinweisfeld 1152B, signifikant.
Die lokale Teilmenge des L2-Cache 1404 ist Teil eines globalen L2-Cache, der in getrennte lokale Teilmengen (eine pro CPU-Kern) aufgeteilt ist. Jede CPU besitzt einen direkten Zugriffspfad auf ihre eigene lokale Teilmenge des L2-Cache 1404. Durch einen CPU-Kern gelesene Daten werden in seiner L2-Cache-Teilmenge 1404 gespeichert, und es kann schnell auf sie zugegriffen werden, parallel mit anderen CPUs, die auf ihre eigenen lokalen L2-Cache-Teilmengen zugreifen. Durch einen CPU-Kern geschriebene Daten werden in seiner L2-Cache-Teilmenge 1404 gespeichert und notwendigenfalls aus anderen Teilmengen ausgeräumt. Das Ringnetzwerk stellt Kohärenz für gemeinsam genutzte Daten sicher.
14B ist eine Explosionsansicht eines Teils des CPU-Kerns in 14A gemäß Ausführungsformen der Erfindung. 14B umfasst einen L1-Daten-Cache 1406A (Teil des L1-Cache 1404), sowie weitere Einzelheiten bezüglich der Vektoreinheit 1410 und der Vektorregister 1414. Genauer gesagt ist die Vektoreinheit 1410 eine 16-breite Vektorverarbeitungseinheit (VPU) (siehe die 16-breite ALU 1428), die Integer-, Einzelgenauigkeits-Float- und Doppelgenauigkeits-Float-Anweisungen ausführt. Die VPU unterstützt Swizzling der Registereingaben mit der Swizzle-Einheit 1420, Numerikumsetzungen mit Numerikumsetzungseinheiten 1422A–B und Replikation mit der Replikationseinheit 1424 am Speichereingang. Schreibmaskenregister 1426 erlauben Behauptung der resultierenden Vektorschreibvorgänge.
Registerdaten können auf vielfältige Weisen geswizzelt werden, z. B. um Matrixmultiplikation zu unterstützen. Daten aus Speicher können über die VPU-Bahnen hinweg repliziert werden. Dies ist eine übliche Operation sowohl bei der Grafik- als auch Nicht-Grafik-Paralleldatenverarbeitung, die die Cache-Effizienz signifikant vergrößert.
Das Ringnetzwerk ist bidirektional, um es Agenten wie CPU-Kernen, L2-Caches und anderen Logikblöcken zu erlauben, innerhalb des Chips miteinander zu kommunizieren. Jeder Ringdatenpfad ist pro Richtung 1312 Bit breit.
Eine beispielhafte Außerreihenfolge-Architektur – Fig. 15
15 ist ein Blockdiagramm einer beispielhaften Außerreihenfolge-Architektur gemäß Ausführungsformen der Erfindung. Genauer gesagt zeigt 15 eine wohlbekannte beispielhafte Außerreihenfolge-Architektur, die modifiziert wurde, um das vektorfreundliche Anweisungsformat und seine Ausführung einzubinden. In 15 bezeichnen Pfeile eine Kopplung zwischen zwei oder mehr Einheiten, und die Richtung des Pfeils gibt eine Richtung des Datenflusses zwischen diesen Einheiten an. 15 umfasst eine Frontend-Einheit 1505, die mit einer Ausführungs-Engine-Einheit 1510 und einer Speichereinheit 1515 gekoppelt ist; die Ausführungs-Engine-Einheit 1510 ist ferner mit der Speichereinheit 1515 gekoppelt.
Die Frontend-Einheit 1505 umfasst eine Leve1-1-(L1-)Verzweigungsvorhersageeinheit 1520, die mit einer Level-2-(L2-)Verzweigungsvorhersageeinheit 1522 gekoppelt ist. Die L1- und L2-Verzweigungsvorhersageeinheit 1520 und 1522 sind mit einer L1-Anweisungs-Cache-Einheit 1524 gekoppelt. Die L1-Anweisungs-Cache-Einheit 1524 ist mit einem Anweisungs-Übersetzungs-Lookaside-Puffer (TLB) 1526 gekoppelt, der ferner mit einer Anweisungsabruf- und -Vordecodiereinheit 1528 gekoppelt ist. Die Anweisungsabruf- und -vordecodiereinheit 1528 ist mit einer Anweisungswarteschlangeneinheit 1530 gekoppelt, die ferner mit einer Decodiereinheit 1532 gekoppelt ist. Die Decodiereinheit 1532 umfasst eine komplexe Decodiereinheit 1534 und drei simple Decodiereinheiten 1536, 1538 und 1540. Die Decodiereinheit 1532 umfasst eine Mikrocode-ROM-Einheit 1542. Die Decodiereinheit 1532 kann wie zuvor beschrieben im Decodierstufenteil operieren. Die L1-Anweisungs-Cache-Einheit 1524 ist ferner mit einer L2-Cache-Einheit 1548 in der Speichereinheit 1515 gekoppelt. Die Anweisungs-TLB-Einheit 1526 ist ferner mit einer Zweiter-Level-TLB-Einheit 1546 in der Speichereinheit 1515 gekoppelt. Die Decodiereinheit 1532, die Mikrocode-ROM-Einheit 1542 und eine Schleifenstromdetektoreinheit 1544 sind jeweils mit einer Umbenennungs-/Vergabeeinheit 1556 in der Ausführungs-Engine-Einheit 1510 gekoppelt.
Die Ausführungs-Engine-Einheit 1510 umfasst die Umbenennungs-/Vergabeeinheit 1556, die mit einer Zurückzieheinheit 1574 und einer vereinigten Scheduler-Einheit 1558 gekoppelt ist. Die Zurückzieheinheit 1574 ist ferner mit Ausführungseinheiten 1560 gekoppelt und umfasst eine Umordnungspuffereinheit 1578. Die vereinigte Scheduler-Einheit 1558 ist ferner mit einer physischen Registerfile-Einheit 1576 gekoppelt, die mit den Ausführungseinheiten 1560 gekoppelt ist. Die physische Registerfile-Einheit 1576 umfasst eine Vektorregistereinheit 1577A, eine Schreibmaskenregistereinheit 1577B und eine Skalarregistereinheit 1577C; diese Registereinheiten können die Vektorregister 1310, die Vektormaskenregister 1315 und die Vielzweckregister 1325 bereitstellen; und die physische Registerfile-Einheit 1576 kann zusätzliche, nicht gezeigte Registerfiles umfassen (z. B. das Skalar-Floating-Point-Stapelregisterfile 1345, das auf das MMX-Packed-Integer-Flachregisterfile 1350 umbezogen wird). Die Ausführungseinheiten 1560 umfassen drei gemischte Skalar- und Vektoreinheiten 1562, 1564 und 1572; eine Ladeeinheit 1566; eine Speicheradresseneinheit 1568; eine Speicherdateneinheit 1570. Die Ladeeinheit 1566, die Speicheradresseneinheit 1568 und die Speicherdateneinheit 1570 sind jeweils ferner mit einer Daten-TLB-Einheit 1552 in der Speichereinheit 1515 gekoppelt.
Die Speichereinheit 1515 umfasst die Zweiter-Level-TLB-Einheit 1546, die mit der Daten-TLB-Einheit 1552 gekoppelt ist. Die Daten-TLB-Einheit 1552 ist mit einer L1-Daten-Cache-Einheit 1554 gekoppelt. Die L1-Daten-Cache-Einheit 1554 ist ferner mit einer L2-Cache-Einheit 1548 gekoppelt. Bei bestimmten Ausführungsformen ist die L2-Cache-Einheit 1548 ferner mit L3- und höheren Cache-Einheiten 1550 in und/oder außerhalb der Speichereinheit 1515 gekoppelt.
Beispielsweise kann die beispielhafte Außerreihenfolge-Architektur eine Prozesspipeline folgendermaßen implementieren: 1) die Anweisungsabruf- und -Vordecodiereinheit 1528 führt die Abruf- und Längendecodierungsphasen aus; 2) die Decodiereinheit 1532 führt die Decodierphase aus; 3) die Umbenennungs-/Vergabeeinheit 1556 führt die Vergabephase und Umbenennungsphase aus; 4) der vereinigte Scheduler 1558 führt die Scheduling-Phase aus; 5) die physische Registerfile-Einheit 1576, die Umordnungspuffereinheit 1578 und die Speichereinheit 1515 führen die Registerlese-/Speicherlesephase aus; die Ausführungseinheiten 1560 führen die Ausführungs-/Datentransformationsphase aus; 6) die Speichereinheit 1515 und die Umordnungspuffereinheit 1578 führen die Rückschreib-/Speicherschreibphase aus; 7) die Zurückzieheinheit 1574 führt die ROB-Lesephase aus; 8) verschiedene Einheiten können an der Programmfehler-Handling-Phase beteiligt sein; und 9) die Zurückzieheinheit 1574 und die physische Registerfile-Einheit 1576 führen die Commit-Phase aus.
Beispielhafte Einzelkern- und Mehrkernprozessoren – Fig. 20
20 ist ein Blockdiagramm eines Einzelkern-Prozessors und eines Mehrkern-Prozessors 2000 mit integriertem Speichercontroller und Grafik gemäß Ausführungsformen der Erfindung. Die durchgezogen gezeichneten Kästen in 119 zeigen einen Prozessor 2000 mit einem einzigen Kern 2002A, einen Systemagenten 2010, eine Menge aus einer oder mehreren Buscontrollereinheiten 2016, während der optionale Zusatz der gestrichelt gezeichneten Kästen einen alternativen Prozessor 2000 mit mehreren Kernen 2002A-N, eine Menge aus einer oder mehreren integrierten Speichercontrollereinheit(en) 2014 in der Systemagent-Einheit 2010 und eine integrierte Grafiklogik 2008 darstellt.
Die Speicherhierarchie umfasst einen oder mehrere Levels von Cache in den Kernen, eine Menge einer oder mehrerer gemeinsam benutzter Cache-Einheiten 2006 und externen Speicher (nicht gezeigt), der mit der Menge von integrierten Speichercontrollereinheiten 2014 gekoppelt ist. Die Menge von gemeinsam benutzten Cache-Einheiten 2006 kann einen oder mehrere Mittel-Level-Caches umfassen, wie etwa Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Levels von Cache, einen Letzter-Level-Cache (LLC) und/oder Kombinationen davon. Obwohl bei einer Ausführungsform eine Verbindungseinheit 2012 auf Ringbasis die integrierte Grafiklogik 2008, die Menge von gemeinsam benutzten Cache-Einheiten 2006 und die Systemagent-Einheit 2010 verbindet, können alternative Ausführungsformen eine beliebige Anzahl wohlbekannter Techniken zur Verbindung solcher Einheiten verwenden.
Bei bestimmen Ausführungsformen sind ein oder mehrere der Kerne 2002A-N zu Mehrfach-Threading fähig. Der Systemagent 2010 umfasst die Komponenten, die die Kerne 2002A-N koordinieren und betreiben. Die Systemagent-Einheit 2010 kann zum Beispiel eine Stromversorgungssteuereinheit (PCU) und eine Displayeinheit umfassen. Die PCU kann zum Regeln des Stromversorgungszustands der Kerne 2002A-N und der integrierten Grafiklogik 2008 benötigte Logik und Komponenten sein oder umfassen. Die Anzeigeeinheit dient zum Ansteuern eines oder mehrerer extern verbundener Displays.
Die Kerne 2002A–N können im Hinblick auf Architektur und/oder Anweisungssatz homogen oder heterogen sein. Zum Beispiel können bestimmte der Kerne 2002A–N vom Typ In-Reihenfolge sein (z. B. wie die in 14A und in 14B gezeigten), während andere vom Typ Außerreihenfolge sind (z. B. wie die in 15 gezeigten). Als weiteres Beispiel können zwei oder mehr der Kerne 2002A-N in der Lage sein, denselben Anweisungssatz auszuführen, während andere in der Lage sein können, nur eine Teilmenge dieses Anweisungssatzes oder einen anderen Anweisungssatz auszuführen. Mindestens einer der Kerne ist in der Lage, das hier beschriebene vektorfreundliche Anweisungsformat auszuführen.
Der Prozessor kann ein Vielzweckprozessor sein, wie etwa ein Prozessor des Typs Core^TM i3, i5, i7, 2 Duo und Quad, Xeon^TM oder Itanium^TM, erhältlich von Intel Corporation in Santa Clara, Kalifornien. Als Alternative können die Prozessoren von einer anderen Firma sein. Der Prozessor kann ein Spezialprozessor sein, wie zum Beispiel ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungs-Engine, ein Grafikprozessor, ein Coprozessor, eingebetteter Prozessor oder dergleichen. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 2000 kann Teil eines oder mehrerer Substrate, die eine beliebige Anzahl von Prozesstechnologien verwenden, wie z. B. BiCMOS, CMOS oder NMOS sein und/oder darauf implementiert sein.
Beispielhafte Computersysteme und Prozessoren Fig. 16–Fig. 19
16–18 sind beispielhafte Systeme, die dafür geeignet sind, den Prozessor 2000 zu umfassen, während 19 ein beispielhaftes System-auf-Chip (SoC) ist, das einen oder mehrere der Kerne 2002 umfassen kann. Es sind auch andere Systementwürfe und -konfigurationen geeignet, die in der Technik für Laptops, Desktops, in der Hand gehaltene PCs, Personal Digital Assistants, technische Workstations, Server, Netzwerkeinrichtungen, Netzwerk-Hubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSP), Grafikeinrichtungen, Videospieleinrichtungen, Set-Topboxes, Mikrocontroller, Mobiltelefone, tragbare Medien-Player, in der Hand gehaltene Einrichtungen und verschiedene andere elektronische Einrichtungen bekannt sind. Im Allgemeinen ist eine enorme Vielfalt von Systemen oder elektronischen Einrichtungen mit der Fähigkeit, einen Prozessor und/oder andere Ausführungslogik wie hier offenbart zu umfassen, allgemein geeignet.
Nunmehr mit Bezug auf 16 ist ein Blockdiagramm eines Systems 1600 gemäß einer Ausführungsform der Erfindung gezeigt. Das System 1600 kann einen oder mehrere Prozessoren 1610, 1615 umfassen, die mit einem Grafikspeichercontroller-Hub (GMCH) 1620 gekoppelt sind. Die optionale Beschaffenheit zusätzlicher Prozessoren 1615 ist in 16 mit gestrichelten Linien angedeutet.
Jeder Prozessor 1610, 1615 kann eine gewisse Version des Prozessors 2000 sein. Es ist jedoch zu beachten, dass es unwahrscheinlich ist, dass integrierte Grafiklogik- und integrierte Speichersteuereinheiten in den Prozessoren 1610, 1615 existieren würden.
16 zeigt, dass der GMCH 1620 mit einem Speicher 1640 gekoppelt sein kann, der zum Beispiel dynamischer Direktzugriffsspeicher (DRAM) sein kann. Der DRAM kann bei mindestens einer Ausführungsform mit einem nichtflüchtigen Cache assoziiert sein.
Der GMCH 1620 kann ein Chipsatz oder ein Teil eines Chipsatzes sein. Der GMCH 1620 kann mit dem Prozessor bzw. den Prozessoren 1610, 1615 kommunizieren und Interaktion zwischen dem Prozessor bzw. den Prozessoren 1610, 1615 und Speicher 1640 steuern. Der GMCH 1620 kann auch als beschleunigte Busschnittstelle zwischen dem Prozessor bzw. den Prozessoren 1610, 1615 und anderen Elementen des Systems 1600 wirken. Bei mindestens einer Ausführungsform kommuniziert der GMCH 1620 über einen Mehrfachabkopplungsbus, wie etwa einen Frontside-Bus (FSB) 1695 mit dem Prozessor bzw. den Prozessoren 1610, 1615.
Ferner ist der GMCH 1620 mit einem Display 1645 (wie etwa einem Flachdisplay) gekoppelt. Der GMCH 1620 kann einen integrierten Grafikbeschleuniger umfassen. Der GMCH 1620 ist ferner mit einem Eingabe-/Ausgabe-(E/A-)Controller-Hub (ICH) 1650 gekoppelt, der zum Koppeln verschiedener Peripheriegeräte mit dem System 1600 verwendet werden kann. Zum Beispiel ist in der Ausführungsform von 16 eine externe Grafikeinrichtung 1660 gezeigt, die zusammen mit einem anderen Peripheriegerät 1670 eine mit dem ICH 1650 gekoppelte diskrete Grafikeinrichtung sein kann.
Als Alternative können auch zusätzliche oder andere Prozessoren in dem System 1600 anwesend sein. Ein zusätzlicher Prozessor bzw. zusätzliche Prozessoren 1615 wären zum Beispiel (ein) zusätzlicher Prozessor(en), die mit dem Prozessor 1610 übereinstimmen, ein zusätzlicher Prozessor bzw. zusätzliche Prozessoren, die zu dem Prozessor 1610 heterogen oder asymmetrisch sind, Beschleuniger (wie z. B. Grafikbeschleuniger oder Einheiten zur digitalen Signalverarbeitung (DSP)), am Einsatzort programmierbare Gatearrays oder ein beliebiger anderer Prozessor. Es kann vielfältige Unterschiede zwischen den physischen Betriebsmitteln 1610, 1615 im Hinblick auf ein Spektrum von Nutzmetriken geben, darunter konstruktionsbedingte, mikrokonstruktionsbedingte, thermische, Stromverbrauchseigenschaften und dergleichen. Diese Unterschiede können sich effektiv als Asymmetrie oder Heterogenität gegenüber den Verarbeitungselementen 1610, 1615 manifestieren. Bei mindestens einer Ausführungsform können die verschiedenen Verarbeitungselemente 1610, 1615 in derselben Chipkapselung residieren.
Nunmehr mit Bezug auf 17 ist ein Blockdiagramm eines zweiten Systems 1700 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 17 gezeigt, ist das Mehrprozessorsystem 1700 ein Punkt-zu-Punkt-Verbindungssystem und umfasst einen ersten Prozessor 1770 und einen zweiten Prozessor 1780, die über eine Punkt-zu-Punkt-Verbindung 1750 gekoppelt sind. Wie in 17 gezeigt, kann jeder der Prozessoren 1770 und 1780 eine bestimmte Version des Prozessors 2000 sein.
Als Alternative kann es sich bei einem oder mehreren der Prozessoren 1770, 1780 um ein anderes Element als einen Prozessor handeln, wie etwa einen Beschleuniger oder ein am Einsatzort programmierbares Gatearray.
Obwohl sie nur mit zwei Prozessoren 1770, 1780 gezeigt ist, versteht sich, dass der Schutzumfang der vorliegenden Erfindung nicht darauf beschränkt ist. Bei anderen Ausführungsformen können in einem gegebenen Prozessor ein oder mehrere zusätzliche Verarbeitungselemente anwesend sein.
Der Prozessor 1770 kann ferner einen integrierten Speichercontroller-Hub (IMC) 1772 und Punkt-zu-Punkt-(P-P-)Schnittstellen 1776 und 1778 umfassen. Ähnlich kann der zweite Prozessor 1780 einen IMC 1782 und P-P-Schnittstellen 1786 und 1788 umfassen. Die Prozessoren 1770, 1780 können über eine Punkt-zu-Punkt-(PtP-)Schnittstelle 1750 unter Verwendung von PtP-Schnittstellenschaltungen 1778, 1788 Daten austauschen. Wie in 17 gezeigt, koppeln die IMC 1772 und 1782 die Prozessoren mit jeweiligen Speichern, nämlich einem Speicher 1742 und einem Speicher 1744, bei denen es sich um lokal an die jeweiligen Prozessoren angeschlossene Teile des Hauptspeichers handeln kann.
Die Prozessoren 1770, 1780 können jeweils über einzelne P-P-Schnittstellen 1752, 1754 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1776, 1794, 1786, 1798 Daten mit einem Chipsatz 1790 austauschen. Der Chipsatz 1790 kann Daten auch über eine Hochleistungs-Grafikschnittstelle 1739 mit einer Hochleistungs-Grafikschaltung 1738 austauschen.
Ein (nicht gezeigter) gemeinsam benutzter Cache kann in jedem Prozessor außerhalb beider Prozessoren, aber über P-P-Verbindungselemente mit den Prozessoren verbunden dergestalt vorgesehen sein, dass die lokalen Cache-Informationen eines oder beider Prozessoren in dem gemeinsam benutzten Cache gespeichert werden können, wenn ein Prozessor in einen Low-Power-Modus versetzt wird.
Der Chipsatz 1790 kann über eine Schnittstelle 1796 mit einem ersten Bus 1716 gekoppelt sein. Bei einer Ausführungsform kann der erste Bus 1716 ein PCI-Bus (Peripheral Component Interconnect) sein oder ein Bus wie etwa ein PCI-Express-Bus oder ein anderer E/A-Verbindungsbus dritter Generation, obwohl der Schutzumfang der vorliegenden Erfindung nicht darauf beschränkt ist.
Wie in 17 gezeigt, können zusammen mit einer Busbrücke 1718, die den ersten Bus 1716 mit einem zweiten Bus 1720 koppelt, verschiedene E/A-Einrichtungen 1714 mit dem ersten Bus 1716 gekoppelt sein. Bei einer Ausführungsform kann der zweite Bus 1720 ein Bus mit niedrigem Pinzählwert (LPC) sein. Es können verschiedene Einrichtungen mit dem zweiten Bus 1720 gekoppelt sein, darunter zum Beispiel bei einer Ausführungsform eine Tastatur/Maus 1722, Kommunikationseinrichtungen 1726 und eine Datenspeichereinheit 1728, wie etwa ein Plattenlaufwerk oder eine andere Massenspeichereinrichtung, die Code 1730 umfassen kann. Ferner kann ein Audio-E/A 1724 mit dem zweiten Bus 1720 gekoppelt sein. Man beachte, dass andere Architekturen möglich sind. Zum Beispiel kann ein System anstelle der Punkt-zu-Punkt-Architektur von 17 einen Mehrfach-Auskopplungsbus oder eine andere solche Architektur implementieren.
Nunmehr mit Bezug auf 18 ist ein Blockdiagramm eines dritten Systems 1800 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente in 17 und 18 tragen gleiche Bezugszahlen, und bestimmte Aspekte von 17 wurden aus 18 weggelassen, um eine Verschleierung anderer Aspekte von 18 zu vermeiden.
18 zeigt, dass die Verarbeitungselemente 1770, 1780 integrierte Speicher- und E/A-Steuerlogik (”CL”) 1772 bzw. 1782 umfassen können. Bei mindestens einer Ausführungsform kann die CL 1772, 1782 Speichercontroller-Hub-Logik (IMC) wie etwa die oben in Verbindung mit 119 und 17 beschriebene umfassen. Zusätzlich kann die CL 1772, 1782 auch E/A-Steuerlogik umfassen. 18 zeigt, dass nicht nur die Speicher 1742, 1744 mit der CL 1772, 1782 gekoppelt sind, sondern auch E/A-Einrichtungen 1814 mit der Steuerlogik 1772, 1782 gekoppelt sind. Veraltete E/A-Einrichtungen 1815 sind mit dem Chipsatz 1790 gekoppelt.
Nunmehr mit Bezug auf 19 ist ein Blockdiagramm eines SoC 1900 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 119 tragen gleiche Bezugszahlen. Außerdem sind gestrichelt gezeichnete Kästen optionale Merkmale auf fortschrittlicheren SoC. In 19 ist eine Verbindungseinheit(en) 1902 mit Folgendem gekoppelt: einem Anwendungsprozessor 1910, der eine Menge von einem oder mehreren Kernen 2002A-N und gemeinsam benutzte Cache-Einheit(en) 2006 umfasst; einer Systemagent-Einheit 2010; einer Buscontrollereinheit(en) 2016; einer integrierten Speichercontrollereinheit(en) 2014; einer Menge von einem oder mehreren Medienprozessoren 1920, die integrierte Grafiklogik 2008, einen Bildprozessor 1924 zur Bereitstellung von Standbild- und/oder Videokamerafunktionalität, einen Audioprozessor 1926 zum Bereitstellen von Hardware-Audiobeschleunigung und einen Videoprozessor 1928 zur Bereitstellung von Videocodierungs-/-decodierungsbeschleunigung umfassen kann; einer Einheit von statischem Direktzugriffsspeicher (SRAM) 1930; einer Direktspeicherzugriffs-(DMA-)Einheit 1932; und einer Anzeigeeinheit 1940 zur Kopplung mi einem oder mehreren externen Displays.
Ausführungsformen der hier offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination solcher Implementierungsansätze implementiert werden. Ausführungsformen der Erfindung können implementiert werden als Computerprogramme oder Programmcode, der auf programmierbaren Systemen ausgeführt wird, die mindestens einen Prozessor, ein Speichersystem (einschließlich flüchtiger und nichtflüchtiger Speicher- und/oder Speicherungselemente), mindestens eine Eingabeeinrichtung und mindestens eine Ausgabeeinrichtung umfassen.
Programmcode kann auf Eingangsdaten angewandt werden, um die hier beschriebenen Funktionen auszuführen und Ausgangsinformationen zu erzeugen. Die Ausgangsinformationen können auf bekannte Weise an eine oder mehrere Ausgabeeinrichtungen angelegt werden. Für die Zwecke der vorliegenden Anmeldung umfasst ein Verarbeitungssystem ein beliebiges System, das einen Prozessor aufweist, wie zum Beispiel einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor.
Der Programmcode kann in einer prozeduralen oder objektorientierten Programmiersprache hoher Ebene implementiert werden, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann auch gegebenenfalls in Assembler- oder Maschinensprache implementiert werden. Tatsächlich sind die hier beschriebenen Mechanismen bezüglich Schutzumfang nicht auf irgendeine konkrete Programmiersprache beschränkt. 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 auf einem maschinenlesbaren Medium gespeicherte Anweisungen implementiert werden, wodurch verschiedene Logik in dem Prozessor repräsentiert wird, die, wenn sie durch eine Maschine gelesen wird, bewirkt, dass die Maschine Logik zum Ausführen der hier beschriebenen Techniken fabriziert. Solche Repräsentationen, die als ”IP-Kerne” bekannt sind, können auf einem greifbaren maschinenlesbaren Medium gespeichert und verschiedenen Kunden oder Herstellungsanlagen geliefert werden, um in die Herstellungsmaschinen geladen zu werden, die die Logik oder den Prozessor tatsächlich herstellen.
Solche maschinenlesbaren Speichermedien wären ohne Beschränkung nichtflüchtige greifbare Anordnungen von Gegenständen, die durch eine Maschine oder Einrichtung hergestellt oder gebildet werden, darunter Speichermedien wie Festplatten, eine beliebige andere Art von Datenträger, darunter Disketten, optische Datenträger (CD-ROM (Compact Disk Read-Only Memories), CD-RW (Compact Disk Rewritables)) und magnetooptische Datenträger, Halbleitereinrichtungen wie Nurlesespeicher (ROM), Direktzugriffsspeicher (RAM), wie zum Beispiel dynamische Direktzugriffsspeicher (DRAN), statische Direktzugriffsspeicher (SRAM), löschbare programmierbare Nurlesespeicher (EPROM), Flash-Speicher, elektrisch löschbare programmierbare Nurlesespeicher (EEPROM), magnetische oder optische Karten oder eine beliebige andere Art von Medien, die zum Speichern von elektronischen Anweisungen geeignet ist.
Dementsprechend umfassen Ausführungsformen der Erfindung auch nichtflüchtige greifbare maschinenlesbare Medien, die Anweisungen des vektorfreundlichen Anweisungsformats enthalten oder Entwurfsdaten wie etwa HDL (Hardware Description Language) enthalten, die hier beschriebene Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale definieren. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
In bestimmten Fällen kann ein Anweisungsumsetzer verwendet werden, um eine Anweisung aus einem Quellenanweisungssatz in einen Zielanweisungssatz umzusetzen. Zum Beispiel kann der Anweisungsumsetzer eine Anweisung in eine oder mehrere durch den Kern zu verarbeitende andere Anweisungen übersetzen (z. B. unter Verwendung von statischer binärer Übersetzung, dynamischer binärer Übersetzung einschließlich dynamischer Kompilierung), Morphen, Emulieren oder anderweitig umsetzen. Der Anweisungsumsetzer kann in Software, Hardware, Firmware oder einer Kombination davon implementiert werden. Der Anweisungsumsetzer kann auf dem Prozessor, außerhalb des Prozessors oder teilweise auf und teilweise außerhalb des Prozessors sein.
21 ist ein Blockdiagramm, das die Verwendung eines Softwareanweisungsumsetzers zum Umsetzen von binären Anweisungen in einem Quellenanweisungssatz in binäre Anweisungen in einem Zielanweisungssatz gemäß Ausführungsformen der Erfindung gegenüberstellt. Bei der dargestellten Ausführungsform ist der Anweisungsumsetzer ein Software-Anweisungsumsetzer, obwohl der Anweisungsumsetzer als Alternative in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 21 zeigt, dass ein Programm in einer hohen Sprache 2102 unter Verwendung eines x86-Compilers 2104 kompiliert werden kann, um x86-Binärcode 2106 zu erzeugen, der nativ durch einen Prozessor mit mindestens einem x86-Anweisungssatzkern 2116 ausgeführt werden kann (es wird angenommen, dass bestimmte der Anweisungen, die kompiliert wurden, im vektorfreundlichen Anweisungsformat vorliegen). Der Prozessor mit mindestens einem x86-Anweisungssatzkern 2116 repräsentiert einen beliebigen Prozessor, der im Wesentlichen dieselben Funktionen wie ein Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern ausführen kann, in dem Folgendes kompatibel ausgeführt oder anderweitig verarbeitet wird: (1) ein wesentlicher Teil des Anweisungssatzes des Intel-x86-Anweisungssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software mit dem Ziel, auf einem Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern zu laufen, um im Wesentlichen dasselbe Ergebnis wie ein Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern zu erzielen. Der x86-Compiler 2104 repräsentiert einen Compiler, der betreibbar ist, um x86-Binärcode 2106 (z. B. Objektcode) zu erzeugen, der mit oder ohne zusätzliche Link-Verarbeitung auf den Prozessor mit mindestens einem x86-Anweisungssatzkern 2116 ausgeführt werden kann. (Ähnlich).
21 zeigt, dass das Programm in der hohen Sprache 2102 unter Verwendung eines Alternativ-Anweisungssatzcompilers 2108 kompiliert werden kann, um Alternativ-Anweisungssatz-Binärcode 2110 zu erzeugen, der nativ durch einen Prozessor ohne mindestens einen x86-Anweisungssatzkern 2114 ausgeführt werden kann (z. B. einen Prozessor mit Kernen, die den MIPS-Anweisungssatz der MIPS Technologies in Sunnyvale, CA, ausführen kann und/oder der den ARM-Anweisungssatz der ARM Holdings in Sunnyvale, CA ausführen kann). Der Anweisungsumsetzer 2112 wird benutzt, um den x86-Binärcode 2106 in Code umzusetzen, der nativ durch den Prozessor ohne einen x86-Anweisungssatzkern 2114 ausgeführt werden kann. Dieser umgesetzte Code ist wahrscheinlich nicht derselbe wie der Alternativ-Anweisungssatz-Binärcode 2110, weil ein hierzu fähiger Anweisungsumsetzer schwierig herzustellen ist; der umgesetzte Code wird jedoch die allgemeine Funktionsweise erreichen und aus Anweisungen aus dem alternativen Anweisungssatz bestehen. Somit repräsentiert der Anweisungsumsetzer 2112 Software, Firmware, Hardware oder eine Kombination davon, die durch Emulation, Simulation oder einen beliebigen anderen Prozess einem Prozessor oder einer anderen elektronischen Einrichtung, der bzw. die nicht über einen x86-Anweisungssatzprozessor oder -kern verfügt, erlaubt, den x86-Binärcode 2106 auszuführen.
Bestimmte Operationen der Anweisung(en) in dem hier offenbarten vektorfreundlichen Anweisungsformat können durch Hardwarekomponenten ausgeführt werden und können in maschinenausführbaren Anweisungen realisiert werden, die benutzt werden, um zu bewirken, dass eine Schaltung oder andere Hardwarekomponente, die mit den Anweisungen programmiert ist, die Operationen ausführt, oder zumindest dazu zu führen. Die Schaltung kann einen Vielzweck- oder Spezialprozessor oder eine Logikschaltung umfassen, um nur einige wenige Beispiele zu nennen. Die Operationen können gegebenenfalls auch durch eine Kombination von Hardware und Software ausgeführt werden. Ausführungslogik und/oder ein Prozessor können spezifische oder konkrete Schaltkreise oder andere Logik umfassen, die auf eine Maschinenanweisung oder ein oder mehrere aus der Maschinenanweisung abgeleitete Steuersignale reagieren, um einen anweisungsspezifizierten Ergebnisoperanden zu speichern. Zum Beispiel können Ausführungsformen der hier offenbarten Anweisung(en) in einem oder mehreren der Systeme von 16–19 ausgeführt werden, und Ausführungsformen der Anweisung(en) im vektorfreundlichen Anweisungsformat können in Programmcode gespeichert werden, um in den Systemen ausgeführt zu werden. Zusätzlich können die Verarbeitungselemente dieser Figuren eine der detaillierten hier erläuterten Pipelines und/oder Architekturen (z. B. die In-Reihenfolge und Außerreihenfolge-Architekturen) benutzen. Zum Beispiel kann die Decodiereinheit der In-Reihenfolge-Architektur die Anweisung(en) decodieren, die decodierte Anweisung zu einer Vektor- oder Skalareinheit leiten usw.
Die obige Beschreibung soll bevorzugte Ausführungsformen der vorliegenden Erfindung veranschaulichen. Aus der obigen Besprechung sollte außerdem ersichtlich sein, dass insbesondere in einem solchen Technologiebereich, bei dem das Wachstum schnell ist und weitere Fortschritte nicht leicht vorherzusehen sind, die Erfindung bezüglich Anordnung und Detail durch Fachleute modifiziert werden kann, ohne von den Prinzipien der vorliegenden Erfindung und dem Schutzumfang der beigefügten Ansprüche und ihrer Äquivalente abzuweichen. Zum Beispiel können eine oder mehrere Operationen eines Verfahrens kombiniert oder weiter zerlegt werden.
Alternative Ausführungsformen
Obwohl Ausführungsformen beschrieben wurden, die das vektorfreundliche Anweisungsformat nativ ausführen würden, können alternative Ausführungsformen der Erfindung das vektorfreundliche Anweisungsformat durch eine Emulationsschicht ausführen, die auf einem Prozessor läuft, der einen anderen Anweisungssatz ausführt (z. B. einem Prozessor, der den MIPS-Anweisungssatz der MIPS Technologies in Sunnyvale, CA, ausführt, einem Prozessor, der den ARM-Anweisungssatz der ARM Holdings in Sunnyvale, CA, ausführt). Obwohl die Flussdiagramme in den Figuren eine bestimmte Reihenfolge von durch bestimmte Ausführungsformen der Erfindung ausgeführten Operationen zeigen, versteht sich außerdem, dass eine solche Reihenfolge beispielhaft ist (z. B. können alternative Ausführungsformen die Operationen in einer anderen Reihenfolge ausführen, bestimmte Operationen kombinieren, bestimmte Operationen überlappen usw.).
In der obigen Beschreibung wurden zur Erläuterung zahlreiche spezifische Einzelheiten dargelegt, um ein umfassendes Verständnis der Ausführungsformen der Erfindung zu gewährleisten. Für Fachleute ist jedoch erkennbar, dass eine oder mehrere andere Ausführungsformen ohne gewisse dieser spezifischen Einzelheiten ausgeübt werden können. Die beschriebenen konkreten Ausführungsformen sollen die Erfindung nicht beschränken, sondern Ausführungsformen der Erfindung veranschaulichen. Der Schutzumfang der Erfindung ist nicht durch die oben angegebenen spezifischen Beispiele zu bestimmen, sondern nur durch die nachfolgenden Ansprüche.

Claims

Verfahren zum Ausführen einer Komprimieranweisung in einem Computerprozessor, umfassend: Abrufen der Komprimieranweisung, wobei die Komprimieranweisung einen Zieloperanden, einen Quellenoperanden und einen Schreibmaskenoperanden umfasst; Decodieren der abgerufenen Komprimieranweisung; Ausführen der decodierten Komprimieranweisung, um auf der Basis von Werten der Schreibmaske auszuwählen, welche Datenelemente aus der Quelle im Ziel zu speichern sind; und Speichern der ausgewählten Datenelemente der Quelle als sequenziell gepackte Datenelemente in dem Ziel.
Verfahren nach Anspruch 1, wobei der Zieloperand Speicher ist und der Quellenoperand ein Register ist.
Verfahren nach Anspruch 1, wobei der Quellen- und Zieloperand Register sind.
Verfahren nach Anspruch 1, wobei das Ausführen ferner Folgendes umfasst: Bestimmen, dass ein erster Bitpositionswert der Schreibmaske angibt, dass das entsprechende erste Quellendatenelement in einer Speicherstelle des Ziels gespeichert werden soll; und Speichern des entsprechenden ersten Quellendatenelements in der Speicherstelle des Ziels.
Verfahren nach Anspruch 1, wobei das Ausführen ferner Folgendes umfasst: Bestimmen, dass ein erster Bitpositionswert der Schreibmaske angibt, dass das entsprechende erste Quellendatenelement nicht in einer Speicherstelle des Ziels gespeichert werden soll; und Auswerten eines zweiten Bitpositionswerts der Schreibmaske, ohne das erste Quellendatenelement in einer Speicherstelle des Ziels zu speichern.
Verfahren nach Anspruch 1, wobei jedes in dem Ziel zu speichernde Quellendatenelement zuerst in einen Strom gesetzt wird und der Strom in dem Ziel gespeichert wird.
Verfahren nach Anspruch 1, ferner umfassend: Abwärtsumsetzen der in dem Ziel zu speichernden Datenelemente, bevor diese in dem Ziel gespeichert werden.
Verfahren nach Anspruch 7, wobei die Datenelemente von 32-Bit-Werten in 16-Bit-Werte abwärts umgesetzt werden.
Verfahren zum Ausführen einer Expandieranweisung in einem Computerprozessor, umfassend: Abrufen der Expandieranweisung, wobei die Expandieranweisung einen Zieloperanden, einen Quellenoperanden und einen Schreibmaskenoperanden umfasst; Decodieren der Expandier-Komprimier-Anweisung; Ausführen der Expandier-Komprimier-Anweisung, um auf der Basis von Werten der Schreibmaske auszuwählen, welche Elemente aus der Quelle spärlich im Ziel zu speichern sind; und Speichern jedes ausgewählten Datenelements der Quelle als ein spärliches Datenelement in einer Zielspeicherstelle, wobei die Zielspeicherstellen jeder Schreibmasken-Bitposition entsprechen, die angibt, dass das entsprechende Datenelement der Quelle zu speichern ist.
Verfahren nach Anspruch 9, wobei der Zieloperand ein Register und der Quellenoperand Speicher ist.
Verfahren nach Anspruch 9, wobei der Quellen- und Zieloperand Register sind.
Verfahren nach Anspruch 9, wobei das Ausführen ferner Folgendes umfasst: Bestimmen, dass ein erster Bitpositionswert der Schreibmaske angibt, dass das entsprechende erste Quellendatenelement in einer entsprechenden Speicherstelle des Ziels gespeichert werden soll; und Speichern des entsprechenden ersten Quellendatenelements in der entsprechenden Speicherstelle des Ziels.
Verfahren nach Anspruch 9, wobei das Ausführen ferner Folgendes umfasst: Bestimmen, dass ein erster Bitpositionswert der Schreibmaske angibt, dass das entsprechende erste Quellendatenelement nicht in einer entsprechenden Speicherstelle des Ziels gespeichert werden soll; und Auswerten eines zweiten Bitpositionswerts der Schreibmaske, ohne das erste Quellendatenelement in einer entsprechenden Speicherstelle des Ziels zu speichern.
Verfahren nach Anspruch 1, wobei jedes in dem Ziel zu speichernde Quellendatenelement zuerst in einen Strom gesetzt und der Strom in dem Ziel gespeichert wird.
Verfahren nach Anspruch 1, ferner umfassend: Aufwärtsumsetzen der in dem Ziel zu speichernden Datenelemente, bevor diese in dem Ziel gespeichert werden.
Verfahren nach Anspruch 7, wobei die Datenelemente von 16-Bit-Werten in 32-Bit-Werte aufwärts umgesetzt werden.
Vorrichtung, umfassend: einen Hardwaredecoder zum Decodieren einer Expandieranweisung und/oder einer Komprimieranweisung, wobei die Expandieranweisung einen ersten Schreibmaskenoperanden, einen ersten Zieloperanden, einen ersten Quellenoperanden umfasst und die Komprimieranweisung einen zweiten Schreibmaskenoperanden, einen zweiten Zieloperanden und einen zweiten Quellenoperanden umfasst; und Ausführungslogik zum Ausführen einer decodierten Expandieranweisung, um auf der Basis von Werten der Schreibmaske auszuwählen, welche Elemente aus der Quelle spärlich in dem Ziel zu speichern sind, und Speichern jedes ausgewählten Datenelements der Quelle als ein spärliches Datenelement in einer Zielspeicherstelle, wobei die Zielspeicherstellen jeder Schreibmasken-Bitposition entsprechen, die angibt, dass das entsprechende Datenelement der Quelle zu speichern ist, und Ausführen einer decodierten Komprimieranweisung, um auf der Basis von Werten der Schreibmaske auszuwählen, welche Datenelemente aus der Quelle im Ziel zu speichern sind, und Speichern der ausgewählten Datenelemente der Quelle als sequenziell gepackte Datenelemente in dem Ziel.
Vorrichtung nach Anspruch 17, ferner umfassend: ein 16-Bit-Schreibmaskenregister zum Speichern der ersten oder zweiten Schreibmaske; und ein erstes 512-Bit-Register zum Speichern der ausgewählten Datenelemente.
Vorrichtung nach Anspruch 18, ferner umfassend: ein zweites 512-Bit-Register zum Wirken als Quelle für die Expandier- und Komprimieranweisungen.
Vorrichtung nach Anspruch 17, wobei die Datenelemente während der Ausführung einer Expandieranweisung von 16-Bit-Werten in 32-Bit-Werte aufwärts umgesetzt werden.