DE102018126036A1

DE102018126036A1 - Systeme und verfahren zum setzen eines kachelregisterpaars auf null

Info

Publication number: DE102018126036A1
Application number: DE102018126036.9A
Authority: DE
Inventors: Raanan Sade; Simon Rubanovich; Amit Gradstein; Zeev Sperber; Alexander Heinecke; Robert Valentine; Mark Charney; Bret Toll; Jesus Corbal; Elmoustapha Ould-Ahmed-Vall; Menachem Adelman; Eyal Hadas
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2017-12-29
Filing date: 2018-10-19
Publication date: 2019-07-04
Also published as: US11023235B2; US20190042256A1; CN113885942A; US11645077B2; US20220019438A1; CN109992305A

Abstract

Hier dargelegte Ausführungsformen betreffen Systeme und Verfahren zum Nullen eines Kachelregisterpaars. In einem Beispiel umfasst ein Prozessor Decodierschaltkreise zum Decodieren einer Matrixpaar-Nullungsanweisung mit Feldern für einen Opcode und einer Kennung zum Identifizieren einer Zielmatrix mit einem PAIR-Parameter gleich TRUE; und Ausführungsschaltkreise zum Ausführen der decodierten Matrixpaar-Nullungsanweisung zum Nullen jedes Elements einer linken Matrix und einer rechten Matrix der identifizierten Zielmatrix.

Description

GEBIET DER ERFINDUNG
Das Gebiet der Erfindung betrifft allgemein eine Computerprozessorarchitektur und genauer Systeme und Verfahren zum Setzen eines Kachelregisterpaars auf null.
STAND DER TECHNIK
Matrizen werden in vielen Rechenaufgaben immer wichtiger, wie zum Beispiel bei maschinellem Lernen und sonstiger Verarbeitung von Massendaten.
Figurenliste
Die vorliegende Erfindung wird in den Figuren der beiliegenden Zeichnungen beispielhaft, jedoch nicht einschränkend illustriert, in denen gleiche Referenzen ähnliche Elemente anzeigen und in denen:

1A eine Ausführungsform von konfigurierten Kacheln illustriert;
1B eine Ausführungsform von konfigurierten Kacheln illustriert;
2 mehrere Beispiele einer Matrixspeicherung illustriert;
3 eine Ausführungsform eines Systems illustriert, das einen Beschleuniger für Matrixoperationen (Kacheloperationen) einsetzt;
4 und 5 verschiedene Ausführungsformen zeigen, wie Arbeitsspeichers unter Verwendung eines Beschleunigers für Matrixoperationen gemeinsam genutzt wird;
6 eine Ausführungsform einer Matrixmultiplikations-Akkumulationsoperation unter Verwendung von Kacheln („TMMA“) illustriert;
7 eine Ausführungsform einer Teilmenge der Ausführung einer Iteration einer verketteten Fused-Multiply-Accumulate-Anweisung illustriert;
8 eine Ausführungsform einer Teilmenge der Ausführung einer Iteration einer verketteten Fused-Multiply-Accumulate-Anweisung illustriert;
9 eine Ausführungsform einer Teilmenge der Ausführung einer Iteration einer verketteten Fused-Multiply-Accumulate-Anweisung illustriert;
10 eine Ausführungsform einer Teilmenge der Ausführung einer Iteration einer verketteten Fused-Multiply-Accumulate-Anweisung illustriert;
11 SIMD-Implementierungen mit einer zu einer Zweierpotenz bemessenen Größe nach einer Ausführungsform illustriert, wobei die Akkumulatoren Eingabegrößen verwenden, die größer als die Eingaben in die Multiplikatoren sind;
12 eine Ausführungsform eines Systems illustriert, das eine Matrixoperationsverschaltung einsetzt;
13 eine Ausführungsform einer Prozessorkern-Pipeline illustriert, die Matrixoperationen unter Verwendung von Kacheln unterstützt;
14 eine Ausführungsform einer Prozessorkern-Pipeline illustriert, die Matrixoperationen unter Verwendung von Kacheln unterstützt;
15 ein Beispiel einer Matrix illustriert, die in zeilenweisem Format und in spaltenweisem Format ausgedrückt ist;
16 ein Beispiel einer Verwendung von Matrizen (Kacheln) illustriert;
17 eine Ausführungsform eines Verfahrens zur Verwendung von Matrizen (Kacheln) illustriert;
18 eine Unterstützung zur Konfiguration der Verwendung von Kacheln nach einer Ausführungsform illustriert;
19 eine Ausführungsform einer Beschreibung der zu unterstützenden Matrizen (Kacheln) illustriert;
20 (A) - (D) Beispiele eines Registers bzw. von Registern illustrieren;
21 eine beispielhafte Ausführung einer TZPAIR-Anweisung illustriert;
22 eine Ausführungsform eines Verfahrens illustriert, das durch einen Prozessor durchgeführt wird, um eine TZPAIR-Anweisung zu verarbeiten;
23 eine ausführlichere Beschreibung einer Ausführung einer TZPAIR-Anweisung illustriert;
24 beispielhafter Pseudocode ist, der eine Ausführungsform eines Verfahrens beschreibt, das durch einen Prozessor durchgeführt wird, um eine TZPAIR-Anweisung zu verarbeiten;
25A-25B Blockdiagramme sind, die ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen davon nach Ausführungsformen der Erfindung illustrieren;
25A ein Blockdiagramm ist, das ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen der Klasse A davon nach Ausführungsformen der Erfindung illustriert;
25B ein Blockdiagramm ist, das das generische vektorfreundliche Anweisungsformat und Anweisungsvorlagen der Klasse B davon nach Ausführungsformen der Erfindung illustriert;
26A ein Blockdiagramm ist, das ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat nach Ausführungsformen der Erfindung illustriert;
26B ein Blockdiagramm ist, das die Felder des spezifischen vektorfreundlichen Anweisungsformats illustriert, die das vollständige Opcode-Feld nach einer Ausführungsform der Erfindung bilden;
26C ein Blockdiagramm ist, das die Felder des spezifischen vektorfreundlichen Anweisungsformats illustriert, die das Registerindexfeld nach einer Ausführungsform der Erfindung bilden;
26D ein Blockdiagramm ist, das die Felder des spezifischen vektorfreundlichen Anweisungsformats illustriert, die das Operationszusatzfeld nach einer Ausführungsform der Erfindung bilden;
27 ein Blockdiagramm einer Registerarchitektur nach einer Ausführungsform der Erfindung ist;
28A ein Blockdiagramm ist, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline nach Ausführungsformen der Erfindung illustriert;
28B ein Blockdiagramm ist, das sowohl ein Ausführungsbeispiel eines Kerns mit In-Order-Architektur als auch eines Kerns mit Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungsarchitektur illustriert, die in einem Prozessor nach Ausführungsformen der Erfindung enthalten sein sollen;
29A-B ein Blockdiagramm einer spezifischeren beispielhaften In-Order-Kernarchitektur illustrieren, wobei der Kern einer von mehreren logischen Blöcken (die anderen Kerne des gleichen Typs und/oder anderer Typen enthalten) in einem Chip wäre;
29A ein Blockdiagramm eines einzelnen Prozessorkerns, zusammen mit seiner Verbindung an das chipinterne Verbindungsnetz und mit seinem lokalen Teilsatz des Level-2(L2)-Zwischenspeichers ist, nach Ausführungsformen der Offenbarung;
29B eine erweiterte Ansicht eines Teils des Prozessorkerns in 29A nach Ausführungsformen der Erfindung ist;
30 ein Blockdiagramm eines Prozessors ist, der nach Ausführungsformen der Erfindung mehr als einen Kern aufweisen kann, eine integrierte Arbeitsspeichersteuerung aufweisen kann und integrierte Grafik aufweisen kann;
31-34 Blockdiagramme von beispielhaften Computerarchitekturen sind;
31 ein Blockdiagramm eines Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt;
32 ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist;
33 ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist;
34 ein Blockdiagramm eines Ein-Chip-Systems (SoC) in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist; und
35 ein Blockdiagramm ist, das die Verwendung eines Softwareanweisungswandlers gegenüberstellt, um binäre Anweisungen in einem Quellanweisungssatz in binäre Anweisungen in einem Zielanweisungssatz nach Ausführungsformen der Erfindung umzuwandeln.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt. Es ist jedoch klar, dass Ausführungsformen der Erfindung ohne diese spezifischen Details praktiziert werden können. In anderen Fällen wurden wohlbekannte Schaltkreise, Strukturen und Techniken nicht im Detail gezeigt, um das Verständnis dieser Beschreibung nicht zu verschleiern.
Bezugnahmen in der Beschreibung auf „eine Ausführungsform“, „ein Ausführungsbeispiel“ usw. zeigen an, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft enthalten kann, aber jede Ausführungsform kann nicht notwendigerweise das bestimmte Merkmal, die bestimmte Struktur oder Eigenschaft enthalten. Darüber hinaus beziehen sich solche Formulierungen nicht notwendigerweise auf die gleiche Ausführungsform. Ferner, wenn ein bestimmtes Merkmal, Struktur oder Eigenschaft in Verbindung mit einer Ausführungsform beschrieben wird, wird vorgebracht, dass es im Wissen von Fachleuten liegt, ein solches Merkmal, eine solche Struktur oder Eigenschaft in Verbindung mit anderen Ausführungsformen zu erwirken, egal, ob es bzw. sie explizit beschrieben wird oder nicht.
In vielen handelsüblichen Prozessoren ist eine Handhabung von Matrizen eine schwierige und/oder anweisungsintensive Aufgabe. Zeilen einer Matrix könnten zum Beispiel in eine Vielzahl von gepackten Datenregistern (z. B. SIMD- oder Vektorregistern) platziert und danach individuell bearbeitet werden. Eine Addition von zwei 8x2-Matrizen kann beispielsweise eine Last erfordern oder in vier gepackte Datenregister angesammelt werden, abhängig von Datengrößen. Danach wird eine erste Addition von gepackten Datenregistern durchgeführt, die einer ersten Zeile von jeder Matrix entsprechen, und eine zweite Addition von gepackten Datenregistern wird durchgeführt, die einer zweiten Zeile von jeder Matrix entsprechen. Danach werden die resultierenden gepackten Datenregister zurück in den Arbeitsspeicher gestreut. Während dieses Szenario für kleine Matrizen akzeptabel sein kann, ist es oft für größere Matrizen nicht akzeptabel.
BESPRECHUNG AUF HOHER EBENE
Hierin werden Mechanismen beschrieben, um Matrixoperationen in Computerhardware wie Zentralprozessoreinheiten (CPUs), Grafikverarbeitungseinheiten (GPUs) und Beschleunigern zu unterstützen. Die Matrixoperationen setzen 2-dimensionale (2D) Datenstrukturen ein, die eine oder mehrere gepackte Arbeitsspeicherbereiche wie Register repräsentieren. In dieser gesamten Beschreibung werden diese 2D-Datenstrukturen als Kacheln bezeichnet. Es ist anzumerken, dass eine Matrix kleiner als eine Kachel sein kann (weniger als die Gesamtheit einer Kachel verwenden kann) oder eine Vielzahl von Kacheln verwenden kann (die Matrix ist größer als die Größe einer Kachel). In der gesamten Beschreibung wird Matrixsprache (Kachel) verwendet, um Operationen anzuzeigen, die unter Verwendung von Kacheln durchgeführt werden und eine Matrix beeinflussen; ob diese Matrix größer als eine Kachel ist oder nicht, ist typischerweise nicht relevant.
Verschiedene Operationen können jede Kachel bearbeiten, wie diejenigen, die hierin ausführlich beschrieben werden und unter anderem einschließen: Matrixmultiplikation (Kachelmultiplikation), Kacheladdition, Kachelsubtraktion, Kacheldiagonale, Kachel-Nullsetzung, Kacheltransposition, Kachel-Skalarprodukt, Kachel-Übertragung, Kachelzeilen-Übertragung, Kachelspalten-Übertragung, Kachelmultiplikation, Kachelmultiplikation und -Akkumulation, Kachelbewegung usw. Zusätzlich kann eine Unterstützung für Operatoren wie die Verwendung einer Skalierung und/oder eines Versatzes mit diesen Operationen oder zur Unterstützung von zukünftigen, nicht numerischen Anwendungen verwendet werden, beispielsweise „lokaler Arbeitsspeicher“ für OpenCL, Datenkomprimierung/-dekomprimierung usw.
Abschnitte von Speicher (wie Arbeitsspeicher (nichtflüchtig und flüchtig), Register, Zwischenspeicher usw.) sind in Kacheln mit verschiedenen horizontalen und vertikalen Dimensionen angeordnet. Eine Kachel kann eine horizontale Dimension von 4 (z. B. vier Zeilen einer Matrix) und eine vertikale Dimension von 8 (z. B. 8 Spalten der Matrix) aufweisen. Üblicherweise ist die horizontale Dimension mit Elementgrößen verbunden (z. B. 2-, 4-, 8-, 16-, 32-, 64-, 128-Bit usw.). Mehrere Datentypen (Gleitkomma mit einfacher Genauigkeit, Gleitkomma mit doppelter Genauigkeit, ganzzahlig usw.) können unterstützt sein.
BEISPIELHAFTE VERWENDUNG VON KONFIGURIERTEN KACHELN
In einigen Ausführungsformen können Kachelparameter konfiguriert werden. Eine bestimmte Kachel kann zum Beispiel konfiguriert werden, um Kacheloptionen bereitzustellen. Beispielhafte Kacheloptionen enthalten unter anderem: eine Anzahl von Zeilen der Kachel, eine Anzahl von Spalten der Kachel, ob die Kachel GÜLTIG ist und ob die Kachel aus einem PAAR von gleich großen Kacheln besteht.
1A illustriert eine Ausführungsform von konfigurierten Kacheln. Wie gezeigt, weisen 4 kB von Anwendungsarbeitsspeicher 102 4 darauf gespeicherte 1-kB-Kacheln auf, Kachel 0 104, Kachel 1 106, Kachel 2 108 und Kachel 3 110. In diesem Beispiel bestehen die 4 Kacheln nicht aus Paaren und jede weist in Zeilen und Spalten angeordnete Elemente auf. Kachel t0 104 und Kachel t1 106 weisen K Zeilen und N Spalten mit 4-Byte-Elementen (z. B. Daten mit einfacher Genauigkeit) auf, wobei K gleich 8 ist und N = 32. Kachel t2 108 und Kachel t3 110 weisen K Zeilen und N/2 Spalten mit 8-Byte-Elementen (z. B. Daten mit doppelter Genauigkeit) auf. Da die Operanden mit doppelter Genauigkeit die zweifache Breite derer mit einfacher Genauigkeit aufweisen, ist diese Konfiguration mit einer Palette vereinbar, die verwendet wird, um Kacheloptionen bereitzustellen und mindestens 4 Bezeichner mit einem Gesamtspeicher von mindestens 4 kB liefert. In Betrieb können die Kacheln unter Verwendung von Lade- und Speicheroperationen aus dem Arbeitsspeicher geladen und in diesem gespeichert werden. Abhängig vom verwendeten Anweisungscodierschema variiert die Menge an verfügbarem Anwendungsarbeitsspeicher sowie die Größe, Anzahl und Konfiguration von verfügbaren Kacheln.
1B illustriert eine Ausführungsform von konfigurierten Kacheln. Wie gezeigt weisen 4 kB von Anwendungsarbeitsspeicher 122 2 Paare von darauf gespeicherten 1-kB-Kacheln auf, wobei das erste Paar aus Kachel t4L 124 und Kachel t4R 126 besteht und das zweite Paar aus Kachel t5L 128 und Kachel t5R 130 besteht. Wie gezeigt, sind die Kachelpaare in eine linke Kachel und eine rechte Kachel aufgeteilt. In anderen Ausführungsformen sind die Kachelpaare in eine gerade Kachel und eine ungerade Kachel aufgeteilt. In diesem Beispiel weisen die 4 Kacheln jeweils in Zeilen und Spalten angeordnete Elemente auf. Kachel t4L 124 und Kachel t4R 126 weisen K Zeilen und N Spalten mit 4-Byte-Elementen (z. B. Daten mit einfacher Genauigkeit) auf, wobei K gleich 8 ist und N gleich 32 ist. Kachel t5L 128 und Kachel t5R 130 weisen K Zeilen und N/2 Spalten mit 8-Byte-Elementen (z. B. Daten mit doppelter Genauigkeit) auf. Da die Operanden mit doppelter Genauigkeit die zweifache Breite derer mit einfacher Genauigkeit aufweisen, ist diese Konfiguration mit einer Palette vereinbar, die verwendet wird, um Kacheloptionen bereitzustellen und mindestens 2 Bezeichner mit einem Gesamtspeicher von mindestens 4 kB liefert. Die vier Kacheln von 1A verwenden 4 Bezeichner, die jeweils eine 1-kB-Kachel benennen, wobei die 2 Kachelpaare in 1B 2 Bezeichner verwenden können, um die gepaarten Kacheln anzugeben. In einigen Ausführungsformen akzeptieren Kachelanweisungen einen Bezeichner einer gepaarten Kachel als einen Operanden. In Betrieb können die Kacheln unter Verwendung von Lade- und Speicheroperationen aus dem Arbeitsspeicher geladen und in diesem gespeichert werden. Abhängig vom verwendeten Anweisungscodierschema variiert die Menge an verfügbarem Anwendungsarbeitsspeicher sowie die Größe, Anzahl und Konfiguration von verfügbaren Kacheln.
In einigen Ausführungsformen können Kachelparameter definiert werden. Es wird zum Beispiel eine „Palette“ verwendet, um Kacheloptionen bereitzustellen. Beispielhafte Optionen enthalten unter anderem: die Anzahl der Kachelbezeichner, die Byteanzahl in einer Speicherzeile, die Zeilen- und Spaltenanzahl in einer Kachel usw. Eine maximale „Höhe“ (Zeilenanzahl) einer Kachel kann beispielsweise folgendermaßen definiert werden:
Max. Kachelzeilen = Speicherarchitektur / (Anzahl an Palettenbezeichnern * Byteanzahl pro Zeile).
Als solche kann eine Anwendung so geschrieben werden, dass eine fixierte Verwendung von Bezeichnern unterschiedliche Speichergrößen über Implementierungen hinweg vorteilhaft nutzen kann.
Eine Konfiguration der Kacheln erfolgt unter Verwendung einer Kachelkonfigurationsanweisung („TILECONFIG“), wobei eine bestimmte Kachelnutzung in einer ausgewählten Palette definiert ist. Diese Deklaration enthält die Anzahl der zu verwendenden Kachelnamen, die angeforderte Anzahl an Zeilen und Spalten pro Bezeichner (Kachel) und in einigen Ausführungsformen den angeforderten Datentyp jeder Kachel. In einigen Ausführungsformen werden Konsistenzprüfungen während der Ausführung einer TILECONFIG-Anweisung durchgeführt, um zu ermitteln, dass sie mit den Einschränkungen des Paletteneintrags übereinstimmt.
BEISPIELHAFTE KACHELSPEICHERTYPEN
2 illustriert mehrere Beispiele einer Matrixspeicherung. Bei (A) wird eine Kachel im Arbeitsspeicher gespeichert. Wie gezeigt besteht jede „Zeile“ aus vier gepackten Datenelementen. Um zur nächsten „Zeile“ zu gelangen, wird ein Schrittwert verwendet. Es ist anzumerken, dass Zeilen im Arbeitsspeicher aufeinanderfolgend gespeichert sein können. Ein schrittweiser Arbeitsspeicherzugriff ermöglicht einen Zugriff auf eine Zeile und danach auf die nächste, wenn die Kachelspeicherung die Zeilenbreite des zugrundeliegenden Arbeitsspeicherarrays nicht abbildet.
Kachelladevorgänge aus dem und Kachelspeichervorgänge in den Arbeitsspeicher sind üblicherweise schrittweise Zugriffe aus dem Anwendungsarbeitsspeicher auf gepackte Datenzeilen. Beispielhafte TILELOAD- und TILESTORE-Anweisungen oder andere Anweisungsreferenzen auf Anwendungsarbeitsspeicher als ein KACHEL-Operand in Lade-Operationsanweisungen können in einigen Ausführungsformen neu gestartet werden, um (bis zu) 2*Zeilen von Seitenfehlern, nicht maskierte Gleitkommaausnahmen und/oder Unterbrechungen pro Anweisung zu handhaben.
In (B) ist eine Matrix in einer Kachel gespeichert, die aus einer Vielzahl von Registern besteht, wie gepackten Datenregistern (eine einzelne Anweisung, mehrere Daten (SIMD) oder Vektorregister). In diesem Beispiel ist die Kachel drei physischen Registern überlagert. Üblicherweise werden aufeinanderfolgende Register verwendet, dies ist jedoch nicht notwendig.
In (C) ist eine Matrix in einer Kachel in einem Nicht-Register-Speicher gespeichert, auf den über einen Fused-Multiply-Accumulate(FMA)-Schaltkreis zugegriffen werden kann, der in Kacheloperationen verwendet wird. Dieser Speicher kann sich innerhalb eines FMA oder daneben befinden. Darüber hinaus kann der Speicher in einigen Ausführungsformen, die unten besprochen werden, für ein Datenelement und nicht für eine ganze Zeile oder Kachel sein.
Die unterstützten Parameter für die TMMA-Architektur werden über CPUID gemeldet. In einigen Ausführungsformen enthält die Liste der Informationen eine Maximalhöhe und eine maximale SIMD-Dimension. Ein Konfigurieren der TMMA-Architektur erfordert ein Angeben der Dimensionen für jede Kachel, die Elementgröße für jede Kachel und die Palettenkennung. Diese Konfiguration erfolgt durch Ausführen der TILECONFIG-Anweisung.
Eine erfolgreiche Ausführung einer TILECONFIG-Anweisung ermöglicht nachfolgende TILE-Operationen. Eine TILERELEASEALL-Anweisung löscht die Kachelkonfiguration und deaktiviert die TILE-Operationen (bis die nächste TILECONFIG-Anweisung ausgeführt wird). In einigen Ausführungsformen werden XSAVE, XSTORE usw. bei einem Kontextwechsel unter Verwendung von Kacheln verwendet. In einigen Ausführungsformen werden 2 XCR0-Bits bei XSAVE verwendet, eines für TILECONFIF-Metadaten und ein Bit, das tatsächlichen Kachelnutzlastdaten entspricht.
TILECONFIG konfiguriert nicht nur die Kachelnutzung, sondern setzt auch eine Zustandsvariable, die anzeigt, dass sich das Programm in einem Bereich mit Code mit konfigurierten Kacheln befindet. Eine Implementierung kann Einschränkungen an anderen Anweisungen auflisten, die mit einem Kachelbereich verwendet werden können, wie zum Beispiel keine Nutzung eines bestehenden Registersatzes usw.
Ein Verlassen eines Kachelbereichs erfolgt üblicherweise mit der TILERELEASEALL-Anweisung. Sie nimmt keine Parameter an und macht alle Kacheln schnell ungültig (wobei angezeigt wird, dass die Daten nicht mehr gespeichert oder wiederhergestellt werden müssen) und löscht den internen Zustand, der einer Anordnung in einem Kachelbereich entspricht.
In einigen Ausführungsformen setzen Kacheloperationen alle Zeilen und alle Spalten über die von der Kachelkonfiguration angegebenen Dimensionen hinaus auf null. Kacheloperationen setzen zum Beispiel die Daten über die konfigurierte Spaltenanzahl (unter Berücksichtigung der Größe der Elemente) auf null, während jede Zeile beschrieben wird. Bei 64-Byte-Zeilen und einer mit 10 Zeilen und 12 Spalten konfigurierten Kachel würde eine Operation, die FP32-Elemente schreibt, zum Beispiel jede der ersten 10 Zeilen mit 12*4 Bytes mit Ausgabe-/Ergebnisdaten beschreiben und die restlichen 4*4 Bytes in jeder Zeile auf null setzen. Kacheloperationen setzen auch alle Zeilen nach den ersten 10 konfigurierten Zeilen vollständig auf null. Bei Verwendung von 1K-Kacheln mit 64-Byte-Zeilen würde es 16 Zeilen geben, deshalb würden die letzten 6 Zeilen in diesem Beispiel auch auf null gesetzt.
In einigen Ausführungsformen setzt eine Kontextwiederherstellung (z. B. XRSTOR) beim Laden von Daten durch, dass die Daten über die für eine Kachel konfigurierten Zeilen hinaus als null beibehalten werden. Falls es keine gültige Konfiguration gibt, werden alle Zeilen auf null gesetzt. Ein XRSTOR der Kacheldaten kann Datenmüll in die über die konfigurierten hinausgehenden Spalten laden. Es sollte für XRSTOR nicht möglich sein, über die konfigurierte Spaltenanzahl hinaus zu löschen, da keine Elementbreitemit der Kachelkonfiguration assoziiert ist.
Ein Kontextspeichervorgang (z. B. XSAVE) setzt den gesamten TILE-Speicherbereich frei, wenn der Vorgang diesen in den Arbeitsspeicher schreibt. Falls XRSTOR Datenmüll in den ganz rechten Teil einer Kachel geladen hat, werden diese Daten von XSAVE gespeichert. XSAVE schreibt Nullen für Zeilen, die über die für jede Kachel angegebene Anzahl hinausgehen.
In einigen Ausführungsformen können Kachelanweisungen neu gestartet werden. Die Operationen, die auf den Arbeitsspeicher zugreifen, ermöglichen einen Neustart nach Seitenfehlern. Die rechnerischen Anweisungen, die Gleitkommaoperationen erledigen, ermöglichen auch demaskierte Gleitkommaausnahmen, wobei die Maskierung der Ausnahmen durch ein Steuer- und/oder Statusregister gesteuert wird.
Um Neustartanweisungen nach diesen Ereignissen zu unterstützen, speichern die Anweisungen Informationen in den Startregistern, die unten ausführlich besprochen werden.
II. SYSTEME FÜR MATRIXOPERATIONEN (KACHELOPERATIONEN)
BEISPIELHAFTE HARDWAREUNTERSTÜTZUNG
3 illustriert eine Ausführungsform eines Systems, das einen Beschleuniger für Matrixoperationen (Kacheloperationen) einsetzt. In dieser Illustration kommuniziert ein Hostprozessor/Verarbeitungssystem 301 Befehle 311 (z. B. Matrixmanipulationsoperationen wie arithmetische oder Matrixmanipulationsoperationen oder Lade- und Speicheroperationen) an einen Matrixoperationsbeschleuniger 307. Dies wird jedoch nur zu Zwecken der Diskussion auf diese Weise dargestellt. Wie später ausführlich besprochen, kann dieser Beschleuniger 307 ein Teil eines Verarbeitungskerns sein. Üblicherweise beziehen sich Befehle 311, die Kachelmanipulations-Operatoranweisungen sind, auf Kacheln im Register-Register- („reg-reg“) oder Register-Arbeitsspeicher-Format („reg-mem“). Andere Befehle wie TILESTORE, TILELOAD, TILECONFIG usw. führen keine Datenoperationen an einer Kachel aus. Befehle können decodierte Anweisungen (z. B. Mikro-Ops) oder Makroanweisungen sein, die der Beschleuniger 307 zu handhaben hat.
In diesem Beispiel ist eine kohärente Arbeitsspeicherschnittstelle 303 so an den Hostprozessor/das Verarbeitungssystem 301 und den Matrixoperationsbeschleuniger 307 gekoppelt, dass diese den Arbeitsspeicher gemeinsam nutzen können. 4 und 5 zeigen verschiedene Ausführungsformen, wie Arbeitsspeicher unter Verwendung eines Beschleunigers für Matrixoperationen gemeinsam genutzt wird. Wie in 4 gezeigt, nutzen der Hostprozessor 401 und die Matrixoperationsbeschleunigerverschaltung 405 den gleichen Arbeitsspeicher 403 gemeinsam. 5 illustriert eine Ausführungsform, bei der der Hostprozessor 501 und der Matrixoperationsbeschleuniger 505 den Arbeitsspeicher nicht gemeinsam nutzen, jedoch jeweils auf den Arbeitsspeicher des anderen zugreifen können. Der Prozessor 501 kann zum Beispiel auf den Kachelarbeitsspeicher 507 zugreifen und seinen Hostarbeitsspeicher 503 wie üblich einsetzen. Gleichermaßen kann der Matrixoperationsbeschleuniger 505 auf den Hostarbeitsspeicher 503 zugreifen, verwendet üblicherweise jedoch seinen eigenen Arbeitsspeicher 507. Es ist anzumerken, dass diese Arbeitsspeicher unterschiedliche Typen sein können.
In einigen Ausführungsformen enthält der Matrixoperationsbeschleuniger 307 eine Vielzahl von FMAs 309, die an Datenpuffer 305 gekoppelt ist (in einigen Ausführungsformen sind einer oder mehrere dieser Puffer 305 in den FMAs des Rasters gespeichert, wie gezeigt). Die Datenpuffer 305 puffern Kacheln, die aus dem Arbeitsspeicher geladen wurden, und/oder Kacheln, die im Arbeitsspeicher zu speichern sind (z. B. unter Verwendung einer Kachellade- oder Kachelspeicheranweisung). Die Datenpuffer können zum Beispiel eine Vielzahl von Registern sein. Üblicherweise sind diese FMAs als ein Raster von verketteten FMAs 309 angeordnet, die Kacheln lesen und schreiben können. In diesem Beispiel hat der Matrixoperationsbeschleuniger 307 eine Matrixmultiplikationsoperation unter Verwendung der Kacheln T0, T1 und T2 auszuführen. Mindestens eine der Kacheln ist im FMA-Raster 309 untergebracht. In einigen Ausführungsformen sind alle Kacheln in einer Operation im FMA-Raster 309 gespeichert. In anderen Ausführungsformen ist nur eine Teilmenge im FMA-Raster 309 gespeichert. Wie gezeigt ist T1 untergebracht und T0 und T2 sind dies nicht. Es ist anzumerken, dass A, B und C die Matrizen dieser Kacheln bezeichnen, die den gesamten Platz der Kachel einnehmen können oder auch nicht.
6 illustriert eine Ausführungsform einer Matrixmultiplikations-Akkumulationsoperation unter Verwendung von Kacheln („TMMA“).
Die Zeilenanzahl in der Matrix (KACHEL A 601) stimmt mit der Anzahl von seriellen (verketteten) FMAs überein, die die Latenz der Berechnung umfassen. Eine Implementierung kann frei auf einem Raster mit kleinerer Höhe umlaufen, aber die Berechnung bleibt die gleiche.
Der Quellen-/Zielvektor stammt von einer Kachel mit N Zeilen (KACHEL C 605) und das Raster von FMAs 611 führt N Vektor-Matrix-Operationen durch, die in einer vollständigen Anweisung resultieren, die eine Matrixmultiplikation von Kacheln durchführt. Kachel B 603 ist die andere Vektorquelle und liefert in jeder Phase „Übertragungs“-Begriffe an die FMAs.
Im Betrieb sind die (in einer Kachel B 603 gespeicherten) Elemente der Matrix B in einigen Ausführungsformen über das rechteckige Raster der FMAs verteilt. Die (in Kachel A 601 gespeicherte) Matrix B weist ihre Elemente einer Zeile transponiert auf, um mit der Spaltendimension des rechteckigen Rasters der FMAs übereinzustimmen. An jedem FMA im Raster wird ein Element von A und B multipliziert und zum (aus oben in der Figur) einlaufenden Summanden addiert und die auslaufende Summe wird an die nächste Zeile von FMAs (oder die endgültige Ausgabe) weitergegeben.
Die Latenz eines einzelnen Schritts ist proportional zu K (Zeilenhöhe der Matrix B) und abhängige TMMAs weisen üblicherweise ausreichende Quellen-Ziel-Zeilen (entweder in einer einzigen Kachel oder über Kacheln hinweg) auf, um diese Latenz zu verbergen. Eine Implementierung kann auch die SIMD-Dimension (die Dimension des gepackten Datenelements) M (Zeilenhöhe der Matrix A) über Zeitschritte aufteilen, aber dies ändert einfach die Konstante, mit der K multipliziert ist. Wenn ein Programm ein kleineres K als das vom TMACC spezifizierte Maximum angibt, kann eine Implementierung dieses durch „Maskierung“ oder „frühe Ausgaben“ frei implementieren.
Die Latenz einer gesamten TMMA ist zu N*K proportional. Die Wiederholrate ist zu N proportional. Die Anzahl von MACs pro TMMA-Anweisung beträgt N*K*M.
7 illustriert eine Ausführungsform einer Teilmenge der Ausführung einer Iteration einer verketteten Fused-Multiply-Accumulate-Anweisung. Insbesondere veranschaulicht dies eine Ausführungsverschaltung einer Iteration einer gepackten Datenelementposition des Ziels. In dieser Ausführungsform operiert die verkettete Fused-Multiply-Accumulate an vorzeichenbehafteten Quellen, wobei der Akkumulator die 2-fache Größe der Eingabedaten aufweist.
Eine erste vorzeichenbehaftete Quelle (Quelle 1 701) und eine zweite vorzeichenbehaftete Quelle (Quelle 2 703) weisen jeweils vier gepackte Datenelemente auf. Jedes dieser gepackten Datenelemente speichert vorzeichenbehaftete Daten wie Gleitkommadaten. Eine dritte vorzeichenbehaftete Quelle (Quelle 3 709) weist zwei gepackte Datenelemente auf, von denen jedes vorzeichenbehaftete Daten speichert. Die Größen der ersten und der zweiten vorzeichenbehafteten Quelle 701 und 703 sind die Hälfte der dritten vorzeichenbehafteten Quelle (Anfangswert oder vorangehendes Ergebnis) 709. Die erste und die zweite vorzeichenbehaftete Quelle 701 und 703 könnten zum Beispiel gepackte 32-Bit-Datenelemente (z. B. Gleitkomma mit einfacher Genauigkeit) aufweisen, während die dritte vorzeichenbehaftete Quelle 709 gepackte 64-Bit-Datenelemente (z. B. Gleitkomma mit doppelter Genauigkeit) aufweisen könnte.
In dieser Illustration sind nur die zwei höchstwertigen gepackten Datenelementpositionen der ersten und der zweiten vorzeichenbehafteten Quelle 701 und 703 und die höchstwertige gepackte Datenelementposition der dritten vorzeichenbehafteten Quelle 709 gezeigt. Natürlich würden die anderen gepackten Datenelementpositionen ebenfalls verarbeitet werden.
Wie illustriert werden gepackte Datenelemente in Paaren verarbeitet. Die Daten der höchstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten vorzeichenbehafteten Quelle 701 und 703 werden zum Beispiel unter Verwendung eines Multiplikationsschaltkreises 705 multipliziert und die Daten der nächsthöchstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten vorzeichenbehafteten Quelle 701 und 703 werden unter Verwendung eines Multiplikationsschaltkreises 707 multipliziert. In einigen Ausführungsformen werden diese Multiplikationsschaltkreise 705 und 707 für andere Positionen der gepackten Datenelemente wiederverwendet. In anderen Ausführungsformen werden zusätzliche Multiplikationsschaltkreise verwendet, sodass die gepackten Datenelemente parallel verarbeitet werden. In einigen Kontexten erfolgt eine parallele Ausführung unter Verwendung von Bahnen, die die Größe der dritten vorzeichenbehafteten Quelle 709 haben. Die Ergebnisse jeder der Multiplikationen werden unter Verwendung von Additionsverschaltung 711 addiert.
Das Ergebnis der Addition der Ergebnisse der Multiplikationen wird zu den Daten der höchstwertigen Position der gepackten Datenelemente der vorzeichenbehafteten Quelle 3 709 (unter Verwendung einer anderen Additionseinheit 713 oder der gleichen Additionseinheit 711) addiert.
Schließlich wird das Ergebnis der zweiten Addition entweder im vorzeichenbehafteten Ziel 715 in einer gepackten Datenelementposition gespeichert, die der gepackten Datenelementposition entspricht, die aus der vorzeichenbehafteten dritten Quelle 709 verwendet wurde, oder an die nächste Iteration weitergeleitet, falls es eine gibt. In einigen Ausführungsformen wird eine Schreibmaske auf diese Speicherung angewandt, sodass, falls eine entsprechende Schreibmaske (ein entsprechendes Bit) gesetzt ist, eine Speicherung erfolgt, und falls sie (es) nicht gesetzt ist, erfolgt keine Speicherung.
8 illustriert eine Ausführungsform einer Teilmenge der Ausführung einer Iteration einer verketteten Fused-Multiply-Accumulate-Anweisung. Insbesondere veranschaulicht dies eine Ausführungsverschaltung einer Iteration einer gepackten Datenelementposition des Ziels. In dieser Ausführungsform operiert die verkettete Fused-Multiply-Accumulate an vorzeichenbehafteten Quellen, wobei der Akkumulator die 2-fache Größe der Eingabedaten aufweist.
Eine erste vorzeichenbehaftete Quelle (Quelle 1 801) und eine zweite vorzeichenbehaftete Quelle (Quelle 2 803) weisen jeweils vier gepackte Datenelemente auf. Jedes dieser gepackten Datenelemente speichert vorzeichenbehaftete Daten wie ganzzahlige Daten. Eine dritte vorzeichenbehaftete Quelle (Quelle 3 809) weist zwei gepackte Datenelemente auf, von denen jedes vorzeichenbehaftete Daten speichert. Die Größen der ersten und der zweiten vorzeichenbehafteten Quelle 801 und 803 sind die Hälfte der dritten vorzeichenbehafteten Quelle 809. Die erste und die zweite vorzeichenbehaftete Quelle 801 und 803 könnten zum Beispiel gepackte 32-Bit-Datenelemente (z. B. Gleitkomma mit einfacher Genauigkeit) aufweisen, die dritte vorzeichenbehaftete Quelle 809 könnte gepackte 64-Bit-Datenelemente (z. B. Gleitkomma mit doppelter Genauigkeit) aufweisen.
In dieser Illustration sind nur die zwei höchstwertigen gepackten Datenelementpositionen der ersten und der zweiten vorzeichenbehafteten Quelle 801 und 803 und die höchstwertige gepackte Datenelementposition der dritten vorzeichenbehafteten Quelle 809 gezeigt. Natürlich würden die anderen gepackten Datenelementpositionen ebenfalls verarbeitet werden.
Wie illustriert werden gepackte Datenelemente in Paaren verarbeitet. Die Daten der höchstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten vorzeichenbehafteten Quelle 801 und 803 werden zum Beispiel unter Verwendung eines Multiplikationsschaltkreises 805 multipliziert und die Daten der nächsthöchstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten vorzeichenbehafteten Quelle 801 und 803 werden unter Verwendung eines Multiplikationsschaltkreises 807 multipliziert. In einigen Ausführungsformen werden diese Multiplikationsschaltkreise 805 und 807 für andere Positionen der gepackten Datenelemente wiederverwendet. In anderen Ausführungsformen werden zusätzliche Multiplikationsschaltkreise verwendet, sodass die gepackten Datenelemente parallel verarbeitet werden. In einigen Kontexten erfolgt eine parallele Ausführung unter Verwendung von Bahnen, die die Größe der dritten vorzeichenbehafteten Quelle (des Anfangswerts oder des Ergebnisses der vorherigen Iteration) 809 haben. Die Ergebnisse jeder der Multiplikationen werden unter Verwendung von Additions-/Sättigungsverschaltung 813 zur vorzeichenbehafteten dritten Quelle 809 addiert.
Die Additions-/Sättigungsverschaltung (Akkumulatorverschaltung) 813 bewahrt ein Vorzeichen eines Operanden, wenn die Addition einen Wert ergibt, der zu groß ist. Insbesondere tritt eine Sättigungsauswertung am Ergebnis mit unendlicher Genauigkeit zwischen der Mehrwegeaddition und dem Schreibvorgang in das Ziel oder der nächsten Iteration ein. Wenn der Akkumulator 813 vom Gleitkommatyp ist und die Eingabeterme ganzzahlig sind, werden die Produktsumme und der Eingabewert in den Gleitkommaakkumulator in Werte mit unendlicher Genauigkeit (Festkommazahlen aus Hunderten von Bits) umgewandelt, die Addition der Multiplikationsergebnisse und der dritten Eingabe wird durchgeführt und eine einzige Rundung auf den tatsächlichen Akkumulatortyp wird durchgeführt.
Eine vorzeichenlose Sättigung bedeutet, dass die Ausgabewerte auf eine vorzeichenlose Maximalzahl für diese Elementbreite (alle 1) beschränkt sind. Eine vorzeichenbehaftete Sättigung bedeutet, dass ein Wert darauf beschränkt wird, dass er im Bereich zwischen einer negativen Minimalzahl und einer positiven Maximalzahl für diese Elementbreite liegt (zum Beispiel reicht der Bereich für Bytes von -128 (= -2^7) bis 127(= 2^7-1)).
Das Ergebnis der Addition und der Sättigungsprüfung wird im vorzeichenbehafteten Ziel 815 in einer gepackten Datenelementposition gespeichert, die der gepackten Datenelementposition entspricht, die aus der vorzeichenbehafteten dritten Quelle 809 verwendet wurde, oder an die nächste Iteration weitergeleitet, falls es eine gibt. In einigen Ausführungsformen wird eine Schreibmaske auf diese Speicherung angewandt, sodass, falls eine entsprechende Schreibmaske (ein entsprechendes Bit) gesetzt ist, eine Speicherung erfolgt, und falls sie (es) nicht gesetzt ist, erfolgt keine Speicherung.
9 illustriert eine Ausführungsform einer Teilmenge der Ausführung einer Iteration einer verketteten Fused-Multiply-Accumulate-Anweisung. Insbesondere veranschaulicht dies eine Ausführungsverschaltung einer Iteration einer gepackten Datenelementposition des Ziels. In dieser Ausführungsform operiert die verkettete Fused-Multiply-Accumulate an einer vorzeichenbehafteten Quelle und an einer vorzeichenlosen Quelle, wobei der Akkumulator die 4-fache Größe der Eingabedaten aufweist.
Eine erste vorzeichenbehaftete Quelle (Quelle 1 901) und eine zweite vorzeichenlose Quelle (Quelle 2 903) weisen jeweils vier gepackte Datenelemente auf. Jedes dieser gepackten Datenelemente weist Daten wie Gleitkomma- oder ganzzahlige Daten auf. Eine dritte vorzeichenbehaftete Quelle (Anfangswert oder Ergebnis 915) weist ein gepacktes Datenelement auf, das vorzeichenbehaftete Daten speichert. Die Größen der ersten und der zweiten Quelle 901 und 903 sind ein Viertel der dritten vorzeichenbehafteten Quelle 915. Die erste und die zweite Quelle 901 und 903 könnten zum Beispiel gepackte 16-Bit-Datenelemente (z. B. ein Wort) aufweisen und die dritte vorzeichenbehaftete Quelle 915 könnte gepackte 64-Bit-Datenelemente (z. B. Gleitkomma mit doppelter Genauigkeit oder ganzzahlige 64-Bit-Zahl) aufweisen.
In dieser Illustration sind die vier höchstwertigen gepackten Datenelementpositionen der ersten und der zweiten Quelle 901 und 903 und die höchstwertige gepackte Datenelementposition der dritten vorzeichenbehafteten Quelle 915 gezeigt. Natürlich würden die anderen gepackten Datenelementpositionen ebenfalls verarbeitet werden, falls es sie gibt.
Wie illustriert werden gepackte Datenelemente in Vierergruppen verarbeitet. Die Daten der höchstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten Quelle 901 und 903 werden zum Beispiel unter Verwendung eines Multiplikationsschaltkreises 905 multipliziert, Daten der nächsthöchstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten Quelle 901 und 903 werden unter Verwendung eines Multiplikationsschaltkreises 907 multipliziert, Daten der dritthöchstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten Quelle 901 und 903 werden unter Verwendung eines Multiplikationsschaltkreises 909 multipliziert und Daten der niedrigstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten Quelle 901 und 903 werden unter Verwendung eines Multiplikationsschaltkreises 911 multipliziert. In einigen Ausführungsformen werden die vorzeichenbehafteten Datenelemente der ersten Quelle 901 vor den Multiplikationen mit einem Vorzeichen erweitert und die vorzeichenlosen gepackten Datenelemente der zweiten Quelle 903 werden mit null erweitert.
In einigen Ausführungsformen werden diese Multiplikationsschaltkreise 905-911 für andere Positionen der gepackten Datenelemente wiederverwendet. In anderen Ausführungsformen werden zusätzliche Multiplikationsschaltkreise verwendet, sodass die gepackten Datenelemente parallel verarbeitet werden. In einigen Kontexten erfolgt eine parallele Ausführung unter Verwendung von Bahnen, die die Größe der dritten vorzeichenbehafteten Quelle 915 haben. Die Ergebnisse jeder der Multiplikationen werden unter Verwendung von Additionsverschaltung 911 addiert.
Das Ergebnis der Addition der Ergebnisse der Multiplikationen wird zu den Daten der höchstwertigen Position der gepackten Datenelemente der vorzeichenbehafteten Quelle 3 915 (unter Verwendung einer anderen Additionseinheit 913 oder der gleichen Additionseinheit 911) addiert.
Schließlich wird das Ergebnis 919 der zweiten Addition entweder im vorzeichenbehafteten Ziel in einer gepackten Datenelementposition gespeichert, die der gepackten Datenelementposition entspricht, die aus der vorzeichenbehafteten dritten Quelle 915 verwendet wurde, oder an die nächste Iteration weitergeleitet. In einigen Ausführungsformen wird eine Schreibmaske auf diese Speicherung angewandt, sodass, falls eine entsprechende Schreibmaske (ein entsprechendes Bit) gesetzt ist, eine Speicherung erfolgt, und falls sie (es) nicht gesetzt ist, erfolgt keine Speicherung.
10 illustriert eine Ausführungsform einer Teilmenge der Ausführung einer Iteration einer verketteten Fused-Multiply-Accumulate-Anweisung. Insbesondere veranschaulicht dies eine Ausführungsverschaltung einer Iteration einer gepackten Datenelementposition des Ziels. In dieser Ausführungsform operiert die verkettete Fused-Multiply-Accumulate an einer vorzeichenbehafteten Quelle und an einer vorzeichenlosen Quelle, wobei der Akkumulator die 4-fache Größe der Eingabedaten aufweist.
Eine erste vorzeichenbehaftete Quelle (Quelle 1 1001) und eine zweite vorzeichenlose Quelle (Quelle 2 1003) weisen jeweils vier gepackte Datenelemente auf. Jedes dieser gepackten Datenelemente speichert Daten wie Gleitkomma- oder ganzzahlige Daten. Eine dritte vorzeichenbehaftete Quelle (Anfangswert oder vorangehendes Ergebnis 1015) weist ein gepacktes Datenelement auf, das vorzeichenbehaftete Daten speichert. Die Größen der ersten und der zweiten Quelle 1001 und 1003 sind ein Viertel der dritten vorzeichenbehafteten Quelle 1015. Die erste und die zweite Quelle 1001 und 1003 könnten zum Beispiel gepackte 16-Bit-Datenelemente (z. B. ein Wort) aufweisen und die dritte vorzeichenbehaftete Quelle 1015 könnte gepackte 64-Bit-Datenelemente (z. B. Gleitkomma mit doppelter Genauigkeit oder ganzzahlige 64-Bit-Zahl) aufweisen.
In dieser Illustration sind die vier höchstwertigen gepackten Datenelementpositionen der ersten und der zweiten Quelle 1001 und 1003 und die höchstwertige gepackte Datenelementposition der dritten vorzeichenbehafteten Quelle 1015 gezeigt. Natürlich würden die anderen gepackten Datenelementpositionen ebenfalls verarbeitet werden, falls es sie gibt.
Wie illustriert werden gepackte Datenelemente in Vierergruppen verarbeitet. Die Daten der höchstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten Quelle 1001 und 1003 werden zum Beispiel unter Verwendung eines Multiplikationsschaltkreises 1005 multipliziert, Daten der nächsthöchstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten Quelle 1001 und 1003 werden unter Verwendung eines Multiplikationsschaltkreises 1007 multipliziert, Daten der dritthöchstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten Quelle 1001 und 1003 werden unter Verwendung eines Multiplikationsschaltkreises 1009 multipliziert und Daten der niedrigstwertigen Positionen der gepackten Datenelemente der ersten und der zweiten Quelle 1001 und 1003 werden unter Verwendung eines Multiplikationsschaltkreises 1011 multipliziert. In einigen Ausführungsformen werden die vorzeichenbehafteten Datenelemente der ersten Quelle 1001 vor den Multiplikationen mit einem Vorzeichen erweitert und die vorzeichenlosen gepackten Datenelemente der zweiten Quelle 1003 werden mit null erweitert.
In einigen Ausführungsformen werden diese Multiplikationsschaltkreise 1005-1011 für andere Positionen der gepackten Datenelemente wiederverwendet. In anderen Ausführungsformen werden zusätzliche Multiplikationsschaltkreise verwendet, sodass die gepackten Datenelemente parallel verarbeitet werden. In einigen Kontexten erfolgt eine parallele Ausführung unter Verwendung von Bahnen, die die Größe der dritten vorzeichenbehafteten Quelle 1015 haben. Das Ergebnis der Addition der Ergebnisse der Multiplikationen wird zu den Daten der höchstwertigen Position der gepackten Datenelemente der vorzeichenbehafteten Quelle 3 1015 unter Verwendung der Additions-/Sättigungsverschaltung 1013 addiert.
Die Additions-/Sättigungsverschaltung (Akkumulatorverschaltung) 1013 bewahrt ein Vorzeichen eines Operanden, wenn die Addition einen Wert ergibt, der für eine vorzeichenbehaftete Sättigung zu groß oder zu klein ist. Insbesondere tritt eine Sättigungsauswertung am Ergebnis mit unendlicher Genauigkeit zwischen der Mehrwegeaddition und dem Schreibvorgang in das Ziel ein. Wenn der Akkumulator 1013 vom Gleitkommatyp ist und die Eingabeterme ganzzahlig sind, werden die Produktsumme und der Eingabewert in den Gleitkommaakkumulator in Werte mit unendlicher Genauigkeit (Festkommazahlen aus Hunderten von Bits) umgewandelt, die Addition der Multiplikationsergebnisse und der dritten Eingabe wird durchgeführt und eine einzige Rundung auf den tatsächlichen Akkumulatortyp wird durchgeführt.
Das Ergebnis 1019 der Addition und der Sättigungsprüfung wird im vorzeichenbehafteten Ziel in einer gepackten Datenelementposition gespeichert, die der gepackten Datenelementposition entspricht, die aus der vorzeichenbehafteten dritten Quelle 1015 verwendet wurde, oder an die nächste Iteration weitergeleitet. In einigen Ausführungsformen wird eine Schreibmaske auf diese Speicherung angewandt, sodass, falls eine entsprechende Schreibmaske (ein entsprechendes Bit) gesetzt ist, eine Speicherung erfolgt, und falls sie (es) nicht gesetzt ist, erfolgt keine Speicherung.
11 illustriert SIMD-Implementierungen mit einer zu einer Zweierpotenz bemessenen Größe nach einer Ausführungsform, wobei die Akkumulatoren Eingabegrößen verwenden, die größer als die Eingaben in die Multiplikatoren sind. Es ist anzumerken, dass die Quelle (für die Multiplikatoren) und die Akkumulatorwerte vorzeichenbehaftete oder vorzeichenlose Werte sein können. Tabelle 1101 veranschaulicht verschiedene Konfigurationen für einen Akkumulator mit 2X-Eingabegrößen (anders ausgedrückt ist der Akkumulatoreingabewert das Doppelte der Größe der Größen der gepackten Datenelemente der Quellen). Für Quellen mit Bytegröße verwendet der Akkumulator Wort- oder Gleitkommawerte mit halber Genauigkeit (HPFP), die eine Größe von 16 Bit aufweisen. Für Quellen mit Wortgröße verwendet der Akkumulator ganzzahlige 32-Bit- oder Gleitkommawerte mit einfacher Genauigkeit (SPFP), die eine Größe von 32 Bit aufweisen. Für Quellen mit SPFP- oder 32-Bit-Ganzzahlgröße verwendet der Akkumulator 64-Ganzzahl- oder Gleitkommawerte mit doppelter Genauigkeit (DPFP), die eine Größe von 64 Bit aufweisen.
Tabelle 1103 veranschaulicht verschiedene Konfigurationen für einen Akkumulator mit 4X-Eingabegrößen (anders ausgedrückt ist der Akkumulatoreingabewert das Vierfache der Größe der Größen der gepackten Datenelemente der Quellen). Für Quellen mit Bytegröße verwendet der Akkumulator ganzzahlige 32-Bit- oder Gleitkommawerte mit einfacher Genauigkeit (SPFP), die eine Größe von 32 Bit aufweisen. Für Quellen mit Wortgröße verwendet der Akkumulator ganzzahlige 64-Bit- oder Gleitkommawerte mit doppelter Genauigkeit (DPFP), die in einigen Ausführungsformen eine Größe von 64 Bit aufweisen.
Tabelle 1105 veranschaulicht eine Konfiguration für einen Akkumulator mit 8X-Eingabegrößen (anders ausgedrückt ist der Akkumulatoreingabewert das Achtfache der Größe der Größen der gepackten Datenelemente der Quellen). Für Quellen mit Bytegröße verwendet der Akkumulator 64-Bit-Ganzzahlen.
Wie oben erwähnt kann eine Matrixoperationsverschaltung in einem Kern oder als ein externer Beschleuniger enthalten sein. 12 illustriert eine Ausführungsform eines Systems, das eine Matrixoperationsverschaltung einsetzt. In dieser Illustration ist eine Vielzahl von Entitäten mit einer Ringverbindung 1245 gekoppelt.
Eine Vielzahl von Kernen 1201, 1203, 1205 und 1207 bietet Unterstützung für nicht auf Kacheln basierende Anweisungen. In einigen Ausführungsformen ist die Matrixoperationsverschaltung 1251 in einem Kern 1203 vorgesehen und in anderen Ausführungsformen kann auf die Matrixoperationsverschaltungen 1211 und 1213 von der Ringverbindung 1245 zugegriffen werden.
Zusätzlich sind ein oder mehrere Arbeitsspeichersteuerungen 1223-1225 vorgesehen, um im Auftrag der Kerne und/oder der Matrixoperationsverschaltung mit den Arbeitsspeichern 1233 und 1231 zu kommunizieren.
13 illustriert eine Ausführungsform einer Prozessorkern-Pipeline, die Matrixoperationen unter Verwendung von Kacheln unterstützt. Eine Verzweigungsvorhersage- und Decodierverschaltung 1303 führt eine Verzweigungsvorhersage von Anweisungen, Decodierung von Anweisungen und/oder beides von im Anweisungsspeicher 1301 gespeicherten Anweisungen durch. Hierin ausführlich besprochene Anweisungen können beispielsweise im Anweisungsspeicher gespeichert sein. In einigen Implementierungen wird eine getrennte Verschaltung für die Verzweigungsvorhersage verwendet und in einigen Ausführungsformen werden zumindest einige Anweisungen in eine oder mehrere Mikrooperationen, Mikrocode-Einstiegspunkte, Mikroanweisungen, andere Anweisungen oder andere Steuersignale unter Verwendung von Mikrocode 1305 verwendet. Die Verzweigungsvorhersage- und Decodierverschaltung 1303 kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Beispiele geeigneter Mechanismen enthalten Nachschlagetabellen, Hardwareimplementierungen, programmierbare Logikarrays (PLAs), schreibgeschützte Mikrocode-Arbeitsspeicher (Mikrocode-ROMs) usw., sind jedoch nicht darauf beschränkt.
Die Verzweigungsvorhersage- und Decodierverschaltung 1303 ist an eine Umbenennungs-/Zuteilungsverschaltung 1307 gekoppelt, die in einigen Ausführungsformen an eine Planungsverschaltung 1309 gekoppelt ist. In einigen Ausführungsformen stellen diese Schaltkreise eine Registerumbenennungs-, Registerzuteilungs- und/oder Planungsfunktionalität durch Durchführen eines oder mehrerer von Folgendem bereit: 1) Umbenennen von Werten logischer Operanden in Werte physischer Operanden (z. B. in einigen Ausführungsformen eine Registeraliastabelle), 2) Zuordnen von Statusbits und -flags zur decodierten Anweisung und 3) Planen der decodierten Anweisung zur Ausführung auf eine Ausführungsverschaltung aus einem Anweisungspool (z. B. in einigen Ausführungsformen unter Verwendung einer Reservierstation).
Die Planungsverschaltung 1309 repräsentiert eine beliebige Anzahl verschiedener Planer, einschließlich Reservierstationen, zentrale Anweisungsfenster usw. Die Planungseinheit(en)-Planungsverschaltung 1309 ist an (eine) physische Registerdatei(en) 1315 gekoppelt oder enthält eine solche. Jede der physischen Registerdatei(en) 1315 repräsentiert eine oder mehrere physische Registerdateien, von denen verschiedene einen oder mehrere verschiedene Datentypen speichern, wie skalare ganze Zahl, skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma, Status (z. B. einen Anweisungszeiger, der die Adresse der nächsten auszuführenden Anweisung ist), Kacheln usw. In einer Ausführungsform umfasst bzw. umfassen die physische(n) Registerdatei(en) 1315 Vektorregisterverschaltung, Schreibmaskenregisterverschaltung und Skalarregisterverschaltung. Diese Registerschaltkreise können architektonische Vektorregister, Vektormaskenregister und Universalregister bereitstellen. Die physische(n) Registerdatei(en) 1315 wird bzw. werden von einem Stilllegungsschaltkreis 1317 überlappt, um verschiedene Arten zu illustrieren, auf die eine Registerumbenennung und Out-of-Order-Ausführung implementiert werden können (z. B. unter Verwendung eines Umordnungspuffers bzw. von Umordnungspuffern und (einer) Stilllegungsregisterdatei(en); unter Verwendung einer bzw. von zukünftigen Datei(en), eines Verlaufspuffers bzw. von Verlaufspuffern und einer Stilllegungsregisterdatei bzw. von Stilllegungsregisterdateien; unter Verwendung einer Registerabbildung und eines Pools von Registern; usw.). Der Stilllegungsschaltkreis 1317 und die physische(n) Registerdatei(en) 1315 sind an den bzw. die Ausführungsschaltkreis(e) 1311 gekoppelt.
Während Registerumbenennen im Kontext einer Out-of-Order-Ausführung beschrieben wird, sollte klar sein, dass das Registerumbenennen in einer In-Order-Architektur verwendet werden kann. Während die illustrierte Ausführungsform des Prozessors auch separate Anweisungs- und Datenzwischenspeichereinheiten und eine gemeinsam genutzte L2-Zwischenspeichereinheit enthalten kann, können alternative Ausführungsformen einen einzigen internen Zwischenspeicher für sowohl Anweisungen als auch Daten aufweisen, wie zum Beispiel einen internen Level-1(L1)-Zwischenspeicher oder mehrere Levels von internem Zwischenspeicher. In manchen Ausführungsformen kann das System eine Kombination eines internen Zwischenspeicher und eines externen Zwischenspeicher enthalten, der extern zum Kern und/oder zum Prozessor ist. Alternativ kann der gesamte Zwischenspeicher extern zum Kern und/oder zum Prozessor sein.
Die Ausführungsverschaltung 1311 einen Satz von einem oder mehreren Ausführungsschaltkreisen 1321, 1323 und 1327 und einen Satz von einem oder mehreren Arbeitsspeicherzugriffsschaltkreisen 1325. Die Ausführungsschaltkreise 1321, 1323 und 1327 führen verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und an verschiedenen Datentypen (z. B. skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma) durch. Während manche Ausführungsformen eine Anzahl von Ausführungseinheiten enthalten können, die spezifischen Funktionen oder Funktionssätzen gewidmet sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten enthalten, die alle alle Funktionen durchführen. Die Skalarverschaltung 1321 führt skalare Operationen durch, die Vektor-/SIMD-Verschaltung 1323 führt Vektor-/SIMD-Operationen durch und die Matrixoperationsverschaltung 1327 führt die hierin ausführlich beschriebenen Matrixoperationen (Kacheloperationen) durch.
Beispielsweise kann die beispielhaften Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungskernarchitektur eine Pipeline folgendermaßen implementieren: 1) ein Anweisungsabrufschaltkreis führt Abruf- und Längendecodierphasen durch; 2) die Verzweigungs- und Decodierverschaltung 1303 führt eine Decodierphase durch; 3) die Umbenennungs-/Zuordnungsverschaltung 1307 führt eine Zuordnungsphase und eine Umbenennungsphase durch; 4) die Zeitplanungsverschaltung 1309 führt eine Zeitplanungsphase durch; 5) eine physische Registerdatei bzw. physische Registerdateien (die an die Planungsverschaltung 1309 und die Umbenennungs-/Zuordnungsverschaltung 1307 gekoppelt ist bzw. sind oder in diesen enthalten ist bzw. sind) und eine Arbeitsspeichereinheit führen eine Registerlese-/Arbeitsspeicherlesephase durch; die Ausführungsverschaltung 1311 führt eine Ausführungsphase durch; 6) eine Speichereinheit und die physische(n) Registerdateieinheit(en) führen eine Zurückschreib-/Speicherschreibphase durch; 7) verschiedene Einheiten können an der Ausnahmebehandlungsphase beteiligt sein; und 8) eine Stilllegungseinheit und die physische(n) Registerdateieinheit(en) führen eine Festschreibphase durch.
Der Kern kann eine oder mehrere Anweisungssätze unterstützen (z. B. den x86-Anweisungssatz (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden); den MIPS-Anweisungssatz von MIPS Technologies in Sunnyvale, CA; den ARM-Anweisungssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings in Sunnyvale, CA), die die hierin beschriebene(n) Anweisung(en) enthalten. In einer Ausführungsform enthält der Kern 1390 Logik, um eine gepackte Datenanweisungssatzerweiterung (z. B. AVX1, AVX2) zu unterstützen, wodurch erlaubt wird, dass die von vielen Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten durchgeführt werden.
Es sollte klar sein, dass der Kern Multithreading (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen kann und dies auf vielfältige Weise tun kann, einschließlich Sliced-Multithreading, simultanes Multithreading (wobei ein einziger physischer Kern jedem der Threads, die der physische Kern simultan nebenläufig ausführt, einen logischen Kern bereitstellt) oder eine Kombination davon (z. B. Zeitscheiben-Abruf und -Decodierung und danach simultanes Multithreading wie in der Intel®-Hyperthreading-Technologie).
14 illustriert eine Ausführungsform einer Prozessorkern-Pipeline, die Matrixoperationen unter Verwendung von Kacheln unterstützt. Eine Verzweigungsvorhersage- und Decodierverschaltung 1403 führt eine Verzweigungsvorhersage von Anweisungen, Decodierung von Anweisungen und/oder beides von im Anweisungsspeicher 1401 gespeicherten Anweisungen durch. Hierin ausführlich besprochene Anweisungen können beispielsweise im Anweisungsspeicher gespeichert sein. In einigen Implementierungen wird eine getrennte Verschaltung für die Verzweigungsvorhersage verwendet und in einigen Ausführungsformen werden zumindest einige Anweisungen in eine oder mehrere Mikrooperationen, Mikrocode-Einstiegspunkte, Mikroanweisungen, andere Anweisungen oder andere Steuersignale unter Verwendung von Mikrocode 1405 verwendet. Die Verzweigungsvorhersage- und Decodierverschaltung 1403 kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Beispiele geeigneter Mechanismen enthalten Nachschlagetabellen, Hardwareimplementierungen, programmierbare Logikarrays (PLAs), schreibgeschützte Mikrocode-Arbeitsspeicher (Mikrocode-ROMs) usw., sind jedoch nicht darauf beschränkt.
Die Verzweigungsvorhersage- und Decodierverschaltung 1403 ist an eine Umbenennungs-/Zuteilungsverschaltung 1407 gekoppelt, die in einigen Ausführungsformen an eine Planungsverschaltung 1409 gekoppelt ist. In einigen Ausführungsformen stellen diese Schaltkreise eine Registerumbenennungs-, Registerzuteilungs- und/oder Planungsfunktionalität durch Durchführen eines oder mehrerer von Folgendem bereit: 1) Umbenennen von Werten logischer Operanden in Werte physischer Operanden (z. B. in einigen Ausführungsformen eine Registeraliastabelle), 2) Zuordnen von Statusbits und - flags zur decodierten Anweisung und 3) Planen der decodierten Anweisung zur Ausführung auf eine Ausführungsverschaltung aus einem Anweisungspool (z. B. in einigen Ausführungsformen unter Verwendung einer Reservierstation).
Die Planungsverschaltung 1409 repräsentiert eine beliebige Anzahl verschiedener Planer, einschließlich Reservierstationen, zentrale Anweisungsfenster usw. Die Planungseinheit(en)-Planungsverschaltung 1409 ist an (eine) physische Registerdatei(en) 1415 gekoppelt oder enthält eine solche. Jede der physischen Registerdatei(en) 1415 repräsentiert eine oder mehrere physische Registerdateien, von denen verschiedene einen oder mehrere verschiedene Datentypen speichern, wie skalare ganze Zahl, skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma, Status (z. B. einen Anweisungszeiger, der die Adresse der nächsten auszuführenden Anweisung ist), Kacheln usw. In einer Ausführungsform umfasst bzw. umfassen die physische(n) Registerdatei(en) 1415 Vektorregisterverschaltung, Schreibmaskenregisterverschaltung und Skalarregisterverschaltung. Diese Registerschaltkreise können architektonische Vektorregister, Vektormaskenregister und Universalregister bereitstellen. Die physische(n) Registerdatei(en) 1415 wird bzw. werden von einem Stilllegungsschaltkreis 1417 überlappt, um verschiedene Arten zu illustrieren, auf die eine Registerumbenennung und Out-of-Order-Ausführung implementiert werden können (z. B. unter Verwendung eines Umordnungspuffers bzw. von Umordnungspuffern und (einer) Stilllegungsregisterdatei(en); unter Verwendung einer bzw. von zukünftigen Datei(en), eines Verlaufspuffers bzw. von Verlaufspuffern und einer Stilllegungsregisterdatei bzw. von Stilllegungsregisterdateien; unter Verwendung einer Registerabbildung und eines Pools von Registern; usw.). Der Stilllegungsschaltkreis 1417 und die physische(n) Registerdatei(en) 1415 sind an den bzw. die Ausführungsschaltkreis(e) 1411 gekoppelt.
Während Registerumbenennen im Kontext einer Out-of-Order-Ausführung beschrieben wird, sollte klar sein, dass das Registerumbenennen in einer In-Order-Architektur verwendet werden kann. Während die illustrierte Ausführungsform des Prozessors auch separate Anweisungs- und Datenzwischenspeichereinheiten und eine gemeinsam genutzte L2-Zwischenspeichereinheit enthalten kann, können alternative Ausführungsformen einen einzigen internen Zwischenspeicher für sowohl Anweisungen als auch Daten aufweisen, wie zum Beispiel einen internen Level-1(L1)-Zwischenspeicher oder mehrere Levels von internem Zwischenspeicher. In manchen Ausführungsformen kann das System eine Kombination eines internen Zwischenspeicher und eines externen Zwischenspeicher enthalten, der extern zum Kern und/oder zum Prozessor ist. Alternativ kann der gesamte Zwischenspeicher extern zum Kern und/oder zum Prozessor sein.
Die Ausführungsverschaltung 1411 einen Satz von einem oder mehreren Ausführungsschaltkreisen 1427 und einen Satz von einem oder mehreren Arbeitsspeicherzugriffsschaltkreisen 1425. Die Ausführungsschaltkreise 1427 führen hierin ausführlich beschriebene Matrixoperationen (Kacheloperationen) durch.
Beispielsweise kann die beispielhaften Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungskernarchitektur eine Pipeline folgendermaßen implementieren: 1) ein Anweisungsabrufschaltkreis führt Abruf- und Längendecodierphasen durch; 2) die Verzweigungs- und Decodierverschaltung 1403 führt eine Decodierphase durch; 3) die Umbenennungs-/Zuordnungsverschaltung 1407 führt eine Zuordnungsphase und eine Umbenennungsphase durch; 4) die Zeitplanungsverschaltung 1409 führt eine Zeitplanungsphase durch; 5) eine physische Registerdatei bzw. physische Registerdateien (die an die Planungsverschaltung 1407 und die Umbenennungs-/Zuordnungsverschaltung '1407 gekoppelt ist bzw. sind oder in diesen enthalten ist bzw. sind) und eine Arbeitsspeichereinheit führen eine Registerlese-/Arbeitsspeicherlesephase durch; die Ausführungsverschaltung 1411 führt eine Ausführungsphase durch; 6) eine Speichereinheit und die physische(n) Registerdateieinheit(en) führen eine Zurückschreib-/Speicherschreibphase durch; 7) verschiedene Einheiten können an der Ausnahmebehandlungsphase beteiligt sein; und 8) eine Stilllegungseinheit und die physische(n) Registerdateieinheit(en) führen eine Festschreibphase durch.
Der Kern kann eine oder mehrere Anweisungssätze unterstützen (z. B. den x86-Anweisungssatz (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden); den MIPS-Anweisungssatz von MIPS Technologies in Sunnyvale, CA; den ARM-Anweisungssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings in Sunnyvale, CA), die die hierin beschriebene(n) Anweisung(en) enthalten. In einer Ausführungsform enthält der Kern 1490 Logik, um eine gepackte Datenanweisungssatzerweiterung (z. B. AVX1, AVX2) zu unterstützen, wodurch erlaubt wird, dass die von vielen Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten durchgeführt werden.
Es sollte klar sein, dass der Kern Multithreading (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen kann und dies auf vielfältige Weise tun kann, einschließlich Sliced-Multithreading, simultanes Multithreading (wobei ein einziger physischer Kern jedem der Threads, die der physische Kern simultan nebenläufig ausführt, einen logischen Kern bereitstellt) oder eine Kombination davon (z. B. Zeitscheiben-Abruf und -Decodierung und danach simultanes Multithreading wie in der Intel®-Hyperthreading-Technologie).
LAYOUT
In dieser gesamten Beschreibung werden Daten unter Verwendung eines zeilenweisen Datenlayouts ausgedrückt. Spaltenweise Nutzer sollten die Begriffe nach ihrer Ausrichtung übersetzen. 15 illustriert ein Beispiel einer Matrix, die in zeilenweisem Format und in spaltenweisem Format ausgedrückt ist. Wie gezeigt ist Matrix A eine 2x3-Matrix. Wenn diese Matrix in einem zeilenweisen Format gespeichert ist, sind die Datenelemente einer Zeile aufeinanderfolgend. Wenn diese Matrix in einem spaltenweisen Format gespeichert ist, sind die Datenelemente einer Spalte aufeinanderfolgend. Matrizen haben eine gut bekannte Eigenschaft, dass A^T * B^T = (BA)^T, wobei die Hochstellung T transponiert bedeutet. Ein Lesen von spaltenweisen Daten als zeilenweise Daten resultiert darin, dass die Matrix wie die transponierte Matrix aussieht.
In einigen Ausführungsformen wird in Hardware eine zeilenweise Semantik verwendet und spaltenweise Daten müssen die Operandenreihenfolge umdrehen, wobei das Ergebnis eine Transponierte der Matrix ist, aber für nachfolgende spaltenweise Lesevorgänge aus dem Arbeitsspeicher ist es die korrekte, nicht transponierte Matrix.
Falls zum Beispiel zwei spaltenweise Matrizen zu multiplizieren sind:

a b g i k ag+bh ai+bj ak+bl

c d * h j l = cg+dh ci+dj ck+dl

e f eg+fh ei+fj ek+fl

(3×2) (2×3) (3×3)
Die Eingabematrizen würden in linearem Arbeitsspeicher (spaltenweise) folgendermaßen gespeichert:

a c e b d f und
g h i j k l.

Wenn diese Matrizen zeilenweise mit Dimensionen 2x3 und 3x2 gelesen werden, würden sie folgendermaßen aussehen:

a c e und g h
b d f i j
k l

Ein Umkehren der Reihenfolge und Matrix-Multiplizieren:

g h a c e ag+bh cg+dh eg+fh

i j * b d f = ai+bj ci+dj ei+fj

k l ak+bl ck+dl ek+fl
Die transponierte Matrix wird ausgegeben und kann dann in zeilenweiser Reihenfolge gespeichert werden: ag+bh cg+dh eg+fh ai+bj ci+dj ei+fj ak+bl ck+dl ek+fl und wenn sie in nachfolgenden spaltenweisen Berechnungen verwendet wird, ist sie die korrekte, nicht transponierte Matrix:

ag+bh ai+bj ak+bl

cg+dh ci+dj ck+dl

eg+fh ei+fj ek+fl
III. BEISPIELHAFTE VERWENDUNG
16 illustriert ein Beispiel einer Verwendung von Matrizen (Kacheln). In diesem Beispiel enthält Matrix C 1601 zwei Kacheln, Matrix A 1603 enthält eine Kachel und Matrix B 1605 enthält zwei Kacheln. Diese Figur zeigt ein Beispiel der inneren Schleife eines Algorithmus, um eine Matrixmultiplikation zu berechnen. In diesem Beispiel werden zwei Ergebniskacheln, tmm0 und tmm1, aus Matrix C 1601 verwendet, um die Zwischenergebnisse zu sammeln. Eine Kachel aus der A-Matrix 1603 (tmm2) wird zweimal wiederverwendet, da sie mit zwei Kacheln der B-Matrix 1605 multipliziert wird. Zeiger, um eine neue A-Kachel und zwei neue B-Kachel aus den Richtungen zu laden, werden von den Pfeilen angezeigt. Eine äußere Schleife, nicht gezeigt, passt die Zeiger für die C-Kacheln an.
Der beispielhafte Code enthält wie gezeigt die Nutzung einer Kachelkonfigurationsanweisung und wird ausgeführt, um die Kachelnutzung zu konfigurieren, Kacheln zu laden, eine Schleife, um die Kacheln zu verarbeiten, Kacheln im Arbeitsspeicher zu speichern und die Kachelnutzung freizugeben.
17 illustriert ein Beispiel einer Verwendung von Matrizen (Kacheln). Bei 1701 wird die Kachelnutzung konfiguriert. Eine TILECONFIG-Anweisung wird zum Beispiel ausgeführt, um die Kachelnutzung zu konfigurieren, was ein Festlegen einer Anzahl von Zeilen und Spalten pro Kachel enthält. Üblicherweise wird mindestens eine Matrix (Kachel) bei 1703 aus dem Arbeitsspeicher geladen. Mindestens eine Matrixoperation (Kacheloperation) wir unter Verwendung der Matrizen (Kacheln) bei 1705 durchgeführt. Bei 1707 wird mindestens eine Matrix (Kachel) im Arbeitsspeicher gespeichert und ein Kontextwechsel kann bei 1709 eintreten.
IV. Beispielhafte Konfiguration
A. Kachelkonfigurations-Hardwareunterstützung
Wie oben besprochen, muss die Kachelnutzung üblicherweise vor der Verwendung konfiguriert werden. Eine vollständige Nutzung aller Zeilen und Spalten kann beispielsweise nicht notwendig sein. Ein Konfigurieren dieser Zeilen und Spalten spart in einigen Ausführungsformen nicht nur Energie, die Konfiguration kann auch verwendet werden, um zu ermitteln, ob eine Operation einen Fehler generieren wird. Eine Matrixmultiplikation der Form (NxM)*(L*N) funktioniert zum Beispiel üblicherweise nicht, wenn M und L nicht gleich sind.
Vor der Verwendung von Matrizen unter Verwendung von Kacheln muss in einigen Ausführungsformen eine Kachelunterstützung konfiguriert werden. Es wird zum Beispiel konfiguriert, wie viele Zeilen und Spalten pro Kachel zu verwenden sind, die Kacheln, die zu verwenden sind, usw. Eine TILECONFIG-Anweisung ist eine Verbesserung an einem Computer selbst, da sie eine Unterstützung bietet, um den Computer zu konfigurieren, einen Matrixbeschleuniger zu verwenden (entweder als Teil eines Prozessorkerns oder als eine externe Vorrichtung). Insbesondere bewirkt eine Ausführung der TILECONFIG-Anweisung, dass eine Konfiguration aus dem Arbeitsspeicher abgerufen wird und auf Matrixeinstellungen (Kacheleinstellungen) innerhalb eines Matrixbeschleunigers angewandt wird.
i. Konfiguration der Kachelnutzung
18 illustriert eine Unterstützung zur Konfiguration der Verwendung von Kacheln nach einer Ausführungsform. Ein Arbeitsspeicher 1801 beinhaltet die Beschreibung der Matrizen (Kacheln), die zu unterstützen sind 1803.
Die Ausführungsverschaltung 1811 eines Prozessors/Kerns 1805 speichert Gesichtspunkte einer Kachelbeschreibung 1803 in Kachelkonfigurationen 1817. Die Kachelkonfigurationen 1817 beschreiben ausführlich, welche Kacheln für eine Palette konfiguriert sind (die Anzahl der Zeilen und Spalten in jeder Kachel) und eine Markierung, dass eine Matrixunterstützung verwendet wird. Insbesondere sind Anweisungsausführungsressourcen 1811 konfiguriert, Kacheln wie durch die Kachelkonfiguration 1817 spezifiziert zu verwenden. Die Anweisungsausführungsressourcen können auch ein maschinenspezifisches Register oder ein Konfigurationsregister enthalten, um die Kachelnutzung anzuzeigen. Zusätzliche Werte wie in Verwendung und Anfangswerte sind ebenfalls festgelegt. Die Kachelkonfigurationen 1817 setzen ein oder mehrere Register 1819 ein, um die Kachelnutzung und Konfigurationsinformationen zu speichern.
19 illustriert eine Ausführungsform einer Beschreibung der zu unterstützenden Matrizen (Kacheln). Dies ist die Beschreibung, die nach einer Ausführung einer STTILECFG-Anweisung zu speichern ist. In diesem Beispiel ist jedes Feld ein Byte. In Byte[0] wird eine Paletten-ID 1901 gespeichert. Die Paletten-ID wird verwendet, um eine Palettentabelle 1813 zu indizieren, die pro Paletten-ID eine Anzahl von Bytes in einer Kachel und Bytes pro Zeile der Kacheln speichert, die mit dieser ID assoziiert sind, wie durch die Konfiguration definiert.
Byte 1 speichert einen in einem „startRow“-Register 1903 zu speichernden Wert und Byte 2 speichert einen in einem „startP“-Register 1905 zu speichernden Wert. Um Neustartanweisungen nach diesen Ereignissen zu unterstützen, speichern die Anweisungen Informationen in den diesen Registern. Um Neustartanweisungen nach Unterbrechungsereignissen zu unterstützen, wie die oben ausführlich besprochenen, speichern die Anweisungen Informationen in diesen Registern. Der startRow-Wert zeigt die Zeile an, die für den Neustart verwendet werden soll. Der startP-Wert zeigt die Position innerhalb der Zeile für Speicheroperationen an, wenn Paare verwendet werden, und zeigt in einigen Ausführungsformen die untere Hälfte der Zeile (in der unteren Kachel eines Paars) oder die obere Hälfte der Zeile (in der höheren Kachel eines Paars) an. Im Allgemeinen wird die Position in der Zeile (die Spalte) nicht benötigt.
Mit Ausnahme von TILECONFIG and STTILECFG, setzt ein erfolgreiches Ausführen von Matrixanweisungen (Kachelanweisungen) sowohl startRow als auch StartP auf null.
Jedes Mal, wenn eine unterbrochene Matrixanweisung (Kachelanweisung) nicht neu gestartet wird, ist Software dafür verantwortlich, die startRow- und startP-Werte auf null zu setzen. Nicht maskierte Gleitkommaausnahmehandler können beispielsweise entscheiden, die Operation in Software zu beenden und den Programmzählerwert auf eine andere Anweisung ändern, üblicherweise die nächste Anweisung. In diesem Fall muss der Softwareausnahmehandler die startRow- und startP-Werte in der ihm vom Betriebssystem präsentierten Ausnahme vor Wiederaufnehmen des Programms auf null setzen. Das Betriebssystem lädt danach diese Werte unter Verwendung einer Wiederherstellungsanweisung neu.
Byte 3 speichert einen Hinweis auf Paare (1 b pro Kachel) von Kacheln 1907.
Bytes 16-17 speichern die Anzahl der Zeilen 1913 und Spalten 1915 für Kachel 0, Bytes 18-19 speichern die Anzahl der Zeilen und Spalten für Kachel 1 usw. Anders ausgedrückt gibt jede 2-Byte-Gruppe eine Anzahl von Zeilen und Spalten für eine Kachel an. Falls keine Gruppe von 2 Bytes verwendet wird, um Kachelparameter anzugeben, sollten sie den Wert null aufweisen. Das Angeben von Kachelparametern für mehr Kacheln als die Implementierungsgrenze oder die Palettengrenze ergibt einen Fehler. Nicht konfigurierte Kacheln werden auf einen Anfangszustand mit 0 Zeilen, 0 Spalten gesetzt.
Schließlich endet die Konfiguration im Arbeitsspeicher üblicherweise mit einer Endabgrenzung, wie alle null für mehrere aufeinanderfolgende Bytes.
ii. Beispielhafte Kachel und Kachelkonfigurationsspeicherung
20(A)-(D) illustrieren Beispiele eines Registers bzw. von Registern 1819. 20 (A) illustriert eine Vielzahl von Registern 1819. Wie gezeigt, weist jede Kachel (TMM0 2001 ... TMMN 2003) ein separates Register auf, wobei jedes Register eine Zeilen- und Spaltengröße für diese bestimmte Kachel speichert. StartP und StartRow sind in separaten Registern 2011 und 2013 gespeichert. Ein oder mehrere Statusregister 2015 sind gesetzt (z. B. TILES_CONFIGURED = 1), um anzuzeigen, dass Kacheln zur Verwendung konfiguriert sind.
20(B) illustriert eine Vielzahl von Registern 1819. Wie gezeigt weist jede Kachel separate Register für ihre Zeilen und Spalten auf. Zum Beispiel, TMM0-Zeilenkonfiguration 2021, TMM0-Spaltenkonfiguration 2023, StartP und StartRow sind in separaten Registern 2011 und 2013 gespeichert. Ein oder mehrere Statusregister 2015 sind gesetzt (z. B. TILES_CONFIGURED = 1), um anzuzeigen, dass Kacheln zur Verwendung konfiguriert sind.
20(C) illustriert ein einzelnes Register 1819. Wie gezeigt speichert dieses Register Kachelkonfigurationen (Zeilen und Spalten pro Kachel) 2031, StartP 2011 und StartRow 2013 sind in einem einzigen Register als gepackte Datenregister gespeichert. Ein oder mehrere Statusregister 2015 sind gesetzt (z. B. TILES_CONFIGURED = 1), um anzuzeigen, dass Kacheln zur Verwendung konfiguriert sind.
20(D) illustriert eine Vielzahl von Registern 1819. Wie gezeigt speichert ein einziges Register Kachelkonfigurationen (Zeilen und Spalten pro Kachel) 2031. StartP und StartRow sind in separaten Registern 2011 und 2013 gespeichert. Ein oder mehrere Statusregister 2015 sind gesetzt (z. B. TILES_CONFIGURED = 1), um anzuzeigen, dass Kacheln zur Verwendung konfiguriert sind.
Es werden andere Kombinationen in Erwägung gezogen, wie zum Beispiel ein Kombinieren der Start-Register in ein einziges Register dort, wo sie separat gezeigt sind, usw.
BEISPIELHAFTE AUSFÜHRUNG
21 illustriert eine beispielhafte Ausführung einer TZPAIR-Anweisung. Das TZPAIR-Anweisungsformat enthält Felder für einen Opcode und eine Zielkachelkennung tmm0 zum Identifizieren eines Paars von Kacheln mit M Zeilen, N Spalten und PAIR- und VALID-Parametern, die beide auf TRUE gesetzt sind. Wie gezeigt wird eine decodierte TZPAIR-Anweisung 2102 durch Ausführungsschaltkreise 2104 empfangen, die bei einigen Ausführungsformen ein Gitter von FMAs 2106 verwenden, um in jedes Element der linken und rechten Zielmatrizen bzw. -kacheln 2108 und 2110 eine null zu schreiben. Wie vorher ausführlich besprochen, können die linken und rechten Zielmatrizen (Kacheln) in einer Sammlung von Registern, in Arbeitsspeicherpositionen oder in anderen Speichern gespeichert sein, auf die die Ausführungsverschaltung zugreifen kann.
Wie gezeigt führen die Ausführungsschaltkreise 2104 eine decodierte TZPAIR-Anweisung 2102 aus, um die Elemente der linken Zielmatrix bzw. -kachel 2108 und der rechten Zielmatrix bzw. -kachel 2110 zu nullen.
Außerdem sind die verbleibenden (unkonfigurierten) Spalten und Zeilen gezeigt, die auf null gesetzt werden, was in einigen Ausführungsformen geschieht. In einigen Ausführungsformen ist eine Matrix (Kachel) ausgelegt, nur eine Teilmenge der möglichen Zeilen und Spalten zu verwenden. Eine Matrix (Kachel) kann zum Beispiel bis zu verwendbare 16 Zeilen und Spalten aufweisen, aber nur jeweils 4 verwenden. Die Konfiguration jeder Matrix (Kachel) erfolgt üblicherweise durch die Ausführung einer Konfigurationsanweisung vor einer Matrixnutzung (Kachelnutzung). In diesem Beispiel sind N Kolonnen und M Zeilen möglich.
II. BEISPIELHAFTES ANWEISUNGSFORMAT BZW. BEISPIELHAFTE ANWEISUNGSFORMATE
Eine Ausführungsform eines Formats für eine TZPAIR-Anweisung ist TZPAIR{B/W/D/Q} TMMO. In einigen Ausführungsformen ist TZPAIR{B/W/D/Q} die Opcode-Mnemonik der Anweisung, wobei B/W/D/Q Datenelementgrößen (Byte, Wort, Doppelwort, Quadwort) der zwei Ziele darstellen. In einigen Ausführungsformen ist das TMM2-Feld ein R/M-Wert (wie 2546 der 25A-B), das TMM1-Feld ist REG 2544 der 25A-B, und die Datenelementgröße wird in 2564 der 25A-B gefunden.
In Ausführungsformen enthalten Codierungen der Anweisung einen Arbeitsspeicheradressenoperanden vom Skalen-Index-Basis(SIB)-Typ, das mehrere indizierte Zielpositionen im Arbeitsspeicher indirekt identifiziert (z. B. Feld 2550 der 25A-B). In einer Ausführungsform kann ein Arbeitsspeicheroperand vom SIB-Typ eine Codierung enthalten, die ein Basisadressregister identifiziert. Der Inhalt des Basisadressregisters kann eine Basisadresse im Arbeitsspeicher repräsentieren, aus der die Adressen der bestimmten Zielpositionen im Arbeitsspeicher berechnet werden. Die Basisadresse kann zum Beispiel die Adresse der ersten Position in einem Block möglicher Zielpositionen für eine erweiterte Vektoranweisung sein. In einer Ausführungsform kann ein Arbeitsspeicheroperand vom SIB-Typ eine Codierung enthalten, die ein Indexregister identifiziert. Jedes Element des Indexregisters kann einen Index oder Offsetwert angeben, der verwendet werden kann, um eine Adresse einer jeweiligen Zielposition innerhalb eines Blocks möglicher Zielpositionen aus der Basisadresse zu berechnen. In einer Ausführungsform kann ein Arbeitsspeicheroperand vom SIB-Typ eine Codierung enthalten, die einen Skalierungsfaktor angibt, der beim Berechnen einer jeweiligen Zieladresse auf jeden Indexwert anzuwenden ist. Falls zum Beispiel ein Skalierungsfaktor von vier im Arbeitsspeicheroperanden vom SIB-Typ codiert ist, kann jeder Indexwert, der aus einem Element des Indexregisters erhalten wird, mit vier multipliziert werden und danach zur Basisadresse addiert werden, um eine Zieladresse zu berechnen.
In einer Ausführungsform kann ein Arbeitsspeicheroperand vom SIB-Typ der Form vm32{x, y, z} ein Vektorarray mit Arbeitsspeicheroperanden identifizieren, die unter einer Arbeitsspeicheradressierung vom SIB-Typ spezifiziert sind. In diesem Beispiel ist das Array der Arbeitsspeicheradressen unter Verwendung eines gemeinsamen Basisregisters, eines konstanten Skalierungsfaktors und eines Vektorindexregisters spezifiziert, das individuelle Elemente beinhaltet, von denen jedes ein 32-Bit-Indexwert ist. Das Vektorindexregister kann ein 128-Bit-Register (z. B. XMM) (vm32x), ein 256-Bit-Register (z. B. YMM) (vm32y) oder ein 512-Bit-Register (z. B. ZMM) (vm32z) sein. In einer anderen Ausführungsform kann ein Arbeitsspeicheroperand vom SIB-Typ der Form vm64{x, y, z} ein Vektorarray mit Arbeitsspeicheroperanden identifizieren, die unter einer Arbeitsspeicheradressierung vom SIB-Typ spezifiziert sind. In diesem Beispiel ist das Array der Arbeitsspeicheradressen unter Verwendung eines gemeinsamen Basisregisters, eines konstanten Skalierungsfaktors und eines Vektorindexregisters spezifiziert, das individuelle Elemente beinhaltet, von denen jedes ein 64-Bit-Indexwert ist. Das Vektorindexregister kann ein 128-Bit-Register (z. B. XMM) (vm64x), ein 256-Bit-Register (z. B. YMM) (vm64y) oder ein 512-Bit-Register (z. B. ZMM) (vm64z) sein.
III. BEISPIELHAFTE(S) AUSFÜHRUNGSVERFAHREN
22 illustriert eine Ausführungsform eines Verfahrens, das durch einen Prozessor durchgeführt wird, um eine TZPAIR-Anweisung zu verarbeiten.
Bei 2201 wird eine Anweisung abgerufen. Eine TZPAIR-Anweisung wird zum Beispiel abgerufen, die Felder für einen Opcode und einen Zielmatrixoperand (Kacheloperand) mit einem PAIR-Parameter gleich TRUE hat. In einigen Ausführungsformen wird die Anweisung aus einem Anweisungszwischenspeicher abgerufen. Der Opcode der TZPAIR-Anweisung gibt eine Nullung von gepackten Datenelementpositionen linker und rechter Matrizen (Kacheln) der identifizierten Zielmatrix bzw. -kachel an. In einigen Ausführungsformen enthält der Opcode der TZPAIR-Anweisung ein Suffix wie „B“, „W“, „D“ oder „Q“ zum Spezifizieren einer Größe jedes der Kachelelemente als ein Byte, ein Wort, ein Doppelwort bzw. ein Quadwort.
Die abgerufene Anweisung wird bei 2203 decodiert. Die abgerufene TZPAIR-Anweisung wird zum Beispiel durch eine Decodierverschaltung wie die hierin beschriebene decodiert.
Eine Ausführung der decodierten Anweisung ist bei 2205 (bei Bedarf) geplant.
Bei 2207 wird die decodierte TZPAIR-Anweisung durch eine Ausführungsverschaltung (Hardware) wie die hierin beschriebene ausgeführt. Für die TZPAIR-Anweisung bewirkt die Ausführung, dass die Ausführungsverschaltung die Elemente der linken und rechten Matrizen (Kacheln) der identifizierten Zielmatrix (Kachel) auf null setzt. In einigen Ausführungsformen werden unkonfigurierte Elemente von Zeilen der Zielmatrix (Kachel) auch auf null gesetzt.
In einigen Ausführungsformen wird die Anweisung bei 2209 festgeschrieben oder stillgelegt.
23 illustriert eine ausführlichere Beschreibung einer Ausführung einer TZPAIR-Anweisung. Üblicherweise wird dies durch eine Ausführungsverschaltung wie die oben beschriebene durchgeführt.
Bei 2302 erfolgt eine Ermittlung, ob ALLES von Folgendem wahr ist: 1) gibt es mindestens eine konfigurierte Matrix (Kachel)? 2) ist bei der identifizierten Zielmatrix bzw. -kachel ein VALID-Parameter auf TRUE gesetzt? und 3) ist bei der identifizierten Zielmatrix bzw. -kachel ein PAIR-Parameter auf TRUE gesetzt? Wenn irgendetwas davon nicht wahr ist, wird bei 2304 ein Fehler erzeugt.
Wenn alle bei 2302 geprüften Bedingungen wahr sind, gehen die Ausführungsschaltkreise bei 2306 in einer Schleife über jede Zeile M einer linken Matrix (Kachel) und einer rechten Matrix (Kachel) der identifizierten Zielmatrix bzw. -kachel, beginnend mit der ersten Zeile. Für jede Zeile führen die Ausführungsschaltkreise eine innere Schleife bei 2308 aus, die in einer Schleife über jede Spalte N der linken Matrix (Kachel) und der rechten Matrix (Kachel) der identifizierten Zielmatrix bzw. -kachel geht, beginnend mit der ersten Spalte. Für jedes der Elemente der inneren Schleife bestimmen die Ausführungsschaltkreise bei 2310, wie viele Byte in jedem Element der Zielmatrizen bzw. -kacheln enthalten sind. Zum Beispiel kann die TZPAIR-Anweisung einen Operanden, ein Opcode-Präfix oder ein Opcode-Suffix von „B“, „W“, „D“ oder „Q“ enthalten, um Elementgrößen von 1 Byte, 2 Byte, 4 Byte bzw. 8 Byte zu spezifizieren. Wenn die linken Matrix- bzw. Kachelelemente und rechten Matrix- bzw. Kachelelemente der identifizierten Zielmatrix bzw. -kachel 1 Byte enthalten, setzen die Ausführungsschaltkreise bei 2312 jedes Element mit Bytegröße auf null. Wenn die linken Matrix- bzw. Kachelelemente und rechten Matrix- bzw. Kachelelemente der identifizierten Zielmatrix bzw. -kachel 2 Byte enthalten, setzen die Ausführungsschaltkreise bei 2314 jedes Element mit Wortgröße auf null. Wenn die linken Matrix- bzw. Kachelelemente und rechten Matrix- bzw. Kachelelemente der identifizierten Zielmatrix bzw. -kachel 4 Byte enthalten, setzen die Ausführungsschaltkreise bei 2316 jedes Element mit Doppelwortgröße auf null. Wenn die linken Matrix- bzw. Kachelelemente und rechten Matrix- bzw. Kachelelemente der identifizierten Zielmatrix bzw. -kachel 8 Byte enthalten, setzen die Ausführungsschaltkreise bei 2318 jedes Element mit Quadwortgröße auf null.
Nach dem Setzen von Elementen der linken Matrix bzw. Kachel und der rechten Matrix bzw. Kachel der identifizierten Zielmatrix bzw. -kachel bei 2312, 2314, 2316 oder 2318 inkrementieren die Ausführungsschaltkreise bei 2320 N und bestimmen, ob irgendwelche Spalten in der inneren Schleife verbleiben, und wenn dem so ist, machen sie mit 2308 weiter, um die nächste Iteration der inneren Schleife durchzuführen. Wenn aber die Bestimmung bei 2320 angibt, dass keine Spalten verbleiben, inkrementieren die Ausführungsschaltkreise bei 2322 M und bestimmen, ob irgendwelche Zeilen in der äußeren Schleife verbleiben und, wenn dem so ist, machen sie mit 2306 weiter, um die nächste Iteration der äußeren Schleife durchzuführen. Wenn aber die Bestimmung bei 2322 angibt, dass keine Zeilen verbleiben, endet der Prozess.
IV. BEISPIELHAFTER PSEUDOCODE
24 ist beispielhafter Pseudocode, der eine Ausführungsform eines Verfahrens beschreibt, das durch einen Prozessor durchgeführt wird, um eine TZPAIR-Anweisung zu verarbeiten. Wie in Pseudocode 2402 gezeigt, enthält die TZPAIR-Anweisung einen Opcode, TZPAIR, und eine Zielmatrixkennung (Kachelkennung), um eine konfigurierte Matrix (Kachel) mit auf TRUE gesetzten VALID- und PAIR-Parametern zu identifizieren. Das im Opcode enthaltene Suffix „B“ zeigt an, dass die Zielmatrix (Kachel) eine linke Matrix (Kachel), tmm1.left, und eine rechte Matrix (Kachel) tmm1.right, mit Elementen mit Bytegröße beinhaltet. Wie gezeigt bewirkt der Pseudocode 2402 zuerst, dass die Ausführungsverschaltung einen Fehler generiert, falls eine von drei Fehlerprüfungen fehlschlägt. Dann bewirkt der Pseudocode, dass der Prozessor in einer Schleife über jede Zeile j und jede Spalte k der linken und rechten Matrizen bzw. Kacheln tmm1.left und tmm1.right geht. An jedem Element setzt der Prozessor das Element bei tmm1.left[j] [k] und tmm1.right [j] [k] auf null.
Der Pseudocode 2404 operiert ähnlich wie der Pseudocode 2402, verarbeitet aber eine Anweisung mit einem Opcode mit einem „W“-Suffix, wodurch angegeben wird, dass die Elemente der linken und rechten Matrizen bzw. Kacheln tmm1.left und tmm1.right jeweils eine Größe von zwei Byte aufweisen.
Der Pseudocode 2406 operiert ähnlich wie der Pseudocode 2402, verarbeitet aber eine Anweisung mit einem Opcode mit einem „D“-Suffix, wodurch angegeben wird, dass die Elemente der linken und rechten Matrizen bzw. Kacheln tmm1.left und tmm1.right jeweils eine Größe von vier Byte aufweisen.
Der Pseudocode 2408 operiert ähnlich wie der Pseudocode 2402, verarbeitet aber eine Anweisung mit einem Opcode mit einem „Q“-Suffix, wodurch angegeben wird, dass die Elemente der linken und rechten Matrizen bzw. Kacheln tmm1.left und tmm1.right jeweils eine Größe von acht Byte aufweisen. Der Pseudocode 2408 führt das Nullen in einer etwas anderen Reihenfolge als der von Pseudocode 2402 aus, da eine erste Schleife alle Elemente der von linken Matrix bzw. Kachel nullt und eine zweite Schleife alle Elemente der rechten Matrix bzw. Kachel nullt.
WEITERE BEISPIELE
Beispiel 1 stellt einen Prozessor bereit, umfassend: Decodierschaltkreise zum Decodieren einer Matrixpaar-Nullungsanweisung mit Feldern für einen Opcode und einer Kennung zum Identifizieren einer Zielmatrix mit einem PAIR-Parameter gleich TRUE; und Ausführungsschaltkreise zum Ausführen der decodierten Matrixpaar-Nullungsanweisung zum Nullen jedes Elements einer linken Matrix und einer rechten Matrix der identifizierten Zielmatrix.
Beispiel 2 umfasst das Wesentliche des beispielhaften Prozessors nach Beispiel 1, wobei der Opcode eine Größe jedes Datenelements der linken und rechten Matrizen definiert.
Beispiel 3 umfasst das Wesentliche des beispielhaften Prozessors nach Beispiel 2, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Doppelwort ist.
Beispiel 4 umfasst das Wesentliche des beispielhaften Prozessors nach Beispiel 2, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Wort ist.
Beispiel 5 umfasst das Wesentliche des beispielhaften Prozessors nach einem der Beispiele 1-4, wobei die Ausführungsschaltkreise ferner alle Datenelemente in verbleibenden Spalten der linken und rechten Matrizen und unkonfigurierte Zeilen der linken und rechten Matrizen nullen.
Beispiel 6 umfasst das Wesentliche des beispielhaften Prozessors nach einem der Beispiele 1-4, wobei die linken und rechten Matrizen jeweils mehrere Register zum Repräsentieren einer Matrix sind.
Beispiel 7 umfasst das Wesentliche des beispielhaften Prozessors nach einem der Beispiele 1-4, wobei die Ausführungsschaltkreise bei einer Bestimmung von mindestens einer der folgenden Bedingungen einen Fehler generieren: eine Anzahl konfigurierter Kacheln ist gleich null, der PAIR-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt und ein VALID-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt.
Beispiel 8 stellt ein Verfahren bereit, umfassend: Decodieren einer Matrixpaar-Nullungsanweisung mit Feldern für einen Opcode und einer Zielmatrixkennung zum Identifizieren einer Zielmatrix mit einem PAIR-Parameter gleich TRUE; und Ausführen der decodierten Matrixpaar-Nullungsanweisung zum Nullen jedes Elements einer linken Matrix und einer rechten Matrix der identifizierten Zielmatrix.
Beispiel 9 umfasst das Wesentliche des beispielhaften Verfahrens nach Beispiel 8, wobei der Opcode eine Größe jedes Datenelements der linken und rechten Matrizen definiert.
Beispiel 10 umfasst das Wesentliche des beispielhaften Verfahrens nach Beispiel 9, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Doppelwort ist.
Beispiel 11 umfasst das Wesentliche des beispielhaften Verfahrens nach Beispiel 9, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Wort ist.
Beispiel 12 umfasst das Wesentliche des beispielhaften Verfahrens nach einem der Beispiele 8-11, ferner umfassend: Nullen aller Datenelemente in verbleibenden Spalten der linken und rechten Matrizen und unkonfigurierten Zeilen der linken und rechten Matrizen.
Beispiel 13 umfasst das Wesentliche des beispielhaften Verfahrens nach einem der Beispiele 8-11, wobei die linken und rechten Matrizen jeweils mehrere Register zum Repräsentieren einer Matrix sind.
Beispiel 14 umfasst das Wesentliche des beispielhaften Verfahrens nach einem der Beispiele 8-11, ferner umfassend: Generieren eines Fehlers bei einer Bestimmung von mindestens einer der folgenden Bedingungen: eine Anzahl konfigurierter Kacheln ist gleich null, der PAIR-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt und ein VALID-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt.
Beispiel 15 stellt ein nichtflüchtiges maschinenlesbares Medium bereit, das eine Matrixpaar-Nullungsanweisung speichert, die bewirkt, dass ein Prozessor die Anweisung ausführt durch: Decodieren der Matrixpaar-Nullungsanweisung mit Feldern für einen Opcode und einer Zielmatrixkennung zum Identifizieren einer Zielmatrix mit einem PAIR-Parameter gleich TRUE; und Ausführen der decodierten Matrixpaar-Nullungsanweisung zum Nullen jedes Elements einer linken Matrix und einer rechten Matrix der identifizierten. Zielmatrix.
Beispiel 16 umfasst das Wesentliche des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von Beispiel 15, wobei der Opcode eine Größe jedes Datenelements der linken und rechten Matrizen definiert.
Beispiel 17 umfasst das Wesentliche des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von Beispiel 15, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Doppelwort ist.
Beispiel 18 umfasst das Wesentliche des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von Beispiel 15, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Wort ist.
Beispiel 19 umfasst das Wesentliche des beispielhaften nichtflüchtigen maschinenlesbaren Mediums nach einem der Beispiele 15-18, ferner umfassend: Nullen aller Datenelemente in verbleibenden Spalten der linken und rechten Matrizen und unkonfigurierten Zeilen der linken und rechten Matrizen.
Beispiel 20 umfasst das Wesentliche des beispielhaften nichtflüchtigen maschinenlesbaren Mediums nach einem der Beispiele 15-18, wobei die linken und rechten Matrizen jeweils mehrere Register zum Repräsentieren einer Matrix sind.
Beispiel 21 umfasst das Wesentliche des beispielhaften nichtflüchtigen maschinenlesbaren Mediums nach einem der Beispiele 15-18, ferner umfassend: Generieren eines Fehlers bei einer Bestimmung von mindestens einer der folgenden Bedingungen: eine Anzahl konfigurierter Kacheln ist gleich null, der PAIR-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt und ein VALID-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt.
Beispiel 22 stellt ein System bereit, umfassend: einen Prozessor, und einen mit dem Prozessor gekoppelten Beschleuniger, wobei der Beschleuniger Folgendes umfasst: Decodierschaltkreise zum Decodieren einer Matrixpaar-Nullungsanweisung mit Feldern für einen Opcode und einer Zielmatrixkennung zum Identifizieren einer Zielmatrix mit einem PAIR-Parameter gleich TRUE; und Ausführungsschaltkreise zum Ausführen der decodierten Matrixpaar-Nullungsanweisung zum Nullen jedes Elements einer linken Matrix und einer rechten Matrix der identifizierten Zielmatrix.
Beispiel 23 umfasst das Wesentliche des beispielhaften Systems von Beispiel 22, wobei der Opcode eine Größe jedes Datenelements der linken und rechten Matrizen definiert.
Beispiel 24 umfasst das Wesentliche des beispielhaften Systems nach einem der Beispiele 22-23, wobei die Ausführungsschaltkreise ferner alle Datenelemente in verbleibenden Elementen der linken und rechten Matrizen und unkonfigurierte Zeilen der linken und rechten Matrizen nullen.
Beispiel 25 umfasst das Wesentliche des beispielhaften Systems nach einem der Beispiele 22-23, wobei die linken und rechten Matrizen jeweils mehrere Register zum Repräsentieren einer Matrix sind.
DETAILLIERTE BEISPIELHAFTE SYSTEME, PROZESSOREN UND EMULATION
Hierin sind Beispiele für Hardware, Software usw. aufgeführt, um die oben beschriebenen Anweisungen auszuführen. Was nachstehend beschrieben wird, beschreibt zum Beispiel Einzelheiten der Befehlsausführung, einschließlich verschiedener Pipelinestufen wie Abrufen, Decodieren, Planen, Ausführen, Stilllegen usw.
Anweisungssätze
Ein Anweisungssatz kann eine oder mehrere Anweisungsformate enthalten. Ein bestimmtes Anweisungsformat kann verschiedene Felder (z. B. Anzahl von Bits, Lage von Bits) definieren, um unter anderem die durchzuführende Operation (z. B. Opcode) und den bzw. die Operand(en), auf den bzw. die diese Operation durchzuführen ist, und/oder ein anderes Datenfeld bzw. andere Datenfelder (z. B. eine Maske) zu spezifizieren. Manche Anweisungsformate sind ferner durch die Definition von Anweisungsvorlagen (oder Teilformaten) aufgegliedert. Zum Beispiel können die Anweisungsvorlagen eines bestimmten Anweisungsformats definiert sein, verschiedene Teilsätze der Felder des Anweisungsformats aufzuweisen (die enthaltenen Felder sind üblicherweise in der gleichen Reihenfolge, aber zumindest einige weisen verschiedene Bitpositionen auf, da weniger Felder enthalten sind), und/oder definiert sein, ein bestimmtes Feld unterschiedlich interpretiert aufzuweisen. Deshalb wird jede Anweisung einer ISA unter Verwendung eines bestimmten Anweisungsformats ausgedrückt (und, falls definiert, in einer bestimmten der Anweisungsvorlagen dieses Anweisungsformats) und enthält Felder zum Spezifizieren der Operation und der Operanden. Zum Beispiel weist eine beispielhafte ADD-Anweisung einen bestimmten Opcode und ein Anweisungsformat auf, das ein Opcode-Feld, um diesen Opcode zu spezifizieren, und Operanden-Felder enthält, um Operanden auszuwählen (Quelle 1/Ziel und Quelle 2); und ein Auftreten dieser ADD-Anweisung in einem Anweisungsstrom wird spezifische Inhalte in den Operanden-Feldern aufweisen, die spezifische Operanden auswählen. Ein Satz von SIMD-Erweiterungen, die als Advanced Vector Extensions (AVX) (AVX1 und AVX2) bezeichnet werden und die das Vector-Extensions(VEX)-Codierschema verwenden, wurde freigegeben und/oder veröffentlicht (siehe z. B. Handbuch für Software-Entwickler zur Intel®-64- und IA-32-Architektur, September 2014; und siehe Programmierreferenz für Advanced Vector Extensions für die Intel®-Architektur, Oktober 2014).
Beispielhafte Anweisungsformate
Ausführungsformen der hierin beschriebenen Anweisung(en) können in verschiedenen Formaten ausgeführt werden. Zusätzlich werden unten beispielhafte Systeme, Architekturen und Pipelines ausführlich besprochen. Ausführungsformen der Anweisung(en) können auf derartigen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf die besprochenen beschränkt.
Generisches vektorfreundliches Anweisungsformat
Ein vektorfreundliches Anweisungsformat ist ein Anweisungsformat, das für Vektoranweisungen geeignet ist (z. B. gibt es bestimmte, für Vektoroperationen spezifische Felder). Während Ausführungsformen werden beschrieben, in denen sowohl Vektor- als auch Skalaroperationen durch das vektorfreundliche Anweisungsformat unterstützt sind, alternative Ausführungsformen setzen nur für Vektoroperationen das vektorfreundliche Anweisungsformat ein.
25A-25B sind Blockdiagramme, die ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen davon nach Ausführungsformen der Erfindung illustrieren. 25A ist ein Blockdiagramm, das ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen der Klasse A davon nach Ausführungsformen der Erfindung illustriert; während 25B ein Blockdiagramm ist, das das generische vektorfreundliche Anweisungsformat und Anweisungsvorlagen der Klasse B davon nach Ausführungsformen der Erfindung illustriert. Genauer ein generisches vektorfreundliches Anweisungsformat 2500, für das Anweisungsvorlagen der Klasse A und der Klasse B definiert sind, von denen beide Anweisungsvorlagen ohne Arbeitsspeicherzugriff 2505 und Anweisungsvorlagen mit Arbeitsspeicherzugriff 2520 enthalten. Der Begriff generisch bezeichnet im Kontext des vektorfreundlichen Anweisungsformats darauf, dass das Anweisungsformat nicht an einen bestimmten Anweisungssatz geknüpft ist.
Während Ausführungsformen der Erfindung beschrieben werden, in denen das vektorfreundliche Anweisungsformat Folgendes unterstützt: eine Vektoroperandenlänge (oder -größe) von 64 Bytes mit 32-Bit- (4-Byte-) oder 64-Bit- (8-Byte-)Datenelementbreiten (oder -größen) (und deshalb besteht ein 64-Byte-Vektor aus entweder 16 doppelwortgroßen Elementen oder alternativ 8 quadwortgroßen Elementen); eine Vektoroperandenlänge (oder -größe) von 64 Bytes mit 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-)Datenelementbreiten (oder -größen); eine Vektoroperandenlänge (oder -größe) von 32 Bytes mit 32-Bit- (4-Byte-), 64-Bit- (8-Byte-), 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-)Datenelementbreiten (oder - großen); und eine Vektoroperandenlänge (oder -größe) von 16 Bytes mit 32-Bit- (4-Byte-), 64-Bit- (8-Byte-), 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-)Datenelementbreiten (oder -größen); können alternative Ausführungsformen mehr, weniger und/oder unterschiedliche Vektoroperandengrößen (z. B. 256-Byte-Vektoroperanden) mit mehr, weniger oder unterschiedlichen Datenelementbreiten (z. B. 128-Bit-(16-Byte-)Datenelementbreiten) unterstützen.
Die Anweisungsvorlagen der Klasse A in 25A enthalten: 1) in den Anweisungsvorlagen ohne Arbeitsspeicherzugriff 2505 wird eine Operationsanweisungsvorlage 2510 ohne Arbeitsspeicherzugriff vom vollständigen Rundungssteuerungstyp und eine Operationsanweisungsvorlage 2515 ohne Arbeitsspeicherzugriff vom Datentransformationstyp gezeigt; und 2) in den Anweisungsvorlagen mit Arbeitsspeicherzugriff 2520 wird eine zeitliche Arbeitsspeicherzugriffsanweisungsvorlage 2525 und eine nicht zeitliche Arbeitsspeicherzugriffsanweisungsvorlage 2530 gezeigt. Die Anweisungsvorlagen der Klasse B in 25B enthalten: 1) in den Anweisungsvorlagen ohne Arbeitsspeicherzugriff 2505 wird eine Operationsanweisungsvorlage 2512 ohne Arbeitsspeicherzugriff vom vollständigen Schreibmaskensteuerungs- und teilweisen Rundungssteuerungstyp und eine Operationsanweisungsvorlage 2517 ohne Arbeitsspeicherzugriff vom Schreibmaskensteuerungsvsize-Typ gezeigt; und 2) in den Anweisungsvorlagen mit Arbeitsspeicherzugriff 2520 wird eine Schreibmaskensteuerungsanweisungsvorlage 2527 mit Arbeitsspeicherzugriff gezeigt.
Das generische vektorfreundliche Anweisungsformat 2500 enthält die folgenden Felder, die unten in der in den 25A-25B veranschaulichten Reihenfolge aufgelistet sind.
Format-Feld 2540 - ein bestimmter Wert (ein Anweisungsformatkennungsfeld) in diesem Feld identifiziert das vektorfreundliche Anweisungsformat eindeutig und deshalb Auftreten von Anweisungen im vektorfreundlichen Anweisungsformat in Anweisungsströmen. Als solches ist dieses Feld in dem Sinn optional, dass es nicht für einen Anweisungssatz benötigt wird, der nur das generische vektorfreundliche Anweisungsformat aufweist.
Basisoperationsfeld 2542 - Sein Inhalt unterscheidet verschiedene Basisoperationen.
Registerindexfeld 2544 - Sein Inhalt, direkt oder durch eine Adressengenerierung, gibt die Positionen der Quellen- und Zieloperanden an, in Registern oder im Arbeitsspeicher. Diese enthalten eine ausreichende Anzahl von Bits, um N Register aus einer PxQ-Registerdatei (z. B. 32x512, 16x128, 32x1024, 64x1024) auszuwählen. Während in einer Ausführungsform N bis zu drei Quellen- und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quellen- und Zielregister unterstützen (z. B. können sie bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel fungiert, können sie bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel fungiert, können sie bis zu zwei Quellen und ein Ziel unterstützen).
Modifikationsfeld 2546 - Sein Inhalt unterscheidet Auftreten von Anweisungen im generischen Vektoranweisungsformat, die einen Arbeitsspeicherzugriff angeben, von denen, die dies nicht tun; das heißt zwischen Anweisungsvorlagen ohne Arbeitsspeicherzugriff 2505 und Anweisungsvorlagen mit Arbeitsspeicherzugriff 2520. Arbeitsspeicherzugriffsoperationen lesen und/oder schreiben in die Arbeitsspeicherhierarchie (wobei sie in einigen Fällen die Quellen- und/oder Zieladressen unter Verwendung von Werten in Registern angeben), während Operationen ohne Arbeitsspeicherzugriff dies nicht tun (z. B. sind die Quelle und Ziele Register). Während in einer Ausführungsform dieses Feld auch zwischen drei verschiedenen Wegen zum Durchführen von Arbeitsspeicheradressenberechnungen auswählt, können alternative Ausführungsformen mehr, weniger oder unterschiedliche Wege zum Durchführen von Arbeitsspeicheradressenberechnungen unterstützen.
Operationszusatzfeld 2550 - Sein Inhalt unterscheidet, welche von einer Vielfalt von unterschiedlichen Operationen zusätzlich zur Basisoperation durchzuführen ist. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 2568, ein Alphafeld 2552 und ein Betafeld 2554 aufgeteilt. Das Operationszusatzfeld 2550 ermöglicht, dass gebräuchliche Gruppen von Operationen in einer einzigen Anweisung anstatt 2, 3 oder 4 Anweisungen durchgeführt werden.
Skalierungsfeld 2560 - Sein Inhalt ermöglicht die Skalierung des Inhalts des Indexfelds zur Generierung einer Arbeitsspeicheradresse (z. B. zur Adressengenerierung, die 2^Skalierung * Index + Basis verwendet).
Offsetfeld 2562A - Sein Inhalt wird als Teil der Arbeitsspeicheradressengenerierung verwendet (z. B. zur Adressengenerierung, die 2^Skalierung * Index + Basis + Offset verwendet).
Offsetfaktorfeld 2562B (es ist anzumerken, dass die Nebeneinanderstellung des Offsetfelds 2562A direkt über dem Offsetfaktor 2562B anzeigt, dass das eine oder das andere verwendet wird) - Sein Inhalt wird als Teil der Adressengenerierung verwendet; er gib einen Offsetfaktor an, der mit der Größe eines Arbeitsspeicherzugriffs (N) zu skalieren ist - wobei N die Anzahl der Bytes im Arbeitsspeicherzugriff ist (z. B. für eine Adressengenerierung, die 2^Skalierung * Index + Basis + skalierter Offset verwendet). Redundante Bits niedriger Ordnung werden ignoriert und deshalb wird der Inhalt des Offsetfaktorfelds mit der Gesamtgröße des Arbeitsspeicheroperanden (N), um den endgültigen Offset zu generieren, der zum Berechnen einer effektiven Adresse zu verwenden ist. Der Wert von N wird von der Prozessorhardware zur Laufzeit auf Grundlage des vollständigen Opcode-Felds 2574 (hierin später beschrieben) und das Datenmanipulationsfeld 2554C ermittelt. Das Offsetfeld 2562A und das Offsetfaktorfeld 2562B sind in dem Sinn optional, dass sie für die Anweisungsvorlagen ohne Arbeitsspeicherzugriff 2505 nicht verwendet werden und/oder andere Ausführungsformen nur eines oder keines der beiden implementieren können.
Datenelementbreitenfeld 2564 - Sein Inhalt unterscheidet, welche einer Anzahl von Datenelementbreiten zu verwenden ist (in einigen Ausführungsformen für alle Anweisungen; in anderen Ausführungsformen nur für einige der Anweisungen). Das Feld ist in dem Sinn optional, dass es nicht benötigt wird, falls nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung eines Gesichtspunkts der Opcodes unterstützt werden.
Schreibmaskenfeld 2570 - Sein Inhalt steuert auf einer Basis pro Datenelementposition, ob diese Datenelementposition im Zielvektoroperanden das Ergebnis der Basisoperation und der Zusatzoperation widerspiegelt. Anweisungsvorlagen der Klasse A unterstützen eine Schreimaskenanwendung mit Zusammenführen, während Anweisungsvorlagen der Klasse B sowohl eine Schreimaskenanwendung mit Zusammenführen als auch eine mit Nullsetzen unterstützen. Beim Zusammenführen ermöglichen Vektormasken, dass ein beliebiger Satz von Elementen im Ziel vor Aktualisierungen während der Ausführung einer beliebigen Operation (die durch die Basisoperation und die Zusatzoperation spezifiziert ist) geschützt ist; wobei in einer anderen Ausführungsform der alte Wert jedes Elements des Ziels geschützt wird, wo das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz dazu ermöglichen Vektormasken beim auf null Setzen, dass ein beliebiger Satz von Elementen im Ziel während der Ausführung einer beliebigen Operation (die durch die Basisoperation und die Zusatzoperation spezifiziert ist) auf null gesetzt wird; in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Eine Teilmenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der Operation, die durchgeführt wird, zu steuern (das heißt den Umfang der Elemente, die modifiziert werden, vom ersten bis zum letzten); es ist jedoch nicht notwendig, dass die Elemente, die modifiziert werden, aufeinanderfolgend sind. Deshalb ermöglicht das Schreibmaskenfeld 2570 teilweise Vektoroperationen, einschließlich Lade-, Speicher-, arithmetische, logische Vorgänge usw. Während Ausführungsformen der Erfindung beschrieben werden, in denen der Inhalt des Schreibmaskenfelds 2570 eines von einer Anzahl von Schreibmaskenregistern auswählt, das die zu verwendende Schreibmaske beinhaltet (und deshalb identifiziert der Inhalt des Schreibmaskenfelds 2570 diese durchzuführende Maskierung indirekt), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Schreibmaskenfelds 2570 direkt die durchzuführende Maskierung angibt.
Direktfeld 2572 - Sein Inhalt ermöglicht die Angabe eines Direktoperanden. Dieses Feld ist in dem Sinn optional, dass es in einer Implementierung des generischen vektorfreundlichen Formats nicht vorhanden ist, das keinen Direktoperanden unterstützt, und es in Anweisungen nicht vorhanden ist, die keinen Direktoperanden verwenden.
Klassenfeld 2568 - Sein Inhalt unterscheidet zwischen verschiedenen Anweisungsklassen. Unter Bezugnahme auf die 25A-B wählt der Inhalt dieses Felds zwischen Anweisungen der Klasse A und der Klasse B aus. In den 25A-B werden Vierecke mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein bestimmter Wert in einem Feld vorhanden ist (z. B. Klasse A 2568A bzw. Klasse B 2568B für das Klassenfeld 2568 in den 25A-B).
Anweisungsvorlagen der Klasse A
Im Fall der Anweisungsvorlagen ohne Arbeitsspeicherzugriff 2505 der Klasse A wird das Alpha-Feld 2552 als ein RS-Feld 2552A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Zusatzoperationstypen durchzuführen ist (z. B. sind die Rundung 2552A.1 bzw. die Datentransformation 2552A.2 für die zwei Operationsanweisungsvorlagen vom Rundungstyp ohne Arbeitsspeicherzugriff 2510 bzw. die Operationsanweisungsvorlage vom Datentransformationstyp ohne Arbeitsspeicherzugriff 2515 spezifiziert), während das Beta-Feld 2554 unterscheidet, welche der Operationen des angegebenen Typs durchzuführen ist. In den Anweisungsvorlagen ohne Arbeitsspeicherzugriff 2505 sind das Skalierungsfeld 2560, das Offsetfeld 2562A und das Offsetskalierungsfeld 2562B nicht vorhanden.
Anweisungsvorlagen ohne Arbeitsspeicherzugriff - Operationen vom vollständigen Rundungssteuerungstyp
In der Operationsanweisungsvorlage vom vollständigen Rundungssteuerungstyp ohne Arbeitsspeicherzugriff 2510 wird das Beta-Feld 2554 als ein Rundungssteuerungsfeld 2554A interpretiert, dessen Inhalt(e) eine statische Rundung bereitstellt bzw. bereitstellen. Während das Rundungssteuerungsfeld 2554A in den beschriebenen Ausführungsformen der Erfindung ein Feld zum Unterdrücken aller Gleitkommaausnahmen (SAE) 2556 und ein Rundungsoperationssteuerungsfeld 2558 enthält, können alternative Ausführungsformen beide dieser Konzepte in das gleiche Feld codieren oder nur das eine oder das andere dieser Konzepte/Felder aufweisen (können z. B. nur das Rundungsoperationssteuerungsfeld 2558 aufweisen).
SAE-Feld 2556 - Sein Inhalt unterscheidet, ob die Ausnahmeereignismeldung zu deaktivieren ist oder nicht; wenn der Inhalt des SAE-Felds 2556 anzeigt, das die Unterdrückung aktiviert ist, meldet eine bestimmte Anweisung keine Art von Gleitkommaausnahmeflag und startet keinen Gleitkommaausnahmehandler.
Rundungsoperationssteuerungsfeld 2558 - Sein Inhalt unterscheidet, welche von einer Gruppe von Rundungsoperationen durchzuführen sind (z. B. Aufrunden, Abrunden, auf null Runden und Runden auf die nächste Ganzzahl). Deshalb ermöglicht das Rundungsoperationssteuerungsfeld 2558 das Ändern des Rundungsmodus pro Anweisung. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Angeben von Rundungsmodi enthält, ist der Inhalt des Rundungsoperationssteuerungsfelds 2550 diesem Registerwert übergeordnet.
Anweisungsvorlagen ohne Arbeitsspeicherzugriff - Operationen vom Datentransformationstyp
In der Operationsanweisungsvorlage vom Datentransformationstyp ohne Arbeitsspeicherzugriff 2515 wird das Beta-Feld 2554 als ein Datentransformationsfeld 2554B interpretiert, dessen Inhalt unterscheidet, welche einer Anzahl von Datentransformationen durchzuführen ist (z. B. keine Datentransformation, Swizzeln, Broadcast).
Im Fall einer Anweisungsvorlage mit Arbeitsspeicherzugriff 2520 der Klasse A wird das Alpha-Feld 2552 als ein Entfernungshinweisfeld 2552B interpretiert, dessen Inhalt unterscheidet, welcher der Entfernungshinweise zu verwenden ist (in 25A, wird zeitlich 2552B.1 bzw. nicht zeitlich 2552B.2 für die zeitliche Arbeitsspeicherzugriffs-Anweisungsvorlage 2525 bzw. die nicht zeitliche Arbeitsspeicherzugriffs-Anweisungsvorlage 2530 spezifiziert), während das Beta-Feld 2554 als ein Datenmanipulationsfeld 2554C interpretiert wird, dessen Inhalt unterscheidet, welche einer Anzahl von Datenmanipulationsoperationen (auch als Stammfunktionen bekannt) durchzuführen ist (z. B. keine Manipulation; Broadcast; Aufwärtskonversion einer Quelle; und Abwärtskonversion eines Ziels). Die Anweisungsvorlagen mit Arbeitsspeicherzugriff 2520 enthalten das Skalierungsfeld 2560 und optional das Offsetfeld 2562A oder das Offsetskalierungsfeld 2562B.
Vektorarbeitsspeicheranweisungen führen Vektor-Ladevorgänge aus dem Arbeitsspeicher und Vektor-Speichervorgänge in den Arbeitsspeicher durch, mit Konvertierungsunterstützung. Wie bei normalen Vektoranweisungen transferieren Arbeitsspeicheranweisungen Daten datenelementweise vom/in den Arbeitsspeicher, wobei die Elemente, die tatsächlich transferiert werden, vom Inhalt der Vektormaske bestimmt werden, der als die Schreibmaske ausgewählt wird.
Arbeitsspeicherzugriffs-Anweisungsvorlagen - zeitlich
Zeitliche Daten sind Daten, bei denen es wahrscheinlich ist, dass sie bald genug wiederverwendet werden, sodass ein Zwischenspeichern vorteilhaft ist. Dies ist jedoch ein Hinweis und unterschiedliche Prozessoren können dies auf unterschiedliche Weise implementieren, einschließlich eines vollständigen Ignorierens des Hinweises.
Arbeitsspeicherzugriffs-Anweisungsvorlagen - nicht zeitlich
Nicht zeitliche Daten sind Daten, bei denen es nicht wahrscheinlich ist, dass sie bald genug wiederverwendet werden, um von einem Zwischenspeichern im Level-1-Zwischenspeicher zu profitieren, und ihnen sollte beim Entfernen Priorität gegeben werden. Dies ist jedoch ein Hinweis und unterschiedliche Prozessoren können dies auf unterschiedliche Weise implementieren, einschließlich eines vollständigen Ignorierens des Hinweises.
Anweisungsvorlagen der Klasse B
Im Fall der Anweisungsvorlagen der Klasse B wird das Alpha-Feld 2552 als ein Schreibmaskensteuerungsfeld (Z-Feld) 2552C interpretiert, dessen Inhalt unterscheidet, ob die vom Schreibmaskenfeld 2570 gesteuerte Schreibmaskierung ein Zusammenführen oder ein Nullsetzen sein soll.
Im Fall der Anweisungsvorlagen ohne Arbeitsspeicherzugriff 2505 der Klasse B wird ein Teil des Beta-Felds 2554 als ein RL-Feld 2557A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Zusatzoperationstypen durchzuführen sind (z. B. sind die Rundung 2557A.1 bzw. die Vektorlänge (VSIZE) 2557A.2 für die Operationsanweisungsvorlage 2512 ohne Arbeitsspeicherzugriff vom vollständigen Schreibmaskensteuerungs- und teilweisen Rundungssteuerungstyp bzw. die Operationsanweisungsvorlage 2517 ohne Arbeitsspeicherzugriff vom Schreibmaskensteuerungs-VSIZE-Typ spezifiziert), während der Rest des Beta-Felds 2554 unterscheidet, welche der Operationen des angegebenen Typs durchzuführen ist. In den Anweisungsvorlagen ohne Arbeitsspeicherzugriff 2505 sind das Skalierungsfeld 2560, das Offsetfeld 2562A und das Offsetskalierungsfeld 2562B nicht vorhanden.
In der Operationsanweisungsvorlage vom vollständigen Rundungssteuerungstyp ohne Arbeitsspeicherzugriff 2510 wird der Rest des Beta-Felds 2554 als ein Rundungsoperationsfeld 2559A interpretiert und die Ausnahmeereignismeldung ist deaktiviert (eine bestimmte Anweisung meldet keine Art von Gleitkommaausnahmeflag und startet keinen Gleitkommaausnahmehandler).
Rundungsoperationssteuerungsfeld 2559A - Sein Inhalt unterscheidet wie beim Rundungsoperationssteuerungsfeld 2558, welche von einer Gruppe von Rundungsoperationen durchzuführen sind (z. B. Aufrunden, Abrunden, auf null Runden und Runden auf die nächste Ganzzahl). Deshalb ermöglicht das Rundungsoperationssteuerungsfeld 2559A das Ändern des Rundungsmodus pro Anweisung. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Angeben von Rundungsmodi enthält, ist der Inhalt des Rundungsoperationssteuerungsfelds 2550 diesem Registerwert übergeordnet.
In der Operationsanweisungsvorlage 2517 ohne Arbeitsspeicherzugriff vom Schreibmaskensteuerungs-VSIZE-Typ wird der Rest des Beta-Felds 2554 als ein Vektorlängenfeld 2559B interpretiert, dessen Inhalt unterscheidet, an welcher einer Anzahl von Datenvektorlängen die Operation durchzuführen ist (z. B. 128, 256 oder 512 Bytes).
Im Fall einer Anweisungsvorlage 2520 mit Arbeitsspeicherzugriff der Klasse B wird ein Teil des Beta-Felds 2554 als ein Broadcastfeld 2557B interpretiert, dessen Inhalt unterscheidet, ob die Datenmanipulation vom Broadcasttyp durchzuführen ist oder nicht, während der Rest des Beta-Felds 2554 als das Vektorlängenfeld 2559B interpretiert wird. Die Anweisungsvorlagen mit Arbeitsspeicherzugriff 2520 enthalten das Skalierungsfeld 2560 und optional das Offsetfeld 2562A oder das Offsetskalierungsfeld 2562B.
In Bezug auf das generische vektorfreundliche Anweisungsformat 2500 wird ein vollständiges Opcode-Feld 2574 gezeigt, das das Formatfeld 2540, das Basisoperationsfeld 2542 und das Datenelementbreitenfeld 2564 enthält. Während eine Ausführungsform gezeigt ist, in der das vollständige Opcode-Feld 2574 alle dieser Felder enthält, das vollständige Opcode-Feld 2574 enthält weniger als alle dieser Felder in Ausführungsformen, die nicht alle davon unterstützen. Das vollständige Opcode-Feld 2574 stellt den Operationscode (Opcode) bereit.
Das Operationszusatzfeld 2550, das Datenelementbreitenfeld 2564 und das Schreibmaskenfeld 2570 ermöglichen, dass diese Funktionen im generischen vektorfreundlichen Anweisungsformat pro Anweisung spezifiziert werden.
Die Kombination des Schreibmaskenfelds und des Datenelementbreitenfelds erzeugen dahingehend typisierte Anweisungen, dass sie ermöglichen, dass die Maske auf Grundlage verschiedener Datenelementbreiten angewandt wird.
Die verschiedenen Anweisungsvorlagen, die innerhalb der Klasse A und der Klasse B gefunden werden, sind in verschiedenen Situationen vorteilhaft. In einigen Ausführungsformen der Erfindung können unterschiedliche Prozessoren oder unterschiedliche Kerne innerhalb eines Prozessors nur Klasse A, nur Klasse B oder beide Klassen unterstützen. Ein Hochleistungs-Out-of-Order-Universalkern für Universalrechenzwecke kann zum Beispiel nur Klasse B unterstützen, ein Kern, der hauptsächlich für Grafik und/oder wissenschaftliches (Durchsatz-)Rechnen gedacht ist, kann nur Klasse A unterstützen und ein Kern, der für beides gedacht ist, kann beides unterstützen (natürlich liegt ein Kern, der eine Mischung von Vorlagen und Anweisungen von beiden Klassen, aber nicht alle Vorlagen und Anweisungen von beiden Klassen aufweist, innerhalb des Geltungsbereichs der Erfindung). Ein einzelner Prozessor kann auch mehrere Kerne enthalten, von denen alle die gleiche Klasse unterstützen oder in dem unterschiedliche Kerne unterschiedliche Klassen unterstützen. In einem Prozessor mit separaten Grafik- und Universal kernen kann zum Beispiel einer der Grafikkerne, der hauptsächlich für Grafik- und/oder wissenschaftliches Rechnen gedacht ist, nur Klasse A unterstützen, während einer oder mehrere der Universalkerne Hochleistungsuniversalkerne mit Out-of-Order-Ausführung und Registerumbenennung sein können, die für Universalrechnen gedacht sind und nur Klasse B unterstützen. Ein anderer Prozessor, der keinen separaten Grafikkern aufweist, kann ein oder mehrere Universal-In-Order- oder Out-of-Order-Kerne enthalten, die sowohl Klasse A als auch Klasse B unterstützen. Natürlich können in verschiedene Ausführungsformen der Erfindung Merkmale einer Klasse auch in der anderen Klasse implementiert sein. Programme, die in einer höheren Programmiersprache geschrieben sind, würden in eine Vielfalt von verschiedenen ausführbaren Formen gesetzt werden (z. B. just-in-time-compiliert oder statisch compiliert), einschließlich: 1) einer Form, die nur Anweisungen der Klasse(n) aufweisen, die vom Zielprozessor zur Ausführung unterstützt werden; oder 2) einer Form mit alternativen Routinen, die unter Verwendung verschiedener Kombinationen der Anweisungen aller Klassen geschrieben sind und Ablaufsteuerungscode aufweisen, der die auszuführenden Routinen auf Grundlage der vom Prozessor unterstützten Anweisungen auswählt, der den Code aktuell ausführt.
Beispielhaftes spezifisches vektorfreundliches Anweisungsformat
26A ist ein Blockdiagramm, das ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat nach Ausführungsformen der Erfindung illustriert. 26A zeigt ein spezifisches vektorfreundliches Anweisungsformat 2600, das in dem Sinn spezifisch ist, dass es die Position, Größe, Interpretation und Reihenfolge der Felder sowie Werte für einige dieser Felder angibt. Das spezifische vektorfreundliche Anweisungsformat 2600 kann verwendet werden, um den x86-Anweisungssatz zu erweitern und deshalb sind einige der Felder denen ähnlich oder die gleichen, wie sie im bestehenden x86-Anweisungssatz und Erweiterungen (z. B. AVX) davon verwendet werden. Dieses Format bleibt mit dem Präfixcodierfeld, realen Opcodebytefeld, MOD-R/M-Feld, SIB-Feld, Offsetfeld und unmittelbaren Feldern des bestehenden x86-Anweisungssatzes mit Erweiterungen vereinbar. Die Felder von 25, in die die Felder von 26A abgebildet sind, sind veranschaulicht.
Es sollte klar sein, dass, obwohl Ausführungsformen der Erfindung unter Bezugnahme auf das spezifische vektorfreundliche Anweisungsformat 2600 im Kontext des generischen vektorfreundlichen Anweisungsformats 2500 für veranschaulichende Zwecke beschrieben sind, die Erfindung nicht auf das spezifische vektorfreundliche Anweisungsformat 2600 eingeschränkt ist, ausgenommen dort, wo dies beansprucht wird. Das generische vektorfreundliche Anweisungsformat 2500 erwägt zum Beispiel eine Vielfalt von möglichen Größen für die verschiedenen Felder, während das spezifische vektorfreundliche Anweisungsformat 2600 als Felder mit spezifischen Größen aufweisend gezeigt wird. Als spezifisches Beispiel, während das Datenelement mit Feld 2564 als ein Ein-Bit-Feld im spezifischen vektorfreundlichen Anweisungsformat 2600 veranschaulicht ist, ist die Erfindung nicht derart eingeschränkt (das heißt, das generische vektorfreundliche Anweisungsformat 2500 erwägt andere Größen des Datenelementbreitenfelds 2564).
Das generische vektorfreundliche Anweisungsformat 2500 enthält die folgenden Felder, die unten in der in der 26A veranschaulichten Reihenfolge aufgelistet sind.
EVEX-Präfix (Bytes 0-3) 2602 - ist in einer Vier-Byte-Form codiert.
Formatfeld 2540 (EVEX-Byte 0, Bits [7:0]) - Das erste Byte (EVEX Byte 0) ist das Formatfeld 2540 und es beinhaltet 0x62 (den eindeutigen Wert, der zum Unterscheiden des vektorfreundlichen Anweisungsformats in einer Ausführungsform der Erfindung verwendet wird).
Die Bytes vom zweiten bis zum vierten (EVEX-Bytes 1-3) enthalten eine Anzahl von Bitfeldern, die eine spezifische Fähigkeit bereitstellen.
REX-Feld 2605 (EVEX-Byte 1, Bits [7-5]) - besteht aus einem EVEX.R-Bitfeld (EVEX-Byte 1, Bit [7] - R), EVEX.X-Bitfeld (EVEX-Byte 1, Bit [6] - X) und 2557BEX-Byte 1, Bit[5] - B). Die Bitfelder EVEX.R, EVEX.X und EVEX.B bieten die gleiche Funktionalität wie die entsprechenden VEX-Bitfelder und sind unter Verwendung einer 1er-Komplementform codiert, d. h. ZMM0 ist als 1111B codiert, ZMM15 ist als 0000B codiert. Andere Felder der Anweisungen codieren die unteren drei Bits der Registerindizes, wie auf dem Fachgebiet bekannt ist (rrr, xxx und bbb), sodass Rrrr, Xxxx und Bbbb durch Addieren von EVEX.R, EVEX.X und EVEX.B gebildet werden kann.
REX'-Feld 2510 - Dies ist der erste Teil des REX'-Felds 2510 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4] - R'), das verwendet wird, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Registersatzes zu codieren. In einer Ausführungsform der Erfindung wird dieses Bit zusammen mit anderen wie unten angezeigt in bitinvertiertem Format gespeichert, um es (im gut bekannten x86-32-Bitmodus) von der BOUND-Anweisung zu unterscheiden, deren reales Opcodebyte 62 ist, aber im MOD-R/M-Feld (unten beschrieben) den Wert von 11 im MOD-Feld nicht akzeptiert; alternative Ausführungsformen der Erfindung speichern dieses und die anderen angezeigten Bits unten nicht im invertierten Format. 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 den anderen RRR von anderen Feldern gebildet.
Das Opcode-Abbildungsfeld 2615 (EVEX-Byte 1, Bits [3:0] - mmmm) - Sein Inhalt codiert ein impliziertes führendes Opcode-Byte (0F, 0F 38 oder 0F 3) .
Datenelementbreitenfeld 2564 (EVEX-Byte 2, Bit [7] - W) - wird durch die Notation EVEX.W repräsentiert. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente) zu definieren.
EVEX.vvvv 2620 (EVEX-Byte 2, Bits [6:3]-vvvv)-Die Rolle von EVEX.vvvv kann Folgendes enthalten: 1) EVEX.vvvv codiert den ersten Quellenregisteroperanden, der in invertierter (1er-Komplement-)Form angegeben ist und für Anweisungen mit 2 oder mehr Quellenoperationen gültig ist; 2) EVEX.vvvv codiert den Zielregisteroperanden, der in Form eines 1er-Komplements für bestimmte Vektorverschiebungen angegeben ist; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b beinhalten. Deshalb codiert das EVEX.vvvv-Feld 2620 die 4 Bits des ersten Quellenregisterspezifizierers niedriger Ordnung, die in invertierter (1er-Komplement) Form gespeichert sind. Abhängig von der Anweisung wird ein zusätzliches anderes EVEX-Bit-Feld verwendet, um die Spezifizierergröße auf 32 Register zu erweiter.
Klassenfeld EVEX.U 2568 (EVEX-Byte 2, Bit [2] - U) - Falls EVEX.U = 0, zeigt es Klasse A oder EVEX.U0 an; falls EVEX.U = 1, zeigt es Klasse B oder EVEX.U1 an.
Präfixcodierfeld 2625 (EVEX-Byte 2, Bits [1:0]-pp) - stellt zusätzliche Bits für das Basisoperationsfeld bereit. Zusätzlich zum Bereitstellen von Unterstützung für die Alt-SSE-Anweisungen im EVEX-Präfixformat weist dies auch den Vorteil des Verdichtens des SIMD-Präfix auf (anstatt ein Byte zu benötigen, um das SIMD-Präfix auszudrücken, benötigt das EVEX-Präfix nur 2 Bits). In einer Ausführungsform, um Alt-SSE-Anweisungen zu unterstützen, die ein SIMD-Präfix (66H, F2H, F3H) in sowohl dem Alt-Format als auch im EVEX-Präfix-Format verwenden, sind diese Alt-SIMD-Präfixe im SIMD-PräfixCodierfeld codiert; und werden zur Laufzeit in das Alt-SIMD-Präfix vor Bereitstellung an das PLA des Decodierers erweitert (sodass das PLA sowohl das Altals auch das EVEX-Format dieser Alt-Anweisungen ohne Modifikation ausführen kann). Obwohl neuere Anweisungen den Inhalt des EVEX-Präfix-Codierfelds direkt als eine Opcode-Erweiterung verwenden könnten, erweitern bestimmte Ausführungsformen zur Kontinuität auf eine ähnliche Weise, ermöglichen jedoch, dass unterschiedliche Bedeutungen von diesen Alt-SIMD-Präfixen angegeben werden. Eine alternative Ausführungsform kann das PLA umkonstruieren, sodass es die 2-Bit-SIMD-Präfixcodierungen unterstützt und deshalb die Erweiterung nicht benötigt.
Alpha-Feld 2552 (EVEX-Byte 3, Bit [7] - EH; auch als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.-Schreibmaskensteuerung und EVEX.N bekannt; auch mit α veranschaulicht) - wie vorher beschrieben, ist dieses Feld kontextspezifisch.
Beta-Feld 2554 (EVEX-Byte 3, Bits [6:4]-SSS, auch als EVEX.s_2-0, EVEX.r_2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB bekannt; auch mit βββ veranschaulicht) - wie vorher beschrieben, ist dieses Feld kontextspezifisch.
REX'-Feld 2510 - Dies ist der Rest des REX'-Felds und ist das EVEX.V'-Bitfeld (EVEX-Byte 3, Bit [3] - V'), das verwendet werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Registersatzes zu codieren. Dieses Bit ist in bitinvertiertem Format gespeichert. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Anders ausgedrückt wird V'VVVV durch Kombinieren von EVEX.V', EVEX.vvvv gebildet.
Schreibmaskenfeld 2570 (EVEX-Byte 3, Bits [2:0]-kkk) - Sein Inhalt gibt den Index eines Registers im Schreibmaskenregister wie vorher beschrieben an. In einer Ausführungsform der Erfindung weist der spezifische Wert EVEX.kkk=000 ein besonderes Verhalten auf, der impliziert, dass keine Schreibmaske für die bestimmte Anweisung verwendet wird. (Dies kann auf eine Vielfalt von Arten und Weisen einschließlich der Verwendung einer auf alles eins festverdrahteten Schreibmaske oder Hardware, die die Maskierungshardware umgeht, implementiert werden.)
Das reale Opcode-Feld 2630 (Byte 4) ist auch als das Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld angegeben.
MOD-R/M-Feld 2640 (Byte 5) enthält MOD-Feld 2642, Reg-Feld 2644 und R/M-Feld 2646. Wie bereits beschrieben, unterscheidet der Inhalt des MOD-Felds 2642 zwischen Operationen mit Arbeitsspeicherzugriff und solchen ohne Arbeitsspeicherzugriff. Die Rolle des Reg-Felds 2644 kann in zwei Situationen zusammengefasst werden: Codieren entweder des Zielregisteroperanden oder eines Quellenregisteroperanden oder Behandlung als eine Opcode-Erweiterung und keine Verwendung zum Codieren irgendeines Anweisungsoperanden. Die Rolle des R/M-Felds 2646 kann Folgendes enthalten: Codieren des Anweisungsoperanden, der eine Arbeitsspeicheradresse referenziert, oder Codieren entweder des Zielregisteroperanden oder eines Quellenregisteroperanden.
Skalierung-Index-Basis(SIB)-Byte (Byte 6) - Wie bereits beschrieben wird der Inhalt des Skalierungsfelds 2550 zur Arbeitsspeicheradressengenerierung verwendet. SIB.xxx 2654 und SIB.bbb 2656 - Auf den Inhalt dieser Felder wurde bereits in Bezug auf die Registerindizes Xxxx und Bbbb Bezug genommen.
Offsetfeld 2562A (Bytes 7-10) - Wenn das MOD-Feld 2642 10 beinhaltet, sind die Bytes 7-10 das Offsetfeld 2562A und es funktioniert auf die gleiche Weise wie der Alt-32-Bit-Offset (disp32) und arbeitet auf Byte-Granularitätsebene.
Offsetfaktorfeld 2562B (Byte 7) - Wenn das MOD-Feld 2642 01 beinhaltet, ist Byte 7 das Offsetfaktorfeld 2562B. Die Position dieses Felds ist die gleiche wie die des 8-Bit-Offsets (disp8) des Alt-x86-Anweisungssatzes, der auf Byte-Granularitätsebene arbeitet. Da disp8 mit Vorzeichen erweitert ist, kann es nur Offsets zwischen -128 und 127 Bytes adressieren; in Form von 64-Byte-Zwischenspeicherleitungen verwendet disp8 8 Bits, die auf nur vier tatsächlich nützliche Werte -128, -64, 0 und 64 gesetzt werden können; da ein größerer Bereich oft benötigt wird, wird disp32 verwendet; disp32 benötigt jedoch 4 Bytes. Im Gegensatz zu disp8 und disp32 ist das Offsetfaktorfeld 2562B eine Neuinterpretation von disp8; wenn das Offsetfaktorfeld 2562B verwendet wird, wird der tatsächliche Offset durch den Inhalt des Offsetfaktorfelds multipliziert mit der Größe des Arbeitsspeicheroperandenzugriffs (N) ermittelt. Diese Art von Offset wird als disp8*N bezeichnet. Dies reduziert die mittlere Anweisungslänge (ein einziges Byte wird für den Offset verwendet, aber mit einem viel größeren Bereich). Ein derartiger komprimierter Offset basiert auf der Annahme, dass der effektive Offset ein Mehrfaches der Granularität des Arbeitsspeicherzugriffs ist und daher müssen die redundanten, niederwertigen Bits des Adressenoffsets nicht codiert werden. Anders ausgedrückt substituiert das Offsetfaktorfeld 2562B den 8-Bit-Offset des Alt-x86-Anweisungssatzes. Deshalb ist das Offsetfaktorfeld 2562B auf die gleiche Weise wie ein 8-Bit-Offset eines x86-Anweisungssatzes codiert (deshalb gibt es keine Änderungen in den ModRM/SIB-Codierregeln), mit der einzigen Ausnahme, dass disp8 auf disp8*N überladen ist. Anders ausgedrückt gibt es keine Änderungen bei den Codierregeln oder Codierlängen, sondern nur bei der Interpretation des Offsetwerts durch die Hardware (die den Offset mit der Größe des Arbeitsspeicheroperanden skalieren muss, um einen byteweisen Adressenoffset zu erhalten). Das Direktfeld 2572 arbeitet wie vorher beschrieben.
Vollständiges Opcode-Feld
26B ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 2600 illustriert, die das vollständige Opcode-Feld 2574 nach einer Ausführungsform der Erfindung bilden. Genauer enthält das vollständige Opcode-Feld 2574 das Formatfeld 2540, das Basisoperationsfeld 2542 und das Datenelementbreiten(W)-Feld 2564. Das Basisoperationsfeld 2542 enthält das Präfixcodierfeld 2625, das Opcodeabbildungsfeld 2615 und das reale Opcodefeld 2630.
Registerindexfeld
26C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 2600 illustriert, die das Registerindexfeld 2544 nach einer Ausführungsform der Erfindung bilden. Genauer enthält das Registerindexfeld 2544 das REX-Feld 2605, das REX'-Feld 2610, das MODR/M.reg-Feld 2644, das MODR/M.r/m-Feld 2646, das VVVV-Feld 2620, xxx-Feld 2654 und das bbb-Feld 2656.
Operationszusatzfeld
26D ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 2600 illustriert, die das Operationszusatzfeld 2550 nach einer Ausführungsform der Erfindung bilden. Wenn das Klassenfeld (U) 2568 0 beinhaltet, bedeutet es EVEX.U0 (Klasse A 2568A); wenn es 1 beinhaltet, bedeutet es EVEX.U1 (Klasse B 2568B). Wenn U = 0 und das MOD-Feld 2642 beinhaltet 11 (was eine Operation ohne Arbeitsspeicherzugriff bedeutet), wird das Alpha-Feld 2552 (EVEX-Byte 3, Bit [7] - EH) als das rs-Feld 2552A interpretiert. Wenn das rs-Feld 2552A eine 1 beinhaltet (Rundung 2552A.1), wird das Beta-Feld 2554 (EVEX-Byte 3, Bits [6:4]- SSS) als das Rundungssteuerungsfeld 2554A interpretiert. Das Rundungssteuerungsfeld 2554A enthält ein Ein-Bit-SAE-Feld 2556 und ein Zwei-Bit-Rundungsoperationsfeld 2558. Wenn das rs-Feld 2552A eine 0 beinhaltet (Datentransformation 2552A.2), wird das Beta-Feld 2554 (EVEX-Byte 3, Bits [6:4]- SSS) als das ein Drei-Bit-Datentransformationsfeld 2554B interpretiert. Wenn U = 0 und das MOD-Feld 2642 beinhaltet 00, 01 oder 10 (was eine Arbeitsspeicherzugriffsoperation bedeutet), wird das Alpha-Feld 2552 (EVEX-Byte 3, Bit [7] - EH) als das Entfernungshinweis(EH)-Feld 2552B interpretiert und das Beta-Feld 2554 (EVEX-Byte 3, Bits [6:4]- SSS) wird als ein Drei-Bit-Datenmanipulationsfeld 2554C interpretiert.
Wenn U = 1, wird das Alpha-Feld 2552 (EVEX-Byte 3, Bit [7] - EH) als das Schreibmaskensteuerungsfeld (Z) 2552C interpretiert. Wenn U = 1 und das MOD-Feld 2642 beinhaltet 11 (was eine Operation ohne Arbeitsspeicherzugriff bedeutet), wird ein Teil des Beta-Felds 2554 (EVEX-Byte 3, Bit [4] - So) als das RL-Feld 2557A interpretiert; wenn es eine 1 beinhaltet (Rundung 2557A.1), wird der Rest des Beta-Felds 2554 (EVEX-Byte 3, Bits [6-5]- S_2-1) als das Rundungsoperationsfeld 2559A interpretiert, wohingegen, wenn das RL-Feld 2557A eine 0 beinhaltet (VSIZE 2557.A2), wird der Rest des Beta-Felds 2554 (EVEX-Byte 3, Bit [6-5]- S_2-1) als das Vektorlängenfeld 2559B interpretiert (EVEX-Byte 3, Bit [6-5]- L_1-0). Wenn U = 1 und das MOD-Feld 2642 beinhaltet 00, 01 oder 10 (was eine Arbeitsspeicherzugriffsoperation bedeutet), wird das Beta-Feld 2554 (EVEX-Byte 3, Bits [6:4]- SSS) als das Vektorlängenfeld 2559B (EVEX-Byte 3, Bit [6-5]-L_1-0) und das Broadcastfeld 2557B (EVEX-Byte 3, Bit [4]-B) interpretiert.
Beispielhafte Registerarchitektur

27 ist ein Blockdiagramm einer Registerarchitektur 2700 nach einer Ausführungsform der Erfindung ist. In der illustrierten Ausführungsform gibt es 32 Vektorregister 2710, die 512 Bits breit sind; auf diese Register wird mit zmm0 bis zmm31 verwiesen. Die 256 niederwertigen Bits der unteren 16 zmm-Register sind den Registern ymm0-16 überlagert. Die 128 niederwertigen Bits der unteren 16 zmm-Register (die 128 niederwertigen Bits der ymm Register) sind den Registern xmm0-15 überlagert. Das spezifische vektorfreundliche Anweisungsformat 2600 operiert an dieser überlagerten Registerdatei, wie in den Tabellen unten veranschaulicht.

Anpassbare Vektorlänge	Klasse	Operationen	Register
Anweisungsvorlagen, die das Vektorlängenfeld 2559B nicht enthalten	A ( 25A; U=0)	2510, 2515, 2525, 2530	zmm-Register (Die Vektorlänge beträgt 64 Bytes.)
	B ( 25B; U=1)	2512	zmm-Register (Die Vektorlänge beträgt 64 Bytes.)
Anweisungsvorlagen, die das Vektorlängenfeld 2559B enthalten	B ( 25B; U=1)	2517, 2527	zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Bytes, 32 Bytes oder 16 Bytes), abhängig vom Vektorlängenfeld 2559B

Anders ausgedrückt wählt das Vektorlängenfeld 2559B zwischen einer Maximallänge und einer oder mehreren anderen kürzeren Längen aus, wobei jede solche kürzere Länge die halbe Länge der vorangehenden Länge ist; und Anweisungsvorlagen ohne das Vektorlängenfeld 2559B wirken auf die maximale Vektorlänge. Ferner wirken die Anweisungsvorlagen der Klasse B des spezifischen vektorfreundlichen Anweisungsformats 2600 in einer Ausführungsform auf gepackte oder skalare Gleitkommadaten mit einfacher/doppelter Genauigkeit und auf gepackte oder skalare ganzzahlige Daten. Skalare Operationen sind Operationen, die an der niederwertigsten Datenelementposition in einem zmm/ymm/xmm-Register durchgeführt werden; wobei die höherwertigen Datenelementpositionen abhängig von der Ausführungsform entweder gleich gelassen werden, wie sie vor der Anweisung waren, oder auf null gesetzt werden.
Schreibmaskenregister 2715 - In der veranschaulichten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), die jeweils eine Größe von 64 Bit aufweisen. In einer alternativen Ausführungsform weisen die Schreibmaskenregister 2715 eine Größe von 16 Bit auf. Wie vorher beschrieben, kann das Vektormaskenregister k0 in einer Ausführungsform der Erfindung nicht als eine Schreibmaske verwendet werden; wenn die Codierung, die normalerweise k0 anzeigen würde, für eine Schreibmaske verwendet wird, wählt sie eine festprogrammierte Schreibmaske von 0xFFFF aus, was effektiv eine Schreibmaskierung für diese Anweisung deaktiviert.
Register 2725 für Universalzwecke - In der veranschaulichten Ausführungsform gibt es sechzehn 64-Bit-Register für Universalzwecke, die zusammen mit den bestehenden x86-Adressiermodi verwendet werden, um Arbeitsspeicheroperanden zu adressieren. Auf diese Register wird mit den Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 Bezug genommen.
Skalare Gleitkomma-Stapelregisterdatei (x87-Stapel) 2745, auf der der MMX-gepackte ganzzahlige flache Registerdatei 2750 ein Alias zugewiesen ist - In der veranschaulichten Ausführungsform ist der x87-Stapel ein Stapel mit acht Elementen, der verwendet wird, um unter Verwendung der x87-Anweisungssatzerweiterung skalare Gleitkommaoperationen an 32/64/80-Bit-Gleitkommadaten durchzuführen; während die MMX-Register verwendet werden, um Operationen an 64-Bit-gepackten ganzzahligen Daten durchzuführen, sowie um Operanden für einige Operationen zu halten, die zwischen den MMX- und XMM-Registern durchgeführt werden.
Alternative Ausführungsformen der Erfindung können breitere oder schmälere Register verwenden. Zusätzlich können alternative Ausführungsformen der Erfindung mehr, weniger oder unterschiedliche Registerdateien und Register verwenden.
Beispielhafte Kernarchitekturen, Prozessoren und Computer-Architekturen
Prozessorkerne können auf verschiedene Arten, für verschiedene Zwecke und in verschiedenen Prozessoren implementiert werden. Zum Beispiel können Implementierungen solcher Kerne Folgendes enthalten: 1) einen Universal-In-Order-Kern, der für allgemeine Rechenzwecke gedacht ist; 2) einen Hochleistungs-Universal-Out-of-Order-Kern, der für allgemeine Rechenzwecke gedacht ist; 3) einen Kern für Sonderzwecke, der primär für Grafik- und/oder wissenschaftliches Rechnen (Durchsatzrechnen) gedacht ist. Implementierungen von verschiedenen Prozessoren können Folgendes enthalten: 1) eine CPU, die einen oder mehrere Universal-In-Order-Kerne, die für allgemeine Rechenzwecke gedacht sind, und/oder einen oder mehrere Universal-Out-of-Order-Kerne enthält, die für allgemeine Rechenzwecke gedacht sind; und 2) einen Coprozessor, der einen oder mehrere Kerne für Sonderzwecke enthält, die primär für Grafik und/oder Wissenschaft (Durchsatz) gedacht sind. Solche verschiedenen Prozessoren führen zu verschiedenen Computersystemarchitekturen, die Folgendes umfassen können: 1) den Coprozessor auf einem separaten Chip von der CPU; 2) den Coprozessor auf einem separaten Chip im gleichen Gehäuse wie eine CPU; 3) den Coprozessor auf dem gleichen Chip wie eine CPU (in diesem Fall wird ein solcher Coprozessor manchmal als Logik für Sonderzwecke bezeichnet, wie integrierte Grafik- und/oder wissenschaftliche Logik (Durchsatzlogik, oder als Kerne für Sonderzwecke); und 4) ein Ein-Chip-System, das die beschriebene CPU (manchmal als der Anwendungskern bzw. die Anwendungskerne oder der Anwendungsprozessor bzw. die Anwendungsprozessoren bezeichnet), den oben beschriebenen Coprozessor und zusätzliche Funktionalität auf dem gleichen Chip enthalten kann. Als Nächstes werden beispielhafte Kernarchitekturen beschrieben, gefolgt von Beschreibungen von beispielhaften Prozessoren und Computerarchitekturen.
Beispielhafte Kernarchitekturen
Blockdiagramm für In-Order- und Out-of-Order-Kerne
28A ist ein Blockdiagramm, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline nach Ausführungsformen der Erfindung illustriert. 28B ist ein Blockdiagramm, das sowohl ein Ausführungsbeispiel eines Kerns mit In-Order-Architektur als auch eines Kerns mit Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungsarchitektur illustriert, die in einem Prozessor nach Ausführungsformen der Erfindung enthalten sein sollen. Die durchgezogen umrandeten Kästchen in den 28A-B illustrieren die In-Order-Pipeline und den In-Order-Kern, während der optionale Zusatz der gestrichelt umrandeten Kästchen die Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline und den Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Kern illustrieren. Da der In-Order-Aspekt eine Teilmenge des Out-of-Order-Aspekts ist, wird der Out-of-Order-Aspekt beschrieben.
In 28A enthält eine Prozessor-Pipeline 2800 eine Abrufphase 2802, eine Längendecodierphase 2804, eine Decodierphase 2806, eine Zuordnungsphase 2808, eine Umbenennungsphase 2810, eine Zeitplanungsphase (auch als Versand- oder Ausgabephase bekannt) 2812, eine Registerlese-/Speicherlesephase 2814, eine Ausführungsphase 2816, eine Zurückschreib-/Speicherschreibphase 2818, eine Ausnahmebehandlungsphase 2822 und eine Festschreibphase 2824.
28B zeigt einen Prozessorkern 2890, der eine Front-End-Einheit 2830 enthält, die an eine Ausführengineeinheit 2850 gekoppelt ist, und beide sind an eine Speichereinheit 2870 gekoppelt. Der Kern 2890 kann ein Reduced-Instruction-Set-Computing(RISC)-Kern, ein Complex-Instruction-Set-Computing(CISC)-Kern, ein Very-Long-Instruction-Word(VLIW)-Kern oder ein Hybrid- oder alternativer Kerntyp sein. Als noch eine weitere Option kann der Kern 2890 ein Kern für Sonderzwecke sein, wie zum Beispiel ein Netzwerk- oder Kommunikationskern, eine Komprimierungsengine, ein Coprozessorkern, einen Kern einer Grafikverarbeitungseinheit für allgemeine Rechenzwecke (GPGPU), ein Grafikkern oder Ähnliches.
Die Front-End-Einheit 2830 enthält eine an eine Anweisungszwischenspeichereinheit 2834 gekoppelte Verzweigungsvorhersageeinheit 2832, die an einen Anweisungsübersetzungspuffer (Translation Lookaside Buffer, TLB) 2836 gekoppelt ist, der an eine Anweisungsabrufeinheit 2838 gekoppelt ist, die an eine Decodiereinheit 2840 gekoppelt ist. Die Decodiereinheit 2840 (oder Decoder) kann Anweisungen decodieren und als Ausgabe eine oder mehrere Mikro-Operationen, Mikrocode-Eingangspunkte, Mikroanweisungen, andere Anweisungen oder andere Steuersignale generieren, die von den ursprünglichen Anweisungen decodiert sind oder diese anderweitig widerspiegeln oder von diesen abgeleitet sind. Die Decodiereinheit 2840 kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Beispiele geeigneter Mechanismen enthalten Nachschlagetabellen, Hardwareimplementierungen, programmierbare Logikarrays (PLAs), schreibgeschützte Mikrocode-Arbeitsspeicher (Mikrocode-ROMs) usw., sind jedoch nicht darauf beschränkt. In einer Ausführungsform enthält der Kern 2890 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für bestimmte Makroanweisungen speichert (z. B. in der Decodiereinheit 2840 oder anderweitig innerhalb der Front-End-Einheit 2830). Die Decodiereinheit 2840 ist in der Ausführungsengineeinheit 2850 an eine Umbenennungs-/Zuordnungseinheit 2852 gekoppelt.
Die Ausführungsengineeinheit 2850 enthält die an eine Stilllegungseinheit 2854 gekoppelte Umbenennungs-/Zuordnungseinheit 2852 und einen Satz von einer oder mehreren Planungseinheiten 2856. Die Planungseinheit(en) 2856 repräsentiert bzw. repräsentieren eine beliebige Anzahl verschiedener Planer, einschließlich Reservierstationen, zentrale Anweisungsfenster usw. Die Planungseinheit(en) 2856 ist bzw. sind an die physische(n) Registerdateieinheit(en) 2858 gekoppelt. Jede der physischen Registerdateieinheit(en) 2858 repräsentiert eine oder mehrere physische Registerdateien, von denen verschiedene einen oder mehrere verschiedene Datentypen speichern, wie skalare ganze Zahl, skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma, Status (z. B. einen Anweisungszeiger, der die Adresse der nächsten auszuführenden Anweisung ist) usw. In einer Ausführungsform umfasst die physische Registerdateieinheit 2858 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine Skalarregistereinheit. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Universalregister bereitstellen. Die physische(n) Registerdateieinheit(en) 2858 wird bzw. werden von der Stilllegungseinheit 2854 überlappt, um verschiedene Arten zu illustrieren, auf die eine Registerumbenennung und Out-of-Order-Ausführung implementiert werden können (z. B. unter Verwendung eines Umordnungspuffers bzw. von Umordnungspuffern und (einer) Stilllegungsregisterdatei(en); unter Verwendung einer bzw. von zukünftigen Datei(en), eines Verlaufspuffers bzw. von Verlaufspuffern und einer Stilllegungsregisterdatei bzw. von Stilllegungsregisterdateien; unter Verwendung einer Registerabbildung und eines Pools von Registern; usw.). Die Stilllegungseinheit 2854 und die physische(n) Registerdateieinheit(en) 2858 sind an das bzw. die Ausführungscluster 2860 gekoppelt. Das bzw. die Ausführungscluster 2860 enthält bzw. enthalten einen Satz einer oder mehrerer Ausführungseinheiten 2862 und einen Satz von einem oder mehreren Speicherzugriffseinheiten 2864. Die Ausführungseinheiten 2862 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und an verschiedenen Datentypen (z. B. skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma) durchführen. Während manche Ausführungsformen eine Anzahl von Ausführungseinheiten enthalten können, die spezifischen Funktionen oder Funktionssätzen gewidmet sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten enthalten, die alle alle Funktionen durchführen. Die Planungseinheit(en) 2856, physische(n) Registerdateieinheit(en) 2858 und Ausführungscluster 2860 sind als möglicherweise mehrzahlig gezeigt, da bestimmte Ausführungsformen separate Pipelines für bestimmte Arten von Daten/Operationen erstellen (z. B. eine Pipeline für skalare ganze Zahlen, eine Pipeline für skalares Gleitkomma/gepackte ganze Zahlen/gepacktes Gleitkomma/vektorielle ganze Zahlen/vektorielles Gleitkomma und/oder eine Speicherzugriffs-Pipeline, die jeweils ihre eigene Planungseinheit, physische Registerdateieinheit und/oder ihr eigenes Ausführungscluster aufweisen - und im Fall einer separaten Speicherzugriffs-Pipeline sind bestimmte Ausführungsformen implementiert, in denen nur das Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 2864 aufweist). Es sollte auch klar sein, dass, wo separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines Out-of-Order-Ausgabe-/Ausführungs- und der Rest In-Order-Pipelines sein können.
Der Satz von Speicherzugriffseinheiten 2864 ist an die Speichereinheit 2870 gekoppelt, die eine Daten-TLB-Einheit 2872 enthält, die an eine Datenzwischenspeichereinheit 2874 gekoppelt ist, die an eine Level-2(L2)-Zwischenspeichereinheit 2876 gekoppelt ist. In einem Ausführungsbeispiel können die Speicherzugriffseinheiten 2864 eine Ladeeinheit, eine Adressspeichereinheit und eine Datenspeichereinheit enthalten, von denen jede an die Daten-TLB-Einheit 2872 in der Speichereinheit 2870 gekoppelt ist. Die Anweisungszwischenspeichereinheit 2834 ist ferner an eine Level-2(L2)-Zwischenspeichereinheit 2876 in der Speichereinheit 2870 gekoppelt. Die L2-Zwischenspeichereinheit 2876 ist an eine oder mehrere andere Zwischenspeicher-Levels und letztendlich an einen Hauptspeicher gekoppelt.
Beispielsweise kann die beispielhaften Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungskernarchitektur die Pipeline 2800 folgendermaßen implementieren: 1) Der Anweisungsabruf 2838 führt den Abruf und die Längendecodierphasen 2802 und 2804 durch; 2) die Decodiereinheit 2840 führt die Decodierphase 2806 durch; 3) die Umbenennungs-/Zuordnungseinheit 2852 führt die Zuordnungsphase 2808 und die Umbenennungsphase 2810 durch; 4) die Zeitplangebereinheit (en) 2856 führt bzw. führen die Zeitplanungsphase 2812 durch; 5) die physische(n) Registerdateieinheit(en) 2858 und die Speichereinheit 2870 führen die Registerlese-/Speicherlesephase 2814 durch; das Ausführungscluster 2860 führt die Ausführungsphase 2816 durch; 6) die Speichereinheit 2870 und die physische(n) Registerdateieinheit(en) 2858 führen die Zurückschreib-/Speicherschreibphase 2818 durch; 7) verschiedene Einheiten können an der Ausnahmebehandlungsphase 2822 beteiligt sein; und 8) die Stilllegungseinheit 2854 und die physische(n) Registerdateieinheit(en) 2858 führen die Festschreibphase 2824 durch.
Der Kern 2890 kann eine oder mehrere Anweisungssätze unterstützen (z. B. den x86-Anweisungssatz (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden); den MIPS-Anweisungssatz von MIPS Technologies in Sunnyvale, CA; den ARM-Anweisungssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings in Sunnyvale, CA), die die hierin beschriebene(n) Anweisung(en) enthalten. In einer Ausführungsform enthält der Kern 2890 Logik, um eine gepackte Datenanweisungssatzerweiterung (z. B. AVX1, AVX2) zu unterstützen, wodurch erlaubt wird, dass die von vielen Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten durchgeführt werden.
Es sollte klar sein, dass der Kern Multithreading (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen kann und dies auf vielfältige Weise tun kann, einschließlich Sliced-Multithreading, simultanes Multithreading (wobei ein einziger physischer Kern jedem der Threads, die der physische Kern simultan nebenläufig ausführt, einen logischen Kern bereitstellt) oder eine Kombination davon (z. B. Zeitscheiben-Abruf und -Decodierung und danach simultanes Multithreading wie in der Intel®-Hyperthreading-Technologie).
Während Registerumbenennen im Kontext einer Out-of-Order-Ausführung beschrieben wird, sollte klar sein, dass das Registerumbenennen in einer In-Order-Architektur verwendet werden kann. Während die illustrierte Ausführungsform des Prozessors auch separate Anweisungs- und Datenzwischenspeichereinheiten 2834/2874 und eine gemeinsam genutzte L2-Zwischenspeichereinheit 2876 enthält, können alternative Ausführungsformen einen einzigen internen Zwischenspeicher für sowohl Anweisungen als auch Daten aufweisen, wie zum Beispiel einen internen Level-1(L1)-Zwischenspeicher oder mehrere Levels von internem Zwischenspeicher. In manchen Ausführungsformen kann das System eine Kombination eines internen Zwischenspeicher und eines externen Zwischenspeicher enthalten, der extern zum Kern und/oder zum Prozessor ist. Alternativ kann der gesamte Zwischenspeicher extern zum Kern und/oder zum Prozessor sein.
Eine spezifische beispielhafte In-Order-Kernarchitektur
29A-B ein Blockdiagramm einer spezifischeren beispielhaften In-Order-Kernarchitektur illustrieren, wobei der Kern einer von mehreren logischen Blöcken (die anderen Kerne des gleichen Typs und/oder anderer Typen enthalten) in einem Chip wäre. Die logischen Blöcke kommunizieren über ein Verbindungsnetzwerk hoher Bandbreite (z. B. ein Ringnetzwerk) mit einiger Logik mit festen Funktionen, Speicher-E/A-Schnittstellen und anderer notwendiger E/A-Logik, abhängig von der Anwendung.
29A ist ein Blockdiagramm eines einzelnen Prozessorkerns, zusammen mit seiner Verbindung an das chipinterne Verbindungsnetz 2902 und mit seinem lokalen Teilsatz des Level-2(L2)-Zwischenspeichers 2904, nach Ausführungsformen der Erfindung. In einer Ausführungsform unterstützt ein Anweisungsdecoder 2900 den x86-Anweisungssatz mit einer Erweiterung für gepackte Datenanweisungssätze. Ein L1-Zwischenspeicher 2906 erlaubt Zugriffe mit niedriger Latenzzeit auf Zwischenspeicherspeicher in die Skalar- und Vektoreinheiten. Während in einer Ausführungsform (um das Design zu vereinfachen) eine Skalareinheit 2908 und eine Vektoreinheit 2910 separate Registersätze (Skalarregister 2912 bzw. Vektorregister 2914) verwenden und zwischen ihnen transferierte Daten in einen Speicher geschrieben und danach wieder aus einem Level-1(L1)-Zwischenspeicher 2906 gelesen werden, können alternative Ausführungsformen der Erfindung einen anderen Ansatz verwenden (z. B. einen einzigen Registersatz verwenden oder einen Kommunikationspfad enthalten, der erlaubt, dass Daten zwischen den zwei Registerdateien ohne Schreiben und Wiedereinlesen transferiert werden).
Der lokale Teilsatz des L2-Zwischenspeichers 2904 ist Teil eines globalen L2-Zwischenspeichers, der in separate lokale Teilsätze aufgeteilt ist, einen pro Prozessorkern. Jeder Prozessorkern weist einen direkten Zugriffspfad zu seinem eigenen lokalen Teilsatz des L2-Zwischenspeichers 2904 auf. Von einem Prozessorkern gelesene Daten werden in seinem L2-Zwischenspeicher-Teilsatz 2904 gespeichert und auf sie kann schnell zugegriffen werden, parallel zu anderen Prozessorkernen, die auf ihre eigenen lokalen L2-Zwischenspeicher-Teilsätze zugreifen. Von einem Prozessorkern geschriebene Daten werden in seinem eigenen L2-Zwischenspeicher-Teilsatz 2904 gespeichert und aus anderen Teilsätzen wenn nötig geleert. Das Ringnetzwerk stellt Kohärenz für gemeinsam genutzte Daten sicher. Das Ringnetzwerk ist bidirektional, um Agenten wie Prozessorkernen, L2-Zwischenspeichern und anderen Logikblöcken zu erlauben, miteinander innerhalb des Chips zu kommunizieren. Jeder Ring-Datenpfad ist pro Richtung 1012 Bit breit.
29B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 29A nach Ausführungsformen der Erfindung. 29B enthält einen Ll-Datenzwischenspeicher 2906A, einen Teil des L1-Zwischenspeicher 2904 sowie mehr Details in Bezug auf die Vektoreinheit 2910 und die Vektorregister 2914. Insbesondere ist die Vektoreinheit 2910 eine 16-breite Vektorverarbeitungseinheit (VPU) (siehe die 16-breite ALU 2928), die eine oder mehrere von folgenden Anweisungen ausführt: ganzzahlige, Gleitkommaanweisungen mit einfacher Genauigkeit und Gleitkommaanweisungen mit doppelter Genauigkeit. Die VPU unterstützt ein Swizzeln der Registereingänge mit Swizzleeinheit 2920, numerische Umwandlung mit numerischen Umwandlungseinheiten 2922A-B und Replizierung mit Replizierungseinheit 2924 am Speichereingang. Schreibmaskenregister 2926 erlauben ein Vergleichen von resultierenden Vektorschreibvorgängen.
30 ist ein Blockdiagramm eines Prozessors 3000, der nach Ausführungsformen der Erfindung mehr als einen Kern aufweisen kann, einen integrierten Speichercontroller aufweisen kann und integrierte Grafik aufweisen kann. Die durchgezogen umrandeten Kästchen in 30 illustrieren einen Prozessor 3000 mit einem einzigen Kern 3002A, einem Systemagenten 3010, einen Satz von einem oder mehreren Buscontrollereinheiten 3016, während die optionale Hinzufügung der gestrichelt umrandeten Kästchen einen alternativen Prozessor 3000 mit mehreren Kernen 3002AN, einem Satz von einem oder mehreren integrierten Speichercontrollereinheiten 3014 in der Systemagenteinheit 3010 und Logik für Sonderzwecke 3008 illustriert.
Deshalb können verschiedene Implementierungen des Prozessors 3000 enthalten: 1) eine CPU, wobei die Logik für Sonderzwecke 3008 integrierte Grafik- und/oder wissenschaftliche Logik (Durchsatzlogik) ist (die einen oder mehrere Kerne enthalten kann) und die Kerne 3002A-N ein oder mehrere Universalkerne sind (z. B. Universal-In-Order-Kerne, Universal-Out-of-Order-Kerne, eine Kombination der zwei); 2) einen Coprozessor, wobei die Kerne 3002A-N eine große Anzahl von Kernen für Sonderzwecke sind, die primär für Grafik und/oder Wissenschaft (Durchsatz) gedacht sind; und 3) einen Coprozessor, wobei die Kerne 3002A-N eine große Anzahl von Universal-In-Order-Kernen sind. Deshalb kann der Prozessor 3000 ein Universal-Prozessor, Coprozessor oder Prozessor für Sonderzwecke sein, wie zum Beispiel ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine Grafikverarbeitungseinheit für allgemeine Rechenzwecke (GPGPU), ein Many-Integrated-Core(MIC)-Coprozessor mit hohem Durchsatz (der 30 oder mehr Kerne enthält), ein eingebetteter Prozessor oder Ähnliches. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 3000 kann ein Teil eines oder mehrerer Substrate sein und/oder kann auf einem oder mehreren Substraten unter Verwendung einer Anzahl von Prozesstechniken wie zum Beispiel BiCMOS, CMOS oder NMOS implementiert sein.
Die Speicherhierarchie enthält einen oder mehrere Level von Zwischenspeichern innerhalb der Kerne, einen Satz von einer oder mehreren gemeinsam genutzten Zwischenspeichereinheiten 3006 und externen Speicher (nicht gezeigt), die an den Satz der integrierten Speichercontrollereinheiten 3014 gekoppelt sind. Der Satz der gemeinsam genutzten Zwischenspeichereinheiten 3006 kann einen oder mehrere Zwischenspeicher mittlerer Levels enthalten, wie Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Zwischenspeicherlevel, einen Last-Level-Zwischenspeicher (LLC) und/oder Kombinationen davon. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 3012 die integrierte Grafiklogik 3008 (die integrierte Grafiklogik 3008 ist ein Beispiel für und wird hierin auch als Logik für Spezialzwecke bezeichnet), den Satz der gemeinsam genutzten Zwischenspeichereinheiten 3006 und die Systemagenteneinheit 3010/den bzw. die integrierten Speichercontrollereinheit(en) 3014 verbindet, können alternative Ausführungsformen eine beliebige Anzahl von gut bekannten Techniken zum Verbinden derartiger Einheiten verwenden. In einer Ausführungsform wird Kohärenz zwischen einem oder mehreren Zwischenspeichereinheiten 3006 und den Kernen 3002-A-N beibehalten.
In manchen Ausführungsformen sind einer oder mehrere der Kerne 3002A-N multithreadingfähig. Der Systemagent 3010 enthält diese Komponenten, die die Kerne 3002A-N koordinieren und betreiben. Die Systemagenteneinheit 3010 kann zum Beispiel eine Energiesteuereinheit (PCU) und eine Anzeigeeinheit enthalten. Die PCU kann Logik und Komponenten enthalten, die zur Regulierung des Energiezustands der Kerne 3002A-N und der integrierten Grafiklogik 3008 benötigt werden. Die Anzeigeeinheit ist zum Ansteuern einer oder mehrerer extern angeschlossener Anzeigen.
Die Kerne 3002A-N können in Bezug auf einen Architekturanweisungssatz homogen oder heterogen sein; das heißt, zwei oder mehr der Kerne 3002A-N können fähig sein, den gleichen Anweisungssatz auszuführen, während andere fähig sein können, nur einen Teilsatz dieses Anweisungssatzes oder einen anderen Anweisungssatz auszuführen.
Beispielhafte Computerarchitekturen
31-34 sind Blockdiagramme von beispielhaften Computerarchitekturen. Andere Systemdesigns und -konfigurationen, die in der Technik für Laptops, Desktops, tragbare PCs, Organizer, Entwicklungs-Workstations, Server, Netzwerkeinrichtungen, Netzwerkhubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Grafikeinrichtungen, Videospieleinrichtungen, Set-Top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Mediaplayer, tragbare Geräte und verschiedene andere Elektronikgeräte bekannt sind, sind ebenfalls geeignet. Im Allgemeinen ist eine enorm große Vielfalt von Systemen oder Elektronikeinrichtungen geeignet, die einen Prozessor und/oder eine andere Ausführungslogik, wie hierin offenbart, einbinden können.
Nunmehr auf 31 Bezug nehmend, wird ein Blockdiagramm eines Systems 3100 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das System 3100 kann einen oder mehrere Prozessoren 3110, 3115 enthalten, die an einen Controllerhub 3120 gekoppelt sind. In einer Ausführungsform enthält der Controllerhub 3120 einen Grafikspeicher-Controllerhub (GMCH) 3190 und einen Eingabe-/Ausgabe-Hub (IOH) 3150 (die auf separaten Chips sein können); der GMCH 3190 enthält Speicher- und Grafikcontroller, an die Speicher 3140 und ein Coprozessor 3145 gekoppelt sind; der IOH 3150 koppelt Eingabe-/Ausgabe(E/A)-Einrichtungen 3160 an den GMCH 3190. Alternativ sind einer der Speicher- und Grafikcontroller oder beide im Prozessor integriert (wie hierin beschrieben), der Speicher 3140 und der Coprozessor 3145 sind direkt an den Prozessor 3110 gekoppelt, und der Controllerhub 3120 in einem einzigen Chip mit dem IOH 3150.
Der optionale Charakter der zusätzlichen Prozessoren 3115 wird in 31 durch unterbrochene Linien angezeigt. Jeder Prozessor 3110, 3115 kann einen oder mehrere der hierin beschriebenen Verarbeitungskerne enthalten und kann eine Version des Prozessors 3000 sein.
Der Speicher 3140 kann zum Beispiel Dynamic Random Access Memory (DRAM), Phase-Change-Memory (PCM) oder eine Kombination der zwei sein. Für mindestens eine Ausführungsform kommuniziert der Controllerhub 3120 mit dem Prozessor bzw. den Prozessoren 3110, 3115 über einen Mehrpunktbus wie einem Frontside-Bus (FSB), einer Punkt-zu-Punkt-Schnittstelle wie QuickPath Interconnect (QPI) oder einer ähnlichen Verbindung 3195.
In einer Ausführungsform ist der Coprozessor 3145 ein Prozessor für Sonderzwecke, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder Ähnliches. In einer Ausführungsform kann der Controllerhub 3120 einen integrierten Grafikbeschleuniger enthalten.
Es kann eine Vielfalt von Unterschieden zwischen den physischen Ressourcen 3110, 3115 in Bezug auf ein Spektrum von Leistungsmetriken geben, einschließlich architektonisch, mikroarchitektonisch, thermal, Energieverbrauchsmerkmalen und Ähnlichem.
In einer Ausführungsform führt der Prozessor 3110 Anweisungen aus, die Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In den Anweisungen können Coprozessoranweisungen eingebettet sein. Der Prozessor 3110 erkennt, dass diese Coprozessoranweisungen von einem Typ sind, die vom angebundenen Coprozessor 3145 ausgeführt werden sollen. Dementsprechend gibt der Prozessor 3110 diese Coprozessoranweisungen (oder Steuersignale, die die Coprozessoranweisungen repräsentieren) auf einem Coprozessorbus oder einer anderen Verbindung an den Coprozessor 3145 aus. Der bzw. die Coprozessor(en) 3145 nimmt bzw. nehmen die empfangenen Coprozessoranweisungen an und führt bzw. führen diese aus.
Nunmehr auf 32 Bezug nehmend, wird ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems 3200 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt. Wie in 32 gezeigt, ist das Multiprozessorsystem 3200 ein Punkt-zu-Punkt-Verbindungssystem und enthält einen ersten Prozessor 3270 und einen zweiten Prozessor 3280, die über eine Punkt-zu-Punkt-Verbindung 3250 gekoppelt sind. Jeder der Prozessoren 3270 und 3280 kann eine Version des Prozessors 3000 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 3270 und 3280 die Prozessoren 3110 bzw. 3115, während der Coprozessor 3238 der Coprozessor 3145 ist. In einer anderen Ausführungsform sind die Prozessoren 3270 und 3280 der Prozessor 3110 bzw. der Coprozessor 3145.
Die Prozessoren 3270 und 3280 sind integrierte Speichercontrollereinheiten (IMC) 3272 bzw. 3282 enthaltend gezeigt. Der Prozessor 3270 enthält auch als Teil seiner Bussteuerungseinheiten Punkt-zu-Punkt(P-P)-Schnittstellen 3276 und 3278; gleichermaßen enthält der zweite Prozessor 3280 P-P-Schnittstellen 3286 und 3288. Die Prozessoren 3270, 3280 können Informationen über eine Punkt-zu-Punkt(P-P)-Schnittstelle 3250 unter Verwendung der P-P-Schnittstellenschaltkreise 3278, 3288 austauschen. Wie in 32 gezeigt, koppeln die IMCs 3272 und 3282 die Prozessoren an jeweilige Speicher, nämlich einen Speicher 3232 und einen Speicher 3234, die Teile von Hauptspeicher sein können, die lokal an die jeweiligen Prozessoren angebunden sind.
Die Prozessoren 3270, 3280 können jeweils Informationen mit einem Chipsatz 3290 über individuelle P-P-Schnittstellen 3252, 3254 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltkreisen 3276, 3294, 3286, 3298 austauschen. Der Chipsatz 3290 kann optional Informationen mit dem Coprozessor 3238 über eine Hochleistungsschnittstelle 3292 austauschen. In einer Ausführungsform ist der Coprozessor 3238 ein Prozessor für Sonderzwecke, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder Ähnliches.
Ein gemeinsam genutzter Zwischenspeicher (nicht gezeigt) kann in einem der beiden Prozessoren oder außerhalb beider Prozessoren enthalten sein, jedoch mit den Prozessoren über eine P-P-Verbindung verbunden sein, sodass die lokalen Zwischenspeicher-Informationen von einem der beiden oder beiden Prozessoren im gemeinsam genutzten Zwischenspeicher gespeichert werden kann, wenn ein Prozessor in einen Niedrigenergiemodus versetzt wird.
Der Chipsatz 3290 kann über eine Schnittstelle 3296 an einen ersten Bus 3216 gekoppelt sein. In einer Ausführungsform ist der erste Bus 3216 ein Peripheral-Component-Interconnect(PCI)-Bus oder ein Bus wie ein PCI-Express-Bus oder ein anderer E/A-Verbindungsbus der dritten Generation sein, obwohl der Umfang der vorliegenden Erfindung dadurch nicht eingeschränkt ist.
Wie in 32 gezeigt, können verschiedene E/A-Einrichtungen 3214 zusammen mit einer Busbrücke 3218, die den ersten Bus 3216 an einen zweiten Bus 3220 koppelt, an den ersten Bus 3216 gekoppelt sein. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessoren 3215 wie Coprozessoren, Hochdurchsatz-MIC-Prozessoren, GPGPUs, Beschleuniger (wie z. B. Grafikbeschleuniger oder digitale Signalverarbeitungseinheiten (DSP)), Field Programmable Gate Arrays oder beliebige andere Prozessoren an den ersten Bus 3216 gekoppelt. In einer Ausführungsform kann der zweite Bus 3220 ein Low-Pin-Count(LPC)-Bus sein. Verschiedene Einrichtungen können an einen zweiten Bus 3220 gekoppelt sein, die zum Beispiel eine Tastatur und/oder Maus 3222, Kommunikationseinrichtungen 3227 und eine Datenspeichereinheit 3228, wie ein Plattenlaufwerk oder eine andere Massenspeichereinrichtung enthält, das in einer Ausführungsform Anweisungen/Code und Daten 3230 enthalten kann. Ferner kann ein Audio-E/A 3224 an den zweiten Bus 3220 gekoppelt sein. Es ist zu beachten, dass andere Architekturen möglich sind. Zum Beispiel kann ein System statt der Punkt-zu-Punkt-Architektur von 32 einen Mehrpunktbus oder eine andere solche Architektur implementieren.
Nunmehr auf 33 Bezug nehmend, wird ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems 3300 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt. Gleiche Elemente in den 32 und 33 tragen gleiche Referenzziffern, und bestimmte Aspekte von 32 wurden von 33 weggelassen, um ein Verdecken anderer Aspekte von 33 zu vermeiden.
33 illustriert, dass die Prozessoren 3270, 3280 eine integrierte Speicher- und E/A-Steuerlogik („CL“) 3272 bzw. 3282 enthalten können. Deshalb enthalten die CL 3272, 3282 integrierte Speichercontrollereinheiten und enthalten E/A-Steuerlogik. 33 illustriert, dass nicht nur die Speicher 3232, 3234 an die CL 3272, 3282 gekoppelt sind, sondern auch, dass E/A-Einrichtungen 3314 ebenfalls an die Steuerlogik 3272, 3282 gekoppelt sind. Alt-E/A-Einrichtungen 3315 sind an den Chipsatz 3290 gekoppelt.
Nunmehr auf 34 Bezug nehmend, wird ein Blockdiagramm eines SoC 3400 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 30 tragen gleiche Referenzziffern. Gestrichelt umrandete Kästchen sind außerdem optionale Merkmale an hochentwickelteren SoCs. In 34 ist eine Verbindungseinheit bzw. sind Verbindungseinheiten 3402 gekoppelt an: einen Anwendungsprozessor 3410, der einen Satz von einem oder mehreren Kernen 3002A-N, die Zwischenspeichereinheiten 3004A-N enthalten, und (eine) gemeinsam genutzte Zwischenspeichereinheit(en) 3006 enthält; eine Systemagenteneinheit 3010; (eine) Buscontrollereinheit(en) 3016; (eine) integrierte Speichercontrollereinheit(en) 3014; einen Satz von einem oder mehreren Coprozessoren 3420, die integrierte Grafiklogik, einen Grafikprozessor, einen Audioprozessor und einen Videoprozessor enthalten können; eine statische Arbeitsspeichereinheit mit wahlfreiem Zugriff (SRAM-Einheit) 3430; eine direkte Speicherzugriffs(DMA)-Einheit 3432; und eine Anzeigeeinheit 3440 zum Koppeln an eine oder mehrere externe Anzeigen. In einer Ausführungsform enthält bzw. enthalten der bzw. die Coprozessor(en) 3420 einen Prozessor für Sonderzwecke, wie zum Beispiel einen Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, eine GPGPU, einen Hochdurchsatz-MIC-Prozessor, einen eingebetteten Prozessor oder Ähnliches.
Hierin offenbarte Ausführungsformen der Mechanismen können in Hardware, Software, Firmware oder einer Kombination solcher Implementierungsansätze implementiert werden. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert werden, die auf programmierbaren Systemen ausgeführt werden, die mindestens einen Prozess, ein Speichersystem (das flüchtigen und nichtflüchtigen Speicher und/oder Speicherelemente enthält), mindestens eine Eingabeeinrichtung und mindestens eine Ausgabeeinrichtung umfassen.
Programmcode, wie der in 32 illustrierte Code 3230 kann auf Eingabeanweisungen angewandt werden, um die hierin beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu generieren. Die Ausgabeinformationen können auf eine oder mehrere Ausgabeeinrichtungen angewandt werden, auf bekannte Weise. Für Zwecke dieser Anmeldung enthält ein Verarbeitungssystem ein beliebiges System, das einen Prozessor aufweist, wie zum Beispiel: einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor.
Der Programmcode kann in einer höheren verfahrens- oder objektorientierten Programmiersprache implementiert werden, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann auch in Assembler- oder Maschinensprache implementiert werden, wenn gewünscht. Tatsächlich sind die hierin beschriebenen Mechanismen im Umfang nicht auf eine beliebige bestimmte Programmiersprache beschränkt. Auf jeden Fall kann die Sprache eine compilierte oder interpretierte Sprache sein.
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentative Anweisungen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logik innerhalb des Prozessors repräsentiert, die, wenn sie von einer Maschine gelesen wird, bewirkt, dass die Maschine Logik erzeugt, um die hierin beschriebenen Techniken durchzuführen. Solche Repräsentationen, als „IP-Kerne“ bekannt, können auf einem greifbaren, maschinenlesbaren Medium gespeichert und an verschiedene Kunden oder Fertigungsanlagen geliefert werden, um in die Fertigungsmaschinen geladen zu werden, die die Logik oder den Prozessor tatsächlich herstellen.
Derartige maschinenlesbaren Speichermedien können nicht-transitorische, greifbare Anordnungen von einer Maschine oder Einrichtung gefertigte oder gebildete Artikel enthalten, die Speichermedien wie Festplatten, irgendeinen anderen Typ von Platte einschließlich Disketten, optische Platten, Compact Disc Read-Only Memories (CD-ROMs), wiederbeschreibbare Compact Discs (CD-RWs) und magneto-optische Platten, Halbleiterbauelemente wie schreibgeschützte Arbeitsspeicher (ROMs), Arbeitsspeicher mit wahlfreiem Zugriff (RAMs) wie dynamische Arbeitsspeicher mit wahlfreiem Zugriff (DRAMs), statische Arbeitsspeicher mit wahlfreiem Zugriff (SRAMs), löschbare programmierbare schreibgeschützte Arbeitsspeicher (EPROMs), Flashspeicher, elektrisch löschbare programmierbare schreibgeschützte Arbeitsspeicher (EEPROMs), Phasenwechselspeicher (PCM), magnetische oder optische Karten oder irgendeinen anderen, zur Speicherung von elektronischen Anweisungen geeigneten Medientyp enthalten, sind jedoch nicht darauf beschränkt.
Dementsprechend enthalten Ausführungsformen der Erfindung auch nicht-transitorische, greifbare maschinenlesbare Medien, die Anweisungen enthalten oder die Designdaten enthalten, wie Hardwarebeschreibungssprache (HDL), die hierin beschriebene Strukturen, Schaltkreise, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
Emulation (einschließlich binärer Übersetzung, Code-Morphing usw.)
In einigen Fällen kann ein Anweisungswandler verwendet werden, um eine Anweisung von einem Quellanweisungssatz in einen Zielanweisungssatz umzuwandeln. Zum Beispiel kann der Anweisungswandler eine Anweisung in eine oder mehrere andere, vom Kern zu verarbeitende Anweisungen übersetzen (z. B. unter Verwendung von statischer binärer Übersetzung, dynamischer binärer Übersetzung einschließlich dynamischem Compilieren), verwandeln, emulieren oder anderweitig umwandeln. Der Anweisungswandler kann in Software, Hardware, Firmware oder einer Kombination davon implementiert werden. Der Anweisungswandler kann sich auf dem Prozessor, nicht auf dem Prozessor, oder teilweise auf und teilweise nicht auf dem Prozessor befinden.
35 ist ein Blockdiagramm, das die Verwendung eines Softwareanweisungswandlers gegenüberstellt, um binäre Anweisungen in einem Quellanweisungssatz in binäre Anweisungen in einem Zielanweisungssatz nach Ausführungsformen der Erfindung umzuwandeln. In der illustrierten Ausführungsform ist der Anweisungswandler ein Softwareanweisungswandler, obwohl alternativ der Anweisungswandler in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 35 zeigt, dass ein Programm in einer höheren Sprache 3502 unter Verwendung eines x86-Compilers 3504 compiliert werden kann, um x86-Binärcode 3506 zu generieren, der nativ von einem Prozessor mit mindestens einem x86-Anweisungssatzkern 3516 ausgeführt werden kann. Der Prozessor mit mindestens einem x86-Anweisungssatzkern 3516 repräsentiert einen beliebigen Prozessor, der im Wesentlichen die gleichen Funktionen wie ein Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern durchführen kann, indem er Folgendes kompatibel ausführt oder anderweitig verarbeitet: (1) einen wesentlichen Teil des Anweisungssatzes des Intel-x86-Anweisungssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software, die auf einem Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern laufen sollen, um im Wesentlichen das gleiche Ergebnis wie ein Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern zu erreichen. Der x86-Compiler 3504 repräsentiert einen Compiler, der betrieben werden kann, um x86-Binärcode 3506 (z. B. Objektcode) zu generieren, der ohne oder mit zusätzlicher Verlinkungsverarbeitung auf dem Prozessor mit mindestens einem x86-Anweisungssatzkern 3516 ausgeführt werden kann. Gleichermaßen zeigt 35, dass das Programm in der höheren Sprache 3502 unter Verwendung eines Compilers für einen alternativen Anweisungssatz 3508 compiliert werden kann, um Binärcode eines alternativen Anweisungssatzes 3510 zu generieren, der nativ von einem Prozessor ohne mindestens einen x86-Anweisungssatzkern 3514 ausgeführt werden kann (z. B. einem Prozessor mit Kernen, die den MIPS-Anweisungssatz von MIPS Technologies in Sunnyvale, CA und/oder die den ARM-Anweisungssatz von ARM Holdings in Sunnyvale, CA ausführen). Der Anweisungswandler 3512 wird verwendet, um den x86-Binärcode 3506 in Code umzuwandeln, der nativ vom Prozessor ohne einen x86-Anweisungssatzkern 3514 ausgeführt werden kann. Es ist unwahrscheinlich, dass dieser umgewandelte Code der gleiche wie der Binärcode eines alternativen Anweisungssatzes 3510, da ein Anweisungswandler, der dazu fähig ist, schwer herzustellen ist; dennoch wird der umgewandelte Code die allgemeine Operation erzielen und aus Anweisungen aus dem alternativen Anweisungssatz bestehen. Deshalb repräsentiert der Anweisungswandler 3512 Software, Firmware, Hardware oder eine Kombination davon, die durch Emulation, Simulation oder einen beliebigen anderen Prozess einem Prozessor oder einer anderen Elektronikeinrichtung erlaubt, der bzw. die keinen x86-Anweisungssatzprozessor oder -Kern aufweist, den x86-Binärcode 3506 auszuführen.

Claims

Beansprucht wird:
Prozessor, umfassend: Decodierschaltkreise zum Decodieren einer Matrixpaar-Nullungsanweisung mit Feldern für einen Opcode und einer Kennung zum Identifizieren einer Zielmatrix mit einem PAIR-Parameter gleich TRUE; und Ausführungsschaltkreise zum Ausführen der decodierten Matrixpaar-Nullungsanweisung zum Nullen jedes Elements einer linken Matrix und einer rechten Matrix der identifizierten Zielmatrix.
Prozessor nach Anspruch 1, wobei der Opcode eine Größe jedes Datenelements der linken und rechten Matrizen definiert.
Prozessor nach Anspruch 2, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Doppelwort ist.
Prozessor nach Anspruch 2, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Wort ist.
Prozessor nach einem der Ansprüche 1-2, wobei die Ausführungsschaltkreise ferner alle Datenelemente in verbleibenden Spalten der linken und rechten Matrizen und unkonfigurierte Zeilen der linken und rechten Matrizen nullen.
Prozessor nach einem der Ansprüche 1-2, wobei die linken und rechten Matrizen jeweils mehrere Register zum Repräsentieren einer Matrix sind.
Prozessor nach einem der Ansprüche 1-2, wobei die Ausführungsschaltkreise bei einer Bestimmung von mindestens einer der folgenden Bedingungen einen Fehler generieren: eine Anzahl konfigurierter Kacheln ist gleich null, der PAIR-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt und ein VALID-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt.
Verfahren, umfassend: Decodieren einer Matrixpaar-Nullungsanweisung mit Feldern für einen Opcode und einer Zielmatrixkennung zum Identifizieren einer Zielmatrix mit einem PAIR-Parameter gleich TRUE; und Ausführen der decodierten Matrixpaar-Nullungsanweisung zum Nullen jedes Elements einer linken Matrix und einer rechten Matrix der identifizierten Zielmatrix.
Verfahren nach Anspruch 8, wobei der Opcode eine Größe jedes Datenelements der linken und rechten Matrizen definiert.
Verfahren nach Anspruch 9, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Doppelwort ist.
Verfahren nach Anspruch 9, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Wort ist.
Verfahren nach einem der Ansprüche 8-9, ferner umfassend: Nullen aller Datenelemente in verbleibenden Spalten der linken und rechten Matrizen und unkonfigurierten Zeilen der linken und rechten Matrizen.
Verfahren nach einem der Ansprüche 8-9, wobei die linken und rechten Matrizen jeweils mehrere Register zum Repräsentieren einer Matrix sind.
Verfahren nach einem der Ansprüche 8-9, ferner umfassend: Generieren eines Fehlers bei einer Bestimmung von mindestens einer der folgenden Bedingungen: eine Anzahl konfigurierter Kacheln ist gleich null, der PAIR-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt und ein VALID-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt.
Nichtflüchtiges maschinenlesbares Medium, das eine Matrixpaar-Nullungsanweisung speichert, die bewirkt, dass ein Prozessor die Anweisung ausführt durch: Decodieren einer Matrixpaar-Nullungsanweisung mit Feldern für einen Opcode und einer Zielmatrixkennung zum Identifizieren einer Zielmatrix mit einem PAIR-Parameter gleich TRUE; und Ausführen der decodierten Matrixpaar-Nullungsanweisung zum Nullen jedes Elements einer linken Matrix und einer rechten Matrix der identifizierten Zielmatrix.
Nichtflüchtiges maschinenlesbares Medium nach Anspruch 15, wobei der Opcode eine Größe jedes Datenelements der linken und rechten Matrizen definiert.
Nichtflüchtiges maschinenlesbares Medium nach Anspruch 16, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Doppelwort ist.
Nichtflüchtiges maschinenlesbares Medium nach Anspruch 16, wobei die Größe jedes Datenelements der linken und rechten Matrizen ein Wort ist.
Nichtflüchtiges maschinenlesbares Medium nach einem der Ansprüche 15-16, ferner umfassend: Nullen aller Datenelemente in verbleibenden Spalten der linken und rechten Matrizen und unkonfigurierten Zeilen der linken und rechten Matrizen.
Nichtflüchtiges maschinenlesbares Medium nach einem der Ansprüche 15-16, wobei die linken und rechten Matrizen jeweils mehrere Register zum Repräsentieren einer Matrix sind.
Nichtflüchtiges maschinenlesbares Medium nach einem der Ansprüche 15-16, ferner umfassend: Generieren eines Fehlers bei einer Bestimmung von mindestens einer der folgenden Bedingungen: eine Anzahl konfigurierter Kacheln ist gleich null, der PAIR-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt und ein VALID-Parameter der identifizierten Zielmatrix ist nicht auf TRUE gesetzt.
System, umfassend: einen Prozessor; und einen mit dem Prozessor gekoppelten Beschleuniger, wobei der Beschleuniger Folgendes umfasst: Decodierschaltkreise zum Decodieren einer Matrixpaar-Nullungsanweisung mit Feldern für einen Opcode und einer Zielmatrixkennung zum Identifizieren einer Zielmatrix mit einem PAIR-Parameter gleich TRUE; und Ausführungsschaltkreise zum Ausführen der decodierten Matrixpaar-Nullungsanweisung zum Nullen jedes Elements einer linken Matrix und einer rechten Matrix der identifizierten Zielmatrix.
System nach Anspruch 22, wobei der Opcode eine Größe jedes Datenelements der linken und rechten Matrizen definiert.
System nach einem der Ansprüche 22-23, wobei die Ausführungsschaltkreise ferner alle Datenelemente in verbleibenden Spalten der linken und rechten Matrizen und unkonfigurierte Zeilen der linken und rechten Matrizen nullen.
System nach einem der Ansprüche 22-23, wobei die linken und rechten Matrizen jeweils mehrere Register zum Repräsentieren einer Matrix sind.