DE112017003351T5

DE112017003351T5 - Systeme, Vorrichtungen und Verfahren für ein kumulatives Produkt

Info

Publication number: DE112017003351T5
Application number: DE112017003351.9T
Authority: DE
Inventors: William M. Brown; Elmoustapha Ould-Ahmed-Vall
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2016-07-02
Filing date: 2017-06-14
Publication date: 2019-03-14
Also published as: US11048510B2; TWI817926B; CN109328333A; WO2018009323A1; TW201810020A; US20180004519A1; CN109328333B; US10089110B2; US20190138306A1

Abstract

Es werden Systeme, Verfahren und Vorrichtungen zum Ausführen einer Anweisung beschrieben. In einigen Ausführungsformen weist die Anweisung mindestens einen Opcode, ein Feld für einen gepackten Datenquelloperanden und ein Feld für einen gepackten Datenzieloperanden auf. Wenn sie ausgeführt wird, veranlasst die Anweisung für jede Datenelementposition des Quelloperanden, dass ein Wert, der in der Datenelementposition gespeichert ist, mit allen Werten, die in vorhergehenden Datenelementpositionen des gepackten Datenquelloperanden gespeichert sind, multipliziert wird und ein Ergebnis der Multiplikation in einer entsprechenden Datenelementposition des gepackten Datenzieloperanden gespeichert wird.

Description

GEBIET DER ERFINDUNG
Das Gebiet der Erfindung betrifft im Allgemeinen eine Computer-Prozessor-Architektur und insbesondere eine Anweisung, die, wenn sie ausgeführt wird, zu einem bestimmten Ergebnis führt.
STAND DER TECHNIK
Ein Anweisungssatz oder eine Anweisungssatzarchitektur (ISA) ist der Teil der Computerarchitektur, der ein Programmieren betrifft, und kann die nativen Datentypen, Anweisungen, Registerarchitektur, Adressiermodi, Speicherarchitektur, Interrupt- und Ausnahmebehandlung und externen Eingang und Ausgang (I/O) aufweisen. Es ist anzumerken, dass der Begriff Anweisung hierin im Allgemeinen eine Makroanweisung betrifft - das heißt Anweisungen, die dem Prozessor zur Ausführung bereitgestellt werden - im Gegensatz zu Mikroanweisungen oder Mikro-Ops - die sich aus einem Decodieren eines Decoders eines Prozessors von Makroanweisungen ergeben.
Die Anweisungssatzarchitektur unterscheidet sich von der Mikroarchitektur, die der innere Aufbau des Prozessors ist, der die ISA implementiert. Prozessoren mit unterschiedlichen Mikroarchitekturen können einen gemeinsamen Anweisungssatz teilen. Zum Beispiel implementieren Intel Pentium 4-Prozessoren, Intel Core-Prozessoren und Advanced Micro Devices, Inc. of Sunnyvale CA-Prozessoren implementieren nahezu identische Versionen des x86-Anweisungssatzes (mit ein paar Erweiterungen, die in neueren Versionen multipliziert wurden), haben jedoch einen unterschiedlichen inneren Aufbau. Zum Beispiel kann die gleiche Registerarchitektur der ISA in unterschiedlichen Weisen in unterschiedlichen Mikroarchitekturen unter Verwendung von allgemein bekannten Techniken implementiert sein, einschließlich zugewiesener physischer Register, einem oder mehrerer dynamisch zugeordneter physischer Register, die einen Registerumbenennungsmechanismus verwenden (z. B. die Verwendung einer Register-Aliastabelle (Register Alias Table (RAT)), eines Neuordnungspuffers (Reorder Buffer (ROB)) und einer Abschlussregisterdatei, wie in US-Patent Nr. 5.446.912 beschrieben ist; die Verwendung von mehreren Zuweisungen und einem Pool von Registern, wie in US-Patent Nr. 5.207.132 beschrieben ist) usw. Solange nichts anderes spezifiziert wird, beziehen sich die Begriffe Registerarchitektur, Registerdatei und Register auf das, was für die/den Software/Programmierer sichtbar ist und die Weise, in der Anweisungen Register spezifizieren. Wenn Spezifizität gewünscht ist, werden die Adjektive logisch, architektonisch oder softwaresichtbar verwendet, um Register/Dateien in der Registerarchitektur anzuzeigen, während andere Adjektive verwendet werden, um Register in einer gegebenen Mikroarchitektur zuzuordnen (z. B. physisches Register, Neuordnungspuffer, Abschlussregister, Registerpool).
Ein Anweisungssatz weist ein oder mehrere Anweisungsformate auf. Ein gegebenes Anweisungsformat definiert verschiedene Felder (Anzahl von Bits, Bitstelle), um unter anderem die Operation, die durchzuführen ist, und den (die) Operanden zu spezifizieren, auf dem (denen) die Operation durchzuführen ist. Eine gegebene Anweisung wird unter Verwendung eines gegebenen Anweisungsformats ausgedrückt und spezifiziert die Operation und die Operanden. Ein Anweisungsstrom ist eine spezifische Sequenz von Anweisungen, wobei jede Anweisung in der Sequenz ein Vorkommen einer Anweisung in einem Anweisungsformat ist.
Wissenschaftliche, finanzielle, auto-vektorisierte Mehrzweck-, RMS- (recognition, mining, and synthesis - Erkennung, Abbau und Synthese)/visuelle und Multimedia-Anwendungen (z. B. 2D/3D-Grafiken, Bildverarbeitung, Videokompression/-dekompression, Spracherkennungsalgorithmen und Audiomanipulation) erfordern oft die gleiche Operation, die auf einer großen Anzahl von Dateneinheiten durchzuführen ist (als „Datenparallelismus“ bezeichnet). SIMD (Single Instruction Multiple Data - Einzelanweisungsmehrfachdaten) beziehen sich auf einen Typ von Anweisung, der einen Prozessor veranlasst, die gleiche Operation auf mehreren Dateneinheiten durchzuführen. Die SIMD-Technologie ist besonders für Prozessoren geeignet, die die Bits in einem Register in eine Anzahl von Datenelementen fester Größe aufteilen können, die jeweils einen separaten Wert darstellen. Zum Beispiel können die Bits in einem 64-Bit-Register als ein Quelloperand spezifiziert sein, auf dem vier separate 16-Bit-Datenelemente zu behandeln sind, von denen jedes einen separaten 16-Bit-Wert darstellt. In einem weiteren Beispiel können die Bits in einem 256-Bit-Register als ein Quelloperand spezifiziert sein, auf dem vier separate gepackte 64-Bit-Datenelemente (Datenelemente von Quadword(Q)-Größe), acht separate gepackte 32-Bit-Datenelemente (Datenelemente von Doppelwort(D)-Größe), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente von Wort(W)-Größe) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente von Byte(B)-Größe) zu behandeln sind. Dieser Datentyp wird als der gepackte Datentyp oder Vektordatentyp bezeichnet und Operanden dieses Datentyps werden als gepackte Datenoperanden oder Vektoroperanden bezeichnet. Mit anderen Worten bezieht sich eine gepackte Dateneinheit oder ein gepackter Datenvektor auf eine Sequenz von gepackten Datenelementen und ein gepackter Datenoperand oder ein Vektoroperand ist ein Quell- oder Zieloperand einer SIMD-Anweisung (auch bekannt als gepackte Datenanweisung oder Vektoranweisung).
Beispielsweise spezifiziert ein Typ von SIMD-Anweisung eine einzige Vektoroperation, der auf zwei Quellvektoroperanden in einer vertikalen Weise durchzuführen ist, um einen Zielvektoroperanden (auch als Ergebnisvektoroperand bezeichnet) der gleichen Größe zu erzeugen, mit der gleichen Anzahl von Datenelementen und in der gleichen Datenelementreihenfolge. Die Datenelemente in den Quellvektoroperanden werden als Quelldatenelemente bezeichnet, während die Datenelemente in dem Zielvektoroperand als Ziel- oder Ergebnisdatenelemente bezeichnet werden. Diese Quellvektoroperanden sind von der gleichen Größe und enthalten Datenelemente der gleichen Breite und daher enthalten sie die gleiche Anzahl von Datenelementen. Die Quelldatenelemente in den gleichen Bitpositionen in den zwei Quellvektoroperanden bilden Paare von Datenelementen (auch als entsprechende Datenelemente bezeichnet, das heißt, dass das Datenelement in Datenelementposition 0 jedes Quellvektoroperanden dem Datenelement in Datenelementposition 1 jedes Quellvektoroperanden entspricht, und so weiter). Die Operation, die durch die SIMD-Anweisung spezifiziert wird, wird getrennt auf jedem dieser Paare von Quelldatenelementen durchgeführt, um eine passende Anzahl von Ergebnisdatenelementen zu erzeugen, und daher hat jedes Paar von Quelldatenelementen ein entsprechendes Ergebnisdatenelement. Da die Operation vertikal ist und da der Ergebnisvektoroperand die gleiche Größe hat, die gleiche Anzahl von Datenelementen hat und die Ergebnisdatenelemente in der gleichen Datenelementreihenfolge gespeichert werden wie die Quellvektoroperanden, sind die Ergebnisdatenelemente in der gleichen Bitposition des Ergebnisvektoroperanden wie ihr entsprechendes Paar von Quelldatenelementen in den Quellvektoroperanden. Zusätzlich zu diesem exemplarischen Typ von SIMD-Anweisung gibt es eine Vielzahl von anderen Typen von SIMD-Anweisungen (z. B. der nur einen hat oder mehr als zwei Quellvektoroperanden hat, der in einer horizontalen Weise vorgeht, der einen Ergebnisvektoroperanden erzeugt, der von einer anderen Größe ist, der eine andere Größe von Datenelementen hat und/oder der eine andere Datenelementreihenfolge hat). Es ist zu verstehen, dass der Begriff Zielvektoroperand (oder Zieloperand) als das direkte Ergebnis eines Durchführens der Operation definiert ist, die durch eine Anweisung spezifiziert wird, einschließlich der Speicherung dieses Zielvektoroperanden an einer Stelle (sei es ein Register oder eine Speicheradresse, das/die durch die Anweisung spezifiziert ist), so dass darauf als ein Quelloperand durch eine andere Anweisung zugegriffen werden kann (durch Spezifikation der gleichen Stelle durch die andere Anweisung).
Figurenliste
Die vorliegende Erfindung ist in den Figuren der beigefügten Zeichnungen als Beispiel und nicht als Beschränkung dargestellt, in denen gleiche Bezugszeichen gleiche Elemente angeben und in denen:

1 eine Ausführungsform von Hardware darstellt, um eine cumprod-Anweisung zu verarbeiten,
2 ein Beispiel einer Ausführung einer cumprod-Anweisung gemäß einer Ausführungsform darstellt,
3 ein Beispiel einer Ausführung einer cumprod-Anweisung gemäß einer Ausführungsform darstellt,
4 Ausführungsformen der cumprod-Anweisung darstellt,
5 eine Ausführungsform eines Verfahrens darstellt, das durch einen Prozessor durchgeführt wird, um eine cumprod-Anweisung zu verarbeiten,
6 eine Ausführungsform des Ausführungsabschnitts des Verfahrens darstellt, das durch einen Prozessor durchgeführt wird, um eine cumprod-Anweisung zu verarbeiten,
7A-7B Blockdiagramme sind, die ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung darstellen,
8A-D ein Blockdiagramm ist, das ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat gemäß Ausführungsformen der Erfindung darstellt,
9 ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform der Erfindung ist,
10A ein Blockdiagramm ist, das sowohl eine beispielhafte geordnete Pipeline als auch eine beispielhafte Registerumbenennungs-, ungeordnete Frage-/Ausführungspipeline gemäß Ausführungsformen der Erfindung darstellt,
10B ein Blockdiagramm ist, das sowohl eine beispielhafte Ausführungsform eines geordneten Architekturkerns als auch einen beispielhaften Registerumbenennungs-, ungeordneten Frage-/Ausführungsarchitekturkern gemäß Ausführungsformen der Erfindung darstellt,
11A-B ein Blockdiagramm einer spezifischeren beispielhaften geordneten Kernarchitektur darstellt, wobei der Kern einer von mehreren logischen Blöcken (einschließlich anderer Kerne des gleichen Typs und/oder unterschiedlicher Typen) in einem Chip wäre,
12 ein Blockdiagramm eines Prozessors 1200 ist, der mehr als einen Kern haben kann, eine integrierte Speichersteuerung haben kann und integrierte Grafiken haben kann, gemäß Ausführungsformen der Erfindung,
13-16 Blockdiagramme von beispielhaften Computerarchitekturen sind und
17 ein Blockdiagramm ist, das die Verwendung eines Softwarekonvertierers gegenüberstellt, um binäre Anweisungen in einem Quellanweisungssatz in binäre Anweisungen in einem Zielanweisungssatz gemäß Ausführungsformen der Erfindung zu konvertieren.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt. Es versteht sich jedoch, dass Ausführungsformen der Erfindung ohne diese spezifischen Einzelheiten ausgeführt werden können. In anderen Beispielen wurden allgemein bekannte Schaltungen, Strukturen und Techniken nicht ausführlich gezeigt, um das Verständnis dieser Beschreibung nicht zu beeinträchtigen.
Bezüge in der Spezifikation auf „eine Ausführungsform“, „eine beispielhafte Ausführungsform“ usw. geben an, dass die beschriebene Ausführungsform ein/e bestimmte/s Merkmal, Struktur oder Eigenschaft aufweist, es muss jedoch nicht jede Ausführungsform das/die bestimmte Merkmal, Struktur oder Eigenschaft aufweisen. Des Weiteren beziehen sich derartige Ausdrücke nicht notwendigerweise auf die gleiche Ausführungsform. Ferner, wenn ein/e bestimmtes Merkmal, Struktur oder Eigenschaft in Verbindung mit einer Ausführungsform beschrieben wird, wird vorgebracht, dass es innerhalb des Wissens von Fachleuten auf dem Gebiet liegt, ein/e derartige/s Merkmal, Struktur oder Eigenschaft in Verbindung mit anderen Ausführungsformen zu bestimmen, ob diese ausdrücklich beschrieben sind oder nicht.
Ein kumulatives Produkt ist eine Sequenz von Teilprodukten einer gegebenen Sequenz. Zum Beispiel sind die kumulativen Produkte der Sequenz {a,b,c,...} a, a*b, a*b*c usw. Für Schleifen, bei denen der Wert der aktuellen Iteration von vorhergehenden Iterationen abhängt, können eine effiziente horizontale kumulative Summe und ein Produkt potentiell eine profitable Vektorisierung ermöglichen, trotz der schleifengetragenen Abhängigkeit. Als einfaches Beispiel wird die folgende Schleife betrachtet:


 int v = 0;
       für (int i = 0; i < 8; ++i) {
              a[i] = v + fun(i);
              v = a[i];
       }

wobei fun(i) eine vektorisierbare Funktion darstellt, um einen Wert basierend auf dem Schleifenindex zu berechnen. In diesem Beispiel hängt der Wert für a, durch i indiziert, von dem Wert in der vorherigen Iteration ab, was eine Abhängigkeit schafft, die eine effiziente Vektorisierung erschwert.

Ein praktischeres Beispiel des Problems tritt in Maschinenlernalgorithmen für die Induktion von Entscheidungsbäumen auf. Die Entscheidungsbaumalgorithmen suchen rekursiv nach Teilungspunkten für Merkmale, die die Ausgabedaten am besten klassifizieren. Zum Beispiel könnte ein Streamingvideodienst vorhersagen, dass jemandem ein Film nur gefallen wird, wenn er jünger als 13 Jahre alt ist. In dem Trainingsprozess wird jeder Teilungspunkt für das Merkmal (z. B. Alter) ausgewertet (bis zu N-1 Teilungspunkte für N Datensätze). Für jeden Teilungspunkt wird eine Metrik (z. B. Informationsgewinn basierend auf Shannon-Entropie, GINI usw.) darauf basierend berechnet, wie die Ausgangsklassen aufgeteilt werden würden (z. B. <25 Jahre, 43 % gefiel der Film). Um viele mögliche Teilungspunkte effizient zu auszuwerten, wird jedes Merkmal nach einem Wert sortiert. Die Schleife über den sortierten Daten ermöglicht eine schnelle Aktualisierung der Klassengrößen, die in der Teilungsmetrik verwendet werden, sie führt jedoch auch mehrere schleifengetragene Abhängigkeiten ein. Eine Codeauflistung für die GINI-Berechnung von dem ScalParC-Entscheidungsbaumalgorithmus in NU-Minebench 2,0 ist unten gezeigt. In der Auflistung indiziert j das Klassenetikett für den Datensatz. Schleifenabhängigkeiten für Cabove, Cbelow, split_above und split below existieren.

Hierin werden Ausführungsform-Vorrichtungen, -Systeme und -Verfahren unter Verwendung einer Kumulativprodukt(„cumprod“)-Anweisung ausgeführt, die, wenn sie durch einen Hardwareprozessor ausgeführt wird, ein kumulatives Produkt veranlasst, für jede Datenelementposition eines gepackten Datenquelloperanden berechnet und in einer entsprechenden Datenelementposition eines gepackten Datenzieloperanden gespeichert zu werden.

1 stellt eine Ausführungsform von Hardware dar, um eine cumprod-Anweisung zu verarbeiten. Die dargestellte Hardware ist typischerweise ein Teil eines Hardwareprozessors oder Kerns, wie etwa ein Teil einer zentralen Verarbeitungseinheit, eines Beschleunigers usw.

Eine cumprod-Anweisung wird durch Decodierschaltkreis 101 empfangen. Zum Beispiel empfängt der Decodierschaltkreis 101 diese Anweisung von einer/m Abruflogik/- schaltkreis. Die cumprod-Anweisung weist Felder für einen Quelloperanden (z. B. ein gepacktes Datenregister (manchmal Vektorregister genannt) oder eine Speicherstelle) und einen Zieloperanden (z. B. ein gepacktes Datenregister (manchmal Vektorregister genannt) oder eine Speicherstelle) auf. Ausführlichere Ausführungsformen von Anweisungsformaten werden später ausführlich beschrieben.

Der Decodierschaltkreis 101 decodiert die cumprod-Anweisung in eine oder mehrere Operationen. In einigen Ausführungsformen weist dieses Decodieren ein Erzeugen von mehreren Mikrooperationen auf, die durch den Ausführungsschaltkreis (wie etwa Ausführungsschaltkreis 109) durchzuführen sind. Der Decodierschaltkreis 101 decodiert auch Anweisungspräfixe.

In einigen Ausführungsformen stellt ein Registerumbenennungs-, Registerzuweisungs- und/oder Planungsschaltkreis 103 eine Funktionalität für eines oder mehrere von Folgendem bereit: 1) Umbenennen von logischen Operandenwerten auf physische Operandenwerte (z. B. eine Register-Aliastabelle in einigen Ausführungsformen), 2) Zuweisen von Statusbits und -kennzeichen zu der decodierten Anweisung und/oder 3) Planen der decodierten Anweisung zur Ausführung auf einem Ausführungsschaltkreis aus einem Anweisungspool (z. B. unter Verwendung einer Reservierungsstation in einigen Ausführungsformen).

Register (Registerdatei) 105 und Speicher 107 speichern Daten als Operanden der cumprod-Anweisung, die auf Ausführungsschaltkreis 109 zu behandeln sind. Beispielhafte Registertypen weisen gepackte Datenregister, Mehrzweckregister und Gleitkomma-Register auf. Die Register 105 können auch Schreibmaskenregister aufweisen, wie hierin ausführlich beschrieben wird.

Ausführungsschaltkreis 109 führt die decodierte cumprod-Anweisung aus, die ein kumulatives Produkt veranlasst, für jede Datenelementposition eines gepackten Datenquelloperanden berechnet und in einer entsprechenden Datenelementposition eines gepackten Datenzieloperanden gespeichert zu werden.

In einigen Ausführungsformen schreibt Abschlussschaltkreis 111 ein Ergebnis architektonisch fest (z. B. schreibt ein Zielregister in dem Register 105 fest) und schließt die Anweisung ab.

2 stellt ein Beispiel einer Ausführung einer cumprod-Anweisung gemäß einer Ausführungsform dar. Dieses Beispiel ist nicht beschränkend auszulegen. Zum Beispiel ermöglichen die Lehren hierin eine Big-Endian-Format-Ausführung, während dieses Beispiel ein Little-Endian-Format verwendet.

Typischerweise hängen die Anzahl von gepackten Datenelementen, die zu extrahieren sind, und ihre Größen von dem Anweisungscodieren (Datenelementgröße) ab. Daher kann eine andere Anzahl von gepackten Datenelementen, wie etwa 2, 4, 8, 16, 32 oder 64, in der gepackten Datenquelle sein. Gepackte Datenzielregistergrößen weisen 64-bit, 128-bit, 256-bit und 512-bit auf.

In diesem Beispiel weist die Quelle 201 (z. B. ein gepacktes Datenregister oder eine Speicherstelle) vier gepackte Datenelemente auf. Die niedrigstwertige Datenelementposition speichert eine „2“ als ihren Wert und die höchstwertige Datenelementposition speichert eine „10“ als ihren Wert. Diese Werte werden als Kommazahl gezeigt, werden jedoch typischerweise als binäre oder hexadezimale Werte gespeichert.

Arithmetischer Schaltkreis 203 („MUL-SCHALTKREIS“ in der Darstellung genannt, um hervorzuheben, dass eine Multiplikation durchgeführt wird), wie etwa eine arithmetische Logikeinheit, wird verwendet, um Multiplikationen durchzuführen. Insbesondere wird ein Wert von jeder Datenelementposition der Quelle 201 mit allen Werten von vorhergehenden Datenelementpositionen multipliziert. Zum Beispiel ist in der niedrigstwertigen Datenelementposition keine Multiplikation notwendig, da es keine vorhergehenden Datenelementpositionen gibt. Für die zweitniedrigstwertige Datenelementposition werden jedoch die Werte der Position (1 in diesem Beispiel) mit den Werten multipliziert, die in den Datenelementpositionen gespeichert sind, die ihr vorausgehen (in diesem Beispiel wird 2 mit 1 multipliziert). In einigen Ausführungsformen wird der unabhängige arithmetische Schaltkreis für die Multiplikationen verwendet. In anderen Ausführungsformen wird der gleiche arithmetische Schaltkreis für die Multiplikationen verwendet.

Das Ergebnis jeder Multiplikation (oder in dem Fall der niedrigstwertigen Datenelementposition keine Multiplikation) wird in einer entsprechenden Datenelementposition in dem Ziel 205 gespeichert (z. B. einem gespeicherten Datenregister oder einer Speicherstelle).

3 stellt ein Beispiel einer Ausführung einer cumprod-Anweisung gemäß einer Ausführungsform dar. Dieses Beispiel ist nicht beschränkend auszulegen. Zum Beispiel ermöglichen die Lehren hierin eine Big-Endian-Format-Ausführung, während dieses Beispiel ein Little-Endian-Format verwendet.

Typischerweise hängt die Anzahl von gepackten Datenelementen, die zu extrahieren ist, und ihre Größen von dem Anweisungscodieren (Datenelementgröße) ab. Daher kann eine andere Anzahl von gepackten Datenelementen, wie etwa 2, 4, 8, 16, 32 oder 64, in der gepackten Datenquelle sein. Gepackte Datenzielregistergrößen weisen 64-bit, 128-bit, 256-bit und 512-bit auf.

In diesem Beispiel weist die Quelle 301 (z. B. ein gepacktes Datenregister oder eine Speicherstelle) vier gepackte Datenelemente auf. Die niedrigstwertige Datenelementposition speichert eine „2“ als ihren Wert und die höchstwertige Datenelementposition speichert eine „10“ als ihren Wert. Diese Werte werden als Kommazahl gezeigt, werden jedoch typischerweise als binäre oder hexadezimale Werte gespeichert.

Arithmetischer Schaltkreis 303 („MUL-SCHALTKREIS“ in der Darstellung genannt, um hervorzuheben, dass eine Multiplikation durchgeführt wird), wie etwa eine arithmetische Logikeinheit, wird verwendet, um Multiplikationen durchzuführen. Insbesondere wird ein Wert von jeder Datenelementposition der Quelle 301 mit allen Werten von vorhergehenden Datenelementpositionen multipliziert. Zum Beispiel ist in der niedrigstwertigen Datenelementposition keine Multiplikation notwendig, da es keine vorhergehenden Datenelementpositionen gibt. Für die zweitniedrigstwertige Datenelementposition werden jedoch die Werte der Position (1 in diesem Beispiel) mit den Werten multipliziert, die in den Datenelementpositionen gespeichert sind, die ihr vorausgehen (in diesem Beispiel wird 2 mit 1 multipliziert). In einigen Ausführungsformen wird der unabhängige arithmetische Schaltkreis für die Multiplikationen verwendet. In anderen Ausführungsformen wird der gleiche arithmetische Schaltkreis für die Multiplikationen verwendet.

Das Ergebnis jeder Multiplikation (oder in dem Fall der niedrigstwertigen Datenelementposition keine Multiplikation) wird in einer entsprechenden Datenelementposition in dem Ziel 305 gespeichert (z. B. einem gespeicherten Datenregister oder einer Speicherstelle) gemäß Werten einer Maske 307 (wie etwa einem Schreibmaskenregister, das hierin ausgeführt wird). Zum Beispiel, wenn eine entsprechende Datenelementposition der Maske 307 eine „1“ ist, dass wird das Ergebnis in das Ziel geschrieben. Wenn die entsprechende Datenelementposition der Maske 307 eine „0“ ist, dann wird das Ergebnis nicht in das Ziel geschrieben. Natürlich kann eine Konvention, die „0“ benutzt, als die Angabe zum Schreiben verwendet werden.

Eine Ausführungsform eines Formats (einschließlich Felder) für eine cumprod-Anweisung ist cumprod{B/W/D/Q}{k} DST/SRC. In einigen Ausführungsformen ist cumprod{B/W/D/Q} der Opcode der Anweisung. B/W/D/Q gibt die Datenelementgrößen der/s Quellen/Ziels als Byte, Wort, Doppelwort und Quadword an. DST/SRC ist eine gepackte Datenquelle und ein Zielregister. K ist eine Schreibmaske, die in einigen Ausführungsformen, die hierin ausgeführt werden, verwendet wird.

Eine andere Ausführungsform eines Formats (einschließlich Felder) für eine cumprod-Anweisung ist cumprod{B/W/D/Q}{k} DST, SRC. In einigen Ausführungsformen ist cumprod{B/W/D/Q} der Opcode der Anweisung. B/W/D/Q gibt die Datenelementgrößen der/s Quellen/Ziels als Byte, Wort, Doppelwort und Quadword an. DST ist ein gepacktes Datenzielregister und SRC ist ein gepacktes Datenquellregister. K ist eine Schreibmaske, die in einigen Ausführungsformen, die hierin ausgeführt werden, verwendet wird.

Eine andere Ausführungsform eines Formats (einschließlich Felder) für eine cumprod-Anweisung ist cumprod{B/W/D/Q}{k} DST, SRCMEM. In einigen Ausführungsformen ist cumprod{B/W/D/Q} der Opcode der Anweisung. B/W/D/Q gibt die Datenelementgrößen der/s Quellen/Ziels als Byte, Wort, Doppelwort und Quadword an. DST ist ein gepacktes Datenzielregister und SRCMEM ist eine Quellspeicherstelle. K ist eine Schreibmaske, die in einigen Ausführungsformen, die hierin ausgeführt werden, verwendet wird.

Eine andere Ausführungsform eines Formats (einschließlich Felder) für eine cumprod-Anweisung ist cumprod{B/W/D/Q}{k} DSTMEM, SRCMEM. In einigen Ausführungsformen ist cumprod{B/W/D/Q} der Opcode der Anweisung. B/W/D/Q gibt die Datenelementgrößen der/s Quellen/Ziels als Byte, Wort, Doppelwort und Quadword an. DSTMEM ist eine Zielspeicherstelle und SRCMEM ist eine Quellspeicherstelle. K ist eine Schreibmaske, die in einigen Ausführungsformen, die hierin ausgeführt werden, verwendet wird.

Eine andere Ausführungsform eines Formats (einschließlich Felder) für eine cumprod-Anweisung ist cumprod{B/W/D/Q}{k} DSTMEM, SRC. In einigen Ausführungsformen ist cumprod{B/W/D/Q} der Opcode der Anweisung. B/W/D/Q gibt die Datenelementgrößen der/s Quellen/Ziels als Byte, Wort, Doppelwort und Quadword an. DSTMEM ist eine Zielspeicherstelle und SRC ist ein gepacktes Quelldatenregister. K ist eine Schreibmaske, die in einigen Ausführungsformen, die hierin ausgeführt werden, verwendet wird.

In Ausführungsformen weisen Codierungen der Anweisungen einen Speicheradressieroperanden vom Skala-Index-Basis(SIB)-Typ auf, der indirekt mehrere indizierte Zielstellen im Speicher identifiziert. In einer Ausführungsform weist ein Speicheroperand vom SIB-Typ ein Codieren auf, das ein Basisadressregister identifiziert. Die Inhalte des Basisadressregisters stellen eine Basisadresse im Speicher dar, von dem die Adressen der bestimmten Zielstellen im Speicher berechnet werden. Zum Beispiel ist die Basisadresse die Adresse der ersten Stelle in einem Block von potentiellen Zielstellen für eine erweiterte Vektoranweisung. In einer Ausführungsform weist ein Speicheroperand vom SIB-Typ ein Codieren auf, das ein Indexregister identifiziert. Jedes Element des Indexregisters spezifiziert einen Index- und Versatzwert, die verwendbar sind, um von der Basisadresse eine Adresse einer jeweiligen Zielstelle innerhalb eines Blocks von potentiellen Zielstellen zu berechnen. In einer Ausführungsform weist ein Speicheroperand vom SIB-Typ ein Codieren auf, das einen Skalierfaktor spezifiziert, der auf jeden Indexwert anzuwenden ist, wenn eine jeweilige Zieladresse berechnet wird. Zum Beispiel, wenn ein Skalierfaktorwert von vier in dem Speicheroperanden vom SIB-Typ codiert wird, wird jeder Indexwert, der von einem Element des Indexregisters erhalten wird, mit vier multipliziert und dann mit der Basisadresse multipliziert, um eine Zieladresse zu berechnen.

In einer Ausführungsform identifiziert ein Speicheroperand vom SIB-Typ der Form vm32{x,y,z} eine Vektoranordnung von Speicheroperanden, die unter Verwendung einer Speicheradressierung vom SIB-Typ spezifiziert sind. In diesem Beispiel ist die Anordnung von Speicheradressen unter Verwendung eines gemeinsamen Basisregisters, eines konstanten Skalierfaktors und eines Vektorindexregisters, das einzelne Elemente enthält, von denen jedes ein 32-bit-Indexwert ist, spezifiziert. Das Vektorindexregister kann ein XMM-Register (vm32x), ein YMM-Register (vm32y) oder ein ZMM-Register (vm32z) sein. In einer anderen Ausführungsform identifiziert ein Speicheroperand vom SIB-Typ der Form vm64{x,y,z} eine Vektoranordnung von Speicheroperanden, die unter Verwendung einer Speicheradressierung vom SIB-Typ spezifiziert sind. In diesem Beispiel ist die Anordnung von Speicheradressen unter Verwendung eines gemeinsamen Basisregisters, eines konstanten Skalierfaktors und eines Vektorindexregisters, das einzelne Elemente enthält, von denen jedes ein 64-bit-Indexwert ist, spezifiziert. Das Vektorindexregister kann ein XMM-Register (vm64x), ein YMM-Register (vm64y) oder ein ZMM-Register (vm64z) sein.

In einigen Ausführungsformen weist die cumprod-Anweisung einen Schreibmaskenregisteroperanden auf. Eine Schreibmaske wird verwendet, um unter bestimmten Bedingungen Operationen pro Element und ein Aktualisieren von Ergebnissen zu steuern. In Abhängigkeit von der Implementierung verwendet die Schreibmaske eine Zusammenführungs- oder Nullsetzungsmaskierung. Anweisungen, die mit einem Prädikatoperanden (maskenschreiben, Maske schreiben oder k registrieren) codiert sind, verwenden den Operanden, um eine Rechenoperation pro Element unter bestimmten Bedingungen und ein Aktualisieren eines Ergebnisses auf einen Zieloperanden zu steuern. Der Prädikatoperand ist als das Opmask(Schreibmasken)-Register bekannt. Die Opmask ist ein Satz von acht architektonischen Registern von Größe MAX_KL (64-bit). Es wird angemerkt, dass von diesem Satz von 8 architektonischen Registern nur k1 bis k7 als Prädikatoperand adressiert werden können. k0 kann als eine reguläre Quelle oder reguläres Ziel verwendet werden, kann jedoch nicht als ein Prädikatoperand codiert werden. Es wird ebenfalls angemerkt, dass ein Prädikatoperand verwendet werden kann, um eine Speicherfehlerunterdrückung für einige Anweisungen mit einem Speicheroperanden (Quelle oder Ziel) zu ermöglichen. Als ein Prädikatoperand enthalten die Opmask-Register ein Bit, um die Operation/Aktualisierung für jedes Datenelement eines Vektorregisters zu regeln. Im Allgemeinen können Opmask-Register Anweisungen mit Elementgrößen unterstützen: Gleitkomma mit einfacher Genauigkeit (float32), Ganzzahl-Doppelwort (int32), Gleitkomma mit doppelter Genauigkeit (float64), Ganzzahl-Quadword (int64). Die Länge eines Opmask-Registers, MAX_KL, ist ausreichend, um bis zu 64 Elemente mit einem Bit pro Element, d. h. 64 Bits, handzuhaben. Für eine gegebene Vektorlänge greift jede Anweisung nur auf die Anzahl von niedrigstwertigen Maskenbits zu, die basierend auf ihrem Datentyp notwendig sind. Ein Opmask-Register beeinflusst eine Anweisung bei Granularität pro Element. Somit werden jede numerische oder nicht numerische Operation jedes Datenelements und Aktualisierungen pro Element von Zwischenelementen für den Zieloperanden auf dem entsprechenden Bit des Opmask-Registers prädiziert. In den meisten Ausführungsformen führt eine Opmask, die als ein Prädikatoperand dient, die folgenden Eigenschaften aus: 1) die Operation der Anweisung wird nicht für ein Element durchgeführt, wenn das Opmaskbit nicht festgelegt ist (dies setzt voraus, dass keine Ausnahme oder Missachtung durch eine Operation auf einem maskierten Element verursacht werden kann, und folglich wird keine Ausnahmekennzeichnung als Ergebnis einer Maskierungsoperation aktualisiert); 2) ein Zielelement wird nicht mit dem Ergebnis der Operation aktualisiert, wenn das entsprechende Schreibmaskenbit nicht festgelegt ist. Stattdessen muss der Zielelementwert gewahrt werden (Zusammenführungsmaskierung) oder er muss auf null gesetzt werden (Nullsetzungsmaskierung); 3) für einige Anweisungen mit einem Speicheroperanden werden Speicherfehler für Elemente mit einem Maskenbit von 0 unterdrückt. Es wird angemerkt, dass dieses Merkmal ein vielseitiges Konstrukt bereitstellt, um eine Ablaufsteuerungsvorhersage zu implementieren, da die Maske tatsächlich ein Zusammenführungsverhalten für Vektorregisterziele bereitstellt. Als Alternative kann die Maskierung zur Nullsetzung anstatt zur Zusammenführung verwendet werden, so dass die ausmaskierten Elemente mit 0 aktualisiert werden, anstatt den alten Wert zu wahren. Das Nullsetzungsverhalten wird bereitgestellt, um die implizite Abhängigkeit von dem alten Wert zu entfernen, wenn sie nicht notwendig ist.

4 stellt Ausführungsformen der cumprod-Anweisung dar, einschließlich Felder den für Opcode 401, Zieloperand 403, Quelloperand 405 (falls notwendig) und in einigen Ausführungsformen einen Schreibmaskenoperanden 407.

5 stellt eine Ausführungsform eines Verfahrens dar, das durch einen Prozessor durchgeführt wird, um eine cumprod-Anweisung zu verarbeiten.

Bei 501 wird eine Anweisung abgerufen. Zum Beispiel wird eine cumprod-Anweisung abgerufen. Die cumprod-Anweisung weist Felder für einen Opcode und einen gepackten Datenquell- und Zieloperanden auf. In einigen Ausführungsformen weist die cumprod-Anweisung ein Feld für einen Schreibmaskenoperanden auf. In einigen Ausführungsformen wird die Anweisung aus einem Anweisungszwischenspeicher abgerufen.

Die abgerufene Anweisung wird bei 503 decodiert. Zum Beispiel wird die abgerufene cumprod-Anweisung durch einen Decodierschaltkreis, wie hierin ausführlich beschrieben, decodiert. In einigen Ausführungsformen wird die Anweisung in eine oder mehrere Mikrooperationen decodiert.

Daten, die dem Quelloperanden der decodierten Anweisung zugeordnet sind, werden bei 505 abgerufen. Zum Beispiel wird auf aufeinanderfolgende Elemente vom Speicher beginnend bei der Quelladresse zugegriffen oder es wird auf ein gepacktes Quell- und/oder Zieldatenregister zugegriffen.

Bei 507 wird die decodierte Anweisung durch einen Ausführungsschaltkreis (Hardware), wie hierin ausführlich beschrieben, ausgeführt. Für die cumprod-Anweisung wird die Ausführung für jede Datenelementposition des gepackten Datenquelloperanden einen Wert, der in der Datenelementposition gespeichert ist, mit allen Werten, die in vorhergehenden Datenelementpositionen des gepackten Datenquelloperanden gespeichert sind, multiplizieren und ein Ergebnis der Multiplikation in einer entsprechenden Datenelementposition des gepackten Datenzieloperanden speichern. In einigen Ausführungsformen hängt der Speicher jedes Ergebnisses von einem Schreibmaskenwert einer entsprechenden Position in einer Schreibmaske ab. In Abhängigkeit von der Ausführungsform können Multiplikationen nacheinander oder parallel durchgeführt werden.

In einigen Ausführungsformen wird die Anweisung bei 509 festgeschrieben oder abgeschlossen.

6 stellt eine Ausführungsform des Ausführungsabschnitts des Verfahrens dar, das durch einen Prozessor durchgeführt wird, um eine cumprod-Anweisung zu verarbeiten.

Bei 601 wird ein Wert einer ersten Datenelementposition des Quelloperanden in dem Zieloperanden an einer Datenelementposition gespeichert, die der ersten Datenelementposition des Quelloperanden entspricht. Zum Beispiel wird ein Wert einer niedrigstwertigen Datenelementposition des Quelloperanden (wie etwa eines gepacktes Datenregisters oder einer Speicherstelle) in einer niedrigstwertigen Datenelementposition des Zieloperanden (wie etwa einem gepackten Datenregister oder einer Speicherstelle) gespeichert. Ein Beispiel dafür ist in 2 gezeigt, in der „2“ von der niedrigstwertigen Datenelementposition der Quelle 201 in dem Ziel 205 gespeichert wird.

Der Wert von der ersten Datenelementposition der Quelle wird mit einem Wert von einer zweiten (nachfolgenden) Datenelementposition der Quelle multipliziert, die unmittelbar benachbart zu der, und größer als die, erste Datenelementposition der Quelle bei 603 ist. Zum Beispiel wird der Wert des nächsten niedrigstwertigen Datenelements der Quelle mit dem Wert der niedrigstwertigen Datenelementposition der Quelle multipliziert. Ein Beispiel dafür ist in 2 gezeigt, in der „2“ mit „1“ von der Quelle 201 multipliziert wird.

Das Ergebnis der Multiplikation von 603 wird gespeichert und in dem Ziel an der Datenelementposition gespeichert, die der größeren Datenelementposition 205 entspricht. Ein Beispiel dafür ist in 2 gezeigt, in der „2“ mit „1“ von der Quelle 201 multipliziert wird und als „3“ in der Datenelementposition des Ziels gespeichert wird, das dem nächsten niedrigstwertigen Datenelement der Quelle entspricht. In einigen Ausführungsformen wird dieser Speicher einer Schreibmaske, wie zuvor ausführlich beschrieben, unterzogen.

Eine Bestimmung, ob alle Datenelementpositionen in der Quelle ausgewertet wurden (falls notwendig einer Multiplikation unterzogen wurden), wird bei 607 durchgeführt.

Wenn alle Datenelementpositionen ausgewertet wurden, ist die Ausführung abgeschlossen. Wenn nicht alle Datenelementpositionen ausgewertet wurden, wird ein Wert von der Multiplikation von 603 mit einem Wert von einer nächsten Datenelementposition der Quelle bei 609 multipliziert, die unmittelbar benachbart zu der, und größer als die, nachfolgende Datenelementposition von 603 ist.

Das Ergebnis der Multiplikation 609 wird gespeichert und in dem Ziel an einer Datenelementposition gespeichert, die der größeren Datenelementposition entspricht. In einigen Ausführungsformen wird dieser Speicher einer Schreibmaske, wie zuvor ausführlich beschrieben, unterzogen. Eine Bestimmung, ob alle Datenelementpositionen in der Quelle ausgewertet wurden (falls notwendig einem Multiplizieren unterzogen wurden), wird bei 607 durchgeführt.

Die Figuren unten führen beispielhafte Architekturen und Systeme aus, um Ausführungsformen von oben zu implementieren. In einigen Ausführungsformen werden eine oder mehrere Hardwarekomponenten und/oder Anweisungen, die oben beschrieben werden, wie unten ausgeführt emuliert oder als Softwaremodule implementiert.

Ausführungsformen der Anweisung(en), die oben ausführlich beschreiben werden, werden ausgeführt, können in einem „generischen vektorfreundlichen Anweisungsformat“ ausgeführt werden, das unter ausführlich beschreiben wird. In anderen Ausführungsformen wird ein derartiges Format nicht benutzt und ein anderes Anweisungsformat wird verwendet, die Beschreibung unten der Schreibmaskenregister, verschiedener Datentransformationen (Swizzle, Übertragung usw.), Adressierung usw. ist im Allgemeinen auf die Beschreibung der Ausführungsformen der Anweisung(en) oben anwendbar. Zudem sind beispielhafte Systeme, Architekturen und Pipelines unten ausführlich dargelegt. Ausführungsformen der Anweisung(en) oben können auf derartigen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf diese beschränkt.

Ein Anweisungssatz kann ein oder mehrere Anweisungsformate aufweisen. Ein gegebenes Anweisungsformat kann verschiedene Felder (z. B. Anzahl von Bits, Bitstelle) definieren, um unter anderem die Operation, die durchzuführen ist (z. B. Opcode), und den (die) Operanden, auf dem (denen) die Operation durchzuführen ist, und/oder (ein) andere(s) Datenfeld(er) zu spezifizieren. Einige Anweisungsformate werden ferner durch die Definition von Anweisungsvorlagen (oder Unterformate) runtergebrochen. Zum Beispiel können die Anweisungsvorlagen eines gegebenen Anweisungsformats definiert werden, um unterschiedliche Untersätze der Felder des Anweisungsformats (die enthaltenen Felder sind typischerweise in der gleichen Reihenfolge, zumindest einige haben jedoch unterschiedliche Bitpositionen, da sie weniger Felder enthalten sind) zu haben, und/oder definiert werden, um ein gegebenes Feld anders auszulegen. Daher wird jede Anweisung einer ISA unter Verwendung eines gegebenen Anweisungsformats ausgedrückt (und, falls definiert, in einer der Anweisungsvorlagen des Anweisungsformats) und weist Felder zum Spezifizieren der Operation und der Operanden auf. Zum Beispiel hat eine beispielhafte ADD-Anweisung einen spezifischen Opcode und ein Anweisungsformat, das ein Opcode-Feld aufweist, um den Opcode zu spezifizieren, und Operandenfelder, um Operanden (Quelle1/Ziel und Quelle2) auszuwählen, und ein Vorkommen dieser ADD-Anweisung in einem Anweisungsstrom wird spezifische Inhalte in den Operandenfeldern haben, die spezifische Operanden auswählen. Ein Satz von SIMD-Erweiterungen, die als Advanced Vector Extensions (AVX) (AVX1 and AVX2) bezeichnet werden und das Vector Extensions (VEX)-Codierschema verwenden, wurden freigegeben und/oder veröffentlicht (z. B. siehe Handbuch für Softwareentwickler von Intel® 64 und IA-32-Architekturen (Intel® 64 and IA-32 Architectures Software Developer's Manual), September 2014, und siehe Programmierreferenz für Intel® Advanced Vector Extensions (Intel® Advanced Vector Extensions Programming Reference), Oktober 2014).

Beispielhafte Anweisungsformate

Ausführungsformen der Anweisung(en), die hierin beschrieben werden, können in unterschiedlichen Formaten ausgeführt werden. Zudem sind beispielhafte Systeme, Architekturen und Pipelines unten ausführlich dargelegt. Ausführungsformen der Anweisung(en) können auf derartigen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht darauf beschränkt.

Generisches vektorfreundliches Anweisungsformat

Ein vektorfreundliches Anweisungsformat ist ein Anweisungsformat, das für Vektoranweisungen geeignet ist (z. B. gibt es bestimmte Felder, die für Vektoroperationen spezifisch sind). Während Ausführungsformen beschrieben werden, in denen sowohl Vektorals auch Skalaroperationen durch das vektorfreundliche Anweisungsformat unterstützt werden, verwenden alternative Ausführungsformen nur Vektoroperationen vom vektorfreundlichen Anweisungsformat.

7A-7B sind Blockdiagramme, die ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung darstellen. 7A ist ein Blockdiagramm, das ein generisches vektorfreundliches Anweisungsformat und Klasse-A-Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung darstellt, während 7B ein Blockdiagramm ist, das das generische vektorfreundliches Anweisungsformat und Klasse-B-Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung darstellt. Insbesondere ein generisches vektorfreundliches Anweisungsformat 700, für das Klasse-A- und Klasse-B-Anweisungsvorlagen definiert sind, wovon beide keine Anweisungsvorlagen für Nichtspeicherzugriff 705 und Anweisungsvorlagen für Speicherzugriff 720 aufweisen. Der Begriff generisch im Kontext des vektorfreundlichen Anweisungsformats bezieht sich auf das Anweisungsformat, das nicht an einen spezifischen Anweisungssatz gebunden ist.

Während Ausführungsformen der Erfindung beschrieben werden, in denen das vektorfreundliche Anweisungsformat Folgendes unterstützt: eine 64 Byte Vektoroperandenlänge (oder Größe) mit 32 Bit (4 Byte) oder 64 Bit (8 Byte) Datenelementbreiten (oder Größen) (und daher besteht einen 64-Byte-Vektor aus entweder 16 Elementen von Doppelwortgröße oder alternativ 8 Elementen von Quadwordgröße), eine 64 Byte Vektoroperandenlänge (oder Größe) mit 16 Bit (2 Byte) oder 8 Bit (1 Byte) Datenelementbreiten (oder Größen), eine 32 Byte Vektoroperandenlänge (oder Größe) mit 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte) Datenelementbreiten (oder Größen) und eine 16 Byte Vektoroperandenlänge (oder Größe) mit 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte) Datenelementbreiten (oder Größen); können alternative Ausführungsformen mehr, weniger und/oder unterschiedliche Vektoroperandengrößen (z. B. 256 Byte Vektoroperanden) mit mehr, weniger oder unterschiedlichen Datenelementbreiten (z. B. 128 Bit (16 Byte) Datenelementbreiten) unterstützen.

Die Klasse-A-Anweisungsvorlagen in 7A weisen Folgendes auf: 1) innerhalb der Anweisungsvorlagen ohne Speicherzugriff 705 ist eine Anweisungsvorlage vom Vollrundungssteuertyp für Operation 710 ohne Speicherzugriff und eine Anweisungsvorlage vom Datentransformationstyp für Operation 715 ohne Speicherzugriff gezeigt und 2) innerhalb der Anweisungsvorlagen mit Speicherzugriff 720 ist eine temporale 725 Anweisungsvorlage mit Speicherzugriff und eine nicht temporale 730 Anweisungsvorlage mit Speicherzugriff gezeigt. Die Klasse-B-Anweisungsvorlagen in 7B weisen Folgendes auf: 1) innerhalb der Anweisungsvorlagen ohne Speicherzugriff 705 ist eine Anweisungsvorlage vom Teilsteuerungstyp für Operation 712 ohne Speicherzugriff und mit Schreibmaskensteuerung und eine Anweisungsvorlage vom vsize-Typ für Operation 717 ohne Speicherzugriff und mit Schreibmaskensteuerung gezeigt und 2) innerhalb der Anweisungsvorlagen mit Speicherzugriff 720 ist eine Anweisungsvorlage mit Speicherzugriff und Schreibmaskensteuerung 727 gezeigt.

Das generische vektorfreundliche Anweisungsformat 700 weist die folgenden Felder auf, die unten in der in 7A-7B dargestellten Reihenfolge aufgelistet sind.

Formatfeld 740 - ein spezifischer Wert (ein Anweisungsformat-Identifizierwert) identifiziert in diesem Feld einmalig das vektorfreundliche Anweisungsformat und daher Vorkommen von Anweisungen in dem vektorfreundlichen Anweisungsformat in Anweisungsströmen. Somit ist dieses Feld optional in dem Sinne, dass es für einen Anweisungssatz nicht notwendig ist, der nur das generische vektorfreundliche Anweisungsformat hat.

Basisoperationsfeld 742 - sein Inhalt erkennt unterschiedliche Basisoperationen.

Registerindexfeld 744 - sein Inhalt spezifiziert, direkt oder durch Adressenerzeugung, die Stellen des Quell- und Zieloperanden, die in Registern oder in einem Speicher sind. Diese weisen eine ausreichende Anzahl von Bits auf, um N Register von PxQ (z. B. 32×512, 16×128, 32×1024, 64×1024) Registerdateien auszuwählen. Während in einer Ausführungsform N bis zu drei Quell- und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quell- und Zielregister unterstützen (z. B. können sie bis zu zwei Quellen unterstützen, wobei eine dieser Quellen als Ziel agiert, können sie bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als Ziel agiert, können sie bis zu zwei Quellen und ein Ziel unterstützen).

Modifizierfeld 746 - sein Inhalt unterscheidet Vorkommen von Anweisungen in dem generischen Vektoranweisungsformat, das einen Speicherzugriff spezifiziert, von denjenigen, die dies nicht tun, das heißt zwischen Anweisungsvorlagen (746A) ohne Speicherzugriff 705 und Anweisungsvorlagen mit Speicherzugriff 720. Speicherzugriffsoperationen lesen und/oder schreiben auf die Speicherhierarchie (in einigen Fällen werden die Quell- und/oder Zieladressen unter Verwendung von Werten in Registern spezifiziert), während Nichtspeicherzugriffsoperationen dies nicht tun (z. B. sind die Quelle und Ziele Register). Während in einer Ausführungsform dieses Feld auch zwischen drei unterschiedliche Weisen auswählt, um Speicheradressberechnungen durchzuführen, können alternative Ausführungsformen mehr, weniger oder unterschiedliche Weisen unterstützen, um Speicheradressberechnungen durchzuführen.

Augmentationsoperationsfeld 750 - sein Inhalt erkennt, welche von einer Vielzahl von unterschiedlichen Operationen zusätzlich zu der Basisoperation durchzuführen ist. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 768, ein Alphafeld 752 und ein Betafeld 754 aufgeteilt. Das Augmentationsoperationsfeld 750 ermöglicht gemeinsamen Operationsgruppen, in einer einzigen Anweisung anstelle von 2, 3 oder 4 Anweisungen durchgeführt zu werden.

Skalafeld 760 - sein Inhalt ermöglicht das Skalieren des Inhalts des Indexfelds zur Speicheradresserzeugung (z. B. zur Adresserzeugung, die 2^Skala * Index + Basis verwendet).

Verschiebungsfeld 762A - sein Inhalt wird als Teil einer Speicheradresserzeugung verwendet (z. B. zur Adresserzeugung, die 2^Skala * Index + Basis + Verschiebung verwendet).

Verschiebungsfaktorfeld 762B (es wird angemerkt, dass die Juxtaposition von Verschiebungsfeld 762A direkt über Verschiebungsfaktorfeld 762B anzeigt, dass das eine oder das andere verwendet wird) - sein Inhalt wird als Teil einer Adresserzeugung verwendet; es spezifiziert einen Verschiebungsfaktor, der um die Größe eines Speicherzugriffs (N) zu skalieren ist - wobei N die Anzahl von Byte in dem Speicherzugriff ist (z. B. zur Adresserzeugung, die 2^Skala * Index + Basis + skalierte Verschiebung verwendet). Redundante niedrigwertige Bits werden ignoriert und daher wird der Inhalt des Verschiebungsfaktorfelds mit der Speicheroperanden-Gesamtgröße (N) multipliziert, um die Endverschiebung zu erzeugen, die beim Berechnen der effektiven Adresse verwendet wird. Der Wert von N wird durch die Prozessorhardware zur Laufzeit basierend auf dem Voll-Opcode-Feld 774 (hierin später beschrieben) und dem Datenmanipulationsfeld 754C bestimmt. Das Verschiebungsfeld 862A und das Verschiebungsfaktorfeld 762B sind optional in dem Sinne, dass sie nicht für die Anweisungsvorlagen ohne Speicherzugriff 705 verwendet werden und/oder unterschiedliche Ausführungsformen nur eine oder keine der beiden umsetzen.

Datenelementbreitenfeld 764 - sein Inhalt erkennt, welche von einer Anzahl von Datenelementbreiten zu verwenden ist (in einigen Ausführungsformen für alle Anweisungen, in anderen Ausführungsformen für nur ein paar der Anweisungen). Dieses Feld ist optional in dem Sinne, dass es nicht notwendig ist, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung von ein paar Opcode-Aspekten unterstützt werden.

Schreibmaskenfeld 770 - sein Inhalt steuert auf einer Basis pro Datenelementposition, ob die Datenelementposition in dem Zielvektoroperanden das Ergebnis der Basisoperation und Augmentationsoperation widerspiegelt. Klasse-A-Anweisungsvorlagen unterstützen Zusammenführungsschreibmaskierung, während Klasse-B-Anweisungsvorlagen sowohl Zusammenführungs- als auch Nullsetzungsschreibmaskierung unterstützen. Beim Zusammenführen ermöglichen es Vektormasken einem Satz von Elementen in dem Ziel, vor Aktualisierungen während der Ausführung einer Operation (die durch die Basisoperation und die Augmentationsoperation spezifiziert ist) geschützt zu werden, in einer anderen Ausführungsform wird der alte Wert jedes Elements des Ziels gewahrt, in dem das entsprechende Maskenbit eine 0 hat. Im Gegensatz dazu ermöglichen es bei Nullsetzungsvektormasken einem Satz von Elementen in dem Ziel, während der Ausführung einer Operation (die durch die Basisoperation und die Augmentationsoperation spezifiziert ist) auf null gesetzt zu werden, in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert hat. Ein Untersatz dieser Funktionalität ist die Fähigkeit, die Vektorlänge der Operation, die durchgeführt wird, zu steuern (das heißt die Spanne von Elementen, die modifiziert werden, vom ersten zum letzten), es ist jedoch notwendig, dass die Elemente aufeinanderfolgend modifiziert werden. Daher ermöglicht das Schreibmaskenfeld 770 Teilvektoroperationen, einschließlich Ladungen, Speichern, arithmetisch, logisch usw. Während Ausführungsformen der Erfindung beschrieben werden, in denen der Inhalt des Schreibmaskenfelds 770 eine Anzahl von Schreibmaskenregistern auswählt, die die zu verwendende Schreibmaske enthält (und daher identifiziert der Inhalt des Schreibmaskenfelds 770 indirekt die durchzuführende Maskierung), ermöglichen es alternative Ausführungsformen stattdessen oder zusätzlich dem Inhalt des Schreibmaskenfelds 770, direkt die durchzuführende Maskierung zu spezifizieren.

Zwischenfeld 772 - sein Inhalt ermöglicht die Spezifikation eines Zwischenprodukts. Dieses Feld ist optional in dem Sinne, dass es in einer Implementierung des generischen vektorfreundlichen Formats nicht vorliegt, das ein Zwischenprodukt nicht unterstützt, und es liegt in Anweisungen nicht vor, die ein Zwischenprodukt nicht verwenden.

Klassenfeld 768 - sein Inhalt unterscheidet zwischen unterschiedlichen Klassen von Anweisungen. Unter Bezugnahme auf 7A-B wählen die Inhalte dieses Felds zwischen Klasse-A- und Klasse-B-Anweisungen aus. In 7A-B werden Quadrate mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein spezifischer Wert in einem Feld vorliegt (z. B. jeweils Klasse A 768A und Klasse B 768B für das Klassenfeld 768 in 7A-7B).

Anweisungsvorlagen von Klasse A

In dem Fall der Anweisungsvorlagen ohne Speicherzugriff 705 von Klasse A wird das Alphafeld 752 als ein RS-Feld 752A ausgelegt, dessen Inhalt erkennt, welcher der unterschiedlichen Augmentationsoperationstypen durchzuführen ist (z. B. Rundung 752A.1 und Datentransformation 752A.2 sind jeweils für die Anweisungsvorlagen für Rundungstypoperation 710 ohne Speicherzugriff und Datentransformationstypoperation 715 ohne Speicherzugriff spezifiziert), während das Betafeld 754 erkennt, welche der Operationen des spezifizierten Typs durchzuführen sind. In den Anweisungsvorlagen ohne Speicherzugriff 705 liegen das Skalafeld 760, das Verschiebungsfeld 762A und das Verschiebungsskalafeld 762B nicht vor.

Anweisungsvorlagen ohne Speicherzugriff - Operation vom Vollsteuerungstyp

In der Anweisungsvorlage des Vollrundungssteuertyps für Operation 710 ohne Speicherzugriff ist das Betafeld 754 als ein Rundungssteuerfeld 754A ausgelegt, dessen Inhalt(e) ein statisches Runden bereitgestellt (bereitstellen). Während in den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerfeld 754A ein Feld 756 zum Unterdrücken aller Gleitkommaausnahmen (SAE) und ein Rundungsoperationssteuerfeld 758 aufweist, können alternative Ausführungsformen beide Konzepte in das gleiche Feld codieren oder nur eines oder beide dieser Konzepte/Felder haben (z. B. können sie nur das Rundungsoperationssteuerfeld 758 haben).

SAE-Feld 756 - sein Inhalt erkennt, ob die Ausnahmeereignisberichterstattung deaktiviert wird oder nicht, wenn der Inhalt des SAE-Felds 756 anzeigt, dass eine Unterdrückung aktiviert ist, eine gegebene Anweisung keine Art von Gleitkommaausnahmekennzeichnung berichtet und keine Gleitkommaausnahmeroutine erhoben wird.

Rundungsoperationssteuerfeld 758 - sein Inhalt erkennt, welche aus einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Gegen-null-Runden und Auf-Nächstes-Runden). Daher ermöglicht das Rundungsoperationssteuerfeld 758 die Veränderung des Rundungsmodus auf einer Basis pro Anweisung. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi aufweist, überschreibt der Inhalt des Rundungsoperationssteuerfelds 750 den Registerwert.

Anweisungsvorlagen ohne Speicherzugriff - Operation vom Datentransformationstyp

In der Anweisungsvorlage für Operation 715 vom Datentransformationstyp ohne Speicherzugriff wird das Betafeld 754 als ein Datentransformationsfeld 754B ausgelegt, dessen Inhalt erkennt, welche von einer Anzahl von Datentransformationen durchzuführen ist (z. B. keine Datentransformation, Swizzle, Übertragung).

In dem Fall einer Anweisungsvorlage mit Speicherzugriff 720 von Klasse A wird das Alphafeld 752 als ein Räumungshinweisfeld 752B ausgelegt, dessen Inhalt erkennt, welcher der Räumungshinweise zu verwenden ist (in 7A sind temporal 752B.1 und nicht temporal 752B.2 jeweils für die temporale 725 Anweisungsvorlage mit Speicherzugriff und die nicht temporale 730 Anweisungsvorlage mit Speicherzugriff spezifiziert), während das Betafeld 754 als ein Datenmanipulationsfeld 754C ausgelegt ist, dessen Inhalt erkennt, welche einer Anzahl von Datenmanipulationsoperationen (auch als Primitive bekannt) durchzuführen sind (z. B. keine Manipulation, Übertragung, Up-Konvertierung einer Quelle und Down-Konvertierung eines Ziels). Die Anweisungsvorlagen mit Speicherzugriff 720 weisen das Skalafeld 760 und optional das Verschiebungsfeld 762A oder das Verschiebungsskalafeld 762B auf.

Die Vektorspeicheranweisungen führen Vektorladungen von und Vektorspeicherungen auf den Speicher mit Konvertierungsunterstützung durch. Wie bei regulären Vektoranweisungen übertragen Vektorspeicheranweisungen Daten von/zu einem Speicher in einer datenelementbasierten Weise, mit den Elementen, die tatsächlich übertragen werden, wird durch die Inhalte der Vektormaske diktiert, die als die Schreibmaske ausgewählt wird.

Anweisungsvorlagen mit Speicherzugriff - Temporal

Temporale Daten sind Daten, die wahrscheinlich früh genug wiederverwendet werden, um vom Zwischenspeichern zu profitieren. Das heißt jedoch, dass ein Hinweis und unterschiedliche Prozessoren sie in unterschiedlichen Weisen implementieren können, einschließlich eines vollständigen Ignorierens des Hinweises.

Anweisungsvorlagen mit Speicherzugriff - Nicht temporal

Nicht temporale Daten sind Daten, die wahrscheinlich nicht früh genug aus dem Zwischenspeicher in dem Zwischenspeicher der ersten Ebene wiederverwendet werden und eine Räumungspriorität erhalten sollten. Das heißt jedoch, dass ein Hinweis und unterschiedliche Prozessoren sie in unterschiedlichen Weisen implementieren können, einschließlich eines vollständigen Ignorierens des Hinweises.

Anweisungsvorlagen von Klasse B

In dem Fall der Anweisungsvorlagen von Klasse B, wird das Alphafeld 752 als ein Schreibmaskensteuerung(Z)-Feld 752C ausgelegt, dessen Inhalt erkennt, ob die Schreibmaskierung, die durch das Schreibmaskenfeld 770 gesteuert wird, eine Zusammenführung oder eine Nullsetzung sein sollte.

In dem Fall von Anweisungsvorlagen von Klasse B ohne Speicherzugriff 705 wird ein Teil des Betafelds 754 als ein RL-Feld 757A ausgelegt, dessen Inhalt erkennt, welcher der unterschiedlichen Augmentationsoperationstypen durchzuführen ist (z. B. Rundung 757A. 1 und Vektorlänge (VSIZE) 757A.2 sind jeweils für die Anweisungsvorlage für Teilrundungssteuertypoperation 712 ohne Speicherzugriff und mit Schreibmaskensteuerung und Anweisungsvorlage für VSIZE-Typoperation 717 ohne Nichtspeicherzugriff und mit Schreibmaskensteuerung spezifiziert), während der Rest des Betafelds 754 erkennt, welche der Operationen des spezifizierten Typs durchzuführen ist. In den Anweisungsvorlagen ohne Speicherzugriff 705 liegen das Skalafeld 760, das Verschiebungsfeld 762A und das Verschiebungsskalafeld 762B nicht vor.

In der Anweisungsvorlage für Teilrundungssteuertypoperation 710 ohne Speicherzugriff und mit Schreibmaskensteuerung wird der Rest des Betafelds 754 als ein Rundungsoperationsfeld 759A ausgelegt und ein Ausnahmeereignisberichterstattung wird deaktiviert (eine gegebene Anweisungsvorlage berichtet von keiner GleitkommaAusnahmekennzeichnung und erhebt keine Gleitkommaausnahmeroutine).

Rundungsoperationssteuerfeld 759A - genau wie Rundungsoperationssteuerfeld 758 erkennt sein Inhalt, welche aus einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Gegen-null-Runden und Auf-Nächstes-Runden). Daher ermöglicht das Rundungsoperationssteuerfeld 759A die Veränderung des Rundungsmodus auf einer Basis pro Anweisung. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi aufweist, überschreibt der Inhalt des Rundungsoperationssteuerfelds 750 den Registerwert.

In der Anweisungsvorlage für VSIZE-Typoperation 717 ohne Speicherzugriff und mit Schreibmaskensteuerung wird der Rest des Betafelds 754 als ein Vektorlängenfeld 759B ausgelegt, dessen Inhalt erkennt, auf welcher von einer Anzahl von Datenvektorlängen durchzuführen ist (z. B. 128, 256 oder 512 Byte).

In dem Fall einer Anweisungsvorlage von Klasse B mit Speicherzugriff 720 wird ein Teil des Betafelds 754 als ein Übertragungsfeld 757B ausgelegt, dessen Inhalt erkennt, ob die Übertragungstyp-Datenmanipulationsoperation durchzuführen ist oder nicht, während der Rest des Betafelds 754 als das Vektorlängenfeld 759B ausgelegt wird. Die Anweisungsvorlagen mit Speicherzugriff 720 weisen das Skalafeld 760 und optional das Verschiebungsfeld 762A oder das Verschiebungsskalafeld 762B auf.

In Bezug auf das generische vektorfreundliche Anweisungsformat 700 ist ein Voll-Opcode-Feld 774 gezeigt, das das Formatfeld 740, das Basisoperationsfeld 742 und das Datenelementbreitenfeld 764 aufweist. Während eine Ausführungsform gezeigt wird, in der das Voll-Opcode-Feld 774 alle dieser Felder aufweist, weist das Voll-Opcode-Feld 774 weniger als alle dieser Felder in Ausführungsformen auf, die nicht alle davon unterstützen. Das Voll-Opcode-Feld 774 stellt den Operationscode (Opcode) bereit.

Das Augmentationsoperationsfeld 750, das Datenelementbreitenfeld 764 und das Schreibmaskenfeld 770 ermöglichen diesen Merkmalen, auf einer Basis pro Anweisung in dem generischen vektorfreundlichen Anweisungsformat spezifiziert zu sein.

Die Kombination aus Schreibmaskenfeld und Datenelementbreitenfeld erzeugt eingegebene Anweisungen, so dass sie es möglichen, dass die Maske basierend auf unterschiedlichen Datenelementbreiten angewandt wird.

Die verschiedenen Anweisungsvorlagen, die innerhalb Klasse A und Klasse B zu finden sind, sind in unterschiedlichen Situationen von Vorteil. In einigen Ausführungsformen der Erfindung können unterschiedliche Prozessoren oder unterschiedliche Kerne innerhalb eines Prozessor nur Klasse A, nur Klasse B oder beide Klassen unterstützen. Zum Beispiel kann ein ungeordneter Hochleistungsmehrzweck-Kern, der für ein Mehrzweckdatenverarbeitung ausgelegt ist, nur Klasse B unterstützen, ein Kern, der primär für grafische und/oder wissenschaftliche (Durchsatz-) Datenverarbeitung ausgelegt ist, kann nur Klasse A unterstützen, und ein Kern, der für beides ausgelegt ist, unterstützt beides (natürlich liegt ein Kern, der eine Mischung von Vorlagen und Anweisungen von beiden Klassen, jedoch nicht alle Vorlagen und Anweisungen von beiden Klassen hat, im Geltungsbereich der Erfindung). Auch ein einzelner Prozessor kann mehrere Kerne aufweisen, von denen alle die gleiche Klasse unterstützen, und unterschiedliche Kerne unterschiedliche Klassen unterstützen. Zum Beispiel kann in einem Prozessor mit getrennten Grafiken und Mehrzweckkernen einer der Grafikkerne, der primär für grafische und/oder wissenschaftliche Datenverarbeitung ausgelegt ist, nur Klasse A unterstützen, während einer oder mehrere der Mehrzweckkerne Hochleistungsmehrzweckkerne mit einer ungeordneten Ausführung und Registerumbenennung sein können, die für eine Mehrzweckdatenverarbeitung ausgelegt sind, die nur Klasse B unterstützen. Ein anderer Prozessor, der keinen getrennten Grafikkern hat, kann einen oder mehrere ungeordnete Mehrzweck- oder ungeordnete Kerne aufweisen, die sowohl Klasse A als auch Klasse B unterstützen. Natürlich können Merkmale einer Klasse auch in der anderen Klasse in unterschiedlichen Ausführungsformen der Erfindung umgesetzt werden. Programme, die in einer Hochsprache geschrieben sind, würden (gerade rechtzeitig kompiliert oder statisch kompiliert) in eine Vielzahl von unterschiedlichen ausführbaren Formen gebracht werden, einschließlich: 1) eine Form mit nur Anweisungen der Klasse(n), die durch den Zielprozessor zur Ausführung unterstützt wird (werden), oder 2) eine Form mit alternativen Routinen, die unter Verwendung von unterschiedlichen Kombinationen der Anweisungen von allen Klassen geschrieben sind, und mit einem Ablaufsteuerungscode, der die Routinen auswählt, um sie basierend auf den Anweisungen auszuführen, die durch den Prozessor unterstützt werden, der aktuell den Code ausführt.

Beispielhaftes spezifisches vektorfreundliches Anweisungsformat

8 ist ein Blockdiagramm, das ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat gemäß Ausführungsformen der Erfindung darstellt. 8 zeigt ein spezifisches vektorfreundliches Anweisungsformat 800, das in dem Sinne spezifisch ist, dass es die Stelle, Größe, Auslegung und Reihenfolge der Felder sowie Werte für einige dieser Felder spezifiziert. Das spezifische vektorfreundliche Anweisungsformat 800 kann verwendet werden, um den x86-Anweisungssatz zu erweitern, und daher sind einige der Felder ähnlich oder die gleichen wie diejenigen, die in dem existierenden x86-Anweisungssatz und dessen Erweiterung (z. B. AVX) verwendet werden. Dieses Format bleibt in Übereinstimmung mit dem Präfixcodierungsfeld, Echt-Opcode-Bytefeld, MOD-R/M-Feld, SIB-Feld, Verschiebungsfeld und Zwischenfeldern des existierenden x86-Anweisungssatzes mit Erweiterungen. Die Felder von 7, zu denen die Felder von 8 zugeordnet sind, sind dargestellt.

Es ist zu verstehen, dass, obwohl Ausführungsformen der Erfindung unter Bezugnahme auf das spezifische vektorfreundliche Anweisungsformat 800 in dem Kontext des generischen vektorfreundlichen Anweisungsformats 700 zum darstellerischen Zweck beschrieben werden, sich die Erfindung nicht auf das spezifische vektorfreundliche Anweisungsformat 800 beschränkt, wenn dies nicht beansprucht wird. Zum Beispiel wird bei dem generischen vektorfreundlichen Anweisungsformat 700 eine Vielzahl von möglichen Größen für die verschiedenen Feld erwägt, während das spezifische vektorfreundliche Anweisungsformat 800 mit Feldern spezifischer Größen gezeigt wird. Vor dem Hintergrund des spezifischen Beispiels, während das Datenelementbreitenfeld 764 als ein Ein-Bit-Feld in dem spezifischen vektorfreundlichen Anweisungsformat 800 dargestellt wird, wird die Erfindung nicht beschränkt (das heißt, dass beim generischen vektorfreundlichen Anweisungsformat 700 andere Größen des Datenelementbreitenfelds 764 erwägt werden).

Das generische vektorfreundliche Anweisungsformat 700 weist die folgenden Felder auf, die unten in der in 8A dargestellten Reihenfolge aufgeführt sind.

EVEX-Präfix (Bytes 0-3) 802 - ist in einer Vier-Byte-Form codiert.

Formatfeld 740 (EVEX Byte 0, Bits [7:0]) - das erste Byte (EVEX Byte 0) ist das Formatfeld 740 und es enthält 0x62 (den eindeutigen Wert, der zur Erkennung des vektorfreundlichen Anweisungsformats in einer Ausführungsform der Erfindung verwendet wird).

Die zweiten, vierten Bytes (EVEX Bytes 1-3) weisen eine Anzahl von Bitfeldern auf, die eine spezifische Fähigkeit bereitstellen.

REX-Feld 805 (EVEX Byte 1, Bits [7-5]) - besteht aus einem EVEX.R-Bitfeld (EVEX Byte 1, Bit [7] - R), EVEX.X-Bitfeld (EVEX Byte 1, Bit [6] - X) und 757BEX Byte 1, Bit[5] - B). Das EVEX.R-, EVEX.X- und EVEX.B-Bitfeld stellen die gleiche Funktionalität wie die entsprechenden VEX-Bitfelder bereit und sind unter Verwendung einer 1s-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 im Stand der Technik bekannt ist (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Hinzuführen von EVEX.R, EVEX.X und EVEX.B gebildet werden.

REX’-Feld 710 - dies ist der erste Teil des REX‘-Felds 710 und ist das EVEX.R'-Bitfeld (EVEX Byte 1, Bit [4] - R'), das verwendet wird, um entweder die oberen 16 oder unteren 16 des erweiterten 32 Registersatzes zu codieren. In einer Ausführungsform der Erfindung ist dieses Bit zusammen mit anderen, die unten dargelegt werden, in bitinvertiertem Format gespeichert, um (in dem allgemein bekannten x86-32-Bit-Modus) aus der BOUND-Anweisung zu erkennen, welches Echt-Opcode-Byte 62 ist, akzeptiert jedoch nicht in dem MOD-R/M-Feld (unten beschrieben) den Wert von 11 in dem MOD-Feld; alternative Ausführungsformen der Erfindung speichern diese und die anderen angegebenen Bits unten in dem invertierten Format nicht. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten wird R'Rrrr durch Kombinieren von EVEX.R', EVEX.R und das andere RRR aus anderen Feldern gebildet.

Opcodezuordnungsfeld 815 (EVEX Byte 1, Bits [3:0] - mmmm) - sein Inhalt codiert ein impliziertes führendes Opcodebyte (0F, 0F 38 oder 0F 3).

Datenelementbreitenfeld 764 (EVEX Byte 2, Bit [7] - W) - ist durch Bezeichnung EVEX.W dargestellt. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps zu definieren (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente).

EVEX.vvvv 820 (EVEX Byte 2, Bits [6:3]-vvvv) - die Rolle von EVEX.vvvv kann Folgendes aufweisen: 1) EVEX.vvvv codiert den ersten Quellregisteroperanden, in invertiertem (1s-Komplement-) Form spezifiziert, und ist für Anweisungen mit 2 oder mehr Quelloperanden gültig; 2) EVEX.vvvv codiert den Zielregisteroperanden, spezifiziert in 1s-Komplementform für bestimmte Vektorverschiebungen, oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Daher codiert EVEX.vvvv-Feld 820 die 4 niedrigwertigen Bits des ersten Quellregister-Spezifizierers, der in invertierter (1s-Komplement-) Form gespeichert ist. In Abhängigkeit von der Anweisung wird ein zusätzliches anderes EVEX-Bitfeld verwendet, um die Spezifizierergröße auf 32 Register zu erweitern.

EVEX.U 768 Klassenfeld (EVEX Byte 2, Bit [2]-U) - Wenn EVEX.U = 0, zeigt es Klasse A oder EVEX.U0 an; wenn EVEX.U = 1, zeigt es Klasse B oder EVEX.U1 an.

Präfixcodierungsfeld 825 (EVEX Byte 2, Bits [1:0]-pp) - stellt zusätzliche Bits für das Basisoperationsfeld bereit. Zusätzlich zur Bereitstellungsunterstützung für Vorläufer-SSE-Anweisungen in dem EVEX-Präfixformat hat dies auch den Vorteil des Kompaktierens des SIMD-Präfixes (anstelle eines Erforderns eines Bytes, um das SIMD-Präfix auszudrücken, erfordert das EVEX-Präfix nur 2 Bits). In einer Ausführungsform, um Vorläufer-SSE-Anweisungen zu unterstützen, die einen SIMD-Präfix (66H, F2H, F3H) in sowohl dem Vorläuferformat als auch in dem EVEC-Präfixformat verwenden, werden diese Vorläufer-SIMD-Präfixe in das SIMD-Präfixcodierungsfeld codiert und zur Laufzeit in das Vorläufer-SIMD-Präfix erweitert, bevor sie der PLA des Decoders bereitgestellt werden (damit die PLA sowohl das Vorläufer- als auch das EVEX-Format dieser Vorläuferanweisungen ohne Veränderung ausführen kann). Obwohl neuere Anweisungen den Inhalt des EVEX-Präfixcodierungsfelds als eine Opcodeerweiterung verwenden, erweitern bestimmte Ausführungsformen in einer ähnlichen Weise aus Gründen der Einheitlichkeit, ermöglichen es jedoch anderen Bedeutungen, durch diese Vorläufer-SIMD-Präfixe spezifiziert zu werden. Eine alternative Ausführungsform kann die PLA umgestalten, um die 2-Bit-SIMD-Präfixcodierungen zu unterstützen und erfordert daher keine Erweiterung.

Alphafeld 752 (EVEX Byte 3, Bit [7] - EH, auch bekannt als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.Schreibmaskensteuerung und EVEX.N, auch mit α dargestellt) - wie zuvor beschrieben, ist dieses Feld kontextspezifisch.

Betafeld 754 (EVEX Byte 3, Bits [6:4]-SSS, auch bekannt als EVEX.s_2-0, EVEX.r_2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB, auch mit βββ dargestellt) - wie zuvor beschrieben, ist dieses Feld kontextspezifisch.

REX'-Feld 710 - 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 unteren 16 des erweiterten 32 Registersatzes zu codieren. Dieses Bit wird in bitinvertiertem Format gespeichert. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten wird V'VVVV durch Kombinieren von EVEX.V', EVEX.vvvv gebildet.

Schreibmaskenfeld 770 (EVEX Byte 3, Bits [2:0]-kkk) - sein Inhalt spezifiziert den Index eines Register in den Schreibmaskenregistern wie zuvor beschrieben. In einer Ausführungsform der Erfindung hat der spezifische Wert EVEX.kkk=000 ein bestimmtes Verhalten, das impliziert, dass keine Schreibmaske für die bestimmte Anweisung verwendet wird (diese kann in einer Vielzahl von Weisen implementiert werden, einschließlich der Verwendung einer Schreibmaske, die mit allem fest verdrahtet ist, oder Hardware, die die Maskierungshardware umgeht).

Echt-Opcode-Feld 830 (Byte 4) ist auch als das Opcodebyte bekannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert.

MOD-R/M-Feld 840 (Byte 5) weist MOD-Feld 842, Reg-Feld 844 und R/M-Feld 846 auf. Wie zuvor beschrieben, unterscheidet der Inhalt des MOD-Felds 842 zwischen Speicherzugriffs- und Nichtspeicherzugriffsoperationen. Die Rolle des Reg-Felds 844 kann zu zwei Situationen zusammengefasst werden: Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden, oder Behandeln als eine Opcodeerweiterung und wird nicht verwendet, um einen Anweisungsoperanden zu codieren. Die Rolle von R/M-Feld 846 kann Folgendes aufweisen: Codieren des Anweisungsoperanden, der auf eine Speicheradresse verweist, oder Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden.

Skala, Index, Basis (SIB) Byte (Byte 6) 850 - Wie zuvor beschrieben, wird der Inhalt des Skalafelds 752 zur Speicheradresserzeugung verwendet. SIB.xxx 854 und SIB.bbb 856 - auf die Inhalte dieser Felder wurde zuvor in Bezug auf die Registerindizes Xxxx und Bbbb verwiesen.

Verschiebungsfeld 762 (Byte 7-10) - wenn MOD-Feld 842 10 enthält, sind Bytes 7-10 das Verschiebungsfeld 762A und es agiert so wie die Vorläufer-32-Bit-Verschiebung (disp32) und funktioniert bei Byte-Granularität.

Verschiebungsfaktorfeld 762B (Byte 7) - wenn MOD-Feld 842 01 enthält, ist 7 das Verschiebungsfaktorfeld 762B. Die Stelle dieses Felds ist die gleiche wie die der Vorläufer-x86-Anweisungssatz-8-Bit-Verschiebung (disp8), die bei Byte-Granularität funktioniert. Da disp8 vorzeichenerweitert wird, kann es nur zwischen -128 und 127 Bytes Versätze handhaben; im Sinne von 64 Byte Zwischenspeicher-Zeilen, verwendet disp8 8 Bits, die auf nur vier wirklich nützliche Werte -128, -64, 0 und 64 eingestellt werden können; da häufig ein größerer Bereich notwendig ist, wird disp32 verwendet; disp32 erfordert jedoch 4 Bytes. Im Gegensatz zu disp8 und disp32 ist Verschiebungsfaktorfeld 762B eine Neuauslegung von disp8; wenn Verschiebungsfaktorfeld 762B verwendet wird, wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfelds bestimmt, der mit der Größe des Speicheroperandenzugriffs (N) multipliziert wird. Dieser Verschiebungstyp wird als disp8*N bezeichnet. Dies verringert die durchschnittliche Anweisungslänge (ein einziges Byte wird für die Verschiebung verwendet, jedoch mit einem sehr viel größeren Bereich). Eine derartige komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung eine Vielzahl der Granularität des Speicherzugriffs ist, und daher müssen die redundanten niedrigwertigen Bits des Adressversatzes nicht codiert werden. Mit anderen Worten ersetzt das Verschiebungsfaktorfeld 762B die Vorläufer-x86-Anweisungssatz-8-Bit-Verschiebung. Daher wird das Verschiebungsfaktorfeld 762B auf die gleiche Weise wie eine x86-Anweisungssatz-8-Bit-Verschiebung codiert (also keine Veränderungen in den ModRM/SIB-Codierungsregeln) mit der einzigen Ausnahme, dass disp8 disp8*N überlappt. Mit anderen Worten gibt es keine Veränderung der Codierungsregeln oder Codierungslängen, sondern nur der Auslegung des Verschiebungswerts durch Hardware (die die Verschiebung um die Größe des Speicheroperanden skalieren muss, um einen bytebasierten Adressversatz zu erhalten). Zwischenfeld 772 funktioniert wie zuvor beschrieben.

Voll-Opcode-Feld

8B ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 800 darstellt, das das Voll-Opcode-Feld 774 gemäß einer Ausführungsform der Erfindung ausmacht. Insbesondere weist das Voll-Opcode-Feld 774 das Formatfeld 740, das Basisoperationsfeld 742 und das Datenelementbreiten(W)-Feld 764 auf. Das Basisoperationsfeld 742 weist das Präfixcodierungsfeld 825, das Opcodezuordnungsfeld 815 und das Echt-Opcode-Feld 830 auf.

Registerindexfeld

8C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 800 darstellt, das das Registerindexfeld 744 gemäß einer Ausführungsform der Erfindung ausmacht. Insbesondere weist das Registerindexfeld 744 das REX-Feld 805, das REX'-Feld 810, das MODR/M.reg-Feld 844, das MODR/M.r/m-Feld 846, das VVVV-Feld 820, xxx-Feld 854 und das bbb-Feld 856 auf.

Augmentationsoperationsfeld

8D ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 800 darstellt, das das Augmentationsoperationsfeld 750 gemäß einer Ausführungsform der Erfindung ausmacht. Wenn das Klasse(U)-Feld 768 0 enthält, bedeutet das EVEX.U0 (Klasse A 768A), wenn es 1 enthält, bedeutet das EVEX.U1 (Klasse B 768B). Wenn U=0 und das MOD-Feld 842 11 enthält (das heißt eine Nichtspeicherzugriffsoperation), wird das Alphafeld 752 (EVEX Byte 3, Bit [7] - EH) als das rs-Feld 752A ausgelegt. Wenn das rs-Feld 752A eine 1 enthält (Rundung 752A.1), wird das Betafeld 754 (EVEX Byte 3, Bits [6:4]- SSS) als das Rundungssteuerfeld 754A ausgelegt. Das Rundungssteuerfeld 754A weist ein Ein-Bit-SAE-Feld 756 und ein Zwei-Bit-Rundungsoperationsfeld 758 auf. Wenn das rs-Feld 752A eine 0 enthält (Datentransformation 752A.2), wird das Betafeld 754 (EVEX Byte 3, Bits [6:4]- SSS) als ein Drei-Bit-Datentransformationsfeld 754B ausgelegt. Wenn U=0 und das MOD-Feld 842 00, 01 oder 10 enthält (das heißt eine Speicherzugriffsoperation), wird das Alphafeld 752 (EVEX Byte 3, Bit [7] - EH) als das Räumungshinweis(EH)-Feld 752B ausgelegt und das Betafeld 754 (EVEX Byte 3, Bits [6:4]- SSS) wird als ein Drei-Bit-Datenmanipulationsfeld 754C ausgelegt.

Wenn U=1, wird das Alphafeld 752 (EVEX Byte 3, Bit [7] - EH) als das Schreibmaskensteuer(Z)-Feld 752C ausgelegt. Wenn U=1 und das MOD-Feld 842 11 enthält (das heißt eine Nichtspeicherzugriffsoperation), wird ein Teil des Betafelds 754 (EVEX Byte 3, Bit [4]- So) als das RL-Feld 757A ausgelegt, wenn es eine 1 enthält (Rundung 757A.1), wird der Rest des Betafelds 754 (EVEX Byte 3, Bit [6-5]- S_2-1) als das Rundungsoperationsfeld 759A ausgelegt, während, wenn das RL-Feld 757A eine 0 enthält (VSIZE 757.A2), der Rest des Betafelds 754 (EVEX Byte 3, Bit [6-5]- S_2-1) als das Vektorlängenfeld 759B (EVEX Byte 3, Bit [6-5]- L_1-0) ausgelegt wird. Wenn U=1 und das MOD-Feld 842 00, 01 oder 10 enthält (das heißt eine Speicherzugriffsoperation), wird das Betafeld 754 (EVEX Byte 3, Bits [6:4]- SSS) als das Vektorlängenfeld 759B (EVEX Byte 3, Bit [6-5]- L_1-0) und das Übertragungsfeld 757B (EVEX Byte 3, Bit [4]- B) ausgelegt.

Beispielhafte Registerarchitektur

9 ist ein Blockdiagramm einer Registerarchitektur 900 gemäß einer Ausführungsform der Erfindung ist. In der dargestellten Ausführungsform gibt es 32 Vektorregister 910, die 512 Bits breit sind; diese Register werden als zmm0 bis zmm31 bezeichnet. Die niedrigwertigen 256 Bits der unteren 16 zmm-Register werden auf Register ymm0-16 gelegt. Die niedrigwertigen 128 Bits des unteren 16 zmm-Registers (die niedrigwertigen 128 Bits der ymm-Register) werden über Register xmm0-15 gelegt. Dieses spezifische vektorfreundliche Anweisungsformat 800 arbeitet auf dieser überlagerten Registerdatei, wie in den Tabellen unten dargestellt ist.

Einstellbare Vektorlänge	Klasse	Operationen	Register
Anweisungsvorlagen, die das Vektorlängenfeld 759B nicht aufweisen	A ( 7A; U=0)	710, 715, 725, 730	zmm-Register (die Vektorlänge beträgt 64 Byte)
	B (Figur	712	zmm-Register (die Vektorlänge
	7B; U=1)		beträgt 64 Byte)
Anweisungsvorlagen, die das Vektorlängenfeld 759B nicht aufweisen	B ( 7B; U=1)	717, 727	zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Byte, 32 Byte oder 16 Byte), die von dem Vektorlängenfeld 759B abhängen

Mit anderen Worten wählt das Vektorlängenfeld 759B zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen aus, wobei jede derartige kürzere Länge die Hälfte der Länge der vorhergehenden Länge beträgt, und Anweisungsvorlagen ohne das Vektorlängenfeld 759B arbeiten auf der maximalen Vektorlänge. Ferner arbeiten in einer Ausführungsform die Klasse-B-Anweisungsvorlagen des spezifischen vektorfreundlichen Anweisungsformats 800 auf gepackten oder skalaren Gleitkommadaten mit einfacher/doppelter Genauigkeit und gepackten oder skalaren Ganzzahldaten. Skalare Operationen sind Operationen, die auf der niedrigstwertigen Datenelementposition in einem zmm-/ymm-/xmm-Register durchgeführt werden; die höherwertigen Datenelementpositionen bleiben entweder die gleichen, die sie vor der Anweisung waren, oder werden in Abhängigkeit von der Ausführungsform auf null gesetzt.

Schreibmaskenregister 915 - in der dargestellten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), die jeweils eine Größe von 64 Bits haben. In einer alternativen Ausführungsform haben die Schreibmaskenregister 915 eine Größe von 16 Bits. Wie zuvor beschrieben, kann in einer Ausführungsform der Erfindung das Vektormaskenregister k0 nicht als Schreibmaske verwendet werden; wenn das Codieren, das normalerweise k0 anzeigt, für eine Schreibmaske verwendet wird, wählt es eine festverdrahtete Schreibmaske von 0xFFFF aus, wodurch das Schreibmaskieren für diese Anweisung effektiv deaktiviert wird.

Mehrzweckregister 925 - in der dargestellten Ausführungsform gibt es sechzehn 64-Bit-Mehrzweckregister, die zusammen mit den existierenden x86-Adressierungsmodi für Adressspeicheroperanden verwendet werden. Diese Register werden mit den Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 bezeichnet.

Skalare Gleitkomma-Stackregisterdatei (x87-Stack) 945, auf der die gepackte flache MMX-Ganzzahl-Registerdatei 950 mit Alias ist - in der dargestellten Ausführungsform ist der x87-Stack ein Stack mit acht Elementen, der verwendet wird, um skalare Gleitkommaoperationen auf 32/64/80-Bit-Gleitkommadaten unter Verwendung der x87-Anweisungssatzerweiterung durchzuführen, während die MMX-Register verwendet werden, um Operationen auf gepackten 64-Bit-Ganzzahldaten 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 schmalere Register verwenden. Zudem können alternative Ausführungsformen der Erfindung mehr, weniger oder unterschiedliche Registerdateien und Register verwenden.

Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen

Prozessorkerne können auf unterschiedliche Weisen implementiert sein, für unterschiedliche Zwecke und in unterschiedlichen Prozessoren. Zum Beispiel können Implementierungen derartiger Kerne Folgendes aufweisen: 1) einen geordneten Mehrzweckkern, der für eine Mehrzweckdatenverarbeitung ausgelegt ist; 2) einen ungeordneten Hochleistungsmehrzweckkern, der für eine Mehrzweckdatenverarbeitung ausgelegt ist; 3) einen Spezialzweckkern, der primär für eine grafische und/oder wissenschaftliche (Durchsatz-) Datenverarbeitung ausgelegt ist. Implementierungen von unterschiedlichen Prozessor weisen Folgendes auf: 1) eine CPU, die einen oder mehrere geordnete Mehrzweckkerne aufweist, die zur Mehrzweckdatenverarbeitung ausgelegt ist, und/oder einen oder mehrere ungeordnete Mehrzweckkerne, die zur Mehrzweckdatenverarbeitung ausgelegt sind, und 2) einen Coprozessor, der einen oder mehrere Spezialzweckkerne aufweist, die primär für grafische und/oder wissenschaftliche (Durchsatz) ausgelegt sind. Derartige unterschiedliche Prozessoren führen zu unterschiedlichen Computersystemarchitekturen, die Folgendes aufweisen können: 1) den Coprozessor auf einem separaten Chip von der CPU, 2) den Coprozessor auf einem separaten Die in dem gleichen Paket wie eine CPU, 3) den Coprozessor auf dem gleichen Die wie eine CPU (in diesem Fall wird ein derartiger Coprozessor manchmal als eine Spezialzwecklogik bezeichnet, wie etwa integrierte grafische und/oder wissenschaftliche (Durchsatz-) Logik, oder als Spezialzweckkerne) und 4) ein System auf einem Chip, das auf dem gleichen Die der beschriebenen CPU (manchmal als der/die Anwendungskern(e) oder Anwendungsprozessor(en) bezeichnet) den oben beschriebenen Coprozessor und zusätzliche Funktionalitäten aufweist. Als Nächstes werden beispielhafte Kernarchitekturen beschrieben, gefolgt von Beschreibungen von beispielhaften Prozessoren und Computerarchitekturen.

Beispielhafte Kernarchitekturen

Blockdiagramm eines geordneten und ungeordneten Kerns

10A ist ein Blockdiagramm, das sowohl eine beispielhafte geordnete Pipeline als auch eine beispielhafte Registerumbenennungs-, ungeordnete Frage-/Ausführungspipeline gemäß Ausführungsformen der Erfindung darstellt. 10B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines geordneten Architekturkerns als auch einen beispielhaften Registerumbenennungs-, ungeordneten Frage-/Ausführungsarchitekturkern, der in einem Prozessor enthalten ist, gemäß Ausführungsformen der Erfindung darstellt. Die durchgehend linierten Kästchen in 10A-B stellen die geordnete Pipeline und den geordneten Kern dar, während die optionale Hinzufügung der gestrichelten Kästchen die Registerumbenennung, ungeordnete Frage-/Ausführungspipeline und -Kern darstellt. Angesichts der Tatsache, dass der geordnete Aspekt ein Untersatz des ungeordneten Aspekts ist, wird der ungeordnete Aspekt beschrieben.

In 10A weist eine Prozessorpipeline 1000 eine Abrufstufe 1002, eine Längendecodierstufe 1004, eine Decodierstufe 1006, eine Zuweisungsstufe 1008, eine Umbenennungsstufe 1010, eine Planungs-(auch bekannt als Versand- oder Ausgabe-)Stufe 1012, eine Registerlese-/Speicherlesestufe 1014, eine Ausführungsstufe 1016, eine Zurückschreib-/Speicherschreibstufe 1018, eine Ausnahmehandhabungsstufe 1022 und eine Festschreibungsstufe 1024 auf.

10B zeigt einen Prozessorkern 1090, der eine Frontendeinheit 1030 aufweist, die mit einer Ausführungsmotoreinheit 1050 gekoppelt ist, und beide sind mit einer Speichereinheit 1070 gekoppelt. Der Kern 1090 kann ein reduzierter Anweisungssatz-Datenverarbeitung(RISC)-Kern, ein komplexer Anweisungssatz-Datenverarbeitung(CISC)-Kern, ein sehr langer Anweisungswort(VLIW)-Kern oder ein hybrider oder alternativer Kerntyp sein. Noch eine weitere Option ist, dass der Kern 1090 ein Spezialzweckkern sein kann, wie etwa zum Beispiel ein Netzwerk- oder Kommunikationskern, Komprimierungsmotor, Coprozessorkern, Mehrzweck-Datenverarbeitung-Grafikverarbeitungseinheit(GPGPU)-Kern, Grafikkern oder dergleichen.

Die Frontendeinheit 1030 weist eine Verzweigungsvorhersageeinheit 1032 auf, die mit einer Anweisungszwischenspeichereinheit 1034 gekoppelt ist, die mit einem Anweisungsübersetzungspuffer (TLB) 1036 gekoppelt ist, der mit einer Anweisungsabrufeinheit 1038 gekoppelt ist, die mit einer Decodiereinheit 1040 gekoppelt ist. Die Decodiereinheit 1040 (oder der Decoder) kann Anweisungen decodieren und als einen Ausgang einer oder mehrere Mikrooperationen, Mikrocode-Eintrittspunkte, Mikroanweisungen, andere Anweisungen oder andere Steuersignale erzeugen, die von den ursprünglichen Anweisungen decodiert sind oder die diese reflektieren oder die davon abgeleitet sind. Die Decodiereinheit 1040 kann unter Verwendung von verschiedenen unterschiedlichen Mechanismen implementiert sein. Beispiele für geeignete Mechanismen weisen Nachschlagtabellen, Hardwareimplementierungen, programmierbare logische Anordnungen (PLA), Mikrocode-Festwertspeicher (ROMs) usw. auf. In einer Anordnung weist der Kern 1090 einen Mikrocode-ROM oder ein anderes Medium auf, das einen Mikrocode für bestimmte Makroanweisungen speichert (z. B. in Decodiereinheit 1040 oder andernfalls innerhalb der Frontendeinheit 1030). Die Decodiereinheit 1040 ist mit einer Umbenennungs-/Zuweisungseinheit 1052 in der Ausführungsmotoreinheit 1050 gekoppelt.

Die Ausführungsmotoreinheit 1050 weist die Umbenennungs-/Zuweisungseinheit 1052 auf, die mit einer Abschlusseinheit 1054 und einem Satz von einer oder mehreren Planungseinheit(en) 1056 gekoppelt ist. Die Planungseinheit(en) 1056 stellt (stellen) eine Anzahl von unterschiedlichen Planungseinrichtungen dar, einschließlich Reservierungsstationen, zentralem Anweisungsfenster usw. Die Planungseinheit(en) 1056 ist (sind) mit der (den) physischen Registerdateieinheit(en) 1058 gekoppelt. Jede der physischen Registerdateieinheiten 1058 stellt eine oder mehrere physische Registerdateien dar, von denen unterschiedliche einen oder mehrere unterschiedliche Datentypen speichern, wie etwa skalare Ganzzahl, skalares Gleitkomma, gepackte Ganzzahl, gespeichertes Gleitkomma, Vektorganzzahl, Vektorgleitkomma, Status (z. B. ein Anweisungszeiger, der die Adresse der nächsten Anweisung ist, die auszuführen ist), usw. In einer Anweisung weist (weisen) die physische(n) Registerdateieinheit(en) 1058 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine skalare Registereinheit auf. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Mehrzweckregister bereitstellen. Die physische(n) Registerdateieinheit(en) 1058 ist (sind) von der Abschlusseinheit 1054 überlappt, um verschiedene Weisen darzustellen, in denen eine Register und ungeordnete Ausführung implementiert werden können (z. B. unter Verwendung eines (von) Neuordnungspuffers(n) und einer (von) Abschlussregisterdatei(en); unter Verwendung einer (von) Zukunftsdatei(en) und einer (von) Abschlussregisterdatei(en); unter Verwendung einer Registerzuordnung und eines Pools von Registern usw.). Die Abschlusseinheit 1054 und die physische(n) Registerdateieinheit(en) 1058 ist (sind) mit Ausführungscluster(n) 1060 gekoppelt. Das (Die) Ausführungscluster 1060 weist (weisen) einen Satz von einer oder mehreren Ausführungseinheiten 1062 und einen Satz von einer oder mehreren Speicherzugriffseinheiten 1064 auf. Die Ausführungseinheiten 1062 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und auf verschiedenen Datentypen (z. B. skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, Vektorganzzahl, Vektorgleitkomme) durchführen. Während einige Ausführungsformen eine Anzahl von Ausführungseinheiten aufweisen können, die spezifischen Funktionen oder Sätzen von Funktionen zugewiesen sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten aufweisen, die alle alle Funktionen durchführen. Die Planungseinheit(en) 1056, physische(n) Registerdateieinheit(en) 1058 und Ausführungscluster 1060 sind als mögliche Mehrzahl dargestellt, da bestimmte Ausführungsformen separate Pipelines für bestimmte Daten-/Operationstypen erzeugen (z. B. eine skalare Ganzzahlpipeline, eine skalare Gleitkomma-/ gepackte Ganzzahl-/ gepackte Gleitkomma-/ Vektorganzzahl-/ Vektorgleitkommapipeline und/oder eine Speicherzugriffspipeline, die jeweils ihre eigene Planungseinheit, physische Registerdateieinheit und/oder Ausführungscluster haben - und im Fall einer separaten Speicherzugriffspipeline sind bestimmte Ausführungsformen implementiert, in denen nur das Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 1064 hat). Es ist zu verstehen, dass, wenn separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines eine ungeordnete Frage/Ausführung und der Rest geordnet sein können.

Der Satz von Speicherzugriffseinheiten 1064 ist mit der Speichereinheit 1070 gekoppelt, die eine Daten-TLB-Einheit 1072 aufweist, die mit einer Datenzwischenspeichereinheit 1074 gekoppelt ist, die mit einer Zwischenspeichereinheit 1076 von Ebene 2 (L2) gekoppelt ist. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 1064 eine Ladeneinheit, eine Speicheradresseneinheit und eine Speicherdateneinheit aufweisen, von denen jede mit der Daten-TLB-Einheit 1072 in der Speichereinheit 1070 gekoppelt ist. Die Anweisungszwischenspeichereinheit 1034 ist ferner mit einer Zwischenspeichereinheit 1076 von Ebene 2 (L2) in der Speichereinheit 1070 gekoppelt. Die L2-Zwischenspeichereinheit 1076 ist mit einer oder mehreren anderen Zwischenspeicherebenen und eventuell mit einem Hauptspeicher gekoppelt.

Als Beispiel kann die beispielhafte Registerumbenennungs-, ungeordnete Frage-/Ausführungs-Kernarchitektur die Pipeline 1000 wie folgt implementieren: 1) der Anweisungsabruf 1038 führt die Abruf- und Längendecodierstufe 1002 und 1004 durch, 2) die Decodiereinheit 1040 führt die Decodierstufe 1006 durch, 3) die Umbenennungs-/Zuweisungseinheit 1052 führt die Zuweisungsstufe 1008 und die Umbenennungsstufe 1010 durch, 4) die Planungseinheit(en) 1056 führt/en die Planungsstufe 1012 durch, 5) die physische(n) Registerdateieinheit(en) 1058 und die Speichereinheit 1070 führt (führen) die Registerlese-/Speicherlesestufe 1014 durch, die Ausführungscluster 1060 führen die Ausführungsstufe 1016 durch, 6) die Speichereinheit 1070 und die physische(n) Registerdateieinheit(en) 1058 führt (führen) die Zurückschreib-/Speicherschreibstufe 1018 durch, 7) verschiedene Einheiten können bei der Ausnahmehandhabungsstufe 1022 beteiligt sein und 8) die Abschlusseinheit 1054 und die physische(n) Registerdateieinheit(en) 1058 führt (führen) die Festschreibungsstufe 1024 durch.

Der Kern 1090 kann einen 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 of Sunnyvale, CA; den ARM-Anweisungssatz (mit optionalen zusätzlichen Erweiterungen, wie etwa NEON) von ARM Holdings of Sunnyvale, CA), einschließlich der(n) Anweisung(en), die hierin beschrieben ist (sind). In einer Ausführungsform weist der Kern 1090 Logik auf, um eine gepackte Datenanweisungssatzerweiterung (z. B. AVX1, AVX2) zu unterstützen, wodurch es den Operationen ermöglicht wird, von vielen Multimedia-Anwendungen verwendet zu werden, die unter Verwendung von gepackten Daten durchzuführen sind.

Es ist zu verstehen, dass der Kern Multithreading (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen kann und dies in einer Vielzahl von Weisen tun kann, einschließlich Zeitscheiben-Multithreading, gleichzeitiges Multithreading (wenn ein einzelner physischer Kern einen logischen Kern für jeden der Threads bereitstellt, für den der physische Kern gleichzeitiges Multithreading durchführt), oder eine Kombination daraus (z. B. stückweises Abrufen und Decodieren und gleichzeitiges Multithreading danach, wie etwa bei der Intel® Hyperthreading-Technologie).

Während eine Registerumbenennung im Kontext einer ungeordneten Ausführung beschrieben wird, ist zu verstehen, dass eine Registerumbenennung in einer geordneten Architektur verwendet werden kann. Während die dargestellte Ausführungsform des Prozessors auch separate Anweisungs- und Datenzwischenspeichereinheiten 1034/1074 und eine gemeinsam genutzte L2-Zwischenspeichereinheit 1076 aufweist, können alternative Ausführungsformen einen einzigen internen Zwischenspeicher für sowohl Anweisungen als auch Daten haben, wie etwa zum Beispiel einen internen Zwischenspeicher von Ebene 1 (L1) oder mehrere interne Zwischenspeicherebenen. In einigen Ausführungsformen kann das System eine Kombination aus einem internen Zwischenspeicher und einem externen Zwischenspeicher aufweisen, der zu dem Kern und/oder dem Prozessor extern ist. Alternativ können alle Zwischenspeicher zu dem Kern und/oder dem Prozessor extern sein.

Spezifische beispielhafte geordnet Kernarchitektur

11A-B stellen ein Blockdiagramm einer spezifischeren beispielhaften geordneten Kernarchitektur dar, wobei der Kern einer von mehreren logischen Blöcken (einschließlich anderen Kernen des gleichen Typs und/oder unterschiedlicher Typen) in einem Chip wäre. Die logischen Blöcke kommunizieren durch ein Verbindungsnetzwerk mit hoher Bandbreite (z. B. ein Ringnetzwerk) mit einigen festen Funktionslogik-, Speicher-I/O-Schnittstellen und anderer notwendiger I/O-Logik in Abhängigkeit von der Anwendung.

11A ist ein Blockdiagramm eines einzelnen Prozessorkerns zusammen mit seiner Verbindung zu dem Auf-Die-Verbindungsnetzwerk 1102 und mit seinem lokalen Untersatz des Zwischenspeichers 1104 von Ebene 2 (L2) gemäß Ausführungsformen der Erfindung. In einer Ausführungsform unterstützt ein Anweisungsdecoder 1100 den x86-Anweisungssatz mit gepackter Datenanweisungssatzerweiterung. Ein L1-Zwischenspeicher 1106 ermöglicht Zugriffe mit niedriger Latenz auf Zwischenspeicher in skalare und Vektoreinheiten. Während in einer Ausführungsform (zur Vereinfachung des Aufbaus) eine skalare Einheit 1108 und eine Vektoreinheit 1110 separate Registersätze (jeweils skalare Register 1112 und Vektorregister 1114) verwenden und Daten, die zwischen ihnen übertragen werden, auf einen Speicher geschrieben und dann in Form eines Zwischenspeichers 1106 von Ebene 1 (L1) zurückgeschrieben werden, können alternative Ausführungsformen der Erfindung einen anderen Ansatz verfolgen (z. B. einen einzelnen Registersatz verwenden oder einen Kommunikationspfad aufweisen, der ermöglicht, Daten zwischen zwei Registerdateien zu übertragen, ohne sie zu schreiben oder zurückzulesen).

Der lokale Untersatz des L2-Zwischenspeichers 1104 ist Teil eines globalen L2-Zwischenspeichers, der in separate lokale Untersätze geteilt wird, einer pro Prozessorkern. Jeder Prozessorkern hat einen direkten Zugriffspfad zu seinem eigenen lokalen Untersatz des L2-Zwischenspeichers 1104. Daten, die durch den Prozessorkern gelesen werden, werden in ihrem L2-Zwischenspeicheruntersatz 1104 gespeichert und es kann schnell auf sie zugegriffen werden, parallel zu anderen Prozessorkernen, die auf ihre eigenen lokalen L2-Zwischenspeicheruntersätze zugreifen. Daten, die durch einen Prozessorkern geschrieben werden, werden in ihrem eigenen L2-Zwischenspeicheruntersatz 1104 gespeichert und aus anderen Untersätzen geleert, falls notwendig. Das Ringnetzwerk stellt die Kohärenz von gemeinsam genutzten Daten sicher. Das Ringnetzwerk ist bidirektional, um Agenten, wie etwa Prozessorkernen, L2-Zwischenspeichern und anderen logischen Blöcken, zu ermöglichen, miteinander innerhalb des Chips zu kommunizieren. Jeder Ringdatenpfad ist 1012-Bits breit pro Richtung.

11B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 11A gemäß Ausführungsformen der Erfindung. 11B weist einen L1-Datenzwischenspeicher 1106A, Teil des L1-Zwischenspeichers 1104, sowie mehr Einzelheiten bezüglich der Vektoreinheit 1110 und des Vektorregisters 1114 auf. Insbesondere die Vektoreinheit 1110 ist eine 16-weite Vektorverarbeitungseinheit (VPU) (siehe die 16-weite ALU 1128), die eine oder mehrere von Ganzzahlanweisungen, Gleitkommazahlanweisungen mit einfacher Genauigkeit und Gleitkommazahlanweisungen mit doppelter Genauigkeit ausführt. Die VPU unterstützt ein Swizzling der Registereingänge mit Swizzle-Einheit 1120, eine numerische Konvertierung mit numerischen Konvertierungseinheiten 1122A-B und eine Replikation mit Replikationseinheit 1124 auf dem Speichereingang. Schreibmaskenregister 1126 ermöglicht eine Vorhersage von sich daraus ergebenden Vektorschreibvorgängen.

12 ist ein Blockdiagramm eines Prozessors 1200, der mehr als einen Kern haben kann, eine integrierte Speichersteuerung haben kann und integrierte Grafiken haben kann, gemäß Ausführungsformen der Erfindung. Die durchgehend linierten Kästchen in 12 stellen einen Prozessor 1200 mit einem einzelnen Kern 1202A, einem Systemagenten 1210, einem Satz von einer oder mehreren Bus-Steuereinheiten 1216 dar, während die optionale Hinzufügung der gestrichelten Kästchen einen alternativen Prozessor 1200 mit mehreren Kernen 1202A-N, einen Satz von einer oder mehreren integrierten Speichersteuereinheit(en) 1214 in der Systemagenteneinheit 1210 und eine Spezialzwecklogik 1208 darstellt.

Daher können unterschiedliche Implementierungen des Prozessors 1200 Folgendes aufweisen: 1) eine CPU mit der Spezialzwecklogik 1208, die eine integrierte grafische und/oder wissenschaftliche (Durchsatz-) Logik ist (die einen oder mehr Kerne aufweisen kann), und die Kerne 1202A-N, die ein oder mehrere Mehrzweckkerne sind (z. B. geordnete Mehrzweckkerne, ungeordnete Mehrzweckkerne, eine Kombination aus beiden), 2) einen Coprozessor mit den Kernen 1202A-N, die eine große Anzahl von Spezialzweckkernen sind, die primär für grafische und/oder wissenschaftliche (Durchsatz) ausgelegt sind, und 3) einen Coprozessor mit den Kernen 1202A-N, die eine große Anzahl von geordneten Mehrzweckkernen sind. Daher kann der Prozessor 1200 ein Mehrzweckprozessor, Coprozessor oder Spezialzweckprozessor sein, wie etwa zum Beispiel ein Netzwerk- oder Kommunikationsprozessor, Komprimierungsmotor, Grafikprozessor, GPGPU (Mehrzweck-Grafikverarbeitungseinheit), ein Many Integrated Core (MIC)-Coprozessor mit hohem Durchsatz (einschließlich 30 oder mehr Kernen), eingebetteter Prozessor oder dergleichen. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 1200 kann ein Teil von und/oder kann auf einem oder mehreren Substraten implementiert sein, unter Verwendung einer Anzahl von Technologien, wie etwa zum Beispiel BiCMOS, CMOS oder NMOS.

Die Speicherhierarchie weise einen oder mehrere Zwischenspeicherebenen 1204A-N innerhalb der Kerne, einen Satz oder eine oder mehrere gemeinsam genutzte Zwischenspeichereinheiten 1206 und einen externen Speicher (nicht gezeigt), der mit dem Satz von integrierten Speichersteuereinheiten 1214 gekoppelt ist, auf. Der Satz von gemeinsam genutzten Zwischenspeichereinheiten 1206 kann einen oder mehrere Mittelstufen-Zwischenspeichereinheit aufweisen, wie etwa Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder andere Zwischenspeicherebenen, einen Zwischenspeicher letzter Ebene (LLC) und/oder Kombinationen daraus. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 1212 die integrierte Grafiklogik 1208, den Satz von gemeinsam genutzten Zwischenspeichereinheiten 1206 und die Systemagenteneinheit 1210/ integrierte Speichersteuereinheit(en) 1214 verbindet, können alternative Ausführungsformen eine Anzahl von allgemein bekannten Techniken zur Verbindung derartiger Einheiten verwenden. In einer Ausführungsform wird die Kohärenz zwischen einer oder mehreren Zwischenspeichereinheiten 1206 und Kernen 1202-A-N aufrechterhalten.

In einigen Ausführungsformen sind ein oder mehrere der Kerne 1202A-N zum Multithreading imstande. Der Systemagent 1210 weist diejenigen Komponenten auf, die Kerne 1202A-N koordinieren und betreiben. Die Systemagenteneinheit 1210 kann zum Beispiel eine Leistungssteuereinheit (PCU) und eine Anzeigeeinheit aufweisen. Die PCU kann eine Logik sein oder diese und andere Komponenten aufweisen, die zum Regeln des Leistungszustands der Kerne 1202A-N und der integrierten Grafiklogik 1208 notwendig sind. Die Anzeigeeinheit ist zum Antreiben einer oder mehrerer externer verbundener Anzeigen ausgelegt.

Die Kerne 1202A-N können homogen oder heterogen im Sinne vom Architektur-Anweisungssatz sein, das heißt, dass zwei oder mehr der Kerne 1202A-N imstande sein können, den gleichen Anweisungssatz auszuführen, während andere imstande sein können, nur einen Untersatz dieses Anweisungssatzes oder eines anderen Anweisungssatzes auszuführen.

Beispielhafte Computerarchitekturen

13-16 sind Blockdiagramme von beispielhaften Computerarchitekturen. Andere Systementwürfe und -konfigurationen, die im Stand der Technik von Laptops, Desktops, Handheld-PCs, persönlichen digitalen Assistenten, Engineering Worksations, Servern, Netzwerkgeräten, Netzwerkhubs, Switches, eingebetteten Prozessoren, digitalen Signalprozessoren (DSPs), Grafikgeräten, Videospielgeräten, Set-Top-Boxen, Mikrosteuerungen, Mobilfunktelefonen, tragbaren Media-Players, handgehaltenen Geräten und verschiedenen anderen elektronischen Geräten bekannt sind, sind auch geeignet. Im Allgemeinen sind eine enorme Vielzahl von Systemen oder elektronischen Geräten, die zur Integration eines Prozessors und/oder andere Ausführungslogik, die hierin offenbart wird, imstande sind, im Allgemeinen geeignet.

Es wird nun auf 13 Bezug genommen, in der ein Blockdiagramm eines Systems 1300 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt ist. Das System 1300 kann einen oder mehrere Prozessoren 1310, 1315 aufweisen, die mit einem Steuerungshub 1320 gekoppelt sind. In einer Ausführungsform weist der Steuerungshub 1320 einen Grafikspeichersteuerungshub (GMCH) 1390 und einen Eingang-/Ausgang-Hub (IOH) 1350 auf (die auf separaten Chips sein können); der GMCH 1390 weist eine Speicher- und Grafiksteuerung auf, mit der ein Speicher 1340 und ein Coprozessor 1345 gekoppelt sind; der IOH 1350 koppelt Eingang-/Ausgangs-(I/O)-Geräte 1360 mit dem GMCH 1390. Alternativ sind eine oder beide der Speicher- und Grafiksteuerungen innerhalb des Prozessors integriert (wie hierin beschrieben), der Speicher 1340 und der Coprozessor 1345 sind direkt mit dem Prozessor 1310 gekoppelt und der Steuerungshub 1320 in einem einzigen Chip mit dem IOH 1350.

Die optionale Gegebenheit eines zusätzlichen Prozessors 1315 ist in 13 mit unterbrochenen Linien angezeigt. Jeder Prozessor 1310, 1315 kann einen oder mehrere der Verarbeitungskerne aufweisen, die hierin beschrieben sind, und kann eine Version des Prozessors 1200 sein.

Der Speicher 1340 kann zum Beispiel ein dynamischer Direktzugriffspeicher (DRAM), Phasenwechselspeicher (PSM) oder eine Kombination aus den beiden sein. Für mindestens eine Ausführungsform kommuniziert der Steuerungshub 1320 mit dem(n) Prozessor(en) 1310, 1315 über einen Multi-Drop-Bus, wie etwa einen Front-Side-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle, wie etwa QuickPath Interconnect (QPI), oder ähnliche Verbindung 1395.

In einer Ausführungsform ist der Coprozessor 1345 ein Spezialzweckprozessor, wie etwa zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, Komprimierungsmotor, Grafikprozessor, GPGPU, eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann ein Steuerungshub 1320 einen integrierten Grafikbeschleuniger aufweisen.

Es kann eine Vielzahl von Unterschieden zwischen den physischen Ressourcen 1310, 1315 geben, im Sinne eines Spektrums von Verdienstmetriken, die architektonische, mikroarchitektonische, thermische, Leistungsverbrach bezogene Eigenschaften und dergleichen aufweisen.

In einer Ausführungsform führt der Prozessor 1310 Anweisungen aus, die Datenverarbeitungsoperationen eines allgemeinen Typs steuern. Eingebettet innerhalb der Anweisungen können Coprozessoranweisungen sein. Der Prozessor 1310 erkennt diese Coprozessoranweisungen, die von einem Typ sind, der durch den angebrachten Coprozessor 1345 ausgeführt werden soll. Folglich erteilt der Prozessor 1310 diese Coprozessoranweisungen (oder Steuersignale, die Coprozessoranweisungen darstellen) auf einem Coprozessorbus oder anderen Verbindung an Coprozessor 1345. Coprozessor(en) 1345 akzeptiert (akzeptieren) die empfangenen Coprozessoranweisungen und führen diese aus.

Es wird nun auf 14 Bezug genommen, in der ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems 1400 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt ist. Wie in 14 gezeigt ist, ist Multiprozessorsystem 1400 ein Punkt-zu-Punkt-Verbindungssystem und weist einen ersten Prozessor 1470 und einen zweiten Prozessor 1480 auf, die über eine Punkt-zu-Punkt-Verbindung 1450 gekoppelt sind. Jeder von Prozessor 1470 und 1480 kann eine Version des Prozessors 1200 sein. In einer Ausführungsform der Erfindung sind Prozessoren 1470 und 1480 jeweils Prozessoren 1310 und 1315, während Coprozessor 1438 Coprozessor 1345 ist. In einer anderen Ausführungsform sind Prozessoren 1470 und 1480 jeweils Prozessor 1310 Coprozessor 1345.

Prozessoren 1470 und 1480 sind einschließlich jeweils integrierter Speichersteuerung(IMC)-Einheiten 1472 und 1482 gezeigt. Prozessor 1470 weist auch einen Teil seiner Punkt-zu-Punkt(P-P)-Schnittstellen 1476 und 1478 von Bussteuereinheiten auf; ähnlich weist zweiter Prozessor 1480 P-P-Schnittstellen 1486 und 1488 auf. Prozessoren 1470, 1480 können Informationen über eine Punkt-zu-Punkt(P-P)-Schnittstelle 1450 unter Verwendung von P-P-Schnittstellenschaltungen 1478, 1488 austauschen. Wie in 14 gezeigt ist, koppeln IMCs 1472 und 1482 die Prozessoren mit jeweiligen Speichern, nämlich einem Speicher 1432 und einem Speicher 1434, die Abschnitte eines Hauptspeichers sein können, der lokal an den jeweiligen Prozessoren angebracht ist.

Prozessoren 1470, 1480 können Informationen mit einem Chipsatz 1490 über einzelne P-P-Schnittstellen 1452, 1454 unter Verwendung von Punktschnittstellenschaltungen 1476, 1494, 1486, 1498 austauchen. Chipsatz 1490 kann optional Informationen mit dem Coprozessor 1438 über eine Hochleistungsschnittstelle 1492 austauschen. In einer Ausführungsform ist der Coprozessor 1438 ein Spezialzweckprozessor, wie etwa zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, Komprimierungsmotor, Grafikprozessor, GPGPU, eingebetteter Prozessor oder dergleichen.

Ein gemeinsam genutzter Zwischenspeicher (nicht gezeigt) kann in beiden Prozessoren oder außerhalb beider Prozessoren enthalten sein, jedoch mit den Prozessoren über eine P-P-Verbindung verbunden sein, wie etwa, dass lokale Zwischenspeicherinformationen eines oder beider Prozessoren in dem gemeinsam genutzten Zwischenspeicher gemeinsam genutzt werden können, wenn ein Prozessor in einem Modus mit geringer Leistung platziert ist.

Chipsatz 1490 kann mit einem ersten Bus 1416 über eine Schnittstelle 1496 gekoppelt sein. In einer Ausführungsform kann erster Bus 1416 ein Peripheral Component Interconnect (PCI)-Bus oder ein Bus, wie etwa ein PCI-Express-Bus oder ein anderer I/O-Verbindungsbus dritter Generation sein, obwohl der Umfang der vorliegenden Erfindung nicht so beschränkt ist.

Wie in 14 gezeigt ist, können verschiedene I/O-Geräte 1414 mit erstem Bus 1416 zusammen mit einer Busbrücke 1418, die ersten Bus 1416 mit einem zweiten Bus 1420 koppelt, gekoppelt sein. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessor(en) 1415, wie etwa Coprozessoren, MIC-Prozessoren mit hohem Durchsatz, GPGPU, Beschleuniger (wie etwa z. B. Grafikbeschleuniger oder digitale Signalverarbeitung(DSP)-einheiten), feldprogrammierbare Gate-Arrays oder ein beliebiger anderer Prozessor, mit erstem Bus 1416 gekoppelt. In einer Ausführungsform kann zweiter Bus 1420 ein Low-Pin-Count(LPC)-Bus sein. Verschiedene Geräte können in einer Ausführungsform mit einem zweiten Bus 1420 gekoppelt sein, der zum Beispiel eine Tastatur und/oder Maus 1422, Kommunikationsvorrichtungen 1427 und eine Speichereinheit 1428, wie etwa ein Plattenlaufwerk oder ein anderes Massenspeichergerät, die Anweisungen/Codes und Daten 1430 aufweisen können, aufweist. Ferner kann ein Audio-I/O 1424 mit dem zweiten Bus 1420 gekoppelt sein. Es wird angemerkt, dass andere Architekturen möglich sind. Zum Beispiel kann ein System, anstelle der Punkt-zu-Punkt-Architektur von 14, einen Multi-Drop-Bus oder eine andere derartige Architektur implementieren.

Es wird nun auf 15 Bezug genommen, in der ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems 1500 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt ist. Gleiche Elemente in 14 und 15 tragen gleiche Bezugszeichen und bestimmte Aspekte von 14 fallen in 15 weg, um eine Verschleierung anderer Aspekte von 15 zu vermeiden.

15 stellt dar, dass die Prozessoren 1470, 1480 jeweils integrierte Speicher- und I/O-Steuerlogik („CL“) 1472 und 1482 aufweisen können. Daher weisen die CL 1472, 1482 integrierte Speichersteuereinheiten auf und weisen I/O-Steuerlogik auf. 15 stellt dar, dass nicht nur die Speicher 1432, 1434 mit den CL 1472, 1482 gekoppelt sind, sondern auch, dass I/O-Geräte 1514 auch mit der Steuerlogik 1472, 1482 gekoppelt sind. Vorläufer-I/O-Geräte 1515 sind mit dem Chipsatz 1490 gekoppelt.

Es wird nun auf 16 Bezug genommen, in der ein Blockdiagramm einer SoC 1600 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt ist. Ähnliche Elemente in 12 tragen gleiche Bezugszeichen. Auch gestrichelte Kästchen sind optionale Merkmale auf fortschrittlicheren SoCs. In 16 ist eine Verbindungseinheit(en) 1602 mit Folgendem gekoppelt: einem Anwendungsprozessor 1610, der einen Satz von einem oder mehreren Kernen 1202A-N, Zwischenspeicher 1204A-N und gemeinsam genutzte Zwischenspeichereinheit(en) 1206 aufweist, einer Systemagenteneinheit 1210, einer Bus-Steuereinheit(en) 1216, einer integrierten Speichersteuereinheit(en) 1214, einem Satz von oder einem oder mehreren Coprozessoren 1620, die eine integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor aufweisen können, einer statischen Direktzugriffspeicher(SRAM)-Einheit 1630, einer Direktspeicherzugriff(DMA)-Einheit 1632 und einer Anzeigeeinheit 1640 zum Koppeln mit einer oder mehreren externen Anzeigen. In einer Ausführungsform weist (weisen) der Coprozessor(en) 1620 einen Spezialzweckprozessor auf, wie etwa zum Beispiel einen Netzwerk- oder Kommunikationsprozessor, Komprimierungsmotor, GPGPU, einen MIC-Prozessor mit hohem Durchsatz, eingebetteten Prozessor oder dergleichen.

Ausführungsformen der Mechanismen, die hierin offenbart werden, können in Hardware, Software, Firmware oder einer Kombination aus derartigen Implementierungsansätzen implementiert sein. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode, die auf programmierbaren Systemen ausführen, implementiert sein, die mindestens einen Prozessor, ein Speichersystem (einschließlich flüchtiger und nichtflüchtiger Speicher- und/oder Speicherelemente) mindestens eine Eingabeeinrichtung und mindestens eine Ausgabeeinrichtung aufweisen.

Programmcode, wie etwa Code 1430, der in 14 dargestellt ist, kann auf Eingangsanweisungen angewandt werden, um die Funktionen durchzuführen, die hierin beschrieben sind, und Ausgangsinformationen erzeugen. Die Ausgangsinformationen können in bekannter Weise auf ein oder mehrere Ausgabegeräte angewandt werden. Zum Zweck dieser Anwendung weist ein Verarbeitungssystem ein beliebiges System auf, das einen Prozessor hat, wie etwa zum Beispiel einen digitalen Signalprozessor (DSP), eine Mikrosteuerung, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor.

Der Programmcode kann in einer verfahrens- oder objektorientierten Programmiersprache auf hohem Niveau implementiert sein, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann auch in Assembler- oder Maschinensprache implementiert sein, falls dies gewünscht ist. Tatsächlich sind die Mechanismen, die hierin beschrieben werden, in ihrem Umfang nicht auf eine bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.

Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentative Anweisungen implementiert sein, die auf einem maschinenlesbaren Medium gespeichert sind, die verschiedene Logiken innerhalb des Prozessors darstellt, die, wenn sie durch eine Maschine gelesen werden, die Maschine veranlassen, Logik herzustellen, um die Techniken durchzuführen, die hierin beschrieben sind. Derartige Darstellungen, die als „IP-Kerne“ bekannt sind, können auf einem materiellen, maschinenlesbaren Medium gespeichert und an verschiedene Verbraucher oder Herstellungseinrichtungen geliefert werden, um Lasten in den Herstellungsmaschinen zu erleichtern, die die Logik oder den Prozessor tatsächlich herstellen.

Derartige maschinenlesbare Speichermedien können, ohne Beschränkung, nicht vorübergehende, materielle Anordnungen von Artikeln aufweisen, die durch eine Maschine oder ein Gerät hergestellt oder gebildet werden, einschließlich Speichermedien, wie etwa Festplatten, ein beliebiger anderer Typ von Platte, einschließlich Disketten, optische Platten, Kompaktplatten-Festwertspeicher (CD-ROMs), wiederbeschreibbare Kompaktplatten (CD-RWs) und magnetooptische Platten, Halbleitervorrichtungen, wie etwa Festwertspeicher (ROMs), Direktzugriffsspeicher (RAMs), wie etwa dynamische Direktzugriffsspeicher (DRAMs), statische Direktzugriffsspeicher (SRAMs), löschbare programmierbare Festwertspeicher (EPROMs), Flash-Speicher, elektrisch löschbare programmierbare Festwertspeicher (EEPROMs), Phasenwechselspeicher (PCM), magnetische oder optische Karten oder ein beliebiger anderer Typ von Medium, der zum Speichern von elektronischen Anweisungen geeignet ist.

Folglich weisen Ausführungsformen der Erfindung auch nicht vorübergehende, materielle maschinenlesbare medienenthaltende Anweisungen oder enthaltende Entwurfsdaten auf, wie etwa Hardware Description Language (HDL), die Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale, die hierin beschrieben werden, definieren. Derartige Ausführungsformen können auch als Programmprodukte bezeichnet werden.

Emulation (einschließlich binärer Übersetzung, Code-Morphing usw.)

In manchen Fällen kann ein Anweisungskonvertierer verwendet werden, um eine Anweisung von einem Quellanweisungssatz in einen Zielanweisungssatz zu konvertieren. Zum Beispiel kann der Anweisungskonvertierer eine Anweisung in eine oder mehrere andere Anweisungen, die durch den Kern zu verarbeiten sind, übersetzen (z. B. unter Verwendung einer statischen binären Übersetzung, dynamischen binären Übersetzung, die eine dynamische Kompilation aufweist), morphieren, emulieren oder auf eine andere Weise konvertieren. Der Anweisungskonvertierer kann in Software, Hardware, Firmware oder einer Kombination daraus implementiert sein. Der Anweisungskonvertierer kann auf einem Prozessor, außerhalb eines Prozessors oder ein Teil auf und ein Teil außerhalb eines Prozessors sein.

17 ist ein Blockdiagramm, das die Verwendung eines Softwareanweisungskonvertierers gegenüberstellt, um binäre Anweisungen in einem Quellanweisungssatz in binäre Anweisungen in einem Zielanweisungssatz gemäß Ausführungsformen der Erfindung zu konvertieren. In der dargestellten Ausführungsform ist der Anweisungskonvertierer ein Softwareanweisungskonvertierer, obwohl alternativ der Anweisungskonvertierer in Software, Firmware, Hardware oder verschiedenen Kombinationen daraus implementiert sein kann. 17 zeigt ein Programm in einer Hochsprache 1702, das unter Verwendung eines x86-Compilers 1704 kompiliert werden kann, um einen binären x86-Code 1706 zu erzeugen, der durch einen Prozessor mit mindestens einem x86-Anweisungssatzkerns 1716 nativ ausgeführt werden kann. Der Prozessor mit mindestens einem x86-Anweisungssatzkern 1716 stellt einen beliebigen Prozessor dar, der im Wesentlichen die gleichen Funktionen durchführen kann, wie ein Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern, durch kompatibles Ausführen oder andernfalls Verarbeiten (1) eines wesentlichen Abschnitts des Anweisungssatzes des Intel-x86-Anweisungssatzkerns oder (2) von Objektcodeversionen von Anwendungen oder anderer Software, auf die abgezielt wird, auf einem Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern zu laufen, um im Wesentlichen das gleiche Ergebnis zu erzielen wie ein Intel-Prozessor mit mindestens einem x86-Anweisungssatzkern. Der x86-Compiler 1704 stellt einen Compiler dar, der betreibbar ist, um einen binären x86-Code 1706 (z. B. Objektcode) zu erzeugen, der mit oder ohne zusätzlichem Linkage-Verarbeiten auf dem Prozessor mit mindestens einem x86-Anweisungssatzkern 1716 ausgeführt werden kann. Ähnlich zeigt 17, dass das Programm in der Hochsprache 1702 unter Verwendung eines alternativen Anweisungssatz-Compilers 1708 kompiliert werden kann, um einen alternativen binären Anweisungssatzcode 1710 zu erzeugen, der durch einen Prozessor ohne mindestens einen x86-Anweisungssatzkern 1714 (z. B. einen Prozessor mit Kernen, die den MIPS-Anweisungssatz von MIPS Technologies of Sunnyvale, CA, ausführen, und/oder die den ARM-Anweisungssatz von ARM Holdings of Sunnyvale, CA, ausführen) nativ ausgeführt werden kann. Der Anweisungskonvertierer 1712 wird verwendet, um den binären x86-Code 1706 in einen Code zu konvertieren, der durch den Prozessor ohne einen x86-Anweisungssatzkern 1714 ausgeführt werden kann. Der konvertierte Code ist wahrscheinlich nicht der gleiche wie der alternative binäre Anweisungssatzcode 1710, da ein Anweisungskonvertierer, der hierzu imstande ist, schwierig herzustellen ist. Der konvertierte Code wird jedoch die allgemeine Operation ausführen und aus Anweisungen aus dem alternativen Anweisungssatz bestehen. Daher stellt der Anweisungskonvertierer 1712 Software, Firmware, Hardware oder eine Kombination daraus dar, die durch Emulation, Simulation oder einen anderen Prozess einem Prozessor oder einer anderen elektronischen Vorrichtung, die keinen x86-Anweisungssatzprozessor oder -kern hat, ermöglicht, den binären x86-Code 1706 auszuführen.

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

US 5446912 [0003]
US 5207132 [0003]

Claims

Vorrichtung, aufweisend: ein Decoderschaltungsmittel zum Decodieren einer Anweisung, wobei die Anweisung mindestens einen Opcode, ein Feld für einen gepackten Datenquelloperanden und ein Feld für einen gepackten Datenzieloperanden aufweist, und Ausführungsschaltkreismittel zum Ausführen der decodierten Anweisung, um für jede Datenelementposition des Quelloperanden einen Wert, der in der Datenelementposition gespeichert ist, mit allen Werten, die in vorhergehenden Datenelementpositionen des gepackten Datenquelloperanden gespeichert sind, zu multiplizieren und ein Ergebnis der Multiplikation in einer entsprechenden Datenelementposition des gepackten Datenzieloperanden zu speichern.
Vorrichtung nach Anspruch 1, wobei der Quelloperand ein gepacktes Datenregister ist und der Zieloperand ein gepacktes Datenregister ist.
Vorrichtung nach Anspruch 2, wobei ein einziges gepacktes Datenregister für den Quell- und Zieloperanden verwendet wird.
Vorrichtung nach einem der Ansprüche 1-3, wobei die Datenelemente des Quelloperanden in einem Little-Endian-Format gespeichert sind.
Vorrichtung nach einem der Ansprüche 1-3, wobei die Datenelemente des Quelloperanden in einem Big-Endian-Format gespeichert sind.
Vorrichtung nach einem der Ansprüche 1-5, wobei die Anweisung einen Feldschreibmaskenoperanden aufweist.
Vorrichtung nach Anspruch 6, wobei das Ausführungsschaltkreismittel ein Ergebnis der Multiplizierten basierend auf Werten des Schreibmaskenoperanden speichert.
Verfahren, aufweisend: Decodieren einer Anweisung, wobei die Anweisung mindestens einen Opcode, ein Feld für einen gepackten Datenquelloperanden und ein Feld für einen gepackten Datenzieloperanden aufweist, und Ausführen der decodierten Anweisung, um für jede Datenelementposition des Quelloperanden einen Wert, der in der Datenelementposition gespeichert ist, mit allen Werten, die in vorhergehenden Datenelementpositionen des gepackten Datenquelloperanden gespeichert sind, zu multiplizieren und ein Ergebnis der Multiplikation in einer entsprechenden Datenelementposition des gepackten Datenzieloperanden zu speichern.
Verfahren nach Anspruch 8, wobei der Quelloperand ein gepacktes Datenregister ist und der Zieloperand ein gepacktes Datenregister ist.
Verfahren nach Anspruch 9, wobei ein einziges gepacktes Datenregister für den Quell- und Zieloperanden verwendet wird.
Verfahren nach einem der Ansprüche 8-10, wobei die Datenelemente des Quelloperanden in einem Little-Endian-Format gespeichert werden.
Verfahren nach einem der Ansprüche 8-10, wobei die Datenelemente des Quelloperanden in einem Big-Endian-Format gespeichert werden.
Verfahren nach einem der Ansprüche 8-12, wobei die Anweisung einen Feldschreibmaskenoperanden aufweist.
Verfahren nach Anspruch 13, wobei das Speichern auf Werten des Schreibmaskenoperanden basiert.
Nicht vorübergehendes maschinenlesbares Medium, das Anweisungen speichert, die, wenn sie ausgeführt werden, einen Prozessor veranlassen, ein Verfahren durchzuführen, wobei das Verfahren Folgendes aufweist: Decodieren einer Anweisung, wobei die Anweisung mindestens einen Opcode, ein Feld für einen gepackten Datenquelloperanden und ein Feld für einen gepackten Datenzieloperanden aufweist, und Ausführen der decodierten Anweisung, um für jede Datenelementposition des Quelloperanden einen Wert, der in der Datenelementposition gespeichert ist, mit allen Werten, die in vorhergehenden Datenelementpositionen des gepackten Datenquelloperanden gespeichert sind, zu multiplizieren und ein Ergebnis der Multiplikation in einer entsprechenden Datenelementposition des gepackten Datenzieloperanden zu speichern.
Nicht vorübergehendes maschinenlesbares Medium nach Anspruch 15, wobei der Quelloperand ein gepacktes Datenregister ist und der Zieloperand ein gepacktes Datenregister ist.
Nicht vorübergehendes maschinenlesbares Medium nach Anspruch 16, wobei ein einziges gepacktes Datenregister für den Quell- und Zieloperanden verwendet wird.
Nicht vorübergehendes maschinenlesbares Medium nach Anspruch 15, wobei die Datenelemente des Quelloperanden in einem Little-Endian-Format gespeichert sind.
Nicht vorübergehendes maschinenlesbares Medium nach Anspruch 15, wobei die Datenelemente des Quelloperanden in einem Big-Endian-Format gespeichert sind.
Nicht vorübergehendes maschinenlesbares Medium nach Anspruch 15, wobei die Anweisung einen Feldschreibmaskenoperanden aufweist und das Speichern auf Werten des Schreibmaskenoperanden basiert.
Vorrichtung, aufweisend: eine Decoderschaltung, um eine Anweisung zu decodieren, wobei die Anweisung mindestens einen Opcode, ein Feld für einen gepackten Datenquelloperanden und ein Feld für einen gepackten Datenzieloperanden aufweist, und einen Ausführungsschaltkreis, um die decodierte Anweisung auszuführen, um für jede Datenelementposition des Quelloperanden einen Wert, der in der Datenelementposition gespeichert ist, mit allen Werten, die in vorhergehenden Datenelementpositionen des gepackten Datenquelloperanden gespeichert sind, zu multiplizieren und ein Ergebnis der Multiplikation in einer entsprechenden Datenelementposition des gepackten Datenzieloperanden zu speichern.
Vorrichtung nach Anspruch 21, wobei der Quelloperand ein gepacktes Datenregister ist und der Zieloperand ein gepacktes Datenregister ist.
Vorrichtung nach Anspruch 22, wobei ein einziges gepacktes Datenregister für den Quell- und Zieloperanden verwendet wird.
Vorrichtung nach Anspruch 21, wobei die Datenelemente des Quelloperanden in einem Little-Endian-Format gespeichert sind.
Vorrichtung nach Anspruch 21, wobei die Datenelemente des Quelloperanden in einem Big-Endian-Format gespeichert sind.