DE112017003338T5 - System, Vorrichtung und Verfahren zum Inspizieren dauerhafter Daten in einem Speicher - Google Patents

Abstract

Es sind Systeme, Verfahren und Vorrichtungen zum Ausführen eines Befehls beschrieben. In einigen Ausführungsformen decodiert eine Decodierschaltung einen Befehl, wobei der Befehl wenigstens einen Opcode, ein Feld für einen Quelloperanden und ein Feld für einen Zieloperanden enthält. Eine Ausführungsschaltung führt den decodierten Befehl aus, um zu ermitteln, ob ein Kennsatz von der Adresse von dem Quelloperanden zu einem Kennsatz in einer ausgewählten nichtflüchtigen Speicheradresscache(Non-Volatile Memory Address Cache, NVMAC)-Cachezeile passt, wobei bei Vorhandensein einer Übereinstimmung eine Trefferanzeige in dem Zieloperanden gespeichert wird, und bei Abwesenheit einer Übereinstimmung eine Fehlanzeige in dem Zieloperanden gespeichert wird und der NVMAC mit dem Kennsatz von der Adresse von dem Quelloperanden aktualisiert wird.

Description

• GEBIET DER ERFINDUNG
• Das Gebiet der Erfindung bezieht sich allgemein auf eine Computerprozessorarchitektur und insbesondere auf einen Befehl, der ein bestimmtes Ergebnis erzeugt, wenn er ausgeführt wird.
• HINTERGRUND
• Ein Befehlssatz, oder eine Befehlssatzarchitektur (Instruction Set Architecture, ISA), ist der Teil der Computerarchitektur, der das Programmieren betrifft und der native Datentypen, Befehle, Registerachitektur, Adressiermodi, Speicherarchitektur, Interrupt- und Ausnahmebehandlung und externe Eingabe und Ausgabe (I/O) beinhalten kann. Es ist zu beachten, dass der Begriff Befehl in dem hier verwendeten Sinne sich allgemein auf Makrobefehle - d. h. Befehle, die an den Prozessor zur Ausführung ausgegeben werden - bezieht, im Gegensatz zu Mikrobefehlen oder Mikro-Operationen - die sich anhand eines Decoders des Prozessors ergeben, der Makrobefehle decodiert.
• Die Befehlssatzarchitektur unterscheidet sich von der Mikroarchitektur, die die interne Konstruktion des Prozessors ist, auf dem die ISA durchführt ist. Prozessoren mit unterschiedlichen Mikroarchitekturen können einen gemeinsamen Befehlssatz teilen. Beispielsweise verwenden Intel Pentium 4 Prozessoren, Intel Core Prozessoren und Hochentwickelte Mikrobauelemente (Advanced Micro Devices, AMD), Inc. of Sunnyvale CA Prozessoren nahezu identische Versionen des x86-Befehlssatzes (wobei zu neueren Versionen einige Erweiterungen hinzugefügt wurden), weisen jedoch unterschiedliche interne Konstruktionen auf. Beispielsweise kann die gleiche Registerachitektur der ISA auf unterschiedlichen Wegen in unterschiedlichen Mikroarchitekturen unter Verwendung gut bekannter Techniken durchgeführt sein, beispielsweise durch speziell zugewiesene physische Register, ein oder mehrere dynamisch zugewiesene physische Register, die eine Registerumbenennungsvorrichtung (z.B. den Einsatz einer Register Alias Tabelle (RAT), eines Neuanordnungspuffers (Recorder Buffer, ROB) und einer Rückzugsregister-Datei (Retirement Register File), wie in dem US-Patent 5 446 912 beschrieben; den Einsatz von Mehrfachabbildungen und einer Datenbasis von Registern, wie in dem US-Patent 5 207 132 beschrieben) und dergleichen verwenden. Falls nicht anderweitig spezifiziert, beziehen sich die Ausdrücke Registerachitektur, Registerdatei und Register auf das, was für die Software/den Programmierer sichtbar ist, und auf die Art und Weise, in der Register Befehle spezifizieren. In Fällen, in denen Spezifität gewünscht ist, werden die Adjektive logisch, architektonisch oder für Software sichtbar verwendet, um Register/Dateien in der Registerarchitektur zu bezeichnen, während unterschiedliche Adjektive verwendet werden, um Register in einer vorgegebenen Mikroarchitektur (z.B. ein physisches Register, einen Neuanordnungspuffer, ein Rückzugsregister, eine Registerdatenbasis) zu bezeichnen.
• Ein Befehlssatz enthält ein oder mehrere Befehlsformate. Ein vorgegebenes Befehlsformat definiert unterschiedliche Felder (Anzahl von Bits, Position von Bits), um unter anderem die auszuführende Operation und den/die Operand(en), an dem/denen jene Operation auszuführen ist, festzulegen. Ein vorgegebener Befehl wird unter Verwendung eines vorgegebenen Befehlsformats ausgedrückt und spezifiziert die Operation und die Operanden. Ein Befehlsdatenstrom ist eine spezielle Folge von Befehlen, wobei jeder Befehl in der Folge ein Vorkommen eines Befehls in einem Befehlsformat ist.
• Wissenschafts-, Finanz-, auto-vektorisierte Mehrzweck-, RMS- (Recognition, Mining, and Synthesis)/visuelle und Multimediaanwendungen (z.B. 2D/3D-Grafiken, Bildverarbeitung, Video-Kompression/Dekompression, Stimmerkennungsalgorithmus und Audio-Bearbeitung) erfordern häufig eine (als „Datenparallelität“ bezeichnete) Ausführung der gleichen Operation an einer großen Anzahl von Datenelementen. Einzelbefehl-Mehrfachdaten (Single Instruction Multiple Data, SIMD) bezieht sich auf einen Typ eines Befehls, der einen Prozessor dazu veranlasst, die gleiche Operation an mehreren Datenelementen auszuführen. Die SIMD-Technologie ist besonders für Prozessoren geeignet, die in der Lage sind, die Bits in einem Register in eine Anzahl von Datenelementen fester Größe logisch aufzuteilen, von denen jedes einen unabhängigen Wert repräsentiert. Beispielsweise können die Bits in einem 64-Bit-Register als ein Quelloperand spezifiziert werden, auf dem wie auf vier getrennten 16-Bit-Datenelementen, von denen jedes einen unabhängigen 16-Bit-Wert repräsentiert, zu arbeiten ist. Als ein weiteres Beispiel können die Bits in einem 256-Bit-Register als ein Quelloperand spezifiziert werden, auf dem wie auf vier getrennten 64-Bit gepackten Datenelementen (Datenelemente der Größe vier Wörter (Quad, Q)), acht getrennten 32-Bit gepackten Datenelementen (Datenelemente der Größe zwei Wörter (Double, D)), sechzehn getrennten 16-Bit gepackten Datenelemente (Datenelemente der Größe ein Wort (W)) oder zweiunddreißig getrennten 8-Bit-Datenelemente (Datenelemente der Größe ein Byte (B)) zu arbeiten ist. Dieser Datentyp wird als der gepackte Datentyp oder Vektordatentyp bezeichnet, und Operanden dieses Datentyps werden als gepackte Datenoperanden oder Vektoroperanden bezeichnet. Mit anderen Worten, ein gepacktes Datenelement bzw. Vektor bezeichnet eine Folge von gepackten Datenelementen; und ein gepackter Datenoperand bzw. Vektoroperand ist ein Quell- oder Zieloperand eines SIMD-Befehls (auch als ein gepackter Datenbefehl oder ein Vektorbefehl bekannt).
• Beispielsweise spezifiziert ein Typ eines SIMD-Befehls, dass eine einzelne Vektoroperation an zwei Quellvektoroperanden in einer vertikale Weise auszuführen ist, um einen (auch als Ergebnisvektoroperanden bezeichneten) Zielvektoroperanden gleicher Größe, mit derselben Anzahl von Datenelementen und in derselben Datenelementreihenfolge zu erzeugen. Die Datenelemente in den Quellvektoroperanden werden als Quelldatenelemente bezeichnet, während die Datenelemente in dem Zielvektoroperanden als Ziel- oder Ergebnisdatenelemente bezeichnet werden. Diese Quellvektoroperanden weisen dieselbe Größe auf und enthalten Datenelemente derselben Breite, und enthalten somit dieselbe Anzahl von Datenelementen. Die Quelldatenelemente an denselben Bitpositionen in den beiden Quellvektoroperanden bilden Paare von Datenelementen (die auch als entsprechende Datenelemente bezeichnet werden; d. h. das Datenelement an der Datenelementposition 0 jedes Quelloperanden entsprechen sich, das Datenelement in Datenelementposition 1 jedes Quelloperanden entsprechen sich, und so weiter). Die Operation, die durch jenen SIMD-Befehl spezifiziert ist, wird an sämtlichen dieser Paare von Quelldatenelementen separat durchgeführt, um eine passende Anzahl von Ergebnisdatenelementen zu erzeugen, und jedes Paar von Quelldatenelementen hat somit ein entsprechendes Ergebnisdatenelement. Da die Operation vertikal verläuft, und da der Ergebnisvektoroperand dieselbe Größe hat, dieselbe Anzahl von Datenelementen hat, und die Ergebnisdatenelemente in derselben Datenelementreihenfolge wie die Quellvektoroperanden gespeichert sind, befinden sich die Ergebnisdatenelemente an denselben Bitpositionen des Ergebnisvektoroperanden wie deren entsprechendes Paar von Quelldatenelementen in den Quellvektoroperanden. Zusätzlich zu diesem exemplarischen Typ eines SIMD-Befehls gibt es vielfältige andere Arten von SIMD-Befehlen (beispielsweise solche mit nur einem einzigen oder mehr als zwei Quellvektoroperanden; solche, die horizontal arbeiten; solche, die einen Ergebnisvektoroperanden erzeugen, der eine unterschiedliche Größe aufweist, die eine unterschiedliche Größe von Datenelementen aufweisen, und/oder die eine unterschiedliche Datenelementreihenfolge aufweisen). Es sollte klar sein, dass der Begriff Zielvektoroperand (oder Zieloperand) als das unmittelbare Ergebnis einer Ausführung der Operation definiert ist, die durch einen Befehl spezifiziert ist, einschließlich der Speicherung jenes Zieloperanden an einem Ort (sei es ein Register oder an einer Speicheradresse, die durch jenen Befehl spezifiziert ist), so dass darauf durch einen weiteren Befehl (durch Spezifizierung jenes selben Ortes durch den weiteren Befehl) als auf einen Quelloperanden zugegriffen werden kann.
• Figurenliste
• Die vorliegende Erfindung wird anhand von Beispielen und ohne Einschränkung in den Figuren der begleitenden Zeichnungen dargestellt, in denen gleiche Bezugszeichen gleiche Elemente bezeichnen und in denen:
• 1 eine Ausführungsform einer Hardware zur Verarbeitung eines nvCheckTag-Befehls zeigt;
• 2 eine Ausführungsform eines Systems zeigt, das einen NVRAM verwendet;
• 3 ein Beispiel einer Ausführung eines nvCheckTag-Befehls gemäß einer Ausführungsform zeigt;
• 4 Ausführungsformen des nvCheckTag-Befehls zeigt;
• 5 eine Ausführungsform eines Verfahrens zeigt, das durch einen Prozessor durchgeführt wird, um einen nvCheckTag-Befehl zu verarbeiten;
• 6 eine Ausführungsform des Ausführungsabschnitts des Verfahrens zeigt, das durch einen Prozessor durchgeführt wird, um einen nvCheckTag-Befehl zu verarbeiten;
• 7A-7B in Blockdiagrammen ein generisches vektorfreundliches Befehlsformat und Befehlsmodelle derselben gemäß Ausführungsformen der Erfindung zeigen;
• 8A-D ein beispielhaftes spezielles vektorfreundliches Befehlsformat gemäß Ausführungsformen der Erfindung zeigen;
• 9 ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform der Erfindung zeigt;
• 10A in einem Blockdiagramm sowohl eine beispielhafte geordnete Pipeline als auch eine beispielhafte Register umbenennende, ungeordnete Ausgabe-/Ausführungspipeline gemäß Ausführungsformen der Erfindung zeigt;
• 10B in einem Blockdiagramm sowohl eine Ausführungsform eines Kerns mit einer geordneten Architektur als auch einen beispielhaften Kern einer Register umbenennenden, ungeordneten Ausgabe-/Ausführungsarchitektur, der in einem Prozessor zu verwenden ist, gemäß Ausführungsformen der Erfindung zeigt;
• 11A-B ein Blockdiagramm einer spezielleren beispielhaften geordneten Kernarchitektur zeigen, wobei der Kern einer von unterschiedlichen Logikblöcken (einschließlich anderer Kerne desselben Typs und/oder eines anderen Typs) auf einem Chip sein würde;
• 12 in einem Blockdiagramm einen Prozessor 1200 zeigt, der mehr als einen Kern haben kann, eine integrierte Speichersteuereinrichtung haben kann und eine integrierte Grafikkarte haben kann, gemäß Ausführungsformen der Erfindung;
• 13-16 Blockdiagramme beispielhafter Computerarchitekturen zeigen; und
• 17 ein Blockdiagramm zeigt, das die Verwendung eines Softwarebefehlsumwandlers zum Umwandeln binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung gegenüberstellt.
• DETAILLIERTE BESCHREIBUNG
• In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt. Jedoch versteht sich, dass Ausführungsformen der Erfindung ohne diese spezifischen Details umgesetzt werden können. In anderen Beispielen wurden wohlbekannte Schaltkreise, Strukturen und Techniken nicht ausführlich gezeigt, um das Verständnis der Beschreibung nicht zu verschleiern.
• Bezugnahmen in der Beschreibung auf „eine (1) Ausführungsform“, „eine Ausführungsform“, „eine beispielhafte Ausführungsform“ und dergleichen, weisen darauf hin, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine Struktur oder ein Charakteristikum enthalten kann, ohne dass jede Ausführungsform dass bestimmte Merkmal, die Struktur oder das Charakteristikum notwendigerweise enthalten muss. Darüber hinaus beziehen sich solche Angaben nicht notwendigerweise auf die gleiche Ausführungsform. Ferner wird vorausgeschickt, dass es, wenn ein bestimmtes Merkmal, eine Struktur oder ein Charakteristikum in Verbindung mit einer Ausführungsform beschrieben wird, zum Wissen eines Durchschnittsfachmanns gehört, ein solches Merkmal, eine Struktur oder ein Charakteristikum in Verbindung mit anderen Ausführungsformen aufzunehmen, unabhängig davon, ob es ausdrücklich beschrieben ist oder nicht.
• Speichertechnologien der nächsten Generation werden einen Nichtflüchtigen Direktzugriffsspeicher (NVRAM) zusätzlich unterstützen, der Daten bewahrt, wenn der Strom ausgeschaltet ist, während seine Leistung derjenigen eines dynamischen Speichers mit wahlfreiem Zugriff (Dynamic Random Access Memory, DRAM), wie er gegenwärtig allgemein verwendet wird, ausreichend nahe kommt. Gegenwärtig werden neue Anwendungsprogrammierschnittstellen (Application Programming Interfaces, APIs) entwickelt, die einen raschen Zugriff auf der Ebene des Benutzers/Compilers auf einen NVRAM über reguläre Speicherbefehle ermöglichen, die ein Weiterbestehen speicherinterner Datenstrukturen bei einem Systemabsturz ermöglichen. Um Konsistenz sicherzustellen, werden dauerhafte Regionen mit transaktionaler Semantik (atomische Aktualisierungen - es werden entweder sämtliche oder keine der Aktualisierungen in dem Bereich sichtbar) definiert; Aktualisierung von dauerhaften Daten bewahren die ältere Version von Daten durch Kopieren älterer Versionen in ein reserviertes Gebiet in einem dauerhaften Speicher - ähnlich dem „Kopieren beim Schreiben“ (Copy on Write). Folglich können Änderungen während einer Wiederherstellungsphase rückgängig gemacht werden.
• Sei beispielsweise angenommen, dass Zeiger „p“ und „q“ auf Daten verweisen, die in einem NVRAM zugewiesen sind.

 p->data = ...;
 q->data = ...;

Der Compiler/Benutzer kann mittels Undo-Protokollierung „undo-logging“ (Schreiben alter Werte in ein in dem NVRAM zugewiesenes Protokoll) folgenden Programmcode erzeugen, um die alten Werte zu bewahren, bevor Aktualisierungen an „p->data“ und „q->data“ durchgeführt werden, wie unten gezeigt.

write p->data to NVM log /*NVM log, das genutzt wird,
 um den NVRAM in einen konsistenten Zustand
 zurückzuversetzen, falls es vor dem Übergabepunkt
 (commit point) zu einem Absturz kommt*/
 p->data = new_p_data;
 ...
 write q->data to NVM log
 q->data = new_q_data;
 ...
 commit region //NVM log entries are discarded

Um die Undo-Protokollierung korrekt zu gestalten, sollten alte Werte von „p->data“ und „q->data“ in ein NVM-Protokoll eingetragen werden, bevor entsprechende Aktualisierungen in den NVRAM geschrieben werden. Diese bedeutet, dass die entsprechenden Cachezeilen für NVM-Protokolldaten entleert „flushed“ werden sollten und nach Schreibvorgängen in das NVM-Protokoll eine geeignete Speicherabgrenzung eingefügt werden sollte, um eine Speichereihenfolge zu erzwingen. Folglich sollte der oben erwähnte Programmcode wie folgt modifiziert werden:

 write p->data to NVM_log
 flush NVM log data from cache to NVM
 p->data = new_p_data;
 ...
 write q->data to NVM_log
 flush NVM log data from cache to NVM
 q->data = new_q_data;
 ...
 flush all NVM data from cache to NVM
 commit region //NVM log entries are discarded

Das Entleeren der NVM-Protokolldaten und das Erzwingen der Schreibreihenfolge kann beispielsweise durch die folgende Schrittfolge verwirklicht werden, wobei „addr“ die Adresse des Protokolleintrags ist, und „len“ die Größe des Protokolleintrags ist.

 /* Schleife durch aneinandergereihte Datenblöcke einer
 Cachezeilenlänge (gewöhnlich 64B), die den vorgegebenen
 Bereich abdecken*/
 for (ptr = addr & ~(FLUSH_ALIGN - 1); ptr < addr + len;
 ptr += FLUSH_ALIGN) {
      _mm_clwb(ptr) ;
 }
 _mm_sfence() ;/* Sicherstellen, dass Cachezeile-
 Zurückschreiben (cache-line writeback, CLWB) vor
 PCOMMIT vollendet ist */
 _mm_pcommit() ;/*Sicherstellen, dass Daten in NVM
 gespeichert werden -- Befehl zur seriellen Anordnung
 mit langer Latenzzeit */
 _mm_sfence();

Allgemein ist ein Ausspülen „flushing“ der Protokolldaten vor jeder Aktualisierung sehr kostspielig. Falls die Zeiger „p“ und „q“ per Alias verbunden sind, was bedeutet, dass „p->data“ und „q->data“ dieselben NVM-Speicherorte sind, ist der zweite Vorgang einer NVM-Protokollierung (Lesen eines alten Werts von q->data, Schreiben desselben in das NVM_Protokoll, Ausspülen der NVM_Protokoll-Cachezeile und die gesamte kostspielige Erzwingung des Speicherns) außerdem redundant und weist in der Regel eine negative Wirkung auf die Leistung auf. Andererseits bei Fehlen einer effizienten Laufzeit/Hardwareunterstützung muss der Compiler/Programmierer -- speziell, bei Vorhandensein eines komplexen Laufzeitdaten- und Steuerdatenstroms -- vor einer Aktualisierung des NVRAM-Orts regelmäßig die Schritte der Wiederherstellung der Protokollierung (undo-logging) durchführen.

Im Vorliegenden sind im Einzelnen Ausführungsformen eines Hardwareunterstützungsmechanismus beschrieben, die einer Software ermöglichen, die unnötige Wiederherstellung der Protokollierung zur Laufzeit wirkungsvoll herauszufiltern. Speziell sind Ausführungsformen von Vorrichtungen, Systemen und Verfahren für einen nichtflüchtigen Speicheradresscache-Kennsatzüberprüfungs(non-volatile memory address Cache Tag Check, „nvCheckTag“)-Befehl beschrieben, der bei Ausführung durch einen Hardwareprozessor eine Entscheidung dahingehend veranlasst, ob ein Kennsatz der Adresse von seinem Quelloperanden zu einem Kennsatz in einer oder mehreren ausgewählten Cachezeilen eines nichtflüchtigen Speicheradresscache (der dem nichtflüchtigen Direktzugriffsspeicher zugeordnet ist) passt, wobei bei Vorhandensein einer Übereinstimmung eine Trefferanzeige (z.B. eine „1“) in seinem Zieloperanden gespeichert wird, jedoch bei Fehlen einer Übereinstimmung eine Fehlanzeige (z.B. eine „0“) in dem Zieloperanden gespeichert wird und die nichtflüchtige Speicheradresscache mit dem Kennsatz von der Adresse von dem Quelloperanden aktualisiert wird. In einigen Ausführungsformen setzt eine Trefferanzeige voraus, dass der Cachezeileneintrag mit einem passenden Kennsatz gültig ist. Wenn keine Übereinstimmung gefunden wird, wird in einigen Ausführungsformen auf der Grundlage eines zuletzt verwendeten Werts, der in der/den ausgewählten Cachezeile(n) gespeichert ist oder dieser/diesen zugeordnet ist, ein Pfad ausgewählt. In einigen Ausführungsformen wird die Cachezeile mittels eines Index ausgewählt, der in der Adresse von dem Quelloperanden gespeichert ist.

Eine Software kann diesen Befehl verwenden, um den Cache zu durchsuchen und zu überprüfen, ob die NVM-Daten (Cachezeilen) bereits gesichert sind, und falls dies der Fall ist (im Falle eines Treffers), vermeidet sie die Durchführung redundanter Sicherungen.

1 zeigt eine Ausführungsform von Hardware zur Verarbeitung eines nvCheckTag-Befehls. Die veranschaulichte Hardware ist gewöhnlich ein Teil eines Hardwareprozessors oder Kerns, beispielsweise ein Teil einer Zentraleinheit (CPU), eines Beschleunigers und dergleichen.

Ein nvCheckTag-Befehl wird durch eine Decodierschaltung 101 empfangen. Beispielsweise empfängt die Decodierschaltung 101 diesen Befehl von einer Abruf-Logik/Schaltung. Der nvCheckTag-Befehl enthält Felder für einen Quelloperanden (z.B. ein (auch als ein Vektorregister bezeichnetes) gepacktes Datenregister oder einen Speicherort) und einen Zieloperanden (z.B. ein (auch als ein Vektorregister bezeichnetes) gepacktes Datenregister oder einen Speicherort). Detailliertere Ausführungsformen von Befehlsformaten werden weiter unten im Einzelnen erörtert.

Die Decodierschaltung 101 decodiert den nvCheckTag-Befehl in eine oder mehrere Operationen. In einigen Ausführungsformen umfasst diese Decodierung den Schritt des Erzeugens mehrerer Mikrooperationen, die durch eine Ausführungsschaltung (beispielsweise eine Ausführungsschaltung 109) durchzuführen ist. Die Decodierschaltung 101 decodiert auch Befehlspräfixe.

In einigen Ausführungsformen sieht eine Registerumbenennungs-, Registerzuweisungs- und/oder Planungsschaltung 103 Funktionalität für eines oder mehreres von Folgendem vor: 1) Umbenennen logischer Operandenwerte in physische Operandenwerte (z.B. in einigen Ausführungsformen in einer Register-Alias-Tabelle), 2) Zuweisen von Statusbits und Flags zu dem decodierten Befehl, und/oder 3) Planen des decodierten Befehls zur Ausführung auf einer Ausführungsschaltung aus einer Befehlsdatenbasis (in einigen Ausführungsformen beispielsweise unter Verwendung einer Reservierungsstation) .

Register (Registerdatei) 105 und Speicher 107 speichern Daten als Operanden des nvCheckTag-Befehls, der durch eine Ausführungsschaltung 109 zu bearbeiten ist. Beispielhafte Registertypen beinhalten gepackte Datenregister, Mehrzweckregister und Fließkommaregister. Das Register 105 kann ferner Schreibmaskenregister einschließen, wie hier im Einzelnen erörtert.

Die Ausführungsschaltung 109 führt den decodierten nvCheckTag-Befehl aus, um eine Entscheidung darüber zu treffen, ob ein Kennsatz der Adresse von seinem Quelloperanden zu einem Kennsatz in einer (oder mehreren) ausgewählten Cachezeile(n) eines nichtflüchtigen Speicheradresscache passt, wobei bei Vorhandensein einer Übereinstimmung eine Trefferanzeige (z.B. eine „1“) in seinem Zieloperanden gespeichert wird, jedoch bei Abwesenheit einer Übereinstimmung, eine Fehlanzeige (z.B. eine „0“) in dem Zieloperanden gespeichert wird und der nichtflüchtige Speicheradresscache mit dem Kennsatz von der Adresse von dem Quelloperanden aktualisiert wird. In einigen Ausführungsformen setzt eine Trefferanzeige voraus, dass der Cachezeileneintrag mit einem passenden Kennsatz gültig ist. Wenn keine Übereinstimmung gefunden wird, wird in einigen Ausführungsformen auf der Grundlage eines zuletzt verwendeten Werts, der in der/den ausgewählten Cachezeile(n) gespeichert ist oder dieser/diesen zugeordnet ist, ein Pfad ausgewählt. In einigen Ausführungsformen wird die Cachezeile mittels eines Index ausgewählt, der in der Adresse von dem Quelloperanden gespeichert ist.

In einigen Ausführungsformen übergibt eine Rückzugsschaltung 111 ein Ergebnis architektonisch (übergibt z.B. ein Zielregister in die Register 105) und zieht den Befehl zurück.

2 veranschaulicht eine Ausführungsform eines Systems, das einen NVRAM verwendet. Ein Prozessor (oder Kern) 205 enthält einen nichtflüchtigen Speicheradresscache (Non-Volatile Memory Address Cache, NVMAC) 207 für einen NVRAM 201. Ein Beispiel eines derartigen NVMAC ist in 3 dargestellt. Der NVMAC 207 kann als ein Teil eines vorhandenen Datencache oder als eine unabhängige Hardwarestruktur durchgeführt werden. Der Prozessor (oder Kern) 205 führt den hier im Einzelnen erörterten nvCheckTag-Befehl durch.

Mit dem Prozessor (Kern) 205 ist ein Speicher 203 verbunden. Dieser Speicher 203 enthält den NVRAM 201 und einen weiteren dauerhaften Speicher 209, wie beispielsweise ein Plattenlaufwerk oder FLASH-Laufwerk. Der NVRAM 201 speichert ein Protokoll 211, wie im Vorausgehenden im Einzelnen erörtert.

3 veranschaulicht ein Beispiel einer Ausführung eines nvCheckTag-Befehls gemäß einer Ausführungsform. Der Befehl enthält einen Zieloperanden und einen Quelloperanden. Der Quelloperand liefert eine Adresse. Zu beachten ist, dass dieses Beispiel nicht beschränken soll. Während dieses Beispiel einen nichtflüchtigen Speicheradresscache (z.B. den NVMAC 207) zeigt, der beispielsweise ein zwei Pfade aufweisender assoziativer Cache ist, bei dem mittlere Adressbits verwendet werden, um den Cache zu indizieren, und höhere Adressbits als der Kennsatz verwendet werden, wird dies nicht vorausgesetzt. Andere Ausführungsformen beinhalten eine andere Anzahl von Pfaden, LRU- oder gültigen Bits, die anderweitig gespeichert sind, und dergleichen.

Die Auflösung jedes Eintrags (Cachezeile) des NVMAC wird durch die Anzahl von Bits niedriger Adresse bestimmt, die ignoriert werden (Offset-Bits). Weiter kann der NVMAC, falls erforderlich, von dem tatsächlichen Datencache vollkommen entkoppelt sein, mit anderen Worten, er muss nicht unbedingt mit dem tatsächlichen Datencache kohärent gehalten werden, und seine Größe kann einen Bereich von einigen Zehn Bytes bis zu ein paar Hundert Kilobytes aufweisen. Weiter enthält der NVMAC Kennsatzfelder, muss jedoch keine Datenfelder enthalten. In diesem Beispiel ist der NVMAC virtuell indiziert und physisch mit einem Kennsatz versehen - d. h. eine virtuelle Adresse, die durch Adresserzeugungseinheiten erzeugt ist, durchläuft noch eine Adressübersetzung, die einen Übersetzungs-Lookaside-Puffer (Translation Lookaside Buffer (TLB) verwendet. Um kompatibel zu sein, ist die NVM-Zeilenlänge gewöhnlich mit der tatsächlichen Datencachezeilenlänge konform.

In diesem Beispiel enthält der Quelloperand des nvCheckTag-Befehls eine Adresse 300. Diese Adresse wird in einen oder mehrere Teile zerlegt, beispielsweise in einen Kennsatz 302, einen Index 304 und einen Offset (Versatz) 306. Der Index 304 wird verwendet, um zu ermitteln, welche Cachezeile für einen Kennsatzvergleich ausgewählt wird. Der Adresskennsatz 302 entspricht gewöhnlich (wie gezeigt) den höheren Bits einer Adresse. Jeder Eintrag (Cachezeile) eines Cachepfads 308, 310 enthält einen Kennsatz und ein gültiges Bit. Das gültig Bit zeigt an, ob der (gelegentlich als „Cachezeilenkennsatz“ bezeichnete) Kennsatz in der NVMAC-Cachezeile gültig ist. In einigen Ausführungsformen enthält eine NVMAC-Cachezeile ein zuletzt verwendetes (Least Recently Used, LRU) Bit, das als ein Teil einer Austauschstrategie verwendet wird. Beispielsweise kann für den für zwei Pfade eingerichteten assoziativen Cache ein einzelnes LRU-Bit pro Cachezeile verwendet werden. Gewöhnlich wird der Offset 306 während der Ausführung eines nvCheckTag-Befehls nicht verwendet.

Eine Ausführung eines nvCheckTag-Befehls bewirkt einen Vergleich durch Vergleichsschaltkreise 312, 316 des Adresskennsatzes 302 von der Adresse, die durch den Quelloperanden geliefert ist, mit einem Cachezeilenkennsatzwert von jedem Cachepfad 308, 310, und speziell von einer Cachezeile pro Pfad 308, 310, die durch den Index 304 ausgewählt ist. Wie gezeigt, zeigt der Index 304 auf die dritte Cachezeile auf jedem Pfad 308, 310. Falls der Adresskennsatz 302 zu einem ausgewählten Cachezeileneintrag passt, wird das Ergebnis, das von der Vergleichsschaltung 314, 318 ausgegeben wird, die die Übereinstimmung erzeugt, eine „1“ sein.

Das gültige Bit jeder der ausgewählten NVMAC-Cachezeileneinträge wird gemeinsam mit dem Ausgang der entsprechenden Vergleichsschaltung mittels einer Hardwareschaltung (z.B. einem UND-Gatter 314 oder UND-Gatter 318) bewertet. Daher wird der Ausgang der Bewertung, wenn eine Kennsatzübereinstimmung für einen gültigen NVMAC-Cachezeileneintrag vorhanden ist, ein „Treffer“ (z.B. eine „1“) sein. Falls keine derartige Übereinstimmung vorhanden ist, wird der Ausgang der Bewertung eine „Fehlanzeige“ (z.B. eine „0“) sein. Jede Anzeige eines „Treffers“ auf irgendeinem Pfad des NVMAC wird an das Ziel als ein „Treffer“ für den NVMAC ausgegeben. In der Ausführungsform wird ein ODER-Gatter 320 verwendet, so dass ein Treffer auf einem der beiden Pfade 308, 310 zur Folge hat, dass in dem Zieloperanden 330 des Befehls ein „Treffer“ gespeichert wird.

Falls auf sämtlichen Pfaden eine „Fehlanzeige“ vorhanden ist, wird in dem Zieloperanden 330 eine „Fehlanzeige“ gespeichert. Im Falle der „Fehlanzeige“ wird eine zusätzliche Schaltung verwendet, um auszuwählen, welcher der Pfade 308, 310 des NVMAC aktualisiert werden wird, um den Adresskennsatz 302 von der Adresse zu speichern, die durch den Quelloperanden 300 geliefert wird. In dem Beispiel wählt eine XOR-Schaltung 324 den Pfad, der im Falle einer Fehlanzeige mit den Daten des Adresskennsatzes 302 zu aktualisieren ist. Der ausgewählte Pfad wird aktualisiert und sein entsprechendes LRU-Bit wird in Antwort auf die Fehlanzeige ebenfalls umgeschaltet.

Eine Ausführungsform eines Formats (das Felder aufweist) für einen nvCheckTag-Befehl ist nvCheckTag DST, SRC. nvCheckTag ist der Opcode des Befehls und DST und SRC sind Ziel- bzw. Quelloperanden. Gewöhnlich sind die Operanden Register (z.B. Mehrzweckregister). SRC speichert eine Adresse „Addr“, die die Adresse des NVRAM-Orts ist, der aktualisiert wird (in dem oben erwähnten Beispiel p->data). Gewöhnlich wird das DST auf „1“ eingestellt, falls die Durchsuchung nach den NVRAM-Ort in dem NVMAC einen „Treffer“ ergibt. Andernfalls wird im Falle einer Fehlanzeige an das DST eine „0“ zurückgegeben und in dem NVMAC wird für die „Addr“ (den „Kennsatz“-Teil) ein Eintrag zugewiesen, so dass das nächste Nachschlagen derselben Adresse (Cachezeile) im Ergebnis einen „Treffer“ ergeben würde.

4 zeigt Ausführungsformen des nvCheckTag-Befehls, der Felder für den Opcode 401, den Zieloperanden 403 und den Quelloperanden 405 aufweist.

5 veranschaulicht eine Ausführungsform eines Verfahrens, das durch einen Prozessor durchgeführt wird, um einen nvCheckTag-Befehl zu verarbeiten.

In Schritt 501 wird ein Befehl abgerufen. Beispielsweise wird ein nvCheckTag-Befehl abgerufen. Der nvCheckTag-Befehl enthält Felder für einen Opcode, einen Quelloperanden und einen Zieloperanden. Beispielhafte Operanden sind Mehrzweckregister. Gewöhnlich speichert der Quelloperand eine Adresse, die einen Kennsatz, einen Index und einen Offset aufweist, wie im Vorausgehenden im Einzelnen erörtert. In einigen Ausführungsformen wird der Befehl von einem Befehlscache abgerufen.

Der abgerufene Befehl wird in Schritt 503 decodiert. Beispielsweise wird der abgerufene nvCheckTag-Befehl durch eine Decodierschaltung decodiert, wie sie beispielsweise hier im Einzelnen erörtert ist. In einigen Ausführungsformen wird der Befehl in einer oder mehreren Mikrooperationen decodiert.

Daten, die dem Quelloperanden des decodierten Befehls zugeordnet sind, werden in Schritt 505 ausgelesen.

In Schritt 507 wird der decodierte Befehl durch eine Ausführungsschaltung (Hardware) ausgeführt, wie sie beispielsweise hier im Einzelnen erörtert ist. Für den nvCheckTag-Befehl wird die Ausführung ermitteln, ob ein Kennsatz von der Adresse von dem Quelloperanden zu einem Kennsatz in einer (oder mehreren) ausgewählten NVMAC-Cachezeile(n) passt, wobei bei Vorhandensein einer Übereinstimmung eine Trefferanzeige (z.B. eine „1“) in dem Zieloperanden gespeichert wird, jedoch bei Abwesenheit einer Übereinstimmung eine Fehlanzeige (z.B. eine „0“) in dem Zieloperanden gespeichert wird und der nichtflüchtige Speicheradresscache mit dem Kennsatz von der Adresse von dem Quelloperanden aktualisiert wird. In einigen Ausführungsformen setzt eine Trefferanzeige voraus, dass der NVMAC-Cachezeileneintrag mit einem passenden Kennsatz gültig ist. In einigen Ausführungsformen wird, wenn keine Übereinstimmung gefunden wird, auf der Grundlage eines zuletzt verwendeten Werts, der in der/den ausgewählten NVMAC-Cachezeile(n) gespeichert ist oder dieser/diesen zugeordnet ist, ein Pfad des NVMAC ausgewählt. In einigen Ausführungsformen wird/werden die NVMAC-Cachezeile(n) mittels eines Index ausgewählt, der in der Adresse von dem Quelloperanden gespeichert ist.

In einigen Ausführungsformen wird der Befehl übergeben oder in Schritt 509 zurückgezogen.

6 veranschaulicht eine Ausführungsform des Ausführungsabschnitts des Verfahrens, das durch einen Prozessor durchgeführt wird, um einen nvCheckTag-Befehl zu verarbeiten.

In Schritt 601 wird ein Index von der Adresse von dem Quelloperanden verwendet, um auf einen speziellen Eintrag (eine Cachezeile) für jeden Pfad des nichtflüchtigen Speicheradresscache zuzugreifen.

Ein Kennsatzwert von jeder der zugegriffenen Cachezeilen wird mit dem Kennsatz von der Adresse verglichen, die bei QAE03 durch den Quelloperanden ausgegeben ist. Diese Vergleiche ermitteln, ob eine Kennsatzübereinstimmung vorhanden ist.

Jedes Vergleichsergebnis wird jeweils mit einem gültigen Bit von der entsprechenden zugegriffenen Cachezeile bei QAE05 mit UND verknüpft. Beispielsweise wird das Vergleichsergebnis des Verwendens eines Kennsatzes von einer Cachezeile X von Pfad 0 mit dem gültigen Bit von einer Cachezeile X von Pfad 0 mit UND verknüpft, das Vergleichsergebnis des Verwendens eines Kennsatzes von einer Cachezeile X von Pfad 1 wird mit dem gültigen Bit von einer Cachezeile X von Pfad 1 mit UND verknüpft, usw.

Die Ausgänge der UND-Operationen werden mit ODER verknüpft und der Ausgang des ODER wird als ein Ergebnis ausgegeben und bei QAE07 in dem Zieloperanden gespeichert.

In einigen Ausführungsformen wird, wenn das Ergebnis des ODER eine Anzeige einer „Fehlanzeige“ ist, auf der Grundlage eines LRU-Bits der zugegriffenen Cachezeilen bei QAE09 ein Pfad des NVMAC ausgewählt. Die zuvor zugegriffene Cachezeile, die zu dem ausgewählten Pfad gehört, wird mit dem Kennsatz von der Adresse von dem Quelloperanden aktualisiert und ihr LRU-Bit bei QAE11 umgeschaltet.

Eine Verwendung des (weiter unten als „_mm_nvCheckTag(ptr)“ gezeigten) nvCheckTag-Befehls, der eine NVMAC der oben erörterten Art inspiziert, wird hier näher beschrieben. Ein nvCheck(addr, len)-Makro kann mit der folgenden Schrittfolge durchgeführt werden, die den NVMAC in einer Schleife nach Treffern (Einträgen, die in dem Protokoll keiner Aktualisierung bedürfen) durchsucht:

 result = 1;
 /* Durchlaufen aneinandergereihter Datenblöcke einer
 Cachezeilenlänge (gewöhnlich 64B), die den vorgegebenen
 Bereich abdecken, in einer Schleife*/
 for (ptr = addr & ~(FLUSH_ALIGN - 1); ptr < addr + len;
 ptr += FLUSH_ALIGN) {
 result &= _mm_nvCheckTag(ptr); //snoop nvAddrCache for
 cache line containing ptr
 }

Der nvCheck(addr, len)-Makrobefehl kann verwendet werden, um den Programmcode, der die Undo-Protokollierung durchführt, zu schützen, wie weiter unten gezeigt. Falls einer der oben erwähnten _mm_nvCheckTag-Befehle eine Null - eine Fehlanzeige in dem Speicheradressen-Cache - zurückgibt, wird die Bedingung, die die Undo-Protokollierung steuert, mit wahr bewertet. Wenn andernfalls sämtliche entsprechenden Cachezeilen bereits gesichert wurden, wird die Undo-Protokollierung übersprungen:

 if(nvCheck(&p->data, size) == 0){
 write cache lines holding p->data to NVM_log
 flush NVM log data from cache to NMV
 }
 p->data = new_p_data;
 ...
 if(nvCheck(&q->data, size) == 0){
 write cache lines holding q->data to NVM_log
 flush NVM log data from cache to NMV
 } 







 q->data = new_q_data;
 ...
 flush all NVM data from cache to NMV
 commit region //NVM log entries are discarded

Die Undo-Protokollierung selbst ist geringfügig modifiziert, um die vollständige(n) Cachezeile(n) zu erhalten, die die Daten enthält/enthalten, die aktualisiert werden (hier p->data und q->data). Das nvCheck-Makro kann ferner in die Undo-Protokollierung integriert werden, um lediglich diejenigen Cachezeilen zu protokollieren, für die entsprechende Adressen in dem nvAddrCache fehlen.

Die nachfolgenden Figuren stellen im Einzelnen Beispiele von Architekturen und Systemen zur Durchführung von Ausführungsformen des Vorausgehenden dar. In einigen Ausführungsformen werden eine oder mehrere oben beschriebene Hardwarekomponenten und/oder Befehle emuliert, wie nachfolgend im Einzelnen erörtert, oder als Softwaremodule durchgeführt.

Ausführungsformen des einen oder der mehreren oben im Einzelnen beschriebenen Befehle sind in einem „generischen vektorfreundlichen Befehlsformat“ ausgeführt oder können darin ausgeführt werden, wie es nachfolgend im Einzelnen erörtert ist. In weiteren Ausführungsformen wird ein derartiges Format nicht verwendet und es wird ein anderes Befehlsformat verwendet, die nachstehende Beschreibung des Schreibmaskenregisters, unterschiedlicher Datentransformationen (Swizzle, Broadcast und dergleichen), Adressierung und dergleichen ist jedoch allgemein auf die Beschreibung der Ausführungsformen des einen oder der mehreren oben beschriebenen Befehle anwendbar. Zusätzlich werden nachfolgend beispielhafte Systeme, Architekturen und Pipelines im Einzelnen erläutert. Ausführungsformen des einen oder der mehreren oben beschriebenen Befehle können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind aber nicht auf die erläuterten beschränkt.

Ein Befehlssatz kann ein oder mehrere Befehlsformate aufweisen. Ein vorgegebenes Befehlsformat kann unterschiedliche Felder (z.B. eine Anzahl von Bits, eine Position von Bits) definieren, um unter anderem die auszuführende Operation (z.B. den Opcode) und den/die Operand(en), an dem/denen jene Operation auszuführen ist, und/oder andere Datenfeld(er) (z.B. eine Maske) festzulegen. Einige Befehlsformate werden durch die Definition von Befehlsmodellen (oder Unterformaten) weiter zerlegt. Beispielsweise können die Befehlsmodelle eines vorgegebenen Befehlsformats definiert sein, um unterschiedliche Teilsätze der Felder des Befehlsformats aufzuweisen (die enthaltenen Felder sind gewöhnlich in derselben Reihenfolge angeordnet, jedoch weisen zumindest einige unterschiedliche Bitpositionen auf, da weniger Felder enthalten sind) und/oder können definiert sein, um ein vorgegebenes Feld anders zu interpretieren. Somit wird jeder Befehl einer ISA unter Verwendung eines vorgegebenen Befehlsformats (und falls es definiert ist, in einem vorgegebenen der Befehlsmodelle jenes Befehlsformats) ausgedrückt und enthält Felder zum Spezifizieren der Operation und der Operanden. Beispielsweise hat ein beispielhafter ADD-Befehl einen speziellen Opcode und ein Befehlsformat, das ein Opcode-Feld, um jenen Opcode zu spezifizieren, und Operandenfelder aufweist, um Operanden (Quelle1/Ziel und Quelle2) auszuwählen; und ein Vorkommen dieses ADD-Befehls in einem Befehlsdatenstrom wird in den Operandenfeldern spezielle Inhalte haben, die spezielle Operanden auswählen. Ein Satz von SIMD-Erweiterungen, die als die weiterentwickelten Vektorerweiterungen (Advanced Vector Extension, AVX) (AVX1 und AVX2) bezeichnet sind und das Vektorerweiterungs(Vector Extension, VEX)-Codierschema verwenden, wurde freigegeben und/oder veröffentlicht (siehe z.B. Intel® 64 and IA-32 Architectures Software Developer's Manual, September 2014; und siehe Intel® Advanced Vector Extensions Programming Reference, Oktober 2014).

Beispielhafte Befehlsformate

Ausführungsformen des einen oder der mehreren hier beschriebenen Befehle können in unterschiedlichen Formaten ausgeführt werden. Zusätzlich werden nachfolgend beispielhafte Systeme, Architekturen und Pipelines im Einzelnen erläutert. Ausführungsformen des/der Befehle können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind aber nicht auf die erläuterten beschränkt.

Generisches vektorfreundliches Befehlsformat

Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das für Vektorbefehle geeignet ist (beispielsweise existieren bestimmte Felder, die für Vektoroperationen spezifisch sind). Während Ausführungsformen beschrieben sind, in denen sowohl Vektor- als auch Skalaroperationen durch das vektorfreundliche Befehlsformat unterstützt werden, verwenden alternative Ausführungsformen lediglich Vektoroperationen vektorfreundlichen Befehlsformat.

7A-7B sind Blockdiagramme, die ein generisches vektorfreundliches Befehlsformat und Befehlsmodelle derselben gemäß Ausführungsformen der Erfindung zeigen. 7A ist ein Blockdiagramm, das ein generisches vektorfreundliches Befehlsformat und Befehlsmodelle der Klasse A desselben gemäß Ausführungsformen der Erfindung zeigt; während 7B ein Blockdiagramm ist, das das generische vektorfreundliche Befehlsformat und Befehlsmodelle der Klasse B desselben gemäß Ausführungsformen der Erfindung zeigt. Insbesondere ein generisches vektorfreundliches Befehlsformat 700, für das Befehlsmodelle der Klasse A und Klasse B definiert sind, die beide Nichtspeicherzugriffs-705-Befehlsmodelle und Speicherzugriffs 720-Befehlsmodelle einschließen. Der Begriff generisch im Kontext des vektorfreundlichen Befehlsformats bezieht sich darauf, dass das Befehlsformat nicht an irgendeinen bestimmten Befehlssatz gebunden ist.

Während Ausführungsformen der Erfindung beschrieben werden, bei denen das vektorfreundliche Befehlsformat das Folgende 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 sich somit ein 64-Byte-Vektor entweder aus 16 Doppelwortgrößenelementen oder alternativ aus 8 Vierwortgrößenelementen zusammensetzt); 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); alternativ können Ausführungsformen weitere, weniger und/oder andere Vektoroperandengrößen (z.B. 256-Byte-Vektoroperanden) mit mehr, weniger oder anderen Datenelementbreiten (z.B. 128 Bit (16 Byte) Datenelementbreiten) unterstützen.

Die Befehlsmodelle der Klasse A in 7A schließen ein: 1) innerhalb der Nichtspeicherzugriffs 705-Befehlsmodelle ist ein Nichtspeicherzugriff, vollständiges Rundungssteuertypenoperations 710-Befehlsmodell und ein Nichtspeicherzugriffs, Datentransformationstypenoperations 715-Befehlsmodell gezeigt; und 2) innerhalb der Speicherzugriffs, Datentransformationstypenoperations 715-Befehlsmodelle ist ein Speicherzugriffs, temporales 725-Befehlsmodell und ein Speicherzugriffs, nicht temporales 730-Befehlsmodell gezeigt. Die Befehlsmodelle der Klasse B in 7B schließen ein: 1) innerhalb der Nichtspeicherzugriffs 705-Befehlsmodelle ist ein Nichtspeicherzugriffs-, Schreibmaskensteuer-, partielles Rundungssteuertypenoperations 712-Befehlsmodell und ein Nichtspeicherzugriffs-, Schreibmaskensteuer-, vsize-Typenoperations 717-Befehlsmodell gezeigt; und 2) innerhalb der Speicherzugriffs 720-Befehlsmodelle ist ein Speicherzugriffs-, Schreibmaskensteuer 727-Befehlsmodell gezeigt.

Das generische vektorfreundliche Befehlsformat 700 enthält die folgenden Felder, die weiter unten in der in 7A-7B gezeigten Reihenfolge aufgeführt sind.

Formatfeld 740 - ein spezifischer Wert (ein Befehlsformatbezeichnerwert) kennzeichnet in diesem Feld eindeutig das vektorfreundliche Befehlsformat, und somit ein Vorkommen von Befehlen in dem vektorfreundlichen Befehlsformat in Befehlsdatenströmen. Auf diese Weise ist das Feld optional in dem Sinne, dass es nicht für einen Befehlssatz benötigt wird, der lediglich das generische vektorfreundliche Befehlsformat aufweist.

Basisoperationsfeld 742 - sein Inhalt unterscheidet unterschiedliche Basisoperationen.

Registerindexfeld 744 - sein Inhalt, gibt direkt oder durch Adresserzeugung die Orte der Quell- und Zieloperanden an, unabhängig davon, ob sie in Registern oder in dem Speicher vorliegen. Diese enthalten eine ausreichende Anzahl von Bits zum Auswählen von N Registern aus einer PxQ (beispielsweise 32x512, 16x128, 32x1024, 64x1024)-Registerdatei. Während N in einer Ausführungsform bis zu drei Quellen und ein Zielregister unterstützen kann, können alternative Ausführungsformen mehr oder weniger Quell- und Zielregister unterstützen (können beispielsweise bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel dient, können bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel dient, können bis zu zwei Quellen und ein Ziel unterstützen).

Modifiziererfeld 746 - sein Inhalt unterscheidet ein Vorkommen von Befehlen in dem generischen Vektorbefehlsformat, die einen Speicherzugriff spezifizieren, von denen, die dies nicht vornehmen, d. h. zwischen Nichtspeicherzugriffs 705-Befehlsmodellen und Speicherzugriffs 720-Befehlsmodellen. Speicherzugriffsoperationen lesen und/oder schreiben in die Speicherhierarchie (in einigen Fällen spezifizieren sie die Quell- und/oder Zieladressen unter Verwendung von Werten in Registern), während Nichtspeicherzugriffsoperationen dies nicht vornehmen (beispielsweise sind die Quelle und Ziele Register). Während in einer Ausführungsform dieses Feld auch zwischen drei verschiedenen Arten unterscheidet, um Speicheradressberechnungen durchzuführen, können alternative Ausführungsformen mehr, weniger oder andere Pfade unterstützen, um Speicheradressberechnungen durchzuführen.

Erweiterungsoperationsfeld 750 - sein Inhalt unterscheidet, welche von mehreren unterschiedlichen Operationen zusätzlich zu der Basisoperation durchgeführt werden sollen. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 768, ein Alphafeld 752 und ein Betafeld 754 unterteilt. Das Erweiterungsoperationsfeld 750 erlaubt, gemeinsame Gruppen von Operationen in einem einzelnen Befehl anstatt in 2, 3 oder 4 Befehlen durchzuführen.

Skalierfeld 760 - sein Inhalt erlaubt das Skalieren des Inhalts des Indexfelds zur Speicheradresserzeugung (beispielsweise für eine Adresserzeugung, die 2^scale * index + base verwendet) .

Verschiebungsfeld 762A - sein Inhalt wird als Teil der Speicheradresserzeugung verwendet (beispielsweise für eine Adresserzeugung, die 2^scale * index + displacement verwendet).

Verschiebungsfaktorfeld 762B (man beachte, dass die Übereinanderanordnung des Verschiebungsfelds 762A direkt über dem Verschiebungsfaktorfeld 762B anzeigt, dass eines von beiden verwendet wird) - sein Inhalt wird als Teil der Adresserzeugung verwendet; er spezifiziert einen Verschiebungsfaktor, der mit der Größe eines Speicherzugriffs (N) skaliert wird - wobei N die Anzahl von Bytes in dem Speicherzugriff ist (beispielsweise für eine Adresserzeugung, die eine Verschiebung von 2^scale * index + base + scaled displacement verwendet). Redundante niedrigwertige Bits werden ignoriert, und somit wird der Inhalt des Verschiebungsfaktorfelds mit der Gesamtgröße (N) der Speicheroperanden multipliziert, um die endgültige Verschiebung zu erzeugen, die beim Berechnen einer effektiven Adresse verwendet werden soll. Der Wert von N wird durch die Prozessorhardware zur Laufzeit anhand des (hier weiter unten beschriebenen) vollständigen Opcode-Felds 774 und des Datenmanipulationsfelds 754C bestimmt. Das Verschiebungsfeld 762A und das Verschiebungsfaktorfeld 762B sind optional in dem Sinne, dass sie nicht für Nichtspeicherzugriffs 705-Befehlsmodelle verwendet werden und/oder andere Ausführungsformen können lediglich eines oder keines von beiden durchführen.

Datenelementbreitenfeld 764 - sein Inhalt unterscheidet, welche einer Anzahl von Datenelementbreiten (in einigen Ausführungsformen für sämtliche Befehle; in anderen Ausführungsformen für lediglich einige der Befehle) verwendet werden soll. Dieses Feld ist optional in dem Sinne, dass es nicht benötigt wird, falls lediglich eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung irgendeines Aspekts der Opcodes unterstützt werden.

Schreibmaskenfeld 770 - sein Inhalt steuert auf der Grundlage einer jeweiligen Datenelementposition, ob diese Datenelementposition in dem Zielvektoroperanden das Ergebnis der Basisoperation und Erweiterungsoperation widerspiegelt. Klasse A Befehlsmodelle unterstützen Mischen-Schreibmaskieren, während Befehlsmodelle der Klasse B sowohl mischendesals auch nullsetzendes Schreibmaskieren unterstützen. Beim Mischen ermöglichen Vektormasken, dass irgendein Satz von Elementen im Ziel vor Aktualisierungen während der Ausführung irgendeiner Operation (die durch die Basisoperation und die Erweiterungsoperation spezifiziert wird) geschützt wird; in einer anderen Ausführungsform Erhalten des alten Werts jedes Elements des Ziels, an dem das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz dazu erlauben Vektormasken beim Nullsetzen ein Nullsetzen jedes Satzes von Elementen im Ziel während der Ausführung irgendeiner Operation (die durch die Basisoperation und die Erweiterungsoperation spezifiziert wird); in einer Ausführungsform wird ein Wert des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Eine Teilmenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der Operation, die ausgeführt wird, zu steuern (das heißt die Spanne von Elementen, die modifiziert werden, von dem ersten bis zu dem letzten); jedoch ist es nicht erforderlich, dass die Elemente, die modifiziert werden, aufeinanderfolgen. Daher ermöglicht das Schreibmaskenfeld 770 partielle Vektoroperationen, einschließlich von Lade-, Speicher-, arithmetischen, logischen Operationen und dergleichen. Während Ausführungsformen der Erfindung beschrieben sind, bei denen der Inhalt des Schreibmaskenfelds 770 aus einer Anzahl von Schreibmaskenregistern eines auswählt, das die zu verwendende Schreibmaske enthält (und somit der Inhalt des Schreibmaskenfelds 770 indirekt anzeigt, dass ein Maskieren durchgeführt werden soll), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Schreibmaskenfelds 770 direkt spezifiziert, dass das Maskieren durchgeführt werden soll.

Unmittelbares Feld 772 - sein Inhalt ermöglicht die Spezifizierung eines unmittelbaren Werts. Dieses Feld ist optional in dem Sinne, dass es nicht in einer Durchführung des generischen vektorfreundlichen Formats vorliegt, das unmittelbare Werte nicht unterstützt und nicht in Befehlen vorliegt, die keinen unmittelbaren Wert verwenden.

Klassenfeld 768 - sein Inhalt unterscheidet zwischen unterschiedlichen Klassen. Mit Bezug auf 7A-B, wählt der Inhalt dieses Felds zwischen Befehlen der Klasse A und Klasse B 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-B).

Befehlsmodelle der Klasse A

Im Falle der Nichtspeicherzugriffs 705-Befehlsmodelle der Klasse A, wird das Alphafeld 752 als ein RS-Feld 752A interpretiert, dessen Inhalt unterscheidet, welcher der unterschiedlichen Erweiterungsoperationstypen durchgeführt werden soll (beispielsweise werden Rundung 752A.1 und Datentransformation 752A.2 jeweils für die Nichtspeicherzugriffs, Rundungstypenoperations 710, und Nichtspeicherzugriffs, Datentransformationstypenoperations 715-Befehlsmodelle spezifiziert), während das Betafeld 754 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. Bei den Nichtspeicherzugriffs 705-Befehlsmodellen sind das Skalierfeld 760, das Verschiebungsfeld 762A und das Verschiebungsskalierfeld 762B nicht vorhanden.

Nichtspeicherzugriffsbefehlsmodelle - Vollständige Rundungssteuertypenoperation

Bei dem vollständigen Rundungssteuertypenoperations 710-Befehlsmodell bei Nichtspeicherzugriff, wird das Betafeld 754 als ein Rundungssteuerfeld 754A interpretiert, dessen Inhalt(e) statisches Runden liefern. Während in den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerfeld 754A ein Feld 756 zum Unterdrücken aller Fließkommaausnahmen (Suppress All Floating Point Exceptions, SAE) und ein Rundungsoperationssteuerfeld 758 enthält können alternative Ausführungsformen diese beiden Konzepte im gleichen Feld oder lediglich eines der beiden dieser Konzepte/Felder unterstützen/codieren (können beispielsweise lediglich das Rundungsoperationssteuerfeld 758 aufweisen).

SAE-Feld 756 - sein Inhalt unterscheidet, ob das Berichten von Ausnahmeereignissen ausgeschaltet werden soll oder nicht; wenn der Inhalt des SAE-Felds 756 anzeigt, dass Unterdrückung eingeschaltet ist, berichtet ein gegebener Befehl von keinerlei Fließkommaausnahme-Flag und ruft keinen Fließkommaausnahmebehandler auf.

Rundungsoperationssteuerfeld 758 - sein Inhalt unterscheidet, welche aus einer Gruppe von Rundungsoperationen durchgeführt werden soll (z.B. Aufrunden, Abrunden, Runden auf Null und Runden auf die nächste Zahl). Somit ermöglicht das Rundungsoperationssteuerfeld 758 ein Ändern des Rundungsmodus je nach Befehl. In einer Ausführungsform der Erfindung, bei der ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi enthält, erhält der Inhalt des Rundungsoperationssteuerfelds 750 Vorrang vor jenem.

Nichtspeicherzugriffsbefehlsmodelle - Datentransformationstypenoperation

Bei dem Befehlsmodell einer Nichtspeicherzugriffsdatentransformationstypenoperation 715 wird das Betafeld als ein Datentransformationsfeld 754B interpretiert, dessen Inhalt unterscheidet, welche einer Anzahl von Datentransformationen durchgeführt werden soll (z.B. keine Datentransformation, Swizzle, Broadcast).

Im Falle eines Speicherzugriffs 720-Befehlsmodells der Klasse A wird das Alphafeld 752 als ein Räumungshinweisfeld 752B interpretiert, dessen Inhalt unterscheidet, welcher der Räumungshinweise verwendet werden soll (in 7A werden jeweils ein temporales Element 752B.1 und ein nicht-temporales Element 752B.2 für das Speicherzugriffs-, temporale 725-Befehlsmodell und das Speicherzugriffs-, nicht-temporale 730-Befehlsmodell spezifiziert), während das Betafeld 754 als ein Datenmanipulationsfeld 754C interpretiert wird, dessen Inhalt unterscheidet, welche aus einer Anzahl von (auch als primitive bekannten) Datenmanipulationsoperationen durchgeführt werden soll (z.B. keine Manipulation; Broadcast; Aufwärtsumwandlung einer Quelle; und Abwärtsumwandlung eines Ziels). Die Speicherzugriffs 720-Befehlsmodelle enthalten das Skalierfeld 760 und optional das Verschiebungsfeld 762A oder das Verschiebungsskalierfeld 762B.

Vektorspeicherbefehle führen Vektorladevorgänge aus dem Speicher und Vektorspeicherungen in den Speicher mit Umwandlungsunterstützung durch. Wie bei regulären Vektorbefehlen übertragen Vektorspeicherbefehle Daten Datenelement für Datenelement aus dem Speicher und in den Speicher, wobei die Elemente, die tatsächlich übertragen werden, durch den Inhalt der Vektormaske vorgegeben werden, die als die Schreibmaske ausgewählt ist.

Speicherzugriffsbefehlsmodelle - temporal

Temporale Daten sind Daten, die wahrscheinlich früh genug wiederverwendet werden, um von einem Caching zu profitieren. Dies stellt jedoch einen Hinweis dar, und unterschiedliche Prozessoren können diesen auf unterschiedliche Arten durchführen, einschließlich eines vollständigen Ignorierens des Hinweises.

Speicherzugriffsbefehlsmodelle - nicht-temporal

Nicht-temporale Daten sind Daten, die wahrscheinlich nicht früh genug wiederverwendet werden, um von dem Caching in dem Level-1-Cache zu profitieren. Dies stellt jedoch einen Hinweis dar, und unterschiedliche Prozessoren können diesen auf unterschiedliche Arten durchführen, einschließlich eines vollständigen Ignorierens des Hinweises.

Befehlsmodelle der Klasse B

Im Falle der Befehlsmodelle der Klasse B wird das Alphafeld 752 als ein Schreibmaskensteuer(Z)-Feld 752C interpretiert, dessen Inhalt unterscheidet, ob das Schreibmaskieren, das durch das Schreibmaskenfeld 770 gesteuert wird, ein Mischen oder ein Nullsetzen sein sollte.

Im Falle der Nichtspeicherzugriffs 705-Befehlsmodelle der Klasse B wird ein Teil des Betafelds 754 als ein RL-Feld 757A interpretiert, dessen Inhalt unterscheidet welcher der unterschiedlichen Erweiterungsoperationstypen durchgeführt werden soll (z.B. Runden 757A.1 und Vektorlänge (VSIZE) 757A.2 sind jeweils für das Nichtspeicherzugriffs-, Schreibmaskensteuer-, partielles Rundungssteuertypenoperations 712-Befehlsmodell und das Nichtspeicherzugriffs-, Schreibmaskensteuer-, VSIZE-Typenoperations 717-Befehlsmodell) spezifiziert, während der Rest des Betafelds 754 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. Bei den Nichtspeicherzugriffs 705-Befehlsmodellen liegen das Skalierfeld 760, das Verschiebungsfeld 762A und das Verschiebungsskalierfeld 762B nicht vor.

Bei dem Nichtspeicherzugriffs-, Schreibmaskensteuer-, partiellen Rundungssteuertypenoperations 710-Befehlsmodell wird der Rest des Betafelds 754 als ein Rundungsoperationsfeld 759A interpretiert und das Berichten von Ausnahmeereignissen ist ausgeschaltet (ein vorgegebener Befehl berichtet von keinerlei Fließkommaausnahme-Flag und ruft keinen Fließkommaausnahmebehandler auf).

Rundungsoperationssteuerfeld 759A - wie im Falle des Rundungsoperationssteuerfelds 758 unterscheidet sein Inhalt, welche aus einer Gruppe von Rundungsoperationen durchgeführt werden soll (z.B. Aufrunden, Abrunden, Runden auf Null und Runden auf die nächste Rundungszahl). Somit ermöglicht das Rundungsoperationssteuerfeld 759A das Ändern des Rundungsmodus je nach Befehl. In einer Ausführungsform der Erfindung, bei der ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi enthält, erhält der Inhalt des Rundungsoperationssteuerfelds 750 Vorrang vor jenem.

Bei dem Nichtspeicherzugriffs-, Schreibmaskensteuer-, VSIZE-Typenoperation 717-Befehlsmodell wird der Rest des Betafelds 754 als ein Vektorlängenfeld 759B interpretiert, dessen Inhalt unterscheidet welche einer Anzahl von Vektorlängen bearbeitet werden soll (z.B. 128, 756 oder 912 Byte).

Im Falle eines Speicherzugriffs 720-Befehlsmodells der Klasse B wird ein Teil des Betafelds 754 als ein Broadcast-Feld 757B interpretiert, dessen Inhalt unterscheidet, ob die Broadcast-Typendatenmanipulationsoperation durchgeführt werden soll oder nicht, während der Rest des Betafelds 754 als ein Vektorlängenfeld 759B interpretiert wird. Die Speicherzugriffs 720-Befehlsmodelle enthalten das Skalierfeld 760 und optional das Verschiebungsfeld 762A oder das Verschiebungsskalierfeld 762B.

Unter Bezugnahme auf das generische vektorfreundliche Befehlsformat 700 ist ein vollständiges Opcode-Feld 774 gezeigt, das das Formatfeld 740, des Basisoperationsfelds 742 und das Datenelementbreitenfelds 764 enthält. Während eine Ausführungsform gezeigt ist, bei der das vollständige Opcode-Feld 774 alle diese Felder enthält, enthält das vollständige Opcode-Feld 774 weniger als sämtliche dieser Felder in Ausführungsformen, die nicht alle unterstützen. Das vollständige Opcode-Feld 774 liefert den Operationscode (Opcode).

Das Erweiterungsoperationsfeld 750, das Datenelementbreitenfeld 764 und das Schreibmaskenfeld 770 ermöglichen, dass diese Strukturen je Befehl in dem generischen vektorfreundlichen Befehlsformat spezifiziert werden.

Die Kombination des Schreibmaskenfelds und Datenelementbreitenfelds erzeugt getypte Befehle, indem diese der Maske ermöglichen, anhand unterschiedlicher Datenelementbreiten angewendet zu werden.

Die verschiedenen Befehlsmodelle, die innerhalb von Klasse A und Klasse B vorgefunden werden, sind in unterschiedlichen Situationen von Vorteil In einigen Ausführungsformen der Erfindung können unterschiedliche Prozessoren oder unterschiedliche Kerne in einem Prozessor lediglich Klasse A, lediglich Klasse B oder beide Klassen unterstützen. Beispielsweise kann ein ungeordneter Hochleistungs-Mehrzweckkern, der für eine Mehrzweckberechnung bestimmt ist, lediglich Klasse B unterstützen, kann ein Kern, der hauptsächlich für grafische und/oder wissenschaftliche (Datendurchsatz) Berechnungen bestimmt ist, lediglich Klasse A unterstützen und kann ein Kern, der für beides bestimmt ist, beide unterstützen (selbstverständlich fällt ein Kern, der eine Mischung von Modellen und Befehlen beider Klassen, jedoch nicht sämtliche Modelle und Befehle beider Klassen aufweist, innerhalb des Schutzbereichs der Erfindung). Außerdem kann ein einzelner Prozessor mehrere Kerne enthalten, die sämtliche die gleiche Klasse stützen oder in denen unterschiedliche Kerne unterschiedliche Klassen stützen. Beispielsweise unterstützt in einem Prozessor mit unabhängigen Grafik- und Mehrzweckkernen, einer der Grafikkerne, der hauptsächlich für grafische und/oder wissenschaftliche Berechnungen bestimmt ist, möglicherweise lediglich Klasse A, während ein oder mehrere für eine Mehrzweckberechnung bestimmte Mehrzweckkerne Hochleistungsmehrzweckkerne mit einer ungeordneten Ausführung und Registerumbenennung sein können, die lediglich Klasse B unterstützen. Ein anderer Prozessor, der keinen getrennten Grafik-Kern aufweist, kann einen oder mehrere geordnete oder ungeordnete Mehrzweckkerne enthalten, die sowohl Klasse A als auch Klasse B unterstützen. Selbstverständlich können in verschiedenen Ausführungsformen der Erfindung Merkmale aus der einen Klasse auch in der anderen Klasse durchgeführt sein. In einer Hochsprache geschriebene Programme würden (z.B. rechtzeitig kompiliert oder statisch kompiliert) in eine Reihe unterschiedlicher ausführbarer Formen überführt werden, beispielsweise: 1) eine Form, die lediglich Befehle der Klasse(n) aufweist, die durch den Zielprozessor für eine Ausführung gestützt werden, oder 2) eine Form mit alternativen Programmroutinen, die unter Verwendung unterschiedlicher Kombinationen der Befehle sämtlicher Klassen geschrieben sind und einen Steuerflusscode aufweisen, der die auszuführenden Programmroutinen auf der Grundlage der Befehle auswählt, die durch den Prozessor gestützt werden, der den Programmcode aktuell ausführt.

Beispielhaftes spezifisches vektorfreundliches Befehlsformat

8 zeigt in einem Blockdiagramm ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß Ausführungsformen der Erfindung. 8 zeigt ein spezifisches vektorfreundliches Befehlsformat 800, das in dem Sinne spezifisch ist, dass es den Ort, die Größe, die Interpretation und die Reihenfolge der Felder sowie Werte für einige jener Felder spezifiziert. Das spezifische vektorfreundliche Befehlsformat 800 kann genutzt werden, um den x86 Befehlssatz zu erweitern, und somit ähneln einige der Felder denjenigen, die in dem vorhandenen x86 Befehlssatz und dessen Erweiterung verwendet werden (z.B. AVX), oder sind mit ihnen identisch. Dieses Format bleibt konsistent mit dem Präfixcodierungsfeld, eigentlichen Opcode-Byte-Feld, MOD-R/M-Feld, SIB-Feld, Verschiebungsfeld und unmittelbaren Feldern des vorhandenen x86 Befehlssatzes mit Erweiterungen. Die Felder von 7, auf die sich die Felder von 8 abbilden, sind veranschaulicht.

Es sollte klar sein, dass, obwohl Ausführungsformen der Erfindung mit Bezug auf das spezifische vektorfreundliche Befehlsformat 800 für Zwecke der Veranschaulichung im Zusammenhang mit dem generischen vektorfreundlichen Befehlsformat 700 beschrieben sind, die Erfindung nicht auf das spezifische vektorfreundliche Befehlsformat 800 beschränkt ist, es sei denn, dies ist beansprucht. Beispielsweise zieht das generische vektorfreundliche Befehlsformat 700 unterschiedliche mögliche Größen für die unterschiedlichen Felder in Betracht, während das spezifische vektorfreundliche Befehlsformat 800 mit Feldern gezeigt ist, die spezielle Größen aufweisen. Anhand eines speziellen Beispiels, während das Datenelementbreitenfeld 764 in dem spezifischen vektorfreundlichen Befehlsformat 800 als ein Ein-BitFeld veranschaulicht ist, ist die Erfindung nicht darauf beschränkt (d. h., für das generische vektorfreundliche Befehlsformat 700 kommen auch andere Größen des Datenelementbreitenfelds 764 in Betracht).

Das generische vektorfreundliche Befehlsformat 700 enthält die folgenden Felder, die weiter unten in der in 8A gezeigten Reihenfolge aufgeführt sind.

EVEX-Prefix (Byte 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 Unterscheidung des vektorfreundlichen Befehlsformats in einer Ausführungsform der Erfindung verwendet wird).

Das zweite-vierte Byte (EVEX-Bytes 1-3) enthalten eine Anzahl von Bitfeldern, die eine spezielle Fähigkeit vorsehen.

REX-Feld 805 (EVEX-Byte 1, Bits [7-5]) - enthält ein EVEX.R-Bitfeld (EVEX-Byte 1, Bit [7] - R), ein EVEX.X-Bitfeld (EVEX-Byte 1, Bit [6] - X) und ein 757BEX-Byte 1, Bit[5] - B). Die EVEX.R-, EVEX.X- und EVEX.B-Bitfelder ermöglichen die gleiche Funktionalität wie die entsprechenden VEX-Bitfelder und werden mittels 1s Komplementform codiert, d. h. ZMM0 wird als 1111B codiert, ZMM15 wird als 0000B codiert. Andere Felder der Befehle codieren die niedrigeren drei Bits der Registerindizes (rrr, xxx und bbb), wie in der Technik bekannt, so dass Rrrr, Xxxx und Bbbb mittels Addition von EVEX.R, EVEX.X und EVEX.B gebildet werden können.

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 genutzt wird, um entweder die höheren 16 oder die niedrigeren 16 des erweiterten 32 Registersatzes zu codieren. In einer Ausführungsform der Erfindung ist dieses Bit, gemeinsam mit anderen, wie weiter unten gezeigt, in einem bitinvertierten Format gespeichert, um (in dem gut bekannten x86 32-Bit-Modus) von dem BOUND-Befehl zu unterscheiden, dessen eigentliches Opcode-Byte 62 ist, jedoch in dem (unten beschriebenen) MOD-R/M-Feld den Wert von 11 in dem MOD-Feld nicht akzeptiert; alternative Ausführungsformen der Erfindung speichern diese und die unten angezeigten anderen Bits nicht in dem invertierten Format. Ein Wert von 1 wird verwendet, um die niedrigeren 16 Register zu codieren. Mit anderen Worten, R'Rrrr wird durch ein Zusammenführen von EVEX.R', EVEX.R und den anderen RRR von anderen Feldern gebildet.

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

Datenelementbreitenfeld 764 (EVEX-Byte 2, Bit [7] - W) - ist mit der Notation EVEX.W bezeichnet. EVEX.W wird verwendet, um die Auflösung (Größe) des Datentyps (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente) zu definieren.

EVEX.vvvv 820 (EVEX-Byte 2, Bits [6:3]-vvvv) - die Aufgabe des EVEX.vvvv kann beinhalten: 1) EVEX.vvvv codiert den ersten Quellregisteroperanden, der in einer invertierten (1s Komplement) Form spezifiziert ist und für Befehle mit 2 oder mehr Quelloperanden gültig ist; 2) EVEX.vvvv codiert den Zielregisteroperanden, der in der 1s Komplementform für gewisse Vektorverschiebungen spezifiziert ist; oder 3) EVEX.vvvv codiert nicht jeden Operanden, das Feld wird reserviert und sollte 1111b enthalten. Somit codiert das EVEX.vvvv-Feld 820 die 4 niedrigwertigen Bits des ersten Quellregisterspezifizierer, die in einer invertierten (1s Komplement-) Form gespeichert sind. Abhängig von dem Befehl wird ein zusätzliches unterschiedliches EVEX-Bitfeld verwendet, um die Spezifizierergröße auf 32 Register zu erweitern.

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

Präfixcodierungsfeld 825 (EVEX-Byte 2, Bits [1:0]-pp) - sieht zusätzliche Bits für das Basisoperationsfeld vor. Zusätzlich zu dem Vorsehen einer Unterstützung für die veralteten SSE-Befehle in dem EVEX-Präfixformat, hat dies auch den Vorteil eines Verdichtens des SIMD-Präfixes (anstelle der Erfordernis eines Byte, um das SIMD-Präfix auszudrücken, erfordert das EVEX-Prefix lediglich 2 Bits). Um veraltete SSE-Befehle zu stützen, die sowohl in dem veralteten Format als auch in dem EVEX-Präfixformat ein SIMD-Präfix (66H, F2H, F3H) verwenden, sind diese veralteten SIMD-Präfixe in einer Ausführungsform in dem SIMD-Präfixcodierungsfeld codiert und werden zur Laufzeit zu dem veralteten SIMD-Präfix erweitert, bevor sie an den PLA des Decodierers ausgegeben werden (so dass die PLA sowohl das veraltete als auch das EVEX-Format dieser veralteten Befehle ohne Modifikation ausführen kann). Obwohl neuere Befehle den Inhalt des EVEX-Präfixcodierungsfelds unmittelbar als eine Opcodeerweiterung verwenden könnten, sind manche Ausführungsformen in einer ähnlichen Weise mit Blick auf Konsistenz erweitert, erlauben jedoch, dass unterschiedliche Bedeutungen durch diese veralteten SIMD-Präfixe spezifiziert werden. Eine alternative Ausführungsform kann die PLA neu entwerfen, um die 2-Bit-SIMD-Präfixcodierungen zu stützen, und kann somit auf die Erweiterung verzichten.

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

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

REX'-Feld 710 - dieses ist der Rest des REX'-Felds und ist das EVEX.V'-Bitfeld (EVEX-Byte 3, Bit [3] - V'), das genutzt werden kann, um entweder die höheren 16 oder die niedrigeren 16 des erweiterten 32 Registersatzes zu codieren. Dieses Bit ist in einem bitinvertierten Format gespeichert. Ein Wert von 1 wird verwendet, um die niedrigeren 16 Register zu codieren. Mit anderen Worten V'VVVV wird durch ein Zusammenführen von EVEX.V', EVEX.vvvv gebildet.

Schreibmaskenfeld 770 (EVEX-Byte 3, Bits [2:0]-kkk) - sein Inhalt spezifiziert den Index eines Registers in den Schreibmaskenregistern, wie zuvor beschrieben. In einer Ausführungsform der Erfindung weist der spezifische Wert EVEX.kkk=000 unter der Voraussetzung, dass für den speziellen Befehl keine Schreibmaske verwendet wird, ein spezielles Verhalten auf (dies kann auf vielfältige Weise durchgeführt werden, einschließlich der Verwendung einer Schreibmaske, die mit sämtlichen oder mit der Hardware fest verdrahtet ist, die die Maskierungshardware umgeht).

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

Ein MOD-R/M-Feld 840 (Byte 5) enthält ein MOD-Feld 842, ein Reg-Feld 844 und ein R/M-Feld 846. Wie zuvor beschrieben, unterscheidet der Inhalt des MOD-Felds 842 zwischen Speicherzugriffs- und Nichtspeicherzugriffsoperationen. Die Aufgabe des Reg-Felds 844 lässt sich auf zwei Situationen zusammenfassen: entweder codiert es den Zielregisteroperanden oder einen Quellregisteroperanden, oder es wird als eine Opcodeerweiterung behandelt und nicht verwendet, um irgendeinen Befehlsoperanden zu codieren. Die Aufgabe des R/M-Felds 846 kann beinhalten: Codieren des Befehlsoperanden, der sich auf eine Arbeitsspeicheradresse bezieht, oder Codieren entweder des Zielregisteroperanden oder eines Quellregisteroperanden.

Skalierungs-, Index-, Basis- (SIB)-Byte (Byte 6) 850 - Wie zuvor beschrieben, wird der Inhalt des Skalierfelds 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 Bezug genommen.

Verschiebungsfeld 762A (Byte 7-10) - wenn das MOD-Feld 842 10 enthält, sind Bytes 7-10 das Verschiebungsfelds 762A, und es arbeitet genauso wie die veraltete 32-Bit-Verschiebung (disp32) und arbeitet bei Byte-Auflösung.

Verschiebungsfaktorfeld 762B (Byte 7) - wenn MOD-Feld 842 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 762B. Der Ort dieses Felds ist derselbe wie derjenige der 8-Bit-Verschiebung (disp8) des veralteten x86-Befehlssatzes, der bei Byte-Auflösung arbeitet. Da disp8 mit Vorzeichen erweitert ist, kann es lediglich Offsets zwischen -128 und 127 Bytes adressieren; was 64-Byte-Cachezeilen betrifft, verwendet disp8 8 Bits, die auf lediglich vier tatsächlich nützliche Werte -128, -64, 0 und 64 gesetzt werden können; da häufig ein größerer Bereich erforderlich ist, wird disp32 verwendet; jedoch erfordert disp32 4 Bytes. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 762B eine Neuinterpretation von disp8; im Falle der Verwendung des Verschiebungsfaktorfelds 762B, ist die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfelds multipliziert mit der Größe des Speicheroperandenzugriffs (N) bestimmt. Diese Art einer Verschiebung wird als disp8*N bezeichnet. Dies verringert die mittlere Befehlslänge (von der ein einziges Byte für die Verschiebung, jedoch mit einem wesentlich größeren Bereich, verwendet wird). Eine solche komprimierte Verschiebung ist auf der Annahme begründet, dass die effektive Verschiebung ein Vielfaches der Auflösung des Speicherzugriffs ist, und somit die redundanten niedrigwertigen Bits des Adressen-Offsets nicht codiert zu werden brauchen. Mit anderen Worten, das Verschiebungsfaktorfeld 762B tritt an die Stelle der 8-Bit-Verschiebung des veralteten x86-Befehlssatzes. Somit wird das Verschiebungsfaktorfeld 762B in derselben Weise wie eine x86-Befehlssatz 8-Bit-Verschiebung (d. h. ohne Änderungen der ModRM/SIB-Codierungsregeln) codiert, mit der einzigen Ausnahme, dass disp8 auf disp8*N überladen wird. Mit anderen Worten, es gibt keine Änderungen der Codierungsregeln oder Codierungslängen mit der einen Ausnahme der Interpretation des Verschiebungswerts durch die Hardware (die die Verschiebung um die Größe des Speicheroperanden skalieren muss, um einen byteweisen Adressen-Offset zu erhalten). Das unmittelbare Feld 772 arbeitet, wie zuvor beschrieben.

Vollständiges Opcode-Feld

8B zeigt in einem Blockdiagramm die Felder des spezifischen vektorfreundlichen Befehlsformats 800, aus denen sich das vollständige Opcode-Feld 774 gemäß einer Ausführungsform der Erfindung zusammensetzt. Insbesondere weist das vollständige Opcode-Feld 774 das Formatfeld 740, das Basisoperationsfeld 742 und das Datenelementbreiten(W)-Feld 764 auf. Das Basisoperationsfeld 742 enthält das Präfixcodierungsfeld 825, das Opcode-Abbildungsfeld 815 und das eigentliche Opcode-Feld 830.

Registerindexfeld

8C zeigt in einem Blockdiagramm die Felder des spezifischen vektorfreundlichen Befehlsformats 800, aus denen sich das Registerindexfeld 744 gemäß einer Ausführungsform der Erfindung zusammensetzt. Insbesondere enthält das Registerindexfeld 744 das REX-Feld 805, das REX'-Feld 810, das MODR/M.reg-Feld 844, das MODR/M.r/m-Feld 846, das VVVV Feld 820, das xxx-Feld 854 und das bbb-Feld 856.

Erweiterungsoperationsfeld

8D zeigt in einem Blockdiagramm die Felder des spezifischen vektorfreundlichen Befehlsformats 800, aus denen sich das Erweiterungsoperationsfeld 750 gemäß einer Ausführungsform der Erfindung zusammensetzt. Wenn das Feld 768 der Klasse (U) 0 enthält, kennzeichnet es EVEX.U0 (Klasse A 768A); wenn es 1 enthält, kennzeichnet es EVEX.U1 (Klasse B 768B). Wenn U=0 und das MOD-Feld 842 11 enthält (was eine Nichtspeicherzugriffsoperation kennzeichnet), wird das Alphafeld 752 (EVEX-Byte 3, Bit [7] - EH) als das rs-Feld 752A interpretiert. Wenn das rs-Feld 752A eine 1 enthält (Rundung 752A.1), wird das Betafeld 754 (EVEX-Byte 3, Bits [6:4]- SSS) als das Rundungssteuerungsfeld 754A interpretiert. Das Rundungssteuerungsfeld 754A enthält ein Ein-Bit-SAE-Feld 756 und eine Zwei-Bit-Rundungsoperationsfeld 758. Wenn das rs-Feld 752A eine 0 enthält (Datentransformation 752A.2), wird das Betafeld 754 (EVEX-Byte 3, Bits [6:4]- SSS) als ein Drei-Bit-Datentransformationsfeld 754B interpretiert. Wenn U=0 und das MOD-Feld 842 00, 01 oder 10 enthält (was eine Speicherzugriffsoperation kennzeichnet), wird das Alphafeld 752 (EVEX-Byte 3, Bit [7] - EH) als das Räumungshinweis(Eviction Hint, EH)-Feld 752B interpretiert, und das Betafeld 754 (EVEX-Byte 3, Bits [6:4]- SSS) wird als eine Drei-Bit-Datenmanipulationsfeld 754C interpretiert.

Wenn U=1, wird das Alphafeld 752 (EVEX-Byte 3, Bit [7] - EH) als das Schreibmaskensteuerungs(Z)-Feld 752C interpretiert. Wenn U=1 und das MOD-Feld 842 11 enthalten (was eine Nichtspeicherzugriffsoperation kennzeichnet), wird ein Teil des Betafelds 754 (EVEX-Byte 3, Bit [4]- S0) als das RL-Feld 757A interpretiert; wenn es eine 1 (Rundung 757A.1) enthält, wird das übrige Betafeld 754 (EVEX-Byte 3, Bit [6-5]-S2-1) als das Rundungsoperationsfeld 759A interpretiert, während, wenn das RL-Feld 757A eine 0 (VSIZE 757.A2) enthält, das übrige Betafeld 754 (EVEX-Byte 3, Bit [6-5]- S2-1) als das Vektorlängenfeld 759B (EVEX-Byte 3, Bit [6-5]- L_1-0) interpretiert wird. Wenn U=1 und das MOD-Feld 842 00, 01 oder 10 enthält (was eine Speicherzugriffsoperation kennzeichnet), 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 Broadcast-Feld 757B (EVEX-Byte 3, Bit [4]- B) interpretiert.

Beispielhafte Registerachitektur

9 zeigt ein Blockdiagramm einer Registerarchitektur 900 gemäß einer Ausführungsform der Erfindung. In der gezeigten 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 niedrigeren 16 zmm-Register werden an Register ymm0-16 angelegt. Die 128 niedrigwertigen Bits der niedrigeren 16 zmm-Register (die niedrigwertigen 128 Bits der ymm-Register) werden an Register xmm0-15 angelegt. Das spezifische vektorfreundliche Befehlsformat 800 arbeitet auf diesen angelegten Registerdatei wie in den untenstehenden Tabellen veranschaulicht.

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

Das heißt, das Vektorlängenfeld 759B wählt zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen, wobei jede solcher kürzeren Längen halb so groß wie die Länge der vorhergehenden Länge ist; und Befehlsmodelle ohne das Vektorlängenfeld 759B arbeiten auf der maximalen Vektorlänge. Ferner arbeiten in einer Ausführungsform die Befehlsmodelle der Klasse B des spezifischen vektorfreundlichen Befehlsformats 800 auf gepackten oder skalaren Fließkommadaten mit einfacher/doppelter Präzision und auf gepackten oder skalaren Ganzzahldaten. Skalare Operationen sind Operationen, die an der niedrigstwertigen Datenelementposition in einem zmm-/ymm-/xmm-Register durchgeführt werden; die höherwertigen Datenelementpositionen werden abhängig von der Ausführungsform entweder belassen, wie sie vor dem Befehl waren, oder nullgesetzt.

Schreibmaskenregister 915 - in der veranschaulichten Ausführungsform, gibt es 8 Schreibmaskenregister (k0 bis k7), die jeweils 64 Bits groß sind. In einer alternativen Ausführungsform sind die Schreibmaskenregister 915 16 Bits groß. Wie zuvor beschrieben, kann das Vektormaskenregister k0 in einer Ausführungsform der Erfindung nicht als Schreibmaske verwendet werden; wenn die Codierung, die normalerweise anzeigen würde, dass k0 für eine Schreibmaske verwendet wird, wählt sie eine fest verdrahtete Schreibmaske von 0xFFFF aus, wobei sie effektiv Schreibmaskieren für diesen Befehl ausschaltet.

Mehrzweckregister 925 - in der veranschaulichten Ausführungsform, gibt es sechzehn 64-Bit-Mehrzweckregister, die gemeinsam mit den existierenden x86-Adressiermodi verwendet werden, um Speicheroperanden zu adressiere. Diese Register werden durch die Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 bezeichnet.

Skalarfließkommastapelregisterdatei (x87-Stapel) 945, mit dem die MMX-gepackte Ganzzahlflachregisterdatei 950 per Alias verbunden ist - in der veranschaulichten Ausführungsform, ist der x87-Stapel ein Stapel aus acht Elementen, der verwendet wird, um skalare Fließkommaoperationen auf 32/64/80-Bit-Fließkommadaten unter Verwendung der x86-Befehlssatzerweiterung durchzuführen; während die MMX-Register verwendet werden, um Operationen auf 64-Bitgepackten Ganzzahldaten durchzuführen und Operanden für einige Operationen vorzuhalten, die zwischen den MMX- und XMM-Registern durchgeführt werden.

Alternative Ausführungsformen der Erfindung können breitere oder schmalere Register verwenden. Zusätzlich können alternative Ausführungsformen der Erfindung mehr, weniger oder andere Registerdateien und Register verwenden.

Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen

Prozessorkerne können auf unterschiedlichen Wegen, für unterschiedliche Zwecke und in unterschiedlichen Prozessoren durchgeführt werden. Beispielsweise können Durchführungen solcher Kerne enthalten: 1) einen geordneten Mehrzweckkern, der für Mehrzweckberechnung bestimmt ist; 2) einen ungeordneten Hochleistungs-Mehrzweckkern, der für Mehrzweckberechnung bestimmt ist; 3) einen Sonderzweck-Kern, der hauptsächlich für grafische und/oder wissenschaftliche (Datendurchsatz) Berechnungen bestimmt ist. Durchführungen unterschiedlicher Prozessoren können aufweisen: 1) eine CPU, die einen oder mehrere geordnete Mehrzweckkerne enthält, die für Mehrzweckberechnung bestimmt sind, und/oder einen oder mehrere ungeordnete Mehrzweckkerne, die für Mehrzweckberechnung bestimmt sind; und 2) einen Coprozessor, der eine oder mehrere speziell angepasste Kerne enthält, die hauptsächlich für Grafik und/oder wissenschaftliche (Datendurchsatz) bestimmt ist. Solche unterschiedlichen Prozessoren führen zu unterschiedlichen Computersystemarchitekturen, die enthalten können: 1) den Coprozessor auf einem von der CPU getrennten Chip; 2) den Coprozessor auf einem getrennten Halbleiterplättchen in derselben Packung wie eine CPU; 3) den Coprozessor auf demselben Halbleiterplättchen wie eine CPU (wobei in einem solchen Fall ein derartiger Coprozessor gelegentlich als Sonderzweck-Logik, z.B. grafische und/oder wissenschaftliche (Datendurchsatz) Logik, oder als Sonderzweck-Kern bezeichnet ist); und 4) ein System auf einem Chip, der die beschriebene CPU auf demselben Halbleiterplättchen enthalten kann (gelegentlich als der/die Anwendungskern(e) oder Anwendungsprozessor(en) bezeichnet), den oben beschriebenen Coprozessor und zusätzliche Funktionalität. Als nächstes werden beispielhafte Kernarchitekturen beschrieben, auf die Beschreibungen beispielhafter Prozessoren und Computerarchitekturen folgen.

Beispielhafte Kernarchitekturen Blockdiagramm eines geordneten und ungeordneten Kerns

10A zeigt in einem Blockdiagramm sowohl eine beispielhafte geordnete Pipeline als auch eine beispielhafte Register umbenennende, ungeordnete Ausgabe-/Ausführungspipeline gemäß Ausführungsformen der Erfindung. 10B zeigt in einem Blockdiagramm sowohl eine Ausführungsform eines Kerns mit einer geordneten Architektur als auch einen beispielhaften Kern mit einer Register umbenennenden, ungeordneten Ausgabe-/Ausführungsarchitektur, der in einem Prozessor gemäß Ausführungsformen der Erfindung zu verwenden ist. Die in 10A-B mit durchgezogener Linie gezeichneten Blöcke veranschaulichen die geordnete Pipeline und den geordneten Kern, während die optionale Hinzufügung der gestrichelt gezeichneten Blöcke die Register umbenennende, ungeordnete Ausgabe-/Ausführungspipeline und den Kern veranschaulicht. Unter der Vorgabe, dass die geordnete Eigenschaft ein Teilsatz der ungeordneten Eigenschaft ist, wird die ungeordnete Eigenschaft beschrieben.

In 10A enthält eine Prozessorpipeline 1000 eine Abrufungsstufe 1002, eine Längendecodierungsstufe 1004, eine Decodierungsstufe 1006, eine Zuweisungsstufe 1008, eine Umbenennungsstufe 1010, eine (auch als Versand- oder Ausgabestufe bekannte) Planungsstufe 1012, eine Registerlese/Speicherlesestufe 1014, eine Ausführungsstufe 1016, eine Zurückschreib-/Speicherschreibstufe 1018, eine Ausnahmenbehandlungsstufe 1022 und eine Übergabestufe 1024.

10B zeigt einen Prozessorkern 1090 mit einer Front-End-Einheit 1030, die mit einer Ausführungsmaschineneinheit 1050 verbunden ist, und beide sind mit einer Speichereinheit 1070 verbunden. Der Kern 1090 kann ein Kern eines Rechners mit reduziertem Befehlssatz (Reduced Instruction Set Computing, RISC), ein Kern eines Rechners mit komplexem Befehlssatz (Complex Instruction Set Computing, CISC), ein Kern mit sehr langem Befehlswort (Very Long Instruction Word, VLIW) oder eine Art eines hybriden oder alternativen Kerns sein. Als noch eine weitere Option kann der Kern 1090 ein Mehrzweck-Kern, wie beispielsweise ein Netzwerk- oder Kommunikationskern, eine Datenkompressionsmaschine, ein Coprozessorkern, ein Kern für Mehrzweckberechnung auf Grafikprozessoreinheiten (General Purpose Computing Graphics Processing Unit GPGPU), ein Grafik-Kern oder dergleichen sein.

Die Front-End-Einheit 1030 enthält eine Zweigvorherberechnungseinheit 1032, die mit einer Befehlscache-Einheit 1034 verbunden ist, die mit einem Befehlsübersetzungs-Lookaside-Puffer (Translation Lookaside Buffer, TLB) 1036 verbunden ist, der mit einer Befehlsabrufeinheit 1038 verbunden ist, die mit einer Decodiereinheit 1040 verbunden ist. Die Decodiereinheit 1040 (bzw. der Decodierer) kann Befehle decodieren und als eine Ausgabe Mikrooperationen, Mikrocode-Eintragspunkte, Mikrobefehle, sonstige Befehle und/oder andere Steuersignale erzeugen, die anhand ursprünglicher Befehle decodiert sind oder diese anderweitig widerspiegeln, oder von diesen abgeleitet sind. Die Decodiereinheit 1040 kann unter Verwendung mehrerer unterschiedlicher Vorrichtungen durchgeführt werden. Beispiele geeigneter Vorrichtungen beinhalten, ohne darauf beschränkt zu sein, Referenztabellen, Hardware-Durchführungen, programmierbare Logikanordnungen (Programmable Logic Arrays, PLAs), Mikrocode-ROM-Einheiten (Read Only Memories, ROMs) und dergleichen. In einer Ausführungsform enthält der Kern 1090 ein Mikrocode-ROM- oder sonstiges Medium, das Mikrocode für gewisse Makrobefehle (beispielsweise in einer Decodiereinheit 1040 oder anderweitig innerhalb der Front-End-Einheit 1030) speichert. Die Decodiereinheit 1040 ist mit einer Umbenennungs-/Zuweisungseinheit 1052 in der Ausführungsmaschineneinheit 1050 verbunden.

Die Ausführungsmaschineneinheit 1050 enthält die Umbenennungs-/Zuweisungseinheit 1052, die mit einer Rückzugseinheit 1054 und einem Satz einer oder mehrerer Planungseinheit(en) 1056 verbunden ist. Die eine oder die mehreren Planungseinheiten 1056 bezeichnen eine beliebige Anzahl von unterschiedlichen Planern, zu denen Reservierungsstationen, zentrale Befehlsfenster und dergleichen gehören. Die eine oder die mehreren Planungseinheiten 1056 sind mit der einen oder den mehreren physischen Registerdatei(en)-Einheiten 1058 verbunden. Jede der physischen Registerdatei(en)-Einheiten 1058 repräsentiert einer oder mehrere physische Registerdateien, von denen unterschiedliche eine oder mehrere unterschiedliche Datentypen speichern, beispielsweise von der Art einer skalaren Ganzzahl, eines skalaren Fließkommas, einer gepackten Ganzzahl, eines gepackten Fließkommas, einer Vektorganzzahl, eines Vektorfließkommas, eines Zustands (z.B. eines Befehlszeigers, der die Adresse des nächsten auszuführenden Befehls) und dergleichen ist. In einer Ausführungsform weist die physische Registerdatei(en)-Einheit 1058 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine Skalarregistereinheit auf. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Mehrzweckregister vorsehen. Die eine oder die mehreren physischen Registerdatei(en)-Einheiten 1058 sind durch die Rückzugseinheit 1054 überlappt, um unterschiedliche Wege zu veranschaulichen, auf denen eine Registerumbenennung und eine ungeordnete Ausführung (beispielsweise unter Verwendung eines oder mehrerer Neuanordnungspuffer und einer oder mehrerer Rückzugsregister-Dateien; unter Verwendung einer oder mehrerer Zukunftsdateien, eines oder mehrerer Vorgeschichtepuffer und einer oder mehrerer Rückzugsregister-Dateien; unter Verwendung einer Registerabbildung und einer Datenbasis von Registern; und dergleichen durchgeführt werden kann). Die Rückzugseinheit 1054 und eine oder die mehreren physischen Registerdatei(en)-Einheiten 1058 sind mit dem Ausführungscluster 1060 verbunden. Das Ausführungscluster 1060 enthält einen Satz von einer oder mehreren Ausführungseinheiten 1062 und einen Satz von einer oder mehreren Speicherzugriffseinheiten 1064. Die Ausführungseinheiten 1062 können unterschiedliche Operationen (z.B. Shift, Addition, Subtraktion, Multiplikation) und an unterschiedlichen Arten von Daten durchführen (z.B. skalarem Fließkomma, gepackter Ganzzahl, gepacktem Fließkomma, Vektorganzzahl, Vektorfließkomma). Während einige Ausführungsformen eine Anzahl von Ausführungseinheiten enthalten können, die für spezielle Funktionen oder Sätze von Funktionen bestimmt sind, können andere Ausführungsformen nur eine (1) Ausführungseinheit oder mehrere Ausführungseinheiten enthalten, die alle sämtliche Funktionen durchführen. Die Planungseinheit(en) 1056, physische(n) Registerdatei(en)-Einheit(en) 1058 und Ausführungscluster 1060 sind als möglicherweise in Mehrzahl gezeigt, da manche Ausführungsformen für gewisse Arten von Daten/Operationen getrennte Pipelines erzeugen (z.B. eine skalare Ganzzahlpipeline, eine skalare Fließkomma/gepackte-Ganzzahl/gepackte Fließkomma/Vektorganzzahl/Vektorfließkomma-Pipeline und/oder eine Speicherzugriffspipeline, die jeweils ihre eigene Planungseinheit, physische Registerdatei(en)-Einheit und/oder Ausführungscluster haben - und im Falle einer getrennten Speicherzugriffspipeline werden manche Ausführungsformen durchgeführt, bei denen lediglich das Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 1064) aufweist. Es ist ebenfalls selbstverständlich, dass im Falle einer Verwendung getrennter Pipelines eine oder mehrere dieser Pipelines ungeordnete Ausgabe/Ausführungs-Piplines und die übrigen geordnete sein können.

Der Satz von Speicherzugriffseinheiten 1064 ist mit der Speichereinheit 1070 verbunden, die eine Daten-TLB-Einheit 1072 enthält, die mit einer Datencache-Einheit 1074 verbunden ist, die mit einer Level 2 (L2) Cache-Einheit 1076 verbunden ist. In einer Ausführungsform können die Speicherzugriffseinheiten 1064 eine Ladeeinheit, eine Adressspeicherungseinheit und eine Datenspeicherungseinheit enthalten, die jeweils mit der Daten-TLB-Einheit 1072 in der Speichereinheit 1070 verbunden sind. Die Befehlscache-Einheit 1034 ist ferner mit einer Level-2-(L2)-Cache-Einheit 1076 in der Speichereinheit 1070 verbunden. Die L2 Cache-Einheit 1076 ist mit einer oder mehreren anderen Levels eines Cache und gegebenenfalls mit einem Hauptarbeitsspeicher verbunden.

Beispielsweise kann die beispielhafte Register umbenennende, ungeordnete Ausgabe/Ausführungs-Kernarchitektur die Pipeline 1000 wie folgt durchführen: 1) die Befehlsabrufung 1038 führt die Abrufungs- und Längendecodierungsstufen 1002 und 1004 durch; 2) die Decodiereinheit 1040 führt die Decodierungsstufe 1006 durch; 3) die Umbenennungs-/Zuweisungseinheit 1052 führt die Zuweisungsstufe 1008 und die Umbenennungsstufe 1010 durch; 4) die eine oder mehreren Planungseinheiten 1056 führen die Planungsstufe 1012 durch; 5) die eine oder die mehreren physischen Registerdatei(en)-Einheiten 1058 und die Speichereinheit 1070 führen die Registerlese/Speicherlesestufe 1014 durch; das Ausführungscluster 1060 führen die Ausführungsstufe 1016 durch; 6) die Speichereinheit 1070 und die eine oder die mehreren physischen Registerdatei(en)-Einheiten 1058 führen die Zurückschreib-/Speicherschreibstufe 1018 durch; 7) unterschiedliche Einheiten können an der Ausnahmenbehandlungsstufe 1022 beteiligt sein; und 8) die Rückzugseinheit 1054 und die eine oder die mehreren physischen Registerdatei(en)-Einheiten 1058 führen die Übergabestufe 1024 durch.

Der Kern 1090 kann einen oder mehrere Befehlssätze (z.B. den x86-Befehlssatz (mit einigen Erweiterungen, die neueren Versionen hinzugefügt wurden); den MIPS-Befehlssatz von MIPS-Technologien von Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen, wie beispielsweise NEON) von ARM Holdings von Sunnyvale, CA) einschließlich des/der hier beschriebenen Befehl(e) stützen. In einer Ausführungsform enthält der Kern 1090 eine Logik, um eine gepackte Datenbefehlssatzerweiterung (z.B. AVX1, AVX2 zu stützen), und er ermöglicht dadurch die von vielen Multimediaanwendungen genutzten Operationen mittels gepackter Daten durchzuführen.

Es sollte einleuchten, dass der Kern Multithreading (Ausführen von zwei oder mehreren parallelen Sätzen von Operationen oder Threads) stützen und dies in der Tat auf vielfältige Weise durchführen kann, einschließlich von Zeitscheiben-Multithreading, simultanem Multithreading (bei dem ein einzelner physischer Kern einen logischen Kern für jeden der Threads vorsieht, an denen der physische Kern gleichzeitig Multithreading durchführt) oder einer Kombination davon (z.B. Zeitscheiben-Abrufen und Decodieren und danach simultanes Multithreading, wie beispielsweise in der Intel® Hyperthreading Technologie).

Während eine Registerumbenennung im Zusammenhang mit einer ungeordneten Ausführung beschrieben wird, sollte es verständlich sein, dass die Registerumbenennung auch in einer geordneten Architektur verwendet werden kann. Während die veranschaulichte Ausführungsform des Prozessors ferner getrennte Befehls- und Datencache-Einheiten 1034/1074 und eine gemeinsam verwendete L2-Cache-Einheit 1076 enthält, können alternative Ausführungsformen einen einzigen internen Cache für sowohl Befehle als auch Daten aufweisen, wie beispielsweise einen Level-1-(L1) internen Cache oder mehrere Levels eines internen Cache. In einigen Ausführungsformen kann das System eine Kombination eines internen Cache und eines externe Cache enthalten, der gegenüber dem Kern und/oder dem Prozessor extern ist. Alternativ kann der gesamte Cache mit Blick auf den Kern und/oder den Prozessor extern sein.

Spezielle beispielhafte geordnete Kernarchitektur

11A-B zeigen ein Blockdiagramm einer spezielleren beispielhaften geordneten Kernarchitektur, wobei der Kern einer von unterschiedlichen Logikblöcken (einschließlich anderer Kerne desselben Typs und/oder unterschiedlichen Typs) auf einem Chip sein würde. Die Logikblöcke kommunizieren über ein mit großen Bandbreiten arbeitendes Verbindungsnetzwerk (z.B. ein Ringnetzwerk) mit einer gewissen feststehenden Funktionslogik, Speicher-I/O-Schnittstellen und einer in Abhängigkeit von der Anwendung sonstigen erforderlichen I/O-Logik,.

11A zeigt ein Blockdiagramm eines einzelnen Prozessorkerns gemeinsam mit seiner Verbindung zu dem auf dem Halbleiterplättchen integrierten Verbindungsnetzwerk 1102 und mit seinem lokalen Teilsatz des Level-2-(L2)-Cache 1104, gemäß Ausführungsformen der Erfindung. In einer Ausführungsform stützt ein Befehlsdecoder 1100 den x86-Befehlssatz mit einer gepackten Datenbefehlssatzerweiterung. Eine L1-Cache 1106 ermöglicht Zugriffe niedriger Latenzzeit auf den Cachespeicher in die Skalar- und Vektoreinheiten. Während in einer Ausführungsform (zur Vereinfachung der Konstruktion) eine Skalareinheit 1108 und eine Vektoreinheit 1110 getrennte Registersätze (bzw., Skalarregister 1112 und Vektorregister 1114) verwenden, und zwischen ihnen übertragene Daten in den Speicher eingetragen und anschließend von einem Level-1-(L1)-Cache 1106 zurückgelesen werden, können alternative Ausführungsformen der Erfindung einen anderen Ansatz verwenden (z.B. Ansätze der Verwendung eines Einzelregisters oder eines Kommunikationspfads, die es ermöglichen, Daten zwischen den beiden Registerdateien auszutauschen, ohne dass diese geschrieben und zurückgelesen werden).

Der lokale Teilsatz des L2-Cache 1104 ist Teil eines globalen L2-Cache, der pro Prozessorkern in getrennte lokale Teilsätze unterteilt ist. Jeder Prozessorkern weist einen unmittelbaren Zugriffspfad auf seinen eigenen lokalen Teilsatz des L2-Cache 1104 auf. Daten, die durch einen Prozessorkern gelesen werden, werden in seinem L2-Cache-Teilsatz 1104 gespeichert, und es kann auf diese rasch parallel mittels anderer Prozessorkerne zugegriffen werden, die auf ihre eigenen lokalen L2-Cache-Teilsätze zugreifen. Daten, die durch einen Prozessorkern geschrieben sind, werden in seinem eigenen L2-Cache-Teilsatz 1104 gespeichert und, falls erforderlich, aus anderen Teilsätzen gespült. Das Ringnetzwerk stellt eine Kohärenz für geteilte (gemeinsam verwendete) Daten sicher. Das Ringnetzwerk ist bidirektional, um Agenten, wie beispielsweise Prozessorkernen, L2-Caches und anderen Logikblöcken, zu ermöglichen, innerhalb des Chips miteinander zu kommunizieren. Jeder Ringdatenpfad ist pro Richtung 1012-Bits breit.

11B zeigt eine detaillierte Ansicht eines Teils des Prozessorkerns von 11A gemäß Ausführungsformen der Erfindung. 11B zeigt einen L1-Datencache 1106A, der ein Teil des L1-Cache 1104 ist, sowie die Vektoreinheit 1110 und die Vektorregister 1114 mehr im Einzelnen. Insbesondere ist die Vektoreinheit 1110 eine 16 Bit breite Vektorverarbeitungseinheit (Vector Processing Unit, VPU) (siehe die 16 Bit breite ALU 1128), die Ganzzahl-, einfache Genauigkeit und/oder doppelte Genauigkeit verwendende Fließkommabefehle ausführt. Die VPU unterstützt Swizzling (Umordnen von Elementen) der Registereingaben mittels der Swizzle-Einheit 1120, numerische Konvertierung mittels numerischer Konvertierungseinheiten 1122A-B und Replikation mittels einer Replikationseinheit 1124 an dem Speichereingang. Schreibmaskenregister 1126 ermöglichen ein Vorherberechnen sich ergebender Vektorschreibvorgänge.

12 zeigt in einem Blockdiagramm einen Prozessor 1200 gemäß Ausführungsformen der Erfindung, der mehr als einen Kern haben kann, eine integrierte Speichersteuereinrichtung haben kann und eine integrierte Grafikkarte haben kann. Die in 12 mit durchgezogener Linie gezeichneten Blöcke veranschaulichen einen Prozessor 1200 mit einem einzigen Kern 1202A, einen Systemagenten 1210 und einen Satz von einem oder mehreren Bussteuereinheiten 1216, während die optionale Hinzufügung der gestrichelt gezeichneten Blöcke einen alternativen Prozessor 1200 mit mehreren Kernen 1202A-N, einen Satz von einem oder mehreren integrierten Speichersteuereinheiten 1214 in der Systemagenteneinheit 1210 und eine Sonderzweck-Logik 1208 veranschaulicht.

Somit können unterschiedliche Durchführungen des Prozessors 1200 Folgendes enthalten: 1) eine CPU, wobei die Sonderzweck-Logik 1208 eine grafische und/oder wissenschaftliche (Datendurchsatz) Logik ist (die einen oder mehrere Kerne enthalten kann), und die Kerne 1202A-N ein oder mehrere Mehrzweckkerne sind (z.B. geordnete Mehrzweckkerne, ungeordnete Mehrzweckkerne oder eine Kombination aus beidem); 2) einen Coprozessor, wobei die Kerne 1202A-N eine große Anzahl von Sonderzweck-Kernen sind, die hauptsächlich für grafische und/oder wissenschaftliche Zwecke (Datendurchsatz) bestimmt sind; und 3) ein Coprozessor, wobei die Kerne 1202A-N eine große Anzahl von geordneten Mehrzweckkernen sind. Somit kann der Prozessor 1200 ein Mehrzweck-Prozessor, ein Coprozessor oder Sonderzweck-Prozessor, wie beispielsweise ein Netzwerk- oder Kommunikationsprozessor, eine Datenkompressionsmaschine, ein Grafikprozessor, eine Mehrzweckgrafikverarbeitungsheit (General Purpose Graphics Processing Unit, GPGPU), ein Coprozessor mit einem vielfach integrierten Kern (Many Integrated Core, MIC) mit hohem Datendurchsatz (der 30 oder mehr Kerne enthält), ein eingebetteter Prozessor oder dergleichen sein. Der Prozessor kann auf einem oder mehreren Chips durchgeführt werden. Der Prozessor 1200 kann ein Teil von einem oder mehreren Substraten sein und/oder kann unter Verwendung einer beliebigen Anzahl von Verfahrenstechnologien, wie beispielsweise BiCMOS, CMOS oder NMOS, darauf durchgeführt sein.

Die Speicherhierarchie umfasst einen oder mehrere Levels von Cache 1204A-N innerhalb der Kerne, einen Satz oder einen oder mehrere gemeinsam verwendete Cache-Einheiten 1206 und einen (nicht gezeigten) externen Speicher, der mit dem Satz von integrierten Speichersteuereinheiten 1214 verbunden ist. Der Satz von gemeinsam verwendeten Cache-Einheiten 1206 kann einen oder mehrere Cachespeicher mittlerer Level enthalten, z.B. Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cachelevel, einen Cache letzten Levels (Last Level Cache, LLC) und/oder Kombinationen davon. Während in einer Ausführungsform eine Ringverbindungseinheit 1212 die integrierte Grafiklogik 1208, den Satz von gemeinsam verwendeten Cache-Einheiten 1206 und die Systemagenteneinheit 1210/integrierte(n) Speichersteuereinheit(en) 1214 miteinander verbindet, können alternative Ausführungsformen eine beliebige Anzahl von allgemein bekannten Techniken verwenden, um derartige Einheiten miteinander zu verbinden. In einer Ausführungsform wird eine Kohärenz zwischen einer oder mehreren Cache-Einheiten 1206 und den Kernen 1202-A-N aufrecht erhalten.

In einigen Ausführungsformen sind ein oder mehrere Kerne 1202A-N für Multithreading geeignet. Der Systemagent 1210 enthält jene Komponenten, die die Kerne 1202A-N koordinieren und betreiben. Die Systemagenteneinheit 1210 kann beispielsweise eine Leistungssteuereinheit (Power Control Unit, PCU) und eine Bildschirmeinheit enthalten. Die PCU kann auf einer Logik und Komponenten basieren, die zum Regeln des Leistungszustands der Kerne 1202A-N und der integrierten Grafiklogik 1208 erforderlich sind. Die Bildschirmeinheit dient zum Betreiben eines oder mehrerer extern verbundener Bildschirme.

Die Kerne 1202A-N können mit Blick auf den Architekturbefehlssatz homogen oder heterogen sein, d. h., zwei oder mehrere der Kerne 1202A-N können in der Lage sein, den gleichen Befehlssatz auszuführen, während andere möglicherweise lediglich einen Teilsatz jenes Befehlssatzes oder eines anderen Befehlssatzes ausführen können.

Beispielhafte Computerarchitekturen

13-16 zeigen Blockdiagramme beispielhafter Computerarchitekturen. Andere im Stand der Technik bekannte Systemdesigns und -konfigurationen für Laptops, Desktops, von Hand geführte PCs, Minicomputer, technische Arbeitsstationen, Server, Netzwerkvorrichtungen, Netzwerk-Hubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-Top-Boxen, Mikro-Controller, Mobiltelefone, tragbare Mediengeräte, von Hand gehaltene Vorrichtungen und verschiedene andere elektronische Bauelemente, sind ebenfalls geeignet. Allgemein ist eine große Vielfalt von Systemen oder elektronischen Bauelementen, die in der Lage sind, einen Prozessor und/oder eine andere Ausführungslogik zu verwenden, wie hier offenbart ist, allgemein geeignet.

Mit Bezug auf 13 ist ein Blockdiagramm eines Systems 1300 gemäß einer Ausführungsform der Erfindung gezeigt. Das System 1300 kann einen oder mehrere Prozessoren 1310, 1315 enthalten, die mit einem Controller-Hub 1320 verbunden sind. In einer Ausführungsform enthält der Controller-Hub 1320 einen Grafikspeichercontroller-Hub (Graphics Memory Controller Hub, GMCH) 1390 und einen Eingabe/Ausgabe-Hub (Input/Output Hub, IOH) 1350 (der auf getrennten Chips angeordnet sein kann sein); der GMCH 1390 enthält Speicher- und Grafiksteuereinrichtungen, mit denen ein Speicher 1340 und ein Coprozessor 1345 verbunden sind; der IOH 1350 verbindet Eingabe/Ausgabe(I/O)-Vorrichtungen 1360 mit dem GMCH 1390. Alternativ ist einer oder sind beide der Speicher und Grafiksteuereinrichtungen in dem Prozessor (wie hier beschrieben) integriert, wobei der Speicher 1340 und der Coprozessor 1345 unmittelbar mit dem Prozessor 1310 und dem Controller-Hub 1320 auf einem einzigen Chip mit dem IOH 1350 verbunden sind.

Die optionale Natur zusätzlicher Prozessoren 1315 ist in 13 mit gestrichelten Linien gekennzeichnet. Jeder Prozessor 1310, 1315 kann einen oder mehrere hier beschriebene Verarbeitungskerne enthalten und kann eine Version des Prozessors 1200 sein.

Der Speicher 1340 kann beispielsweise ein dynamischer Speicher mit wahlfreiem Zugriff (Dynamic Random Access Memory, DRAM), ein Phasenwechselspeicher (Phase Change Memory, PCM) oder eine aus beiden gebildete Kombination sein. In wenigstens einer Ausführungsform kommuniziert der Controller-Hub 1320 mit dem einen oder den mehreren Prozessoren 1310, 1315 über einen Multi-Drop-Bus, beispielsweise einen Frontside-Bus (Frontside Bus, FSB), eine Point-to-Point-Schnittstelle, wie beispielsweise QuickPath Interconnect (QPI) oder eine ähnliche Verbindung 1395.

In einer Ausführungsform ist der Coprozessor 1345 ein Mehrzweck-Prozessor, wie beispielsweise ein MIC-Prozessor mit hohem Datendurchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Datenkompressionsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann der Controller-Hub 1320 einen integrierten Grafikbeschleuniger enthalten.

Es gibt eine Vielzahl von Unterschieden zwischen den physischen Ressourcen 1310, 1315 hinsichtlich eines Spektrums vorteilhafter Metriken, einschließlich architektonischer, mikroarchitektonischer, thermischer, Leistungsverbrauchscharakteristiken und dergleichen.

In einer Ausführungsform führt der Prozessor 1310 Befehle aus, die Datenverarbeitungsvorgänge eines allgemeinen Typs steuern. In die Befehle können Coprozessorbefehle eingebettet sein. Der Prozessor 1310 erkennt diese Coprozessorbefehle als einen Typ, der durch den verknüpften Coprozessor 1345 ausgeführt werden sollte. Dementsprechend gibt der Prozessor 1310 diese Coprozessorbefehle (oder Steuersignale, die Coprozessorbefehle kennzeichnen) auf einem Coprozessorbus oder einer anderen Verbindung an den Coprozessor 1345 aus. Der eine oder die mehreren Coprozessoren 1345 akzeptieren die aufgenommenen Coprozessorbefehle und führen sie aus.

Mit Bezug auf 14 wird nun in einem Blockdiagramm ein erstes spezielleres beispielhaftes System 1400 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 14 dargestellt, ist ein Multiprozessorsystem 1400 ein Punkt-zu-Punkt-Verbindungssystem und enthält einen ersten Prozessor 1470 und einen zweiten Prozessor 1480, die über eine Punkt-zu-Punkt-Verbindung 1450 verbunden sind. Jeder der Prozessoren 1470 und 1480 kann eine Version des Prozessors 1200 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 1470 und 1480 jeweils die Prozessoren 1310 und 1315, während ein Coprozessor 1438 der Coprozessor 1345 ist. In einer weiteren Ausführungsform sind die Prozessoren 1470 und 1480 der Prozessor 1310 bzw. der Coprozessor 1345.

Die Prozessoren 1470 und 1480 sind jeweils mit integrierten Speichersteuereinrichtungs(Integrated Memory Controller, IMC)-Einheiten 1472 und 1482 gezeigt. Der Prozessor 1470 enthält ferner als Teil seiner Bussteuereinheiten Punkt-zu-Punkt(P-P)-Schnittstellen 1476 und 1478; in ähnlicher Weise enthält der zweite Prozessor 1480 P-P-Schnittstellen 1486 und 1488. Die Prozessoren 1470, 1480 können über eine Punkt-zu-Punkt(P-P)-Schnittstelle 1450 unter Verwendung von P-P-Schnittstellenschaltkreisen 1478, 1488 Informationen austauschen. Wie in 14 gezeigt, verbinden die IMCs 1472 und 1482 die Prozessoren mit entsprechenden Speichern, d. h. einem Speicher 1432 und einem Speicher 1434, die Abschnitte eines Hauptspeichers sein können, der lokal mit den entsprechenden Prozessoren verbunden ist.

Die Prozessoren 1470, 1480 können jeweils über einzelne P-P-Schnittstellen 1452, 1454 mittels der Punkt-zu-Punkt-Schnittstellenschaltkreise 1476, 1494, 1486, 1498 Informationen mit einem Chipsatz 1490 austauschen. Der Chipsatz 1490 kann optional über eine Hochleistungsschnittstelle 1492 Informationen mit dem Coprozessor 1438 austauschen. In einer Ausführungsform ist der Coprozessor 1438 ein Sonderzweck-Prozessor, wie beispielsweise ein MIC-Prozessor mit hohem Datendurchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Datenkompressionsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.

In jedem Prozessor oder außerhalb beider Prozessoren kann ein (nicht gezeigter) gemeinsam verwendeter Cache enthalten sein, der jedoch über eine P-P-Verbindung mit den Prozessoren verbunden ist, so dass lokale Cacheinformationen eines oder beider Prozessoren in dem gemeinsam verwendeten Cache gespeichert werden können, falls ein Prozessor in einen Niedrigleistungsmodus versetzt wird.

Der Chipsatz 1490 kann über eine Schnittstelle 1496 mit einem ersten Bus 1416 verbunden sein. In einer Ausführungsform kann der erste Bus 1416 eine Peripheral-Component-Interconnect(PCI)-Bus oder ein Bus, wie beispielsweise ein PCI-Expressbus oder ein anderer I/O-Verbindungsbus der dritten Generation sein, obwohl der Schutzumfang der vorliegenden Erfindung nicht darauf beschränkt ist.

Wie in 14 gezeigt, können unterschiedliche I/O-Vorrichtungen 1414 über eine Busbridge 1418, die den ersten Bus 1416 mit einem zweiten Bus 1420 verbindet, mit dem ersten Bus 1416 verbunden sein. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessor(en) 1415, z.B. Coprozessoren, MIC-Prozessoren mit hohem Datendurchsatz, GPGPUs, Beschleuniger (beispielsweise Grafikbeschleuniger oder digitale Signalverarbeitungs(Digital Signal Processing, DSP)-Einheiten), im Feld programmierbare Gatteranordnungen (Field Programmable Gate Array, FPGA) oder ein beliebiger sonstiger Prozessor mit dem ersten Bus 1416 verbunden. In einer Ausführungsform kann der zweite Bus 1420 ein Bus mit geringer Pinanzahl (Low Pin Count, LPC) sein. Unterschiedliche Vorrichtungen können in einer Ausführungsform mit einem zweiten Bus 1420 verbunden werden, beispielsweise eine Tastatur und/oder Maus 1422, Kommunikationsvorrichtungen 1427 und eine Datenspeichereinheit 1428, beispielsweise ein Plattenlaufwerk oder eine andere Massenspeichereinheit, die Befehle/Programmcode und Daten 1430 enthalten kann. Weiter kann eine Audio-I/O-Einrichtung 1424 mit dem zweiten Bus 1420 verbunden sein. Zu beachten ist, dass auch andere Architekturen möglich sind. Beispielsweise kann anstelle der Punkt-zu-Punkt Architektur nach 14 ein System einen Multi-Drop-Bus oder eine andere derartige Architektur durchführen.

Mit Bezug auf 15 wird nun in einem Blockdiagramm ein zweites spezielleres beispielhaftes System 1500 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente tragen in 14 und 15 gleiche Bezugszeichen, und bestimmte Aspekte nach 14 wurden von 15 weggelassen, um ein Verschleiern anderer Aspekte von 15 zu vermeiden.

15 zeigt anschaulich, dass die Prozessoren 1470, 1480 jeweils eine integrierte Speicher- und Eingabe-Ausgabe-Steuerlogik (Control Logic, CL) 1472 und 1482 enthalten können. Somit enthalten die CL 1472, 1482 Steuereinheiten mit integriertem Speicher und eine I/O-Steuerlogik. 15 veranschaulicht, dass nicht nur die Speicher 1432, 1434 mit den CL 1472, 1482 verbunden sind, sondern auch, die I/O-Vorrichtungen 1514 mit den CL 1472, 1482 verbunden sind. Veraltete I/O-Vorrichtungen 1515 sind mit dem Chipsatz 1490 verbunden.

Unter Bezugnahme auf 16 ist ein Blockdiagramm eines SoC 1600 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 12 tragen ähnliche Bezugszeichen. Außerdem stehen gestrichelte Blöcke für optionale Merkmale weiter fortgeschrittener SoCs. In 16 sind eine oder mehrerer Verbindungseinheiten 1602 verbunden mit: einem Anwendungsprozessor 1610, der einen Satz eines oder mehrerer Kerne 1202A-N, Caches 1204A-N und eine oder mehrere gemeinsam verwendete Cache-Einheiten 1206 enthält; einer Systemagenteneinheit 1210; einer oder mehreren Bussteuereinheiten 1216; einer oder mehreren integrierten Speichersteuereinheiten 1214; einem Satz von oder einem oder mehreren Coprozessoren 1620, die die integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor aufweisen können; einer statischen Direktzugriffsspeicher(Static Random Access Memory, SRAM)-Einheit 1630; einer Direkt-Speicherzugriffs(Direct Memory Access, DMA)-Einheit 1632; und einer Bildschirmeinheit 1640 zur Verbindung mit einem oder mehreren externen Bildschirmen. In einer Ausführungsform beinhalten der eine oder die mehreren Coprozessoren 1620 einen Sonderzweck-Prozessor, wie beispielsweise einen Netzwerk- oder Kommunikationsprozessor, eine Datenkompressionsmaschine, eine GPGPU, einen MIC-Prozessor mit hohem Datendurchsatz, einen eingebetteten Prozessor oder dergleichen.

Ausführungsformen der hier offenbarten Vorrichtungen können in Hardware, Software, Firmware oder einer Kombination solcher Durchführungsansätze verwirklicht sein. Ausführungsformen der Erfindung können als Computerprogramme oder ein Programmcode durchgeführt sein, die/der auf programmierbaren Systemen ausgeführt werden können/kann, die wenigstens einen Prozessor, ein Speichersystem (einschließlich eines flüchtigen und nichtflüchtigen Speichers und/oder Speicherelementen), wenigstens eine Eingabevorrichtung und wenigstens eine Ausgabevorrichtung enthalten.

Der Programmcode, z.B. der in 14 veranschaulichte Programmcode 1430, kann auf Eingabebefehle angewendet werden, um die hier beschriebenen Funktionen durchzuführen und Ausgangsinformationen zu erzeugen. Die Ausgangsinformationen können in bekannter Weise auf eine oder mehrere Ausgabevorrichtungen anwendet werden. Für Zwecke dieser Anwendung enthält ein Verarbeitungssystem ein beliebiges System, das einen Prozessor, wie z.B. einen digitalen Signalprozessor (DSP), einen Mikrocontroller, einen anwendungsspezifischen integrierten Schaltkreis (Application Specific Integrated Circuit, ASIC) oder einen Mikroprozessor enthält.

Der Programmcode kann als eine prozedurale Hochsprache oder objektorientierte Programmiersprache durchführt sein, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann auch in Assembler- oder Maschinensprache durchführt sein, falls gewünscht. Tatsächlich sind die hier beschriebenen Mechanismen hinsichtlich eines Schutzbereichs nicht auf irgendeine bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.

Einer oder mehrere Aspekte der wenigstens einen Ausführungsform können durch repräsentative Befehle durchführt sein, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logiken innerhalb des Prozessors repräsentiert, die, wenn sie durch eine Maschine gelesen werden, die Maschine veranlassen, Logik herzustellen, um die hier beschriebenen Techniken durchzuführen. Solche Repräsentationen, die als „IP-Cores“ bekannt sind, können auf einem greifbaren, maschinenlesbaren Medium gespeichert und verschiedenen Kunden oder Herstellungseinrichtungen übergeben werden, um in die Herstellungsmaschinen geladen zu werden, die die eigentliche Logik oder den Prozessor herstellen.

Solche maschinenlesbaren Speichermedien können, ohne darauf beschränken zu wollen, nichtflüchtige greifbare Anordnungen von Erzeugnissen beinhalten, die durch eine Maschine oder Vorrichtung hergestellt werden, beispielsweise Speichermedien wie etwa Festplatten, eine beliebige sonstige Art einer Platte, z.B. Disketten, optische Platten, Kompaktdisk-Nur-LeseSpeicher (CD-ROMs), wiederbeschreibbare Kompaktdisks (CD-RWs) und magneto-optische Platten, Halbleiterbauelemente, wie beispielsweise Nur-LeseSpeicher (ROMs), Direktzugriffsspeicher (RAMs), wie beispielsweise dynamische Direktzugriffsspeicher (DRAMs), statische Direktzugriffsspeicher (SRAMs), löschbare programmierbare Lesespeicher (EPROMs), Flashmemorys, elektrisch löschbare programmierbare Lesespeicher (EEPROMs), Phasenwechselspeicher (Phase Change Memory, PCM), magnetische oder optische Karten oder beliebige andere Medientypen, die zum Speichern elektronischer Befehle geeignet sind.

Somit schließen Ausführungsformen der Erfindung auch nichtflüchtige, greifbare maschinenlesbare Medien ein, die Befehle enthalten oder Designdaten enthalten, z.B. Hardwarebeschreibungssprache (Hardware Description Language, HDL), die hier beschriebene Strukturen, Schaltkreise, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.

Emulation (z.B. Binärübersetzung, Programmcode-Morphing und dergleichen)

In einigen Fällen kann ein Befehlsumwandler verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. Beispielsweise kann der Befehlsumwandler übersetzen (z.B. unter Verwendung statischer Binärübersetzung, dynamischer Binärübersetzung einschließlich von dynamischem Kompilieren), morphen, emulieren oder anderweitig einen Befehl in einen oder mehrere andere Befehle umwandeln, die durch den Kern verarbeitet werden sollen. Der Befehlsumwandler kann in Form von Software Hardware, Firmware oder einer Kombination davon verwirklicht werden. Der Befehlsumwandler kann auf einem Prozessor, außerhalb eines Prozessors oder teilweise auf und teilweise außerhalb eines Prozessors sein.

17 stellt in einem Blockdiagramm die Verwendung eines Softwarebefehlsumwandlers zum Umwandeln binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz gemäß Ausführungsformen der Erfindung gegenüber. In der veranschaulichten Ausführungsform ist der Befehlsumwandler ein Softwarebefehlsumwandler, obwohl alternativ der Befehlsumwandler in Software, Firmware, Hardware oder verschiedenen Kombinationen derselben durchführt sein kann. 17 zeigt ein Programm in einer Hochsprache 1702, das unter Verwendung eines x86-Compilers 1704 kompiliert werden kann, um x86-Binärcode 1706 zu erzeugen, der durch einen Prozessor mit wenigstens einem x86-Befehlssatzkern 1716 nativ ausgeführt werden kann. Der Prozessor mit wenigstens einem x86-Befehlssatzkern 1716 repräsentiert einen beliebigen Prozessor, der im Wesentlichen die gleichen Funktionen wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern durchführen kann, indem er (1) einen wesentlichen Teil des Befehlssatzes des Intel-x86-Befehlssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software mit wenigstens einem x86 Befehlssatzkern kompatibel ausführt oder auf andere Weise verarbeitet, um im Wesentlichen das gleiche Ergebnis wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatzkern zu erreichen. Der x86-Compiler 1704 repräsentiert einen Compiler, der betreibbar ist, um x86-Binärcode 1706 (beispielsweise Objektcode) zu erzeugen, der mit oder ohne zusätzliche Verbindungs(linkage)-Verarbeitung auf dem Prozessor mit wenigstens einem x86-Befehlssatzkern 1716 ausgeführt werden kann. Auf ähnliche Weise zeigt 17, dass das Programm in der Hochsprache 1702 unter Verwendung eines alternativen Befehlssatzcompilers 1708 kompiliert werden kann, um einen alternativen Befehlssatzbinärcode 1710 zu erzeugen, der durch einen Prozessor ohne wenigstens einen x86-Befehlssatzkern 1714 nativ ausgeführt werden kann (beispielsweise einen Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS-Technologies aus Sunnyvale, CA, ausführen und/oder die den ARM-Befehlssatz von ARM-Holdings aus Sunnyvale, CA, ausführen). Der Befehlsumwandler 1712 wird verwendet, um den x86-Binärcode 1706 in Code umzuwandeln, der durch den Prozessor ohne einen x86-Befehlssatzkern 1714 nativ ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht der gleiche wie der alternative Befehlssatzbinärcode 1710, da ein Befehlsumwandler, der dazu in der Lage ist, schwierig herzustellen ist; jedoch wird der umgewandelte Code den allgemeinen Betrieb ermöglichen und sich aus Befehlen aus dem alternativen Befehlssatz zusammensetzen. Somit repräsentiert der Befehlsumwandler 1712 Software, Firmware, Hardware oder eine Kombination derselben, die durch Emulation, Simulation oder irgendeinen anderen Prozess einem Prozessor oder einer anderen elektronischen Einrichtung, die keinen x86-Befehlssatzprozessor oder -kern aufweist, ermöglicht, den x86-Binärcode 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 (20)

1. Vorrichtung, umfassend: ein Decodiermittel zum Decodieren eines Befehls, wobei der Befehl wenigstens einen Opcode, ein Feld für einen Quelloperanden und ein Feld für einen Zieloperanden enthält; und Ausführungsmittel zum Ausführen des decodierten Befehls, um zu ermitteln, ob ein Kennsatz von der Adresse von dem Quelloperanden zu einem Kennsatz in einer ausgewählten nichtflüchtigen Speicheradresscache(Non-Volatile Memory Address Cache, NVMAC)-Cachezeile passt, wobei bei Vorhandensein einer Übereinstimmung eine Trefferanzeige in dem Zieloperanden gespeichert wird, und bei Abwesenheit einer Übereinstimmung eine Fehlanzeige in dem Zieloperanden gespeichert wird und der NVMAC mit dem Kennsatz von der Adresse von dem Quelloperanden aktualisiert wird.
2. Vorrichtung nach Anspruch 1, wobei der NVMAC Cachezeilen für einen nichtflüchtigen Direktzugriffsspeicher speichert.
3. Vorrichtung nach einem beliebigen der Ansprüche 1-2, wobei das Ausführungsmittel ferner bestimmt, dass ein Cachezeileneintrag mit einem passenden Kennsatz gültig ist.
4. Vorrichtung nach einem beliebigen der Ansprüche 1-3, wobei, wenn keine Übereinstimmung gefunden wird, das Ausführungsmittel einen Pfad des NVMAC auf der Grundlage eines am längsten nicht verwendeten Werts auswählt, der in der ausgewählten Cachezeile gespeichert ist.
5. Vorrichtung nach einem beliebigen der Ansprüche 1-4, wobei die NVMAC-Cachezeile mittels eines Index ausgewählt wird, der in der Adresse von dem Quelloperanden gespeichert ist.
6. Vorrichtung nach einem beliebigen der Ansprüche 1-5, wobei der NVMAC von einem Datencache getrennt ist.
7. Vorrichtung nach einem beliebigen der Ansprüche 1-5, wobei der NVMAC ein Teil eines Datencache ist.
8. Verfahren, umfassend: Decodieren eines Befehls, wobei der Befehl wenigstens einen Opcode, ein Feld für einen Quelloperanden und ein Feld für einen Zieloperanden enthält; und Ausführen des decodierten Befehls, um zu ermitteln, ob ein Kennsatz von der Adresse von dem Quelloperanden zu einem Kennsatz in einer ausgewählten nichtflüchtigen Speicheradresscache(Non-Volatile Memory Address Cache, NVMAC)-Cachezeile passt, wobei bei Vorhandensein einer Übereinstimmung eine Trefferanzeige in dem Zieloperanden gespeichert wird, und bei Abwesenheit einer Übereinstimmung eine Fehlanzeige in dem Zieloperanden gespeichert wird und der NVMAC mit dem Kennsatz von der Adresse von dem Quelloperanden aktualisiert wird.
9. Verfahren nach Anspruch 8, wobei der NVMAC Cachezeilen für einen nichtflüchtigen Direktzugriffsspeicher speichert.
10. Verfahren nach einem beliebigen der Ansprüche 8-9, ferner umfassend: Bestimmen, dass ein Cachezeileneintrag mit einem passenden Kennsatz gültig ist.
11. Verfahren nach einem beliebigen der Ansprüche 8-10, wobei, wenn keine Übereinstimmung gefunden wird, ein Pfad des NVMAC auf der Grundlage eines zuletzt verwendeten Werts ausgewählt wird, der in der ausgewählten Cachezeile gespeichert ist.
12. Verfahren nach einem beliebigen der Ansprüche 8-11, wobei die NVMAC-Cachezeile mittels eines Index ausgewählt wird, der in der Adresse von dem Quelloperanden gespeichert ist.
13. Verfahren nach einem beliebigen der Ansprüche 8-12, wobei der NVMAC von einem Datencache getrennt ist.
14. Verfahren nach einem beliebigen der Ansprüche 8-12, wobei der NVMAC ein Teil eines Datencache ist.
15. Nichtflüchtiges maschinenlesbares Medium, das Befehle speichert, die bei Ausführung einen Prozessor dazu veranlassen, ein Verfahren durchzuführen, wobei das Verfahren Folgendes umfasst: Decodieren eines Befehls, wobei der Befehl wenigstens einen Opcode, ein Feld für einen Quelloperanden und ein Feld für einen Zieloperanden enthält; und Ausführen des decodierten Befehls, um zu ermitteln, ob ein Kennsatz von der Adresse von dem Quelloperanden zu einem Kennsatz in einer ausgewählten nichtflüchtigen Speicheradresscache(Non-Volatile Memory Address Cache, NVMAC)-Cachezeile passt, wobei bei Vorhandensein einer Übereinstimmung eine Trefferanzeige in dem Zieloperanden gespeichert wird, und bei Abwesenheit einer Übereinstimmung eine Fehlanzeige in dem Zieloperanden gespeichert wird und der NVMAC mit dem Kennsatz von der Adresse von dem Quelloperanden aktualisiert wird.
16. Nichtflüchtiges maschinenlesbares Medium nach Anspruch 15, wobei der NVMAC Cachezeilen für einen nichtflüchtigen Direktzugriffsspeicher speichert.
17. Nichtflüchtiges maschinenlesbares Medium nach Anspruch 15, ferner aufweisend: Bestimmen, dass ein Cachezeileneintrag mit einem passenden Kennsatz gültig ist.
18. Nichtflüchtiges maschinenlesbares Medium nach Anspruch 15, wobei, wenn keine Übereinstimmung gefunden wird, ein Pfad des NVMAC auf der Grundlage eines am längsten nicht verwendeten Werts ausgewählt wird, der in der ausgewählten Cachezeile gespeichert ist.
19. Nichtflüchtiges maschinenlesbares Medium nach Anspruch 15, wobei die NVMAC-Cachezeile mittels eines Index ausgewählt wird, der in der Adresse von dem Quelloperanden gespeichert ist.
20. Nichtflüchtiges maschinenlesbares Medium nach Anspruch 15, wobei der NVMAC von einem Datencache getrennt ist.

Images