DE112013005338T5 - Vorrichtung und Verfahren für Beschleunigeraufruf mit geringer Latenz - Google Patents

Vorrichtung und Verfahren für Beschleunigeraufruf mit geringer Latenz Download PDF

Info

Publication number
DE112013005338T5
DE112013005338T5 DE112013005338.1T DE112013005338T DE112013005338T5 DE 112013005338 T5 DE112013005338 T5 DE 112013005338T5 DE 112013005338 T DE112013005338 T DE 112013005338T DE 112013005338 T5 DE112013005338 T5 DE 112013005338T5
Authority
DE
Germany
Prior art keywords
instruction
accelerators
register
command
accelerator
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112013005338.1T
Other languages
English (en)
Inventor
Oren Ben-Kiki
Ilan Pardo
Robert Valentine
Eliezer Weissmann
Dror Markovich
Yuval Yosef
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112013005338T5 publication Critical patent/DE112013005338T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3802—Instruction prefetching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G06F11/0724—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU] in a multiprocessor or a multi-core unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G06F9/30043—LOAD or STORE instructions; Clear instruction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30101—Special purpose registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/3016—Decoding the operand specifier, e.g. specifier format
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3838—Dependency mechanisms, e.g. register scoreboarding
    • G06F9/384—Register renaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3877—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3877—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • G06F9/3879—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor for non-native instruction execution, e.g. executing a command; for Java instruction set
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3877—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • G06F9/3879—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor for non-native instruction execution, e.g. executing a command; for Java instruction set
    • G06F9/3881—Arrangements for communication of instructions and data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/452—Instruction code

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Advance Control (AREA)

Abstract

Es werden eine Vorrichtung und ein Verfahren zum Bereitstellen von Beschleunigeraufruf mit geringer Latenz bereitgestellt. Zum Beispiel umfasst ein Prozessor gemäß einer Ausführungsform: ein Befehlsregister zum Speichern von Befehlsdaten, die einen auszuführenden Befehl identifizieren; ein Ergebnisregister zum Speichern eines Ergebnisses des Befehls oder von Daten, die einen Grund dafür angeben, warum der Befehl nicht ausgeführt werden konnte; Ausführungslogik zum Ausführen einer Mehrzahl von Anweisungen, die eine Beschleunigeraufrufanweisung zum Aufrufen eines oder mehrerer Beschleunigerbefehle umfassen; und einen oder mehrere Beschleuniger zum Auslesen der Befehlsdaten aus dem Befehlsregister und Versuchen in Reaktion darauf, den durch die Befehlsdaten identifizierten Befehl auszuführen.

Description

  • HINTERGRUND
  • Gebiet der Erfindung
  • Die Erfindung betrifft das Gebiet von Computerprozessoren. Insbesondere betrifft die Erfindung eine generische, erweiterbare Anweisung für Beschleunigeraufruf mit geringer Latenz.
  • Beschreibung der verwandten Technik
  • Das Aufrufen von Beschleunigern erfordert heutzutage den Durchtritt durch eine Treiberschnittstelle. In einem System, in dem eine hierarchische Schutzdomäne verwendet wird, bedeutet dies, zu Ring 0 zu wechseln und Daten in einen anderen Adressraum zu kopieren, was erhebliche Zeit in Anspruch nimmt und beträchtliche Verarbeitungsressourcen verbraucht. Aufgrund der hohen Latenz sind solche Beschleunigerschnittstellen außerdem von Natur aus asynchron. Programmierbare Beschleuniger erfordern, dass der beschleunigte Code in ihrer eigenen Anweisungssatzarchitektur (ISA für engl. instruction set architecture) implementiert wird.
  • Einige aktuelle Prozessorarchitekturen versuchen, einige dieser Probleme zu lösen, stellen aber nur einen grobkörnigen asynchronen Mechanismus mit einer hohen Latenz zwischen der Anforderung einer beschleunigten Aufgabe und ihrer Ausführung bereit. Außerdem verwenden aktuelle Architekturen eine von X86 verschiedene ISA, die eine separate Toolkette erfordert, um die beschleunigte Aufgabe in das x86-Hauptprogramm zu generieren und zu integrieren.
  • Außerdem ermöglichen aktuelle asynchrone Hardwarebeschleuniger (z. B. GPUs) eine Ausführung der beschleunigten Aufgabe ohne Beziehung zum Anwendungsthread, der sie auslöste. Dies ermöglicht es dem Anwendungsthread, Ausnahmen und/oder Unterbrechungen zu behandeln, ohne die beschleunigte Aufgabe zu beeinträchtigen, und es ermöglicht es dem Anwendungsthread sogar, ohne Auswirkung auf den Ort der beschleunigten Aufgabe im System zwischen Kernen zu migrieren.
  • Aktuelle synchrone Hardwarebeschleuniger müssen gewährleisten, dass Unterbrechungen, Ausnahmen, Kontextwechsel und Kernmigrationen weiterhin funktionell korrekt sind und Fortschritt gewährleisten. Dies erfolgt entweder durch (1) Gewährleisten, dass der Beschleuniger kurz genug ist und keine Ausnahmen verursacht, so dass jegliche Unterbrechungen verschoben werden, bis der Beschleuniger fertig ist; (2) Aufrechterhalten des Fortschritts des Beschleunigers in bestehenden Architekturregistern (z. B. REPMOV); oder (3) Definieren von neuen Architekturregistern, um den Beschleunigerstatus zu bewahren, und Hinzufügen derselben zu XSAVE/XRESTORE.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Erfindung wird aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden Zeichnungen besser verständlich, wobei:
  • 1A ein Blockdiagramm ist, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs- und Out-of-Order-Ausgabe-/Ausführungs-Pipeline gemäß Ausführungsformen der Erfindung veranschaulicht;
  • 1B ein Blockdiagramm ist, das sowohl eine beispielhafte Ausführungsform eines Kerns mit In-Order-Architektur als auch eines beispielhaften Kerns mit Registerumbenennungs- und Out-of-Order-Ausgabe-/Ausführungsarchitektur veranschaulicht, die in einen Prozessor gemäß Ausführungsformen der Erfindung integriert werden sollen;
  • 2 ein Blockdiagramm eines Einzelkernprozessors und eines Mehrkernprozessors mit integrierter Speichersteuerung und integrierten Grafiken gemäß Ausführungsformen der Erfindung ist;
  • 3 ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
  • 4 ein Blockdiagramm eines zweiten Systems gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
  • 5 ein Blockdiagramm eines dritten Systems gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
  • 6 ein Blockdiagramm eines Systemchips (SoC) gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
  • 7 ein Blockdiagramm veranschaulicht, das die Verwendung eines Softwareanweisungsumsetzers zum Umsetzen von Binäranweisungen in einem Quellenanweisungssatz in Binäranweisungen in einem Zielanweisungssatz gemäß Ausführungsformen der Erfindung vergleicht;
  • 8A eine Prozessorarchitektur veranschaulicht, in welcher Ausführungsformen der Erfindung implementiert sein können;
  • 8B und 8C Register zum Speichern von Daten veranschaulichen, die zum Aufrufen von Beschleunigern und Überprüfen von Ergebnissen verwendet werden;
  • 9A bis 9C ein Verfahren zum Aufrufen eines Beschleunigers gemäß einer Ausführungsform der Erfindung veranschaulichen;
  • 10 ein Verfahren zum Verarbeiten von komplexen Anweisungen veranschaulicht, die häufig fehlschlagen;
  • 11 eine Ausführungsform der Erfindung veranschaulicht, die einen Stapel zum Speichern von Beschleunigerzustandsinformationen verwendet;
  • 12A und 12B Blockdiagramme sind, die ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulichen;
  • 13A bis 13D Blockdiagramme sind, die ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat gemäß Ausführungsformen der Erfindung veranschaulichen; und
  • 14 ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform der vorliegenden Erfindung ist.
  • 15 veranschaulicht ein Computersystem gemäß bestimmten Ausführungsformen der Erfindung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In der folgenden Beschreibung werden zu Erläuterungszwecken zahlreiche spezifische Details dargelegt, um ein umfassendes Verständnis der Ausführungsformen zu vermitteln, die im Folgenden beschrieben werden. Für Fachleute ist jedoch zu erkennen, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Einzelheiten realisiert werden können. In anderen Fällen sind allgemein bekannte Strukturen und Einrichtungen in der Form von Blockdiagrammen dargestellt, um ein Verkomplizieren der den Ausführungsformen der Erfindung zugrunde liegenden Prinzipien zu vermeiden.
  • Beispielhafte Prozessorarchitekturen und Datentypen
  • 1A ist ein Blockdiagramm, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs- und Out-of-Order-Ausgabe-/Ausführungs-Pipeline gemäß Ausführungsformen der Erfindung veranschaulicht. 1B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines Kerns mit In-Order-Architektur als auch eines beispielhaften Kerns mit Registerumbenennungs- und Out-of-Order-Ausgabe-/Ausführungsarchitektur veranschaulicht, die in einen Prozessor gemäß Ausführungsformen der Erfindung integriert werden sollen. Die Kästchen mit durchgehenden Linien in 1A und 1B veranschaulichen die In-Order-Pipeline und den In-Order-Kern, während die optionale Hinzufügung der Kästchen mit gestrichelten Linien die Pipeline und den Kern für Registerumbenennung und Out-of-Order-Ausgabe/Ausführung veranschaulicht. Da der In-Order-Aspekt ein Teilsatz des Out-of-Order-Aspekts ist, wird der Out-of-Order-Aspekt beschrieben.
  • In 1A umfasst eine Prozessor-Pipeline 100 eine Abrufstufe 102, eine Längendecodierstufe 104, eine Decodierstufe 106, eine Zuordnungsstufe 108, eine Umbenennungsstufe 110, eine Ablaufsteuerungs(auch bekannt als Abfertigungs- oder Ausgabe)-Stufe 112, eine Registerlese-/Speicherlesestufe 114, eine Ausführungsstufe 116, eine Zurückschreib-/Speicherschreibstufe 118, eine Ausnahmebehandlungsstufe 122 und eine Commit-Stufe 124.
  • 1B stellt einen Prozessorkern 190 dar, der eine Eingangseinheit 130 umfasst, die mit einer Ausführungsmaschineneinheit 150 gekoppelt ist, wobei beide mit einer Speichereinheit 170 gekoppelt sind. Der Kern 190 kann ein Kern zum Rechnen mit reduziertem Anweisungssatz (RISC für engl. reduced instruction set computing), ein Kern zum Rechnen mit komplexem Anweisungssatz (CISC für engl. complex instruction set computing), ein Kern für sehr lange Anweisungswörter (VLIW für engl. very long instruction word) oder ein Hybrid- oder alternativer Kerntyp sein. Als noch eine andere Option kann der Kern 190 ein Spezialkern, wie beispielsweise ein Netzwerk- oder Kommunikationskern, eine Kompressionsmaschine, ein Coprozessorkern, ein Kern für Allzweckberechnung auf Grafikverarbeitungseinheiten (GPGPU für engl. general purpose computing graphics processing unit), ein Grafikkern oder dergleichen sein.
  • Die Eingangseinheit 130 umfasst eine Zweigprädiktionseinheit 132, die mit einer Anweisungs-Cache-Einheit 134 gekoppelt ist, die mit einem Anweisungsübersetzungs-Vorgriffspuffer (TLB) 136 gekoppelt ist, der mit einer Anweisungsabrufeinheit 138 gekoppelt ist, die mit einer Decodiereinheit 140 gekoppelt ist. Die Decodiereinheit 140 (oder der Decoder) kann Anweisungen decodieren und als eine Ausgabe eine oder mehrere Mikrooperationen, Mikrocode-Eintrittsstellen, Mikroanweisungen, andere Anweisungen oder andere Steuersignale generieren, die aus den Originalanweisungen decodiert oder von diesen abgeleitet werden oder diese anderweitig widerspiegeln. Die Decodiereinheit 140 kann unter Verwendung von mehreren verschiedenen Mechanismen implementiert sein. Beispiele von geeigneten Mechanismen umfassen, ohne darauf beschränkt zu sein, Nachschlagetabellen, Hardwareimplementierungen, programmierbare Logikfelder (PLAs), Mikrocode-Festwertspeicher (ROMs für engl. read only memories) usw. In einer Ausführungsform umfasst der Kern 190 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für bestimmte Makroanweisungen speichert (z. B. in der Decodiereinheit 140 oder andernfalls in der Eingangseinheit 130). Die Decodiereinheit 140 ist mit einer Umbenennungs-/Zuordnungseinheit 152 in der Ausführungsmaschineneinheit 150 gekoppelt.
  • Die Ausführungsmaschineneinheit 150 umfasst die Umbenennungs-/Zuordnungseinheit 152, die mit einer Ausmusterungseinheit 154 und einem Satz von einer oder mehreren Scheduler-Einheit(en) 156 gekoppelt ist. Die Scheduler-Einheit(en) 156 stellt/stellen eine beliebige Anzahl von verschiedenen Schedulern dar, die Reservierungsstationen, ein zentrales Anweisungsfenster usw. umfassen. Die Scheduler-Einheit(en) 156 ist/sind mit der/den Einheit(en) physikalischer Registerdatei(en) 158 gekoppelt. Jede der Einheiten physikalischer Registerdatei(en) 158 stellt eine oder mehrere physikalische Registerdateien dar, von welchen verschiedene einen oder mehrere Datentypen speichern, wie beispielsweise skalare Ganzzahl, skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, vektorielle Ganzzahl, vektorielles Gleitkomma, Status (z. B. einen Anweisungszeiger, der die Adresse der nächsten Anweisung ist, die ausgeführt werden soll) usw. In einer Ausführungsform umfasst die Einheit physikalischer Registerdatei(en) 158 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine Skalarregistereinheit. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Universalregister bereitstellen. Die Einheit(en) physikalischer Registerdatei(en) 158 sind von der Ausmusterungseinheit 154 überlappt, um verschiedene Möglichkeiten zu veranschaulichen, in welchen Registerumbenennung und Out-of-Order-Ausführung (z. B. unter Verwendung von Neuordnungspuffer(n) und Ausmusterungsregisterdatei(en); unter Verwendung von Zukunftsdatei(en), Verlaufspuffer(n) und Ausmusterungsregisterdatei(en); unter Verwendung von Registerverzeichnissen und eines Registerpools usw.) implementiert sein können. Die Ausmusterungseinheit 154 und die Einheit(en) physikalischer Registerdatei(en) 158 sind mit Ausführungscluster(n) 160 gekoppelt. Der/die Ausführungscluster 160 umfasst/umfassen einen Satz von einer oder mehreren Ausführungseinheiten 162 und einen Satz von einer oder mehreren Speicherzugriffseinheiten 164. Die Ausführungseinheiten 162 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und an verschiedenen Datentypen (z. B. skalarem Gleitkomma, gepackter Ganzzahl, gepacktem Gleitkomma, vektorieller Ganzzahl, vektoriellem Gleitkomma) ausführen. Obwohl einige Ausführungsformen eine Anzahl von Ausführungseinheiten umfassen können, die spezifischen Funktionen oder Sätzen von Funktionen gewidmet sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten umfassen, die allesamt alle Funktionen ausführen. Die Scheduler-Einheit(en) 156, die Einheit(en) physikalischer Registerdatei(en) 158 und der/die Ausführungscluster 160 sind so dargestellt, dass sie möglicherweise mehrere sind, da bestimmte Ausführungsformen separate Pipelines für bestimmte Typen von Daten/Operationen erstellen (z. B. eine skalare Ganzzahl-Pipeline, eine skalare Gleitkomma-/gepackte Ganzzahl-/gepackte Gleitkomma-/vektorielle Ganzzahl-/vektorielle Gleitkomma-Pipeline und/oder eine Speicherzugriffs-Pipeline, die jeweils ihre eigene Scheduler-Einheit, ihre eigene Einheit physikalischer Registerdatei(en) und/oder ihren eigenen Ausführungscluster aufweisen – und im Falle einer separaten Speicherzugriffs-Pipeline sind bestimmte Ausführungsformen implementiert, in welche nur der Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 164 aufweist). Es versteht sich außerdem von selbst, dass bei Verwenden separater Pipelines eine oder mehrere dieser Pipelines mit Out-of-Order- und die restlichen mit In-Order-Ausführung sein können.
  • Der Satz von Speicherzugriffseinheiten 164 ist mit der Speichereinheit 170 gekoppelt, welche eine Daten-TLB-Einheit 172 umfasst, die mit einer Daten-Cache-Einheit 174 gekoppelt ist, die mit einer Cache-Einheit 176 der Ebene 2 (L2) gekoppelt ist. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 164 eine Lasteinheit, eine Speicheradresseinheit und eine Speicherdateneinheit umfassen, die jeweils mit der Daten-TLB-Einheit 172 in der Speichereinheit 170 gekoppelt sind. Die Anweisungs-Cache-Einheit 134 ist ferner mit der Cache-Einheit 176 der Ebene 2 (L2) in der Speichereinheit 170 gekoppelt. Die L2-Cache-Einheit 176 ist mit einer oder mehreren anderen Cache-Ebenen und schließlich mit einem Hauptspeicher gekoppelt.
  • Als Beispiel kann die beispielhafte Registerumbenennungs- und Out-of-Order-Ausgabe-/Ausführungs-Kernarchitektur die Pipeline 100 folgendermaßen implementieren: 1) die Anweisungsabrufeinheit 138 führt die Abruf- und Längendecodierstufen 102 und 104 aus; 2) die Decodiereinheit 140 führt die Decodierstufe 106 aus; 3) die Umbenennungs-/Zuordnungseinheit 152 führt die Zuordnungsstufe 108 und die Umbenennungsstufe 110 aus; 4) die Scheduler-Einheit(en) 156 führt/führen die Ablaufsteuerungsstufe 112 aus; 5) die Einheit(en) physikalischer Registerdatei(en) 158 und die Speichereinheit 170 führen die Registerlese-/Speicherlesestufe 114 aus; der Ausführungscluster 160 führt die Ausführungsstufe 116 aus; 6) die Speichereinheit 170 und die Einheit(en) physikalischer Registerdatei(en) 158 führen die Zurückschreib-/Speicherschreibstufe 118 aus; 7) verschiedene Einheiten können an der Ausnahmebehandlungsstufe 122 beteiligt sein; und 8) die Ausmusterungseinheit 154 und die Einheit(en) physikalischer Registerdatei(en) 158 führen die Commit-Stufe 124 aus.
  • Der Kern 190 kann einen oder mehrere Anweisungssätze (z. B. den x86-Anweisungssatz (mit einigen Erweiterungen, welche bei neueren Version hinzugefügt wurden); den MIPS-Anweisungssatz von MIPS Technologies, Sunnyvale, Kalifornien; den ARM-Anweisungssatz (mit optionalen zusätzlichen Erweiterungen, wie beispielsweise NEON) von der ARM Holdings, Sunnyvale, Kalifornien), einschließlich der hierin beschriebenen Anweisung(en), unterstützen. In einer Ausführungsform umfasst der Kern 190 Logik zum Unterstützen einer Anweisungssatzerweiterung für gepackte Daten (z. B. AVX1, AVX2 und/oder irgendeine Form des nachstehend beschriebenen generischen vektorfreundlichen Anweisungsformats (U = 0 und/oder U = 1)), um dadurch zu ermöglichen, dass die durch viele Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten ausgeführt werden.
  • Es versteht sich von selbst, dass der Kern Multithreading (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützten kann und dies auf verschiedene Arten und Weisen tun kann, welche Zeitscheiben-Multithreading, simultanes Multithreading (wobei ein einziger physikalischer Kern einen logischen Kern für jeden der Threads bereitstellt, für die der physikalische Kern simultanes Multithreading ausführt) oder eine Kombination davon (z. B. Zeitscheiben-Abruf und -Decodierung und anschließendes simultanes Multithreading, wie beispielsweise in der Intel® Hyperthreading-Technologie) umfassen.
  • Es versteht sich von selbst, dass, obwohl Registerumbenennung im Kontext von Out-of-Order-Ausführung beschrieben wird, Registerumbenennung auch in einer In-Order-Architektur verwendet werden kann. Obwohl die veranschaulichte Ausführungsform des Prozessors getrennte Anweisungs- und Daten-Cache-Einheiten 134/174 und eine gemeinsam benutzte L2-Cache-Einheit 176 umfasst, können alternative Ausführungsformen einen einzigen internen Cache sowohl für Anweisungen als auch Daten aufweisen, wie beispielsweise einen internen Cache der Ebene 1 (L1) oder einen internen Cache mehrerer Ebenen. In einigen Ausführungsformen kann das System eine Kombination eines internen Caches und eines externen Caches aufweisen, der außerhalb des Kerns und/oder des Prozessors ist. Alternativ können alle der Caches außerhalb des Kerns und/oder des Prozessors sein.
  • 2 ist ein Blockdiagramm eines Prozessors 200, der mehr als einen Kern aufweisen kann, eine integrierte Speichersteuereinheit aufweisen kann, und integrierte Grafik gemäß Ausführungsformen der Erfindung aufweisen kann. Die Kästchen mit durchgehenden Linien in 9 veranschaulichen einen Prozessor 200 mit einem einzigen Kern 202A, einem Systemagenten 210, einem Satz von einer oder mehreren Bussteuereinheiten 216, während die optionale Hinzufügung der Kästchen mit gestrichelten Linien einen alternativen Prozessor 200 mit mehreren Kernen 202A–N, einen Satz von einer oder mehreren integrierten Speichersteuereinheit(en) 214 in der Systemagenteneinheit 210 und Speziallogik 208 umfasst.
  • Demnach können verschiedene Implementierungen des Prozessor 200 Folgendes umfassen: 1) eine CPU mit der Speziallogik 208, wobei es sich um integrierte Grafik- und/oder wissenschaftliche (Durchsatz-)Logik handelt (welche einen oder mehrere Kerne umfassen kann), und die Kerne 202A–N, wobei es sich um einen oder mehrere Universalkerne handelt (z. B. In-Order-Universalkerne, Out-of-Order-Universalkerne, eine Kombination der beiden); 2) einen Coprozessor mit den Kernen 202A–N, wobei es sich um eine große Anzahl von Spezialkernen handelt, die in erster Linie für Grafik und/oder Wissenschaft (Durchsatz) bestimmt sind; und 3) einen Coprozessor mit den Kernen 202A–N, wobei es sich um eine große Anzahl von In-Order-Universalkernen handelt. Demnach kann der Prozessor 200 ein Universalprozessor, ein Coprozessor oder Spezialprozessor, wie beispielsweise ein Netzwerk- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU (Universal-Grafikverarbeitungseinheit), ein Coprozessor mit hohem Durchsatz und vielen integrierten Kernen (MIC für engl. many integrated cores) (der 30 oder mehr Kerne umfasst), ein eingebetteter Prozessor oder dergleichen sein. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 200 kann Teil eines oder mehrerer Substrate sein und/oder er kann auf einem oder mehreren Substraten unter Verwendung einer beliebigen von einer Anzahl von Prozesstechnologien, wie beispielsweise BiCMOS, CMOS oder NMOS, implementiert sein.
  • Die Speicherhierarchie umfasst eine oder mehrere Cache-Ebenen innerhalb der Kerne, einen Satz von oder einen oder mehrere gemeinsam benutzte(n) Cache-Einheiten 206 und einen externen Speicher (nicht dargestellt), der mit dem Satz von integrierten Speichersteuereinheiten 214 gekoppelt ist. Der Satz der gemeinsam benutzten Cache-Einheiten 206 kann einen oder mehrere Caches mittlerer Ebene, wie beispielsweise Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder anderer Cache-Ebenen, einen Cache der letzten Ebene (LLC für engl. last level cache) und/oder Kombinationen davon umfassen. Obwohl in einer Ausführungsform eine ringbasierte Zwischenverbindungseinheit 212 die integrierte Grafiklogik 208, den Satz von gemeinsam benutzten Cache-Einheiten 206 und die Systemagenteneinheit 210 bzw. die integrierten Speichersteuereinheit(en) 214 miteinander verbindet, können alternative Ausführungsformen eine beliebige Anzahl von allgemein bekannten Techniken für die Verbindung solcher Einheiten miteinander verwenden. In einer Ausführungsform wird Kohärenz zwischen einer oder mehreren Cache-Einheiten 206 und den Kernen 202A–N aufrechterhalten.
  • In einigen Ausführungsformen sind ein oder mehrere der Kerne 202A–N zu Multithreading imstande. Der Systemagent 210 umfasst jene Komponenten, welche die Kerne 202A–N koordinieren und steuern. Die Systemagenteneinheit 210 kann zum Beispiel eines Leistungssteuerungseinheit (PCU für engl. power control unit) und eine Anzeigeeinheit umfassen. Die PCU kann Logik sein oder Logik und Komponenten umfassen, die zum Regeln des Leistungszustands der Kerne 202A–N und der integrierten Grafiklogik 208 benötigt werden. Die Anzeigeeinheit ist zum Ansteuern einer oder mehrerer extern angeschlossener Anzeigen.
  • Die Kerne 202A–N können homogen oder heterogen in Bezug auf den Architekturanweisungssatz sein; das heißt, zwei oder mehr der Kerne 902A–N können zur Ausführung des gleichen Anweisungssatzes imstande sein, während andere nur zur Ausführung eines Teilsatzes dieses Anweisungssatzes oder eines anderen Anweisungssatzes imstande sein können.
  • 3 bis 6 sind Blockdiagramme von beispielhaften Computerarchitekturen. Andere auf dem Fachgebiet bekannte Systemkonstruktionen und -konfigurationen für Laptops, Tischcomputer, Hand-PCs, persönliche digitale Assistenten, Engineering-Workstations, Server, Netzwerkgeräte, Netzkontrollstationen, Switches, eingebettete Prozessoren, Digitalsignalprozessoren (DSPs), Grafikgeräte, Videospielgeräte, Set-Top-Boxen, Mikro-Controller, Zellulartelefone, tragbare Media Player, Hand-Geräte und verschiedene andere elektronische Einrichtungen sind ebenfalls geeignet. Im Allgemeinen eignet sich grundsätzlich eine große Vielzahl von Systemen oder elektronischen Einrichtungen, die zum Integrieren eines Prozessors und/oder anderer Ausführungslogik, wie hierin offenbart, imstande sind.
  • Nunmehr unter Bezugnahme auf 3 ist ein Blockdiagramm eines Systems 300 gemäß einer Ausführungsform der vorliegenden Erfindung dargestellt. Das System 300 kann einen oder mehrere Prozessoren 310, 315 umfassen, welche mit einem Steuerhub 320 gekoppelt sind. In einer Ausführungsform umfasst der Steuerhub 320 einen Grafikspeicher-Steuerhub (GMCH für engl. graphics memory controller hub) 390 und einen Eingangs-/Ausgangs-Hub (EAH) 350 (die auf separaten Chips sein können); der GMCH 390 umfasst Speicher- und Grafiksteuereinheiten, mit welchen ein Speicher 340 und ein Coprozessor 345 gekoppelt sind; der EAH 350 koppelt Eingabe-/Ausgabe(E-/A)-Einrichtungen 360 mit dem GMCH 390. Alternativ sind eine oder beide der Speicher- und Grafiksteuereinheiten in den Prozessor integriert (wie hierin beschrieben), der Speicher 340 und der Coprozessor 345 sind direkt mit dem Prozessor 310 gekoppelt, und der Steuerhub 320 in einem einzigen Chip mit dem EAH 350.
  • Die optionale Beschaffenheit von zusätzlichen Prozessoren 315 ist in 3 durch gestrichelte Linien dargestellt. Jeder Prozessor 310, 315 kann einen oder mehrere der hierin beschriebenen Prozessorkerne umfassen und kann eine Version des Prozessors 200 sein.
  • Der Speicher 340 kann zum Beispiel ein dynamischer Direktzugriffsspeicher (DRAM für engl. dynamic random access memory), ein Phasenwechselspeicher (PCM für engl. phase change memory) oder eine Kombination der beiden sein. Für mindestens eine Ausführungsform kommuniziert der Steuerhub 320 mit dem/den Prozessor(en) 310, 315 über einen Mehrpunktbus, wie beispielsweise einem Frontside-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle, wie beispielsweise eine QuickPath Interconnect (QPI), oder eine ähnliche Verbindung 395.
  • In einer Ausführungsform ist der Coprozessor 345 ein Spezialprozessor, wie beispielsweise ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann der Steuerhub 320 einen integrierten Grafikbeschleuniger umfassen.
  • Es kann eine Vielzahl von Unterschieden zwischen den physikalischen Ressourcen 310, 315 in Bezug auf ein Spektrum von Bewertungsmetriken geben, die architektonische, mikroarchitektonische, thermische und Leistungsverbrauchscharakteristiken und dergleichen umfassen.
  • In einer Ausführungsform führt der Prozessor 310 Anweisungen aus, welche Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In die Anweisungen können Coprozessoranweisungen eingebettet sein. Der Prozessor 310 erkennt diese Coprozessoranweisungen als einen Typ, der vom angeschlossenen Coprozessor 345 ausgeführt werden sollte. Demgemäß gibt der Prozessor 310 diese Coprozessoranweisungen (oder Steuersignale, welche die Coprozessoranweisungen darstellen) auf einem Coprozessorbus oder einer anderen Zwischenverbindung an den Coprozessor 345 aus. Der oder die Coprozessor(en) 345 nehmen die empfangenen Coprozessoranweisungen an und führen sie aus.
  • Nunmehr unter Bezugnahme auf 4 ist ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems 400 gemäß einer Ausführungsform der vorliegenden Erfindung dargestellt. Wie in 4 dargestellt, ist das Multiprozessorsystem 400 ist ein Punkt-zu-Punkt-Zwischenverbindungssystem 470 und umfasst einen ersten Prozessor 1170 und einen zweiten Prozessor 480, die über eine Punkt-zu-Punkt-Zwischenverbindung 450 gekoppelt sind. Jeder der Prozessoren 470 und 480 können eine Version des Prozessors 200 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 470 und 480 Prozessoren 310 bzw. 315, während ein Coprozessor 438 ein Coprozessor 345 ist. In einer Ausführungsform sind die Prozessoren 470 und 480 ein Prozessor 310 bzw. ein Coprozessor 345.
  • Die Prozessoren 470 und 480 sind so dargestellt, dass sie integrierte Speichersteuer(IMC für engl. integrated memory controller)-Einheiten 472 bzw. 482 aufweisen. Der Prozessor 470 umfasst außerdem als Teil seiner Bussteuereinheiten Punkt-zu-Punkt(P-P)-Schnittstellen 476 und 478; ähnlich umfasst der zweite Prozessor 480 P-P-Schnittstellen 486 und 488. Die Prozessoren 470, 480 können über eine Punkt-zu-Punkt(P-P)-Schnittstelle 450 unter Verwendung von P-P-Schnittstellenschaltungen 478, 488 Informationen austauschen. Wie in 4 dargestellt, koppeln die IMCs 472 und 482 die Prozessoren mit jeweiligen Speichern, nämlich mit einem Speicher 432 und einem Speicher 434, welche Abschnitte eines Hauptspeichers sein können, der lokal an die jeweiligen Prozessoren angeschlossen ist.
  • Die Prozessoren 470, 480 können jeweils über individuelle P-P-Schnittstellen P-P 452, 454 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 476, 494, 486, 498 Informationen mit einem Chipsatz 490 austauschen. Der Chipsatz 490 kann optional über eine Hochleistungsschnittstelle 439 Informationen mit dem Coprozessor 438 austauschen. In einer Ausführungsform ist der Coprozessor 438 ein Spezialprozessor, wie beispielsweise ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.
  • Ein gemeinsam benutzter Cache (nicht dargestellt) kann in jedem Prozessor enthalten oder außerhalb von beiden Prozessoren, aber dennoch über eine P-P-Zwischenverbindung mit den Prozessoren verbunden sein, derart dass Informationen des lokalen Caches eines oder beider Prozessoren im gemeinsam benutzten Cache gespeichert werden können, wenn ein Prozessor in einen Stromsparmodus versetzt wird.
  • Der Chipsatz 490 kann über eine Schnittstelle 496 mit einem ersten Bus 416 gekoppelt sein. In einer Ausführungsform kann der erste Bus 416 ein Bus zur Verbindung von Peripheriekomponenten (PCI für engl. Peripheral Component Interconnect) oder solch ein Bus wie beispielsweise ein PCI Express-Bus oder ein anderer E-/A-Zwischenverbindungsbus der dritten Generation sein, obwohl der Schutzbereich der vorliegenden Erfindung nicht darauf beschränkt ist.
  • Wie in 4 dargestellt, können verschiedene E-/A-Einrichtungen 414 mit dem ersten Bus 416 zusammen mit einer Busbrücke 418 gekoppelt sein, welche den ersten Bus 416 mit einem zweiten Bus 420 koppelt. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessor(en) 415, wie beispielsweise Coprozessoren, MIC-Prozessoren mit hohem Durchsatz, GPGPUs, Beschleuniger(wie etwa z. B. Grafikbeschleuniger oder Digitalsignalverarbeitungs (DSP)-Einheiten), feldprogrammierbare Gate-Arrays oder jeglicher andere Prozessor mit dem ersten Bus 416 gekoppelt. In einer Ausführungsform kann der zweite Bus 420 ein Bus mit geringer Anschlusszahl (LPC für engl. low pin count) sein. Verschiedene Einrichtungen können an einen zweiten Bus 420 angeschlossen sein, die in einer Ausführungsform zum Beispiel eine Tastatur und/oder eine Maus 422, Kommunikationseinrichtungen 427 und eine Speichereinheit 428, wie beispielsweise ein Plattenlaufwerk oder eine Massenspeichereinrichtung, umfassen, die Anweisungen/Code und Daten 430 enthalten kann. Ferner kann Audio-E/-A 424 mit dem zweiten Bus 420 gekoppelt sein. Es ist zu erwähnen, dass auch eine andere Architektur möglich ist. Zum Beispiel kann ein System anstelle der Punkt-zu-Punkt-Architektur von 4 eine Mehrpunktbus- oder andere derartige Architektur implementieren.
  • Nunmehr unter Bezugnahme auf 5 ist ein Blockdiagramm eines zweiten, spezifischeren beispielhaften Systems 500 gemäß einer Ausführungsform der vorliegenden Erfindung dargestellt. Gleiche Elemente in 4 und 5 tragen gleiche Bezugszeichen, und bestimmte Aspekte von 4 wurden in 5 weggelassen, um ein Verkomplizieren anderer Aspekte von 5 zu vermeiden.
  • 5 veranschaulicht, dass die Prozessoren 470, 480 integrierte Speicher und E-/A-Steuerlogik („CL” für engl. control logic) 472 bzw. 482 umfassen können. Demnach umfasst die CL 472, 482 integrierte Speichersteuereinheiten und E-/A-Steuerlogik. 5 veranschaulicht, dass nicht nur die Speicher 432, 434 mit der CL 472, 482 gekoppelt sind, sondern dass auch E-/A-Einrichtungen 514 mit der Steuerlogik 472, 482 gekoppelt sind. Ältere E-/A-Einrichtungen 515 sind mit dem Chipsatz 490 gekoppelt.
  • Nunmehr unter Bezugnahme auf 6 ist ein Blockdiagramm eines Systemchips (SoC für engl. system an a chip) 600 gemäß einer Ausführungsform der vorliegenden Erfindung dargestellt. Ähnliche Elemente in 2 tragen gleiche Bezugszeichen. Außerdem sind Kästchen mit gestrichelten Linien optionale Funktionen auf weiterentwickelten SoCs. In 6 sind eine oder mehrere Zwischenverbindungseinheiten 602 mit Folgendem gekoppelt: einem Anwendungsprozessor 610, der einen Satz von einem oder mehreren Kernen 202A–N und einer oder mehreren gemeinsam benutzte Cache-Einheit(en) 206 umfasst; einer Systemagenteneinheit 210; Bussteuereinheit(en) 216; integrierten Speichersteuereinheit(en) 214; einem Satz von oder einem oder mehreren Coprozessoren 620, welche integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor umfassen können; einer statischen Direktzugriffsspeicher(SRAM für engl. static random access memory)-Einheit 630; einer Speicherdirektzugriffs(DMA für engl. direct memory access)-Einheit 632; und einer Anzeigeeinheit 640 zur Kopplung mit einer oder mehreren externen Anzeigen. In einer Ausführungsform umfasst/umfassen der/die Coprozessor(en) 620 einen Spezialprozessor, wie beispielsweise einen Netzwerk- oder Kommunikationsprozessor, eine Kompressionsmaschine, eine GPGPU, einen MIC-Prozessor mit hohem Durchsatz, einen eingebetteten Prozessor oder dergleichen.
  • Ausführungsformen der hierin offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination solcher Implementierungslösungen implementiert sein. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert sein, die auf programmierbaren Systemen ausgeführt werden, die mindestens einen Prozessor, ein Speichersystem (das flüchtige und nichtflüchtige Speicher und/oder Speicherelemente umfasst), mindestens eine Eingabeeinrichtung und mindestens eine Ausgabeeinrichtung umfassen.
  • Programmcode, wie beispielsweise der in 4 veranschaulichte Code 430, kann auf Eingabeanweisungen angewendet werden, um die hierin beschriebenen Funktionen auszuführen und Ausgabeinformationen zu generieren. Die Ausgabeinformationen können in bekannter Weise auf eine oder mehrere Ausgabeeinrichtungen angewendet werden. Zum Zwecke dieser Anmeldung umfasst ein Verarbeitungssystem jedes System, das einen Prozessor, wie beispielsweise einen Digitalsignalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC für engl. application specific integrated circuit) oder einen Mikroprozessor, aufweist.
  • Der Programmcode kann in einer verfahrens- oder objektorientierten Programmiersprache implementiert sein, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmiercode kann außerdem in Assembler- oder Maschinensprache implementiert sein, falls gewünscht. Tatsächlich sind die hierin beschriebenen Mechanismen nicht auf eine bestimmte Programmiersprache beschränkt. Auf jeden Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
  • Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentative Anweisungen implementiert sein, die auf einem maschinenlesbaren Medium gespeichert sind, welches diverse Logik innerhalb des Prozessors darstellt, und die, wenn durch eine Maschine ausgelesen, die Maschine veranlassen, Logik zu erstellen, um die hierin beschriebenen Techniken auszuführen. Solche Darstellungen, die als „IP-Kerne” bekannt sind, können auf einem gegenständlichen, maschinenlesbaren Medium gespeichert sein und an verschiedene Kunden oder Produktionsstätten geliefert werden, um sie in die Fertigungsmaschinen zu laden, welche die Logik oder den Prozessor tatsächlich erzeugen.
  • Solche maschinenlesbaren Speichermedien können, ohne darauf beschränkt zu sein, Folgende umfassen: nicht-transitorische, gegenständliche Anordnungen von Gegenständen, die durch eine Maschine oder ein Gerät hergestellt oder ausgebildet sind, einschließlich Speichermedien, wie beispielsweise Festplatten, jeglichen anderen Typs von Platten, einschließlich Disketten, optischer Platten, Compact-Disk-Festwertspeicher (CD-ROMs für engl. compact disk read-only memories), wiederbeschreibbarer Compact-Disks (CD-RWs für engl. compact disk rewritable's) und magnetooptischer Platten, Halbleiterbauelemente wie beispielsweise Festwertspeicher (ROMs für engl. read-only memories), Direktzugriffsspeicher (RAMs für engl. random access memories), wie beispielsweise dynamischer Direktzugriffsspeicher (DRAMs für engl. dynamic random access memories), statischer Direktzugriffsspeicher (SRAMs für engl. static random access memories), löschbarer programmierbarer Festwertspeicher (EPROMs für engl. erasable programmable read-only memories), Flash-Speicher, elektrisch löschbarer programmierbarer Festwertspeicher (EEPROMs für engl. electrically erasable programmable read-only memories), Phasenwechselspeicher (PCM für engl. phase change memory), magnetischer oder optischer Karten, oder jeden anderen Typs von Medien, die zum Speichern von elektronischen Anweisungen imstande sind.
  • Demgemäß umfassen Ausführungsformen der Erfindung auch nicht-transitorische, gegenständliche maschinenlesbare Medien, welche Anweisungen enthalten oder welche Entwurfsdaten enthalten, wie beispielsweise Hardwarebeschreibungssprache (HDL für engl. Hardware Description Language), welche hierin beschriebene Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemfunktionen definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
  • In einigen Fällen kann ein Anweisungsumsetzer zum Umsetzen einer Anweisung von einem Quellenanweisungssatz in einen Zielanweisungssatz verwendet werden. Zum Beispiel kann der Anweisungsumsetzer eine Anweisung in einen oder mehrere durch den Kern zu verarbeitende Anweisungen übersetzen (z. B. unter Verwendung von statischer Binärübersetzung, dynamischer Binärübersetzung, einschließlich dynamischer Kompilierung), morphen, emulieren oder anderweitig umsetzen. Der Anweisungsumsetzer kann in Software, Hardware, Firmware oder einer Kombination davon implementiert sein. Der Anweisungsumsetzer kann prozessorintern, prozessorextern oder teilweise prozessorintern und teilweise prozessorextern sein.
  • 7 ist ein Blockdiagramm, das die Verwendung eines Softwareanweisungsumsetzers zum Umsetzen von Binäranweisungen in einem Quellenanweisungssatz in Binäranweisungen in einem Zielanweisungssatz gemäß Ausführungsformen der Erfindung vergleicht. In der veranschaulichten Ausführungsform ist der Anweisungsumsetzer ein Softwareanweisungsumsetzer, obwohl der Anweisungsumsetzer alternativ in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 7 stellt ein Programm in einer höheren Programmiersprache 702 dar, die unter Verwendung eines x86-Compilers 704 kompiliert werden kann, um x86-Binärcode 706 zu generieren, der durch einen Prozessor mit mindestens einem x86-Anweisungssatzkern 716 nativ ausgeführt werden kann. Der Prozessor mit mindestens einen x86-Anweisungssatzkern 716 stellt jeden Prozessor dar, der im Wesentlichen die gleichen Funktionen wie ein Intel Prozessor mit mindestens einem x86-Bfehlssatzkern durch kompatibles Ausführen oder anderweitiges Verarbeiten (1) eines wesentlichen Teils des Anweisungssatzes des Intel x86-Anweisungssatzkerns oder (2) von Objektcodeversionen von Anwendungen oder anderer Software, die auf einem Intel Prozessor mit mindestens einem x86-Anweisungssatzkern ausgeführt werden soll, ausführen kann, um im Wesentlichen das gleiche Ergebnis wie ein Intel Prozessor mit mindestens einem x86-Anweisungssatzkern zu erzielen. Der x86-Compiler 704 stellt einen Compiler dar, der so betrieben werden kann, dass er x86-Binärcode 706 (z. B. Objektcode) generiert, der mit oder ohne zusätzliche Verknüpfungsverarbeitung, auf dem Prozessor mit mindestens einem x86-Anweisungssatzkern 716 ausgeführt werden kann. Ähnlich stellt 7 das Programm in der höheren Programmiersprache 702 dar, die unter Verwendung eines alternativen Anweisungssatz-Compilers 708 kompiliert werden kann, um alternativen Anweisungssatz-Binärcode 710 zu generieren, der durch einen Prozessor ohne mindestens einen x86-Anweisungssatzkern 714 (z. B. einen Prozessor mit Kernen, die den MIPS-Anweisungssatz von MIPS Technologies in Sunnyvale, Kalifornien, ausführen, oder den ARM-Anweisungssatz der ARM Holdings in Sunnyvale, Kalifornien, ausfahren) nativ ausgeführt werden kann. Der Anweisungsumsetzer 712 wird zum Umsetzen des x86-Binärcodes 1406 in Code verwendet, der durch den Prozessor ohne x86-Anweisungssatzkern 714 nativ ausgeführt werden kann. Dieser umgesetzte Code ist wahrscheinlich nicht der gleiche wie der alternative Anweisungssatz-Binärcode 710, da ein Anweisungsumsetzer, der dazu imstande ist, schwer herzustellen ist; der umgesetzte Code führt jedoch die allgemeine Operation aus und besteht aus Anweisungen aus dem alternativen Anweisungssatz. Demnach stellt der Anweisungsumsetzer 712 Software, Firmware, Hardware oder eine Kombination davon dar, die durch Emulation, Simulation oder einen beliebigen anderen Prozess einen Prozessor oder eine andere elektronische Einrichtung ermöglicht, der/die keinen x86-Anweisungssatzprozessor oder -kern zum Ausführen des x86-Binärcodes 706 aufweist.
  • Vorrichtung und Verfahren zum effektiven Aufrufen von Beschleunigern
  • Eine Ausführungsform der Erfindung stellt eine generische, erweiterbare Anweisung zum Aufruf mit geringer Latenz von synchronen (z. B. Festfunktions- oder programmierbaren) Beschleunigern (z. B. Coprozessoren, Funktionseinheiten) bereit, die hierin als „XCALL”-Anweisung bezeichnet wird. In einer Ausführungsform ist die Anweisung eine x86-Anweisung.
  • Die der Erfindung zugrunde liegenden Prinzipien sind jedoch auf keine bestimmte Anweisungssatzarchitektur (ISA) beschränkt.
  • Das Anweisungsformat gemäß einer Ausführungsform ist XCALL result-register, command-register, param-register, und es identifiziert ein Ergebnisregister zum Speichern von Ergebnissen nach der Ausführung der Anweisung, ein Befehlsregister zum Speichern des spezifischen Befehls, der durch einen Beschleuniger in Reaktion auf die Anweisung ausgeführt werden soll, und von damit assoziierten Informationen bzw. ein Parameterregister zum Speichern von Parametern, die mit der aufgerufenen Anweisung assoziiert sind. Die spezifischen Informationen, die in jedem Register gemäß einer Ausführungsform der Erfindung gespeichert werden, werden im Folgenden dargelegt.
  • 8A veranschaulicht eine Ablaufübersicht, in welcher ein oder mehrere Prozessorcluster 804 Universalverarbeitungsoperationen ausführen und ein oder mehrere Beschleunigercluster 801 beschleunigerspezifische Operationen ausführen. Als Beispiel kann der Universalprozessorcluster 804 Ausführungslogik innerhalb eines Prozessorkerns zum Ausführen von Anweisungen (z. B. Universalanweisungen, wie beispielsweise x86-Anweisungen) umfassen, welche Anweisungen umfassen, die Befehle in den Beschleunigerclustern 801 aufrufen. In einer Ausführungsform sind die Beschleuniger des Beschleunigerclusters 801 Coprozessoren oder Funktionseinheiten zum Ausführen von speziellen Datenverarbeitungsoperationen (z. B. Vektor-/SIMD-Operationen, Grafikoperationen, Sortier- und Schleifenoperation usw.). Die der Erfindung zugrunde liegenden Prinzipien sind jedoch auf keinen bestimmten Typ von Universalkernen oder Beschleunigerkernen beschränkt.
  • Die Prozessorcluster 804 und die Beschleunigercluster 801 können logische Einheiten innerhalb des gleichen Prozessorchips oder -kerns sein. Alternativ können die Prozessorcluster 804 auf einem Chip sein, und die Beschleunigercluster 801 können auf einem anderen Chip sein (entweder im gleichen Halbleitergehäuse oder in verschiedenen Gehäusen), und sie können über einen Kommunikationsbus (z. B. etwa einen PCI Express-, einen Direct Media Interface(DMS)- oder einen anderen Typ von Kommunikationsbus) verbunden sein. In noch einer anderen Ausführungsform können einige der Beschleunigercluster 801 auf dem gleichen Chip oder Kern wie die Prozessorcluster 804 sein, während andere Beschleunigercluster 801 auf einem anderen Chip oder Kern sein können. Die hierin beschriebenen Ausführungsformen der Erfindung sind weder auf bestimmte Chip-/Gehäusekonfigurationen noch Unterstützungsimplementierungen mit mehreren verschiedenen Typen von Beschleunigerclustern beschränkt.
  • Wie in 8A veranschaulicht, ist ein Satz von Registern 830 vorgesehen, um die Kommunikation von Befehlen, Parametern und Ergebnissen zwischen den Universalprozessorclustern 804 und den Beschleunigerclustern 801 zu ermöglichen, wie hierin beschrieben. Insbesondere umfasst der Registersatz 830 in einer Ausführungsform die Befehlsregister, Ergebnisregister und Parameterregister, die durch die XCALL-Anweisung spezifiziert werden. Beim Registersatz 830 kann es sich um Universalregister (GPRs für engl. general purpose registers) handeln, die für die im Folgenden spezifizierten Zwecke (z. B. Speichern von Befehlen, Parameterdaten und Ergebnisdaten in Reaktion auf die Ausführung einer XCALL-Anweisung) verwendet werden. In einer alternativen Ausführungsform sind sie dedizierte, anwendungsspezifische Register.
  • In einer Ausführungsform führen die Cluster Programmcode 806–807, 809–810 aus, der eine XCALL-Anweisung umfasst und bewirken kann, dass ein oder mehrere Beschleuniger aufgerufen werden 808. In Reaktion werden Steuerinformationen, die eine auszuführende Operation spezifizieren, für den Beschleuniger 801 über ein Befehlsregister (im Folgenden in Bezug auf 8B beschrieben) und/oder ein Parameterregister innerhalb des Registersatzes 830 bereitgestellt. In Reaktion kann der Beschleuniger eine oder mehrere Einheiten mit fester Funktion 802 und/oder Einheiten mit programmierbaren Funktionen 803 zum Ausführen des Befehls verwenden. Alternativ kann der Beschleunigercluster 801 mit einer Beschäftigt-Anzeige, einer Ausnahme oder einem Verstoß reagieren. Die Ergebnisse werden dann über ein Ergebnisregister innerhalb des Registersatzes 830 (im Folgenden in Bezug auf 8C beschrieben) für die Prozessorcluster 804 bereitgestellt. Wenn der Befehl erfolgreich ausgeführt wurde, können die resultierenden Daten im Ergebnisregister gespeichert werden. Wenn der Befehl dagegen nicht erfolgreich ausgeführt wurde, dann können Daten, welche den Grund für den Misserfolg angeben, im Ergebnisregister gespeichert (und zum Beispiel zum Bestimmen, ob die Ausführung des Befehls erneut versucht werden soll, verwendet) werden.
  • Wie in 8A angezeigt, können ein oder mehrere Handler 805, 806 in den Prozessorclustern ausgeführt werden. In einer Ausführungsform können Unterbrechungen, die durch einen Handler verursacht werden, einen Aufruf der Beschleunigungscluster herbeiführen, wie veranschaulicht.
  • 8B veranschaulicht eine Ausführungsform einer Befehlsregisterstruktur. Wie dargestellt, enthalten die obersten 16 Bits des Befehlsregisters (identifiziert als Feld 811 bis 815) die folgenden Datenfelder, die mit der spezifizierten Anzahl von Bits codiert sind:
    Reserviert 811: 2 Bit
    Weiter 812: 1 Bit
    Tickle 813: 1 Bit
    Privat 814: 1 Bit
    ID 815: 11 Bit
  • In einer Ausführungsform identifiziert die ID den aufzurufenden Beschleuniger eindeutig. Wie bereits erwähnt, können zum Beispiel mehrere Beschleuniger innerhalb des Beschleunigerclusters 801 enthalten sein, und jeder dieser Beschleuniger kann durch einen Beschleuniger-ID-Code eindeutig identifiziert werden.
  • In einer Ausführungsform zeigt das „Privat”-Bit an, ob der Beschleuniger zu einer bestimmten Gruppe von bekannten Beschleunigern gehört. Wenn das Privat-Bit zum Beispiel auf 0 gesetzt ist, kann die ID einen eines allgemeinen Satzes von Beschleunigern (wie durch den Abtretungsempfänger der vorliegenden Patentanmeldung definiert) derart identifizieren, dass sich die gleiche ID über alle Computersysteme/Prozessoren auf den gleichen Beschleuniger bezieht. Wenn das Privat-Bit auf 1 gesetzt ist, identifiziert die ID einen proprietären oder lagermengeneinheits(SKU für engl. stock-keeping unit)-spezifischen Beschleuniger. Demnach kann sich die gleiche ID bei auf 1 gesetztem Privat-Bit auf verschiedene Beschleuniger in verschiedenen Systemen beziehen.
  • In einer Ausführungsform enthalten die unteren 48 Bits des Befehlsregisters (in 8B als Feld 816 identifiziert) und alle des Parameterregisters (nicht dargestellt) anwendungsspezifische Daten, die durch den spezifischen aufgerufenen Beschleuniger definiert sind.
  • In einer Ausführungsform setzt die XCALL-Anweisung das Z-Bit in einem EFLAGS bei Ausmusterung wie folgt. Wie Fachleute wissen, ist EFLAGS ein Statusregister in x86-Implementierungen, das den aktuellen Zustand des Prozessors enthält. Das Z-Bit wird auf 1 gesetzt, wenn der XCALL die Ausführung des angeforderten Beschleunigers abgeschlossen hat. Wenn in diesem Fall das Tickle-Bit auf 1 gesetzt war, wird das Ergebnisregister nicht modifiziert, und es wird keine tatsächliche Arbeit ausgeführt. Wenn das Tickle-Bit auf 0 gesetzt war, wird das Ergebnisregister auf einen beschleunigerspezifischen Wert gesetzt. Das Z-Bit wird auf 0 gesetzt, wenn der XCALL keine Arbeit ausgeführt hat. Obwohl das Z-Bit in dieser Ausführungsform verwendet wird, um anzuzeigen, ob die XCALL-Anweisung erfolgreich war, kann ein anderes Bit gesetzt werden, während dennoch die der Erfindung zugrunde liegenden Prinzipien erfüllt werden.
  • In einer Ausführungsform, die in 8C veranschaulicht ist, enthält das Ergebnisregister die folgenden Datenfelder:
    Reserviert 817: 2 Bit (in einer Ausführungsform immer auf null gesetzt)
    Permanent 818: 1 Bit
    Privat 819: 1 Bit
    Fehlerdetails 820: 60 Bit
  • In einer Ausführungsform wird das Permanent-Bit 818 verwendet, um anzuzeigen, ob ein anschließender Aufruf für den gleichen XCALL erfolgreich sein wird. Zum Beispiel zeigt das auf 0 gesetzte Permanent-Bit, an, dass ein zukünftiger Aufruf des gleichen XCALL erfolgreich sein kann (wenn z. B. der Beschleuniger mit der Versorgung eines anderen HW-Threads beschäftigt war). Wenn es dagegen keinen Punkt eines erneuten Versuchens des gleichen XCALL gibt (wenn z. B. der spezifizierte Beschleuniger in der aktuellen SKU nicht vorhanden ist, oder wenn die angeforderte spezifische Befehls- und/oder Parameterkombination vom Beschleuniger in dieser SKU nicht unterstützt wird), dann wird das Permanent-Bit auf 1 gesetzt.
  • In einer Ausführungsform werden die unteren 60 Bits des Ergebnisregisters so gesetzt, dass sie zusätzliche Daten über den Grund für den XCALL-Misserfolg bereitstellen. In einer Ausführungsform stellt der Beschleunigercluster 801 die Informationen bereit, die zum Aktualisieren des Ergebnisregisters benötigt werden, wie zuvor beschrieben.
  • Wenn in einer Ausführungsform das Privat-Bit des Ergebnisregisters 819 auf 1 gesetzt ist, haben diese Details ein beschleunigerspezifisches Format. Wenn das Privat-Bit auf 0 gesetzt ist, werden diese Details in einem vorbestimmten, allgemeinen Format bereitgestellt (wie z. B. einem Format, das durch den Abtretungsempfänger der vorliegenden Patentanmeldung spezifiziert wird). Beispielhafte Fehlerergebniscodes, die in einer Ausführungsform eingesetzt werden, umfassen:
    Reserviert-Bits im Befehlsregister, wenn nicht 0
    Beschleuniger ist nicht vorhanden
    Beschleuniger ist mit Versorgung eines anderen Threads beschäftigt
  • Das in 9A bis 9C dargelegte Flussdiagramm veranschaulicht die Operationen, die von einer Ausführungsform der Erfindung ausgeführt werden. Bei 901 wird eine XCALL-Anweisung decodiert. Als Ergebnis werden bei 902 Daten in Bezug auf den Befehl, der von einem Beschleuniger ausgeführt werden soll, an das Befehlsregister gesendet, und alle notwendigen Parameter werden an das Parameterregister gesendet. Bei 903 wird das Privat-Bit im Befehlsregister in Abhängigkeit davon gesetzt, ob der Beschleuniger zu einer bekannten Gruppe von Beschleunigern oder einem proprietären Beschleuniger gehört (wie zuvor beschrieben). Außerdem wird bei 903 ein ID-Code im Befehlsregister aktualisiert, um den spezifischen Beschleuniger zu identifizieren, der den Befehl ausführen wird.
  • Bei 904 empfängt der identifizierte Beschleuniger den durch die XCALL-Anweisung spezifizierten Befehl und bestimmt, ob er ausgeführt werden kann. Zum Beispiel kann der Beschleuniger gegenwärtig mit der Versorgung eines anderen Hardwarethreads beschäftigt und daher möglicherweise nicht in der Lage sein, den aktuellen Befehl auszuführen. Wenn außerdem die angeforderte aktuelle Befehls- und/oder Parameterkombination vom Beschleuniger nicht unterstützt wird, dann ist der Beschleuniger nicht imstande, den Befehl erfolgreich auszuführen. Alternativ kann der Beschleuniger den Befehl bei 904 erfolgreich ausführen.
  • Wenn der Befehl erfolgreich ausgeführt wird, dann geht der Prozess zu 9B weiter, wo bei 906 das Z-Bit im EFLAGS gleich 0 gesetzt wird, um die erfolgreiche Ausführung des Befehls anzuzeigen (wie zuvor erörtert). Wenn das Tickle-Bit des Befehlsregisters zuvor auf 1 gesetzt wurde (z. B. bei Operation 902 in 9A), wie bei 907 bestimmt, dann wird das Ergebnisregister bei 908 unmodifiziert gelassen. Wenn das Tickle-Bit zuvor auf 0 gesetzt wurde, dann wird das Tickle-Bit bei 909 auf einen beschleunigerspezifischen Wert gesetzt.
  • Wenn der durch die XCALL-Anweisung spezifizierte Befehl vom Beschleuniger nicht erfolgreich ausgeführt wurde (wie bei 905 in 9A bestimmt), dann wird bei 910 in 9C das Z-Bit von EFLAGS gleich 1 gesetzt (um das Misslingen der Ausführung des Befehls anzuzeigen). Wenn erwartet wird, dass ein zukünftiger Versuch, die XCALL-Anweisung auszuführen, erfolgreich sein wird, wie bei 911 bestimmt, dann wird bei 913 das Permanent-Bit des Ergebnisregisters (818 in 8C) auf 0 gesetzt. Zusätzliche Daten, welche den Grund für den Misserfolg spezifizieren, können in den Fehlerdetailfeldern 820 des Ergebnisregisters ebenfalls angegeben werden.
  • Wenn bei 911 erwartet wird, dass ein zukünftiger Versuch, die XCALL-Anweisung auszuführen, erfolglos sein wird, dann wird bei 912 das Permanent-Bit gleich 1 gesetzt (um die Permanenz des Ergebnisses anzuzeigen), und zusätzliche Daten in Bezug auf das Misslingen der Ausführung der XCALL-Anweisung werden im Detailfeld 820 des Ergebnisregisters angegeben. In jedem der vorstehenden Fälle kann das Detailfeld 820 analysiert werden, um die Grundursache des Misserfolgs zu bestimmen und/oder Schritte zum Modifizieren der Anweisungsausführung zu unternehmen.
  • Wie bereits erwähnt, können das Steuerregister und/oder das Parameterregister durch die XCALL-Anweisung modifiziert werden. Außerdem kann ein XCALL, genauso wie ein normaler Aufruf, Stapelbereich innerhalb des Prozessors verbrauchen. In einer Ausführungsform, die eine x86-Architektur verwendet, wird während des XCALL (z. B. bei Überprüfung durch einen Ausnahmehandler) das 64-Bit-Stapelzeigerregister (RSP) aktualisiert, um die Stapelnutzung widerzuspiegeln. Bei Ausmusterung wird das RSP-Register wieder auf seinen Originalwert wiederhergestellt, um die Freigabe des verwendeten Stapelbereichs widerzuspiegeln. Die verwendete Stapelmenge hängt vom spezifischen Beschleuniger in Verwendung ab.
  • Der aufgerufene Beschleuniger kann den Wert von zusätzlichen Registern und/oder Speicherorten während der hierin beschriebenen Operationsfolgen überprüfen und/oder modifizieren. Obwohl die spezifischen Semantiken für verschiedene Beschleuniger verschieden sein können, bleiben die der Erfindung zugrunde liegenden Prinzipien gleich.
  • In einer Ausführungsform sind Beschleuniger so konfiguriert, dass sie den folgenden Satz von Regeln befolgen:
    • (1) Wenn während des XCALL Unterbrechungen und/oder Ausnahmen zugelassen sind, dann wird das Weiter-Bit auf 1 gesetzt, und der XCALL wird neu ausgegeben, sobald der Handler fertig ist und die Ausführung weitergeht.
    • (2) Der Beschleuniger muss bei Vorhandensein von Unterbrechungen und/oder Ausnahmen Fortschritt gewährleisten.
    • (3) Jeder Zustand, der vom Beschleuniger zum Implementieren von Fortschritt bei Vorhandensein von Unterbrechungen und/oder Ausnahmen benötigt wird, kann in dokumentierten beschleunigerspezifischen Ort(en) aktualisiert werden, wobei es sich um eines oder mehrere von (a) den Befehls- und/oder Parameterregistern; (b) anderen Architekturregistern; (c) dem Stapelbereich; (d) zusätzlichen Speicherorten handeln kann. In allen der zuvor genannten Fälle muss solch ein Zustand Sicherungs- und Wiederherstellungsoperationen, wie beispielsweise von einem Kontextwechsel (z. B. XSAVE/Kontextwechsel/XRESTORE), überleben.
    • (4) Ein Beschleuniger kann wählen, einen Aufruf permanent zurückzuweisen, wenn ihm ein „ungültiger” Befehl und/oder „ungültige” Parameterregister (z. B. nicht unterstützte Merkmale, Werte, welche Hardwarebeschränkungen überschreiten usw.) erteilt werden. Wenn ein Beschleuniger jedoch einen Aufruf akzeptiert hat, ist er für das Durchführen der Anforderung und das Bereitstellen von Ergebnissen verantwortlich.
    • (5) Programmierbare Beschleuniger rufen Benutzercode auf, der auf beschleunigerspezifische Arten und Weisen beschränkt sein kann (dargestellt durch eine Einheit mit programmierbaren Funktionen 803 in 8A). Zum Beispiel kann ein „Sortier”-Beschleuniger die Vergleichsfunktion aufrufen, und ein „Schleifen”-Beschleuniger kann den Schleifenrumpf aufrufen. Wenn der Benutzercode die erwarteten Beschränkungen nicht befolgt (d. h. versucht, in den Ring 0 einzutreten, wenn eine ringbasierte hierarchische Schutzdomäne verwendet wird), dann löst der Beschleuniger nach dem üblichen Sichern seines Zustands eine Ausnahme (insbesondere UD) aus.
    • (6) Der Ausnahmehandler kann wählen, (a) den partiell bewerteten Beschleuniger basierend auf dem gesicherten Zustand in nicht beschleunigter Software abzuschließen; (b) die nicht unterstützte Anweisung zu emulieren und den XCALL neu auszugeben (was ein Optimieren des gesicherten Zustands erfordert, damit die nicht unterstütze Operation nicht erneut versucht wird); oder (c) die Ausführung zu beenden. Einfach versuchen, den XCALL ohne jegliche Modifikation neu auszugeben, löst einfach erneut die Ausnahme aus (wie für UD erwartet).
  • Die hierin beschriebenen Ausführungsformen der Erfindung stellen einen standardmäßigen Mechanismus bereit, der in eine Anweisungssatzarchitektur (ISA), wie beispielsweise eine x86-ISA, zum Aufrufen von Beschleunigern integriert werden kann. Im Gegensatz zu Techniken, die im Hintergrund der vorliegenden Patentanmeldung beschrieben wurden, ermöglichen die hierin beschriebenen Beschleunigeraufruftechniken feinkörnige synchrone Beschleuniger mit geringer Latenz, die natürlicherweise möglichst viele (oder wenige) der Kernressourcen, wie beispielsweise Speicherübersetzung, Register, Cache usw., gemeinsam benutzen. Programmierbare XCALL-Beschleuniger ermöglichen es dem Benutzer, normalen x86-Code (z. B. Schleifen und Sortierung), der ein wesentlicher Bestandteil des x86-Hauptprogramms ist und keine separate Toolkette benötigt, zu beschleunigen.
  • Außerdem sind aktuelle Beschleunigerschnittstellen für einen spezifischen Beschleuniger ausgelegt, während hierin beschriebene Ausführungsformen der Erfindung erweiterbar sind und die optimierte Bereitstellung von spezifischen Beschleunigern für spezifische Marktsegmente sowie „allgemeine” Beschleuniger über alle Marktsegmente ermöglichen. Der Beschleunigeraufruf kann mit geringen Latenzen und ohne Datenkopiermehraufwand erfolgen, was es dem Ökosystem solcher Beschleuniger ermöglicht, Funktionalität zu decken, deren Bereitstellung früher unpraktisch war. Es wird außerdem möglich, SKUs mit Beschleunigern für spezifische Märkte (eingebettete Systeme, Bildverarbeitung, HPC-Server usw.) bei Aufrechterhalten der festen Integration in bestehende ISAs, wie beispielsweise x86, maßzuschneidern.
  • Die hierin beschriebene XCALL-Schnittstelle eröffnet außerdem die Möglichkeit, CPUs so zu erweitern, dass sie Funktionalität decken, die früher nicht zugänglich war, ohne die CPU-ISA und -Toolkette (der vom Abtretungsempfänger der vorliegenden Patentanmeldung entwickelten x86-ISA für Prozessoren) zu verlassen. Zum Beispiel können unter Verwendung der hierin beschriebenen Techniken programmierbare Beschleuniger 803, wie beispielsweise programmierbare Schleifenbeschleuniger (SKMD) und Sortierbeschleuniger, sowie Beschleuniger mit fester Funktion 802, wie beispielsweise jene, welche schnelle Fourier-Transformation (FFT), Texturabtastung und verschiedene andere Funktionen ausführen, bereitgestellt werden.
  • Schnelle Fehlerbehandlung von komplexen ISA-Anweisungen
  • Gegenwärtig haben erfolglose Anweisungen keine Möglichkeit, zusätzliche Details über den Misserfolg bereitzustellen, außer durch dedizierte Flagbits und/oder dedizierte Register, die typischerweise in Ausnahmehandlern verwendet werden. Die Ausführungsformen der Erfindung, die im Folgenden beschrieben werden, stellen ein neues „schnelles Fehler”-Verhalten für Anweisungen bereit. Bei diesem neuen Verhalten kann eine Anweisung eine Erfolg-/Misserfolg-Anzeige (z. B. innerhalb eines Flagregisters, wie beispielsweise EFLAGS oder irgendeinem anderen Register) zurücksenden. Außerdem schreibt die Anweisung in einer Ausführungsform bei Erkennung eines Fehlers zusätzliche Fehlerdetails in ein normales Zielregister. Dies ermöglicht es dem Anwendungscode, den Erfolg/Misserfolg der Anweisung zu prüfen und auf bestimmte Fehlermodi zu reagieren, ohne Verarbeitungsressourcen und Zeit zu vergeuden, die aus dem Aufruf eines Ausnahmehandlers oder einem Wechsel zu einer Domäne der unteren Ebene in einem System resultieren würden, das hierarchische Schutzdomänen (z. B. Ring 0) einsetzt.
  • Der vorgeschlagene neue Kompromisspunkt zur Anweisungsfehlerbehandlung ist für eine bestimmte Klasse von Anweisungen ausgewählt, welche sowohl fehleranfällig sind, als auch komplexe Fehlermodi aufweisen, wie beispielsweise die zuvor beschriebene XCALL-Anweisung. Er ist jedoch nicht geeignet für andere Klassen von Operationen, wie beispielsweise Teilung durch Null (DIV), die nicht fehleranfällig sind, oder für fehleranfällige Operationen, wie beispielsweise Sperren, die einen einfachen Fehlermodus aufweisen.
  • Eine Ausführungsform der Erfindung teilt Anweisungen in eine der folgenden Gruppen ein:
    • (1) Immer erfolgreich. Es wird erwartet, dass zum Beispiel jeder Fall einer Anweisung, welche die Werte in zwei Registern hinzufügt, erfolgreich ist. In einer Ausführungsform der Erfindung wird für Anweisungen dieser Kategorie keine Fehlerbehandlung bereitgestellt.
    • (2) Voraussichtlich meistens erfolgreich. Zum Beispiel ist eine Anweisung, welche die in zwei Registern gespeicherten Werte teilt, normalerweise erfolgreich. Sie wird nur infolge eines Dividieren-durch-Null-Fehlers erfolglos sein. In einer Ausführungsform der Erfindung löst diese Klasse von Anweisungen bei Misserfolg einen Ausnahmehandler aus. Der Ausnahmehandler kann dann dedizierte Register prüfen, wie beispielsweise x86-Steuerregister (CR für engl. control register), welche zusätzliche Fehlerinformationen enthalten, um die korrekte Vorgehensweise zu bestimmen (z. B. CR2 für Seitenfehler). Der Ausnahmehandler ist vom normalen Anwendungscode getrennt und hält den Anwendungscode durch die Fehlerbehandlungslogik sauber und unverunreinigt.
    • (3) Voraussichtlich „oft” erfolglos bei einfachem Fehlermodus. In einer Ausführungsform werden für diese Typen von Anweisungen Bit(s) in Flags und/oder Zielregister(n) gesetzt, um einen Fehler anzuzeigen, aber es werden keine Details bereitgestellt. Ein Beispiel ist eine Anweisung, welche versucht, Sperrdaten festzulegen. Für diese einfachen Fehlermodi wickelt der Anwendungscode die Wiederherstellung ausdrücklich selbst (ohne Notwendigkeit eines Ausnahmehandlers) ab.
    • (4) Voraussichtlich „oft” erfolglos bei komplexem Fehlermodus. Für diese Klasse von Anweisungen müssen Verarbeitungssysteme gegenwärtig auf einen Ausnahmehandler zurückgreifen, um auf dedizierte Register zum Prüfen von Fehlerdetails zuzugreifen. Für Anweisungen, die „oft” erfolglos sind und einen komplexe Fehlermodi aufweisen, ermöglichen die Ausführungsformen der Erfindung ein Setzen von Bit(s) in Flags und/oder Zielregister(n), um Fehler anzuzeigen, und außerdem ein Setzen von zusätzlichen Bit(s) in Zielregister(n), um die Details des Fehlers anzuzeigen, was es dem Anwendungscode ermöglicht, die korrekten Maßnahmen zu ergreifen, ohne auf einen Ausnahmehandler zurückzugreifen.
  • Dies reduziert die Fehlerkosten auf ein Minimum (auf Kosten des Prüfenmüssens des Ergebnisses jeder Anweisung). Es ermöglicht der Anwendung außerdem, ihre Fehlerbehandlungslogik trivial auf den aktuellen Kontext zuzuschneiden, statt einen schwer zu ändernden allgemeinen Ausnahmehandler zu verwenden (auf Kosten des ausdrücklichen Aufrufenmüssens dieser Logik bei jedem Aufrufpunkt).
  • Als Beispiel ist dieses Verhalten vorstehend für die XCALL-Anweisung beschrieben. In dem in 9A bis 9C bereitgestellten Beispiel spezifiziert die XCALL-Anweisung einen Befehl, der von einem bestimmten Beschleuniger ausgeführt werden soll. In Reaktion kann der Beschleuniger den Befehl ausführen und die Ergebnisse im Ergebnisregister bereitstellen (das, wie bereits erwähnt, ein Universalregister ist). Alternativ kann der Beschleuniger aus einer Vielzahl von Gründen den Befehl möglicherweise nicht auszuführen und das Ergebnisregister mit den Gründen für den Misserfolg aktualisieren. Zum Beispiel kann der Beschleuniger gegenwärtig mit dem Versorgen eines anderen Hardwarethreads beschäftigt und daher möglicherweise nicht in der Lage sein, den aktuellen Befehl auszuführen. In diesem Fall kann die XCALL-Anweisung zu einem späteren Zeitpunkt erfolgreich ausgeführt werden, wenn der Beschleuniger nicht mehr beschäftigt ist. Entsprechend wird das Permanent-Bit 818 in Reaktion im Ergebnisregister auf die Fehleranzeige auf 0 gesetzt, um anzuzeigen, dass ein zweiter Versuch gemacht werden kann, um die XCALL-Anweisung auszuführen.
  • Wenn dagegen die angeforderte aktuelle Befehls- und/oder Parameterkombination vom Beschleuniger nicht unterstützt wird, dann ist der Beschleuniger nie imstande, den Befehl erfolgreich auszuführen. Entsprechend wird das Permanent-Bit 818 in Reaktion auf die Fehleranzeige im Ergebnisregister auf 1 gesetzt, um anzuzeigen, dass ein zweiter Versuch nicht zu einer erfolgreichen Ausführung der XCALL-Anweisung führen wird.
  • Ein anschließender Programmcode kann dann das Ergebnisregister auslesen, um zu bestimmen, wie er vorgehen soll. Wenn zum Beispiel das Permanent-Bit auf 0 gesetzt ist, kann er erneut versuchen, die XCALL-Anweisung auszuführen, während er, wenn das Permanent-Bit auf 1 gesetzt ist, möglicherweise nicht versucht, die XCALL-Anweisung auszuführen.
  • 10 ist ein Flussdiagramm, das eine Ausführungsform der Erfindung zum Implementieren dieses Betriebsmodus veranschaulicht. Die im Flussdiagramm spezifizierten Operationen können durch Logik innerhalb einer Ausführungseinheit implementiert werden. Bei 1001 wird ein Versuch gemacht, eine erste Anweisung auszuführen, und bei 1002 wird ein Versuch gemacht, eine zweite Anweisung auszuführen. Wenn die erste Anweisung erfolgreich ausgeführt wurde, wie bei 1003, dann bei 1004 bestimmt, wird auch die zweite Anweisung erfolgreich ausgeführt. Die zweite Anweisung kann zum Beispiel auf den Ergebnissen der ersten Anweisung beruhen, die in ein Register geschrieben werden (wie beispielsweise das zuvor erwähnte Ergebnisregister).
  • Wenn die erste Anweisung nicht erfolgreich ausgeführt wurde, dann wird bei 1005 auch die zweite Anweisung nicht ausgeführt. Im Gegensatz zu früheren Implementierungen werden die komplexen Fehlerdetails bei 1006 ohne Aufrufen eines Ausnahmehandlers überprüft, so dass eine Fehlerauswertung durch den Anwendungsprogrammcode durchgeführt werden kann. Insbesondere kann eine anschließende Anweisung ausgeführt werden, um die Ergebnisse aus dem Ergebnisregister auszulesen und zu bestimme, ob ein neuer Versuch gemacht werden sollte, die erste Anweisung auszuführen. Wenn die Ergebnisse des Fehlers anzeigen, dass ein zweiter Versuch nicht funktionieren würde, dann kann der zweite Versuch verhindert werden, wodurch Zeit und Prozessorressourcen gespart werden. Wenn die Ergebnisse anzeigen, dass ein zweiter Versuch erfolgreich sein kann, dann kann ein zweiter Versuch gemacht werden, die erste Anweisung auszuführen. Es versteht sich von selbst, dass, obwohl diese spezifischen Beispiele zur Erleichterung der Erläuterung bereitgestellt werden, die der Erfindung zugrunde liegenden Prinzipien nicht auf diese spezifischen Details beschränkt sind.
  • Demnach werden in den hierin beschriebenen Ausführungsformen der Erfindung normale Zielregister einer Anweisung für zwei Funktionen verwendet; sie bewahren im Falle einer normalen Ausführung das Ergebnis und bei erfolgloser Anweisung die Fehlerdetails. Dies unterscheidet sich von gegenwärtigen Implementierungen, in welchen dedizierte Register für Rechenergebnisse und für Fehlerergebnisse vorhanden sind, und/oder in welchen ein Ausnahmehandler aufgerufen werden muss. Diese Techniken können auf alle Anbieter von programmierbaren Prozessoren (CPUs, DSPs, GPUs, ...) angewendet werden.
  • Die Verwendung einer schnellen Fehlerbehandlung von komplexen Anweisungen eröffnet die Möglichkeit des Implementierens von Anweisungen, wie beispielsweise XCALL, welche sonst schwer als eine effiziente Anweisung zu definieren wären. Prozessoren, die solche effizienten Anweisungen verwenden, realisieren verbesserte Leistung und reduzierte Entwicklungskosten.
  • Aufgabenwechselfähige synchrone HW-Beschleuniger
  • Synchrone Hardwarebeschleuniger müssen im Falle von Ausnahmen Fortschritt gewährleisten; dazu müssen sie ihren Zustand an einem Ort sichern, der Sicherungs- und Wiederherstellungsoperationen überlebt (wie beispielsweise XSAVE/XRESTORE in x86-Architekturen). Eine Ausführungsform der Erfindung ermöglicht diese Operation durch Erweitern des Sicherungs-/Wiederherstellungsbereichs, um neue Hardwarebeschleuniger (wie beispielsweise jene, die zuvor beschrieben und in 8A veranschaulicht wurden) zu unterstützen.
  • Eine Ausführungsform der Erfindung verwendet den Stapelbereich in einem Speicher zum Speichern des Zwischenzustands von synchronen Hardwarebeschleunigern, um ein robustes Ausnahmenmodell zu ermöglichen, das die Abwicklung von Aufgabenwechsel und Kernmigration ohne Aktivierung des Betriebssystems (OS für engl. operating system) umfasst. Insbesondere ermöglichen die Ausführungsformen der Erfindung es Beschleunigern, wie beispielsweise synchronen Hardwarebeschleunigern, ihren Zustand im Speicherstapel zu sichern und ihren Zustand nach verschiedenen Typen von Prozessorereignissen (wie beispielsweise Ausnahmen, die von einem Ausnahmehandler verwaltet werden, wie im Folgenden beschrieben) wiederherzustellen.
  • In einer Ausführungsform wird der Hardwarebeschleunigeraufruf als eine CALL-Anweisung behandelt, in welcher der Beschleuniger einen Bereich auf dem Stapel des Benutzers verbrauchen kann, um seinen Zustand aufrechtzuerhalten. Wenn eine Ausnahme und/oder Unterbrechung den Beschleuniger zum Anhalten zwingt, ist dieser Zustand automatisch beständig und verfügbar, wenn der Beschleuniger nach dem Ausnahmehandler, dem Kontextwechsel und/oder der Kernmigration wieder fortgesetzt wird. Im letzteren Fall kann der Hardwarebeschleuniger, der das Rechnen wieder aufnimmt, ein anderer (mit dem neuen Kern assoziierter) sein. In solch einem Fall kann der neue Kern auf den gesicherten Zustand innerhalb des Stapels (z. B. vom Speicher oder einem gemeinsamen Cache) zugreifen.
  • In einer Ausführungsform wird der synchrone Beschleuniger wie eine Bibliotheksfunktion behandelt, die aufgerufen wird, den Stapel nach dem Aufruf verwendet und dann diesen Abschnitt des Stapels freigibt, wenn fertig (sich wie ein Funktionsaufruf verhaltend). Wenn in einer Ausführungsform der Beschleuniger aufgerufen wird, wird der Stapelzeiger bewegt, um mit den lokalen Variablen des aufgerufenen Beschleunigers zu arbeiten. Wenn der Aufruf abgeschlossen ist, wird der Stapelzeiger an den Platz zurückbewegt, an dem er ursprünglich war, so dass der Aufrufer dort beginnen kann, wo er aufgehört hat, als der Aufruf eintrat. Falls in einer Ausführungsform ein Ausnahmehandler aufgerufen wird, wird der Stapelzeiger des Programms so angepasst, dass er die Stapelnutzung des Beschleunigers widerspiegelt, um dadurch zu gewährleisten, dass der Ausnahmehandler den Sicherungsbereich des Beschleunigers nicht modifiziert.
  • Eine Ausführungsform der Erfindung ist in 11 veranschaulicht, welche einen Hardwarestapel 1150 im Speicher, einen Anwendungshardwarethread 1151 und einen Beschleunigerthread 1152 darstellt. Der konkrete Stapel 1150, der in 11 dargestellt ist, umfasst einen Aufrufer-Stapelbereich 1120 zum Speichern von Daten, die mit der Ausführung des Anwendungshardwarethreads 1151 assoziiert sind; ein Beschleuniger-Sicherungsbereich 1130 zum Speichern von Daten, die mit der Ausführung des Beschleunigerthreads 1152 assoziiert sind; und einen Ausnahmehandler-Stapelbereich 1140 zum Speichern von Daten, die mit der Ausführung eines Ausnahmehandlers 1105 assoziiert sind.
  • In einer Ausführungsform wird während der Ausführung des Anwendungshardwarethreads eine Beschleunigerfunktion aufgerufen. In Reaktion wird der Stapelzeiger so angepasst, dass er auf das obere Ende des Beschleuniger-Sicherungsbereichs 1130 zeigt, und die Einträge im Übersetzungsvorgriffspuffer (TLB), die mit dem Beschleuniger-Sicherungsbereich 1130 assoziiert sind, werden bei 1101 gesperrt. Ein Grund dafür ist, dass es wünschenswert ist, wenn eine Ausnahme eintritt und der Beschleuniger seinen Zustand sichert (sei es auf dem Stapel oder in einem anderen dazu bestimmten Speicherbereich), einen zusätzlichen Seitenfehler zu vermeiden, der die ursprüngliche Ausnahme in eine doppelte verwandeln würde. Eine Möglichkeit, dies zu vermeiden, besteht darin, den TLB-Seiteneintrag (oder die TLB-Seiteneinträge) für den Beschleuniger-Sicherungsbereich 1130 zu sperren, wenn der Beschleuniger zu arbeiten beginnt, um dadurch zu gewährleisten, dass kein solcher Seitenfehler verursacht wird. Das OS kann die Seite noch immer als unverfügbar kennzeichnen, wird aber gezwungen, ihre Entfernung physikalisch bis zum nächsten Kontextwechsel zu verschieben (wenn der Thread überhaupt nicht ausgeführt wird, und der Beschleunigerzustand sicher gesichert ist). Bei Rückkehr vom Kontextwechsel fordert der Beschleuniger die TLB-Seiteneinträge (die auf andere physikalische Orte zeigen können) erneut an, lädt den Zustand und fährt fort. Ein großer Beschleuniger-Sicherungsbereich kann sich über mehrere TLB-Seiten (in Extremfällen über Dutzende von 4-k-Seiten) erstrecken. Die Anzahl von TLB-Einträgen, die gesperrt werden müssen, kann durch Verwenden großer Seiten (z. B. 64-k-Seiten)verringert werden.
  • Bei 1102 führt der Beschleuniger Operationen basierend auf dem Befehl aus, den er ausführt, und bei 1103 stellt er seinen aktuellen Zustand im Beschleuniger-Sicherungsbereich 1130 innerhalb des Stapels 1150 sicher. Dann entsperrt er den TLB 1104 (der bei 1101 gesperrt wurde, um einen zusätzlichen Seitenfehler zu vermeiden, wie zuvor beschrieben). Wie dargestellt, wird ein Ausnahmeereignis erkannt, das an einen Ausnahmehandler 1105 weitergegeben wird, der innerhalb des Anwendungshardwarethreads 1151 ausgeführt wird. Während der Ausführung kann der Ausführungshandler unter Verwendung eines Abschnitts 1140 des Stapels lesen/schreiben (d. h. er verwendet den Ausnahmehandlerstapel 1140 zum Speichern von Zwischenzustandsinformationen während der Bearbeitung des Ausnahmezustands). Sobald der Ausnahmehandler seine Operationen abgeschlossen hat, ermöglicht er die Fortsetzung des Beschleunigerthreads 1152.
  • Bei 1106 sperrt der Beschleuniger den TLB (aus den gleichen Gründen wie zuvor angegeben) erneut, und bei 1107 lädt er den Zustand, der zuvor im Beschleuniger-Sicherungsbereich 1130 gespeichert wurde. Es ist zu erwähnen, dass der Beschleunigerthread 1152 auf dieser Stufe in Wirklichkeit auf einem anderen Kern oder Prozessor als der erste Abschnitt des Beschleunigerthreads (Operationen 1101 bis 1104) ausgeführt werden kann. In solch einem Fall kann er einfach den gesicherten Beschleunigerzustand aus dem Beschleuniger-Sicherungsbereich 1130 laden, der sich physikalisch in einem gemeinsamen Speicher oder Cache befindet. Er schließt dann seinen Ausführungsthread bei 1108 ab, entsperrt den TLB bei 1109 und stellt bei 1110 fertig. Die Steuerung wird dann zum Anwendungshardwarethread 1151 zurückversetzt, was den Stapelzeiger auf das obere Ende des Beschleuniger-Sicherungsbereichs 1130 zurückstellt (d. h. dorthin, wo er aufhörte, als er mit der Ausführung des Beschleunigerthreads 1152 begann).
  • Es versteht sich von selbst, dass verschiedene Modifikationen an den zuvor bereitgestellten spezifischen Details implementiert werden können, während dennoch die der Erfindung zugrunde liegenden Prinzipien erfüllt werden. Zum Beispiel kann in einer Ausführungsform eine spezifische Speicherregion (anstelle des Verwendens des Stapels) für den Beschleuniger bestimmt sein, um seinen Zustand darin zu bewahren. In diesem Fall besteht keine Notwendigkeit, den Stapelzeiger des Programms für den Ausnahmehandler zu modifizieren.
  • In jeder Ausführungsform ermöglichen die hierin beschriebenen Techniken es Beschleunigern, transparent zu arbeiten, wenn der Aufrufthread zwischen (symmetrischen) Kernen migriert wird; der Beschleuniger auf einem Kern sichert seinen Zustand im Speicher und, wenn der Thread auf einem anderen Kern disponiert wird, lädt der Beschleuniger dort die Daten aus dem Speicher (der Effizienz halber z. B. über einen geteilten gemeinsamen Cache). Demnach ermöglichen die hierin beschriebenen Ausführungsformen der Erfindung es einem Beschleuniger, seinen Zustand transparent zu sichern und Fortschritt bei Vorhandensein von Ausnahmen, Kontextwechsel und/oder Kernmigrationen ohne OS-Aktivierung (z. B. ohne Modifizieren von XSAVE/XRESTORE und/oder Hinzufügen von Architekturregistern) zu gewährleisten. Dies wiederum ermöglicht die Verwendung von Beschleunigerformen, die früher die Hinzufügung von neuen Architekturregistern und OS-Aktivierung über modifiziertes XSAVE erforderten. Prozessoren, die solche Beschleuniger verwenden, realisieren verbesserte Leistung und reduzierte Entwicklungskosten.
  • Beispielhafte Anweisungsformate
  • Ausführungsformen der hierin beschriebenen Anweisung(en) können in verschiedenen Formaten verwirklicht sein. Außerdem werden im Folgenden beispielhafte Systeme, Architekturen und Pipelines ausführlich beschrieben. Ausführungsformen der Anweisung(en) können in solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind aber nicht auf jene beschränkt, die beschrieben werden.
  • Ein vektorfreundliches Anweisungsformat ist ein Anweisungsformat, das für Vektoranweisungen geeignet ist (z. B. gibt es bestimmte Felder, die für Vektoroperationen spezifisch sind). Obwohl Ausführungsformen beschrieben werden, in welchen sowohl Vektor- als auch Skalar-Operationen durch das vektorfreundliche Anweisungsformat unterstützt werden, verwenden alternative Ausführungsformen nur Vektoroperationen mit dem vektorfreundlichen Anweisungsformat.
  • 12A und 12B sind Blockdiagramme, die ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulichen; 12A ist ein Blockdiagramm, das ein generisches vektorfreundliches Anweisungsformat und Klasse-A-Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulicht; während 12B ein Blockdiagramm ist, das ein generisches vektorfreundliches Anweisungsformat und Klasse-B-Anweisungsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulicht. Insbesondere ein generisches vektorfreundliches Anweisungsformat 1100, für welches Anweisungsvorlagen der Klasse A und der Klasse B definiert sind, welche beide Anweisungsvorlagen ohne Speicherzugriff 1105 und Anweisungsvorlagen mit Speicherzugriff 1120 umfassen. Der Begriff „generisch” im Kontext des vektorfreundlichen Anweisungsformats bezieht sich darauf, dass das Anweisungsformat an keinen spezifischen Anweisungssatz gebunden ist.
  • Obwohl Ausführungsformen der Erfindung beschrieben werden, in welchen das vektorfreundliche Anweisungsformat Folgendes unterstützt: eine Vektoroperandenlänge (oder -größe) von 64 Byte mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte) oder 64 Bit (8 Byte) (so dass ein 64-Byte-Vektor entweder aus 16 Elementen von Doppelwortgröße oder alternativ 8 Elementen von Quadwortgröße besteht); eine Vektoroperandenlänge (oder -größe) von 64 Byte mit Datenelementbreiten (oder -größen) von 16 Bit (2 Byte) oder 8 Bit (1 Byte); eine Vektoroperandenlänge (oder -größe) von 32 Byte mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte); und eine Vektoroperandenlänge (oder -größe) von 16 Byte mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte); alternative Ausführungsformen können größere, kleinere und/oder andere Vektoroperandengrößen (z. B. Vektoroperanden von 256 Byte) mit größeren, kleineren und/oder anderen Datenelementbreiten (z. B. Datenelementbreiten von 128 Bit (16 Byte)) unterstützen.
  • Die Anweisungsvorlagen der Klasse A in 12A umfassen: 1) innerhalb der Anweisungsvorlagen ohne Speicherzugriff 1105 sind eine Anweisungsvorlage für Vollrundungssteuerungsoperation ohne Speicherzugriff 1110 und eine Anweisungsvorlage für Datenumwandlungsoperation ohne Speicherzugriff 1115 dargestellt; und 2) innerhalb der Anweisungsvorlagen mit Speicherzugriff 1120 sind eine temporale Anweisungsvorlage mit Speicherzugriff 1125 und eine nicht-temporale Anweisungsvorlage mit Speicherzugriff 1130 dargestellt. Die Anweisungsvorlagen der Klasse B in 11B umfassen: 1) innerhalb der Anweisungsvorlagen ohne Speicherzugriff 1105 sind eine Anweisungsvorlage für Schreibmaskensteuerungs- und Teilrundungssteuerungsoperation ohne Speicherzugriff 1112 und eine Anweisungsvorlage für Schreibmaskensteuerungs- und vsize-Operation ohne Speicherzugriff 1117 dargestellt; und 2) innerhalb der Anweisungsvorlagen mit Speicherzugriff 1120 ist eine Anweisungsvorlage für Schreibmaskensteuerung mit Speicherzugriff 1127 dargestellt.
  • Das generische vektorfreundliche Anweisungsformat 1100 umfasst die folgenden Felder, die nachstehend in der in 12A und 12B veranschaulichten Reihenfolge aufgelistet sind.
  • Formatfeld 1140 – ein spezifischer Wert (ein Anweisungsformatkennungswert) in diesem Feld identifiziert das vektorfreundliche Anweisungsformat und demnach die Auftrittshäufigkeiten von Anweisungen im vektorfreundlichen Anweisungsformat in Anweisungsströmen eindeutig. Entsprechend ist dieses Feld insofern optional, als es für einen Anweisungssatz, der nur das generische vektorfreundliche Anweisungsformat aufweist nicht benötigt wird.
  • Basisoperationsfeld 1142 – sein Inhalt unterscheidet verschiedene Basisoperationen.
  • Registerindexfeld 1144 – sein Inhalt spezifiziert direkt oder durch Adressgenerierung die Orte der Quellen- und Zieloperanden, einerlei ob in Registern und in Speicher. Diese umfassen eine ausreichende Anzahl von Bits, um N Register aus einer P × Q(z. B. 32×512, 16×128, 32×1024, 64×1024)-Registerdatei auszuwählen. Obwohl sich N in einer Ausführungsform auf bis zu drei Quellen- und ein Zielregister belaufen kann, können alternative Ausführungsformen mehr oder weniger Quellen- und Zielregister unterstützen (z. B. können sie bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als Ziel fungiert, sie können bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch Ziel fungiert, sie können bis zu zwei Quellen und ein Ziel unterstützen).
  • Modifiziererfeld 1146 – sein Inhalt unterscheidet Auftrittshäufigkeiten von Anweisungen im generischen vektorfreundlichen Anweisungsformat, welche Speicherzugriff spezifizieren, von jenen, die dies nicht tun; das heißt, zwischen Anweisungsvorlagen ohne Speicherzugriff 1105 und Anweisungsvorlagen mit Speicherzugriff 1120. Speicherzugriffsoperationen lesen und/oder schreiben in die Speicherhierarchie (in einigen Fällen unter Angabe der Ursprungs- und Zieladressen, wobei Werte in Registern verwendet werden), während Operationen ohne Speicherzugriff dies nicht tun (z. B. die Quellen und die Ziele Register sind). Obwohl dieses Feld in einer Ausführungsform auch zwischen drei verschiedenen Möglichkeiten zum Durchführen von Speicheradressberechnungen auswählt, können alternative Ausführungsformen mehr, weniger oder andere Möglichkeiten zum Durchführen von Speicheradressberechnungen unterstützen.
  • Erweiterungsoperationsfeld 1150 – sein Inhalt unterscheidet, welche von einer Vielzahl von verschiedenen Operationen zusätzlich zur Basisoperation ausgeführt werden soll. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 1168, ein Alpha-Feld 1152 und ein Beta-Feld 1154 unterteilt. Das Erweiterungsoperationsfeld 1150 ermöglicht die Ausführung von gemeinsamen Gruppen von Operationen in einer einzigen Anweisung statt in 2, 3 oder 4 Anweisungen.
  • Skalierfeld 1160 – sein Inhalt ermöglich die Skalierung des Indexfeldinhalts zur Speicheradressgenerierung (z. B. für eine Adressgenerierung, die 2scale·Index + Basis verwendet).
  • Verschiebungsfeld 1162A – sein Inhalt wird als Teil einer Speicheradressgenerierung verwendet (z. B. für eine Adressgenerierung, die 2scale·Index + Basis + Verschiebung verwendet).
  • Verschiebungsfaktorfeld 1162B (es ist zu erwähnen, dass die Nebeneinanderstellung des Verschiebungsfeldes 1162A direkt über dem Verschiebungsfaktorfeld 1162B anzeigt, dass eines oder das andere verwendet wird) – sein Inhalt wird als Teil der Adressgenerierung verwendet; er spezifiziert einen Verschiebungsfaktor, der um die Größe eines Speicherzugriffs (N) skaliert werden soll – wobei N die Anzahl von Bytes im Speicherzugriff ist (z. B. für Adressgenerierung, die 2scale·Index + Basis + skalierte Verschiebung verwendet). Redundante niederwertige Bits werden ignoriert, und daher wird der Inhalt des Verschiebungsfaktorfeldes mit der Gesamtgröße (N) der Speicheroperanden multipliziert, um die endgültige Verschiebung zu generieren, die beim Berechnen einer effektiven Adresse verwendet werden soll. Der Wert von N wird durch die Prozessorhardware zur Laufzeit basierend auf dem vollständigen Opcode-Feld 11174 (hierin beschrieben) und dem Datenbearbeitungsfeld 1154C bestimmt. Das Verschiebungsfeld 1162A und das Verschiebungsfaktorfeld 1162B sind insofern optional, als sie für die Anweisungsvorlagen ohne Speicherzugriff 1105 nicht verwendet werden und/oder verschiedene Ausführungsformen nur eines oder keines der beiden implementieren können.
  • Datenelementbreitenfeld 1164 – sein Inhalt unterscheidet, welche von einer Anzahl von Datenelementbreiten verwendet werden soll (in einigen Ausführungsformen für alle Anweisungen; in anderen Ausführungsformen nur für einige der Anweisungen). Dieses Feld ist insofern optional, als es nicht benötigt wird, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung eines gewissen Aspekts der Opcodes unterstützt werden.
  • Schreibmaskenfeld 1170 – sein Inhalt kontrolliert auf einer Pro-Datenelementposition-Basis, ob die Datenelementposition im Zielvektoroperanden das Ergebnis der Basisoperation und der Erweiterungsoperation widerspiegelt. Anweisungsvorlagen der Klasse A unterstützen Zusammenführungs-Schreibmaskieren, während Anweisungsvorlagen der Klasse B sowohl Zusammenführungs- als auch Nullsetzungs-Schreibmaskieren unterstützen. Beim Zusammenführen ermöglichen Vektormasken es, jeden Satz von Elementen im Ziel vor Aktualisierungen während der Ausführung jeglicher Operation (spezifiziert durch die Basisoperation und die Erweiterungsoperation) zu schützen; wobei in einer anderen Ausführungsform der alte Wert jedes Elements des Ziels bewahrt wird, wenn das entsprechende Maskenbit eine 0 aufweist. Beim Nullsetzen dagegen ermöglichen Vektormasken es, jeden Satz von Elementen im Ziel vor Aktualisierungen während der Ausführung jeglicher Operation (spezifiziert durch die Basisoperation und die Erweiterungsoperation) auf null zu setzen; in einer Ausführungsform wird ein Elements des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Ein Teilsatz dieser Funktionalität ist die Fähigkeit zum Steuern der Vektorlänge der Operation, die ausgeführt wird (das heißt, die Spanne von Elementen wird vom ersten bis zum letzten modifiziert); es ist jedoch nicht notwendig, dass die Elemente, die modifiziert werden, hintereinander sind. Demnach ermöglicht das Schreibmaskenfeld 1170 partielle Vektoroperationen, die Lade, Speicher-, arithmetische, logische usw. Operationen umfassen. Obwohl Ausführungsformen der Erfindung beschrieben werden, in welchen der Inhalt des Schreibmaskenfeldes 1170 eines von einer Anzahl von Schreibmaskenregistern auswählt, das die Schreibmaske enthält, die verwendet werden soll (und der Inhalt des Schreibmaskenfeldes 1170 daher indirekt identifiziert, dass diese Maskierung durchgeführt werden soll), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Schreibmaskenfeldes 1170 die Maskierung, die ausgeführt werden soll, direkt spezifiziert.
  • Unmittelbares Feld 1172 – sein Inhalt ermöglicht die Spezifizierung einer unmittelbaren Adressierung. Dieses Feld ist insofern optional, als es in einer Implementierung des generischen vektorfreundlichen Formats, das unmittelbare Adressierung nicht unterstützt, nicht vorhanden ist und in Anweisungen, die unmittelbare Adressierung nicht verwenden, nicht vorhanden ist.
  • Klassenfeld 1168 – sein Inhalt unterscheidet zwischen verschiedenen Klassen von Anweisungen. Unter Bezugnahme auf 11A und 11B wählen die Inhalte dieses Feldes zwischen Anweisungen der Klasse A und der Klasse B. In 11A und 11B werden Vierecke mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein spezifischer Wert in einem Feld vorhanden ist (z. B. Klasse A 1168A und Klasse B 1168B für das Klassenfeld 1168 in 11A bzw. 11B).
  • Anweisungsvorlagen der Klasse A
  • Im Falle der Anweisungsvorlagen ohne Speicherzugriff 1105 der Klasse A, wird das Alpha-Feld 1152 als ein RS-Feld 1152A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Erweiterungsoperationstypen durchgeführt werden soll (z. B. werden Rundung 1152A.1 und Datenumwandlung 1152A.2 für die Anweisungsvorlagen für Rundungsoperation ohne Speicherzugriff 1110 bzw. Datenumwandlungsoperation ohne Speicherzugriff 1115 spezifiziert), während das Beta-Feld 1154 unterscheidet, welche der Operationen des spezifizierten Typs ausgeführt werden soll. In den Anweisungsvorlagen ohne Speicherzugriff 1105 sind das Skalierfeld 1160, das Verschiebungsfeld 1162A und das Verschiebungsskalierfeld 1162B nicht vorhanden.
  • Anweisungsvorlagen ohne Speicherzugriff – Vollrundungssteuerungsoperation
  • In der Anweisungsvorlage für Vollrundungssteuerungsoperation ohne Speicherzugriff 1110 wird das Beta-Feld 1154 als ein Rundungssteuerungsfeld 1154A interpretiert, dessen Inhalt(e) statische Rundung bereitstellen. Obwohl in den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerungsfeld 1154A ein Feld Alle-Gleitkomma-Ausnahmenunterdrücken (SAE für engl. suppress all floating point exceptions) und ein Rundungsoperationssteuerungsfeld 1158 umfasst, könne alternative Ausführungsformen beide dieser Konzepte im gleichen Feld unterstützen oder nur eines oder das andere diese Konzepte/Felder aufweisen (z. B. nur das Rundungsoperationssteuerfeld 1158 aufweisen).
  • SAE-Feld 1156 – sein Inhalt unterscheidet, ob die Ausnahmeereignismeldung deaktiviert werden soll oder nicht; wenn der Inhalt des SAE-Feldes 1156 anzeigt, dass Unterdrückung aktiviert ist, dann meldet eine bestimmte Anweisung weder irgendeine Art von Gleitkomma-Ausnahme-Flag, noch löst sie einen Gleitkomma-Ausnahmehandler aus.
  • Rundungsoperationssteuerungsfeld 1158 – sein Inhalt unterscheidet, welche von einer Gruppe von Rundungsoperationen ausgeführt werden soll (z. B. Aufrunden, Abrunden, Runden gegen Null und Runden auf nächste Zahl). Daher ermöglicht das Rundungsoperationssteuerungsfeld 1158 die Änderung des Rundungsmodus auf einer Pro-Anweisung-Basis. In einer Ausführungsform der Erfindung, in welcher ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi umfasst, überschreibt der Inhalt des Rundungsoperationssteuerungsfeldes 1150 diesen Registerwert.
  • Anweisungsvorlagen ohne Speicherzugriff – Datenumwandlungsoperation
  • In der Anweisungsvorlage für Datenumwandlungsoperation ohne Speicherzugriff 1115 wird das Beta-Feld 1154 als ein Datenumwandlungsfeld 1154B interpretiert, dessen Inhalt unterscheidet, welche von einer Anzahl von Datenumwandlungen durchgeführt werden soll (z. B. keine Datenumwandlung, Umordnung, Broadcast).
  • Im Falle einer Anweisungsvorlage mit Speicherzugriff 110 der Klasse A wird das Alpha-Feld 1152 als ein Entfernungshinweisfeld 1152B interpretiert, dessen Inhalt unterscheidet, welcher der Entfernungshinweise verwendet werden soll (in 12A sind temporal 1152B.1 und nicht-temporal 1152B.2 für die temporale Anweisungsvorlage mit Speicherzugriff 1125 bzw. die nicht-temporale Anweisungsvorlage mit Speicherzugriff 1130 spezifiziert), während das Beta-Feld 1154 als ein Datenbearbeitungsfeld 1154C interpretiert wird, dessen Inhalt unterscheidet, welche von einer Anzahl von Datenbearbeitungsoperationen (auch als Primitive bekannt) ausgeführt werden soll (z. B. keine Bearbeitung; Broadcast; Aufwärtsumsetzung einer Quelle; und Abwärtsumsetzung eines Ziels). Die Anweisungsvorlagen mit Speicherzugriff 1120 umfassen das Skalierfeld 1160 und optional das Verschiebungsfeld 1162A oder das Verschiebungsfaktorfeld 1162B.
  • Vektorspeicheranweisungen führen Operationen des Vektorladens und Vektorspeicherns in Speicher mit Umsetzungsunterstützung durch. Wie bei regulären Vektoranweisungen übertragen Vektorspeicheranweisungen Daten datenelementweise aus/in Speicher, wobei die Elemente, die tatsächlich übertragen werden, durch die Inhalte der Vektormaske vorgeschrieben werden, die als die Schreibmaske ausgewählt ist.
  • Anweisungsvorlagen mit Speicherzugriff – Temporal
  • Temporale Daten sind Daten, die wahrscheinlich früh genug wiederverwendet werden, um aus Caching Nutzen zu ziehen. Dies ist jedoch ein Hinweis, und verschiedene Prozessoren können ihn auf verschiedene Art und Weise, einschließlich eines völligen Ignorierens des Hinweises, implementieren.
  • Anweisungsvorlagen mit Speicherzugriff – Nicht-temporal
  • Nicht-temporale Daten sind Daten, die wahrscheinlich nicht früh genug wiederverwendet werden, um aus Caching im Cache der 1. Ebene Nutzen zu ziehen, und denen Entfernungspriorität erteilt werden sollte. Dies ist jedoch ein Hinweis, und verschiedene Prozessoren können ihn auf verschiedene Art und Weise, einschließlich eines völligen Ignorierens des Hinweises, implementieren.
  • Anweisungsvorlagen der Klasse B
  • Im Falle der Anweisungsvorlagen der Klasse B wird das Alpha-Feld 1152 als ein Schreibmaskensteuer(Z)-Feld 1152C interpretiert, dessen Inhalt unterscheidet, ob das Schreibmaskieren, das durch das Schreibmaskenfeld 1170 gesteuert wird, ein Zusammenführen oder ein Nullsetzen sein sollte.
  • Im Falle der Anweisungsvorlagen ohne Speicherzugriff 1105 der Klasse B, wird das Beta-Feld 1154 als ein RL-Feld 1157A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Erweiterungsoperationstypen durchgeführt werden soll (z. B. werden Rundung 1157A.1 und Vektorlänge (VSIZE) 1157A.2 für die Anweisungsvorlage für Schreibmaskensteuerungs- und Teilrundungssteuerungsoperation ohne Speicherzugriff 1112 bzw. die Anweisungsvorlage für Schreibmaskensteuerungs- und VSIZE-Operation ohne Speicherzugriff 1117 spezifiziert), während der Rest des Beta-Feldes 1154 unterscheidet, welche der Operationen des spezifizierten Typs ausgeführt werden soll. In den Anweisungsvorlagen ohne Speicherzugriff 1105 sind das Skalierfeld 1160, das Verschiebungsfeld 1162A und das Verschiebungsfaktorfeld 1162B nicht vorhanden.
  • In der Anweisungsvorlage für Schreibmaskensteuerungs- und Teilrundungssteuerungsoperation ohne Speicherzugriff 1110 wird des Rest des beta-Feldes 1154 als ein Rundungsoperationsfeld 1159A interpretiert, und Ausnahmeereignismeldung ist deaktiviert (ein bestimmte Anweisung meldet weder irgendeine Art von Gleitkomma-Ausnahme-Flag, noch löst sie einen Gleitkoma-Ausnahmehandler aus).
  • Rundungsoperationssteuerungsfeld 1159A – wie beim Rundungsoperationssteuerungsfeld 1158 unterscheidet sein Inhalt, welche von einer Gruppe von Rundungsoperationen ausgeführt werden soll (z. B. Aufrunden, Abrunden, Runden gegen null und Runden auf nächste Zahl). Daher ermöglicht das Rundungsoperationssteuerungsfeld 1159A die Änderung des Rundungsmodus auf einer Pro-Anweisung-Basis. In einer Ausführungsform der Erfindung, in welcher ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi umfasst, überschreibt der Inhalt des Rundungsoperationssteuerungsfeldes 1150 diesen Registerwert.
  • In der Anweisungsvorlage für Schreibmaskensteuerungs- und VSIZE-Operation ohne Speicherzugriff 1117 wird der Rest des Beta-Feldes 1154 als ein Vektorlängenfeld 1159B interpretiert, dessen Inhalt unterscheidet, welche von einer Anzahl von Datenvektorlängen daran durchgeführt werden soll (z. B. 128, 256 oder 512 Byte).
  • Im Falle einer Anweisungsvorlage mit Speicherzugriff 1120 der Klasse B wird ein Teil des Beta-Feldes 1154 als ein Broadcast-Feld 1157B interpretiert, dessen Inhalt unterscheidet, ob die Broadcastdatenbearbeitungsoperation ausgeführt werden soll oder nicht, während der Rest des Beta-Feldes 1154 als das Vektorlängenfeld 1159B interpretiert wird. Die Anweisungsvorlagen mit Speicherzugriff 1120 umfassen das Skalierfeld 1160 und optional das Verschiebungsfeld 1162A oder das Verschiebungsfaktorfeld 1162B.
  • In Bezug auf das generische vektorfreundliche Anweisungsforma 1100 ist ein vollständiges Opcode-Feld 1174 so dargestellt, dass es das Formatfeld 1140, das Basisoperationsfeld 1142 und das Datenelementbreitenfeld 1164 umfasst. Obwohl eine Ausführungsform dargestellt ist, in welcher das vollständige Opcode-Feld 1174 all diese Felder umfasst, umfasst das vollständige Opcode-Feld 1174 in Ausführungsformen, die nicht alle davon unterstützen, weniger als all diese Felder. Das vollständige Opcode-Feld 1174 stellt den Operationscode (Opcode) bereit.
  • Das Erweiterungsoperationsfeld 1150, das Datenelementbreitenfeld 1164 und das Schreibmaskenfeld 1170 ermöglichen die Spezifizierung dieser Merkmale auf einer Pro-Anweisung-Basis im generischen vektorfreundlichen Anweisungsformat.
  • Die Kombination von Schreibmaskenfeld und Datenelementbreitenfeld erzeugt typenorientierte Anweisungen, insofern sie ermöglichen, dass die Maske basierend auf verschiedenen Datenelementbreiten angewendet wird.
  • Die verschiedenen Anweisungsvorlagen, die innerhalb der Klasse A und der Klasse B vorzufinden sind, sind in verschiedenen Situationen vorteilhaft. In einigen Ausführungsformen der Erfindung können verschiedene Prozessoren oder verschiedene Kerne innerhalb eines Prozessors nur Klasse A, nur Klasse B oder beide Klassen unterstützen. Zum Beispiel kann ein für Allzweckberechnung bestimmter Out-of-Order-Hochleistungs-Universalkern nur Klasse B unterstützen, ein in erster Linie für Computergrafik und/oder wissenschaftliches (Durchsatz-)Rechnen bestimmter Kern kann nur Klasse A unterstützen, und ein Kern, der für beides bestimmt ist, kann beide Klassen unterstützen (natürlich fällt ein Kern, der eine bestimmte Mischung von Vorlagen und Anweisungen aus beiden Klassen, aber nicht alle Vorlagen und Anweisungen aus beiden Klassen aufweist, in den Schutzbereich der Erfindung). Außerdem kann ein einzelner Prozessor mehrere Kerne umfassen, von welchen alle die gleiche Klasse unterstützen, oder in welchen verschiedene Kerne eine unterschiedliche Klasse unterstützen. Zum Beispiel kann in einem Prozessor mit separaten Grafik- und Universalkernen einer der Grafikkerne, der in erster Linie für Computergrafik und/oder wissenschaftliches Rechnen bestimmt ist, nur Klasse A unterstützen, während ein oder mehrere der Universalkerne Hochleistungs-Universalkerne ohne Out-of-Order-Ausführung und Registerumbenennung sein können, die für Allzweckberechnung bestimmt sind und nur Klasse B unterstützen. Ein anderer Prozessor, der keinen separaten Grafikkern aufweist, kann einen oder mehrere In-Order- oder Out-of-Order-Universalkerne umfassen, die sowohl Klasse A als auch Klasse B unterstützen. Natürlich können in verschiedenen Ausführungsformen der Erfindung Merkmale aus einer Klasse auch in der anderen Klasse implementiert sein. Programme, die in einer höheren Programmiersprache geschrieben sind, würden in eine Vielzahl von verschiedenen ausfahrbaren Formen versetzt werden, die umfassen: 1) eine Form nur mit Anweisungen der vom Zielprozessor zur Ausführung unterstützen Klasse(n); oder 2) eine Form mit alternativen Routinen, die unter Verwendung von verschiedenen Kombinationen der Anweisungen aller Klassen geschrieben sind und Steuerflusscode aufweisen, der die auszuführenden Routinen basierend auf den Anweisungen auswählt, die vom Prozessor unterstützt werden, der den Code gerade ausführt.
  • 13A ist ein Blockdiagramm, das ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat gemäß Ausführungsformen der Erfindung veranschaulicht. 13A stellt ein spezifisches vektorfreundliches Anweisungsformat 1200 dar, das in dem Sinne spezifisch ist, dass es den Ort, die Größe, die Interpretation und die Reihenfolge der Felder sowie die Werte für einige dieser Felder spezifiziert. Das spezifische vektorfreundliche Anweisungsformat 1200 kann verwendet werden, um den x86-Anweisungssatz zu erweitern, weshalb einige Felder ähnlich oder gleich wie jene sind, die im bestehenden x86-Anweisungssatz und einer Erweiterung davon (z. B. AVX) verwendet werden. Dieses Format bleibt konform mit dem Präfixcodierungsfeld, dem Realer-Opcode-Byte-Feld, dem MOD R/M-Feld, dem SIB-Feld, dem Verschiebungsfeld und den unmittelbaren Feldern des bestehenden x86-Anweisungssatzes mit Erweiterungen. Es sind die Felder von 12 veranschaulicht, in welche die Felder von 13 abgebildet sind.
  • Es versteht sich von selbst, dass, obwohl Ausführungsformen der Erfindung in Bezug auf das spezifische vektorfreundliche Anweisungsformat 1200 im Kontext des generischen vektorfreundlichen Anweisungsformats 1100 zu Veranschaulichungszwecken beschrieben werden, die Erfindung nicht auf das spezifische vektorfreundliche Anweisungsformat 1200 beschränkt ist, außer wo dies beansprucht wird. Zum Beispiel sieht das generische vektorfreundliche Anweisungsformat 1100 eine Vielzahl von möglichen Größen für die verschiedenen Felder vor, während das spezifische vektorfreundliche Anweisungsformat 1200 so dargestellt ist, dass es Felder von spezifischen Größen aufweist. Obwohl als spezifisches Beispiel das Datenelementbreitenfeld 1164 im spezifischen vektorfreundlichen Anweisungssatz 1200 als ein Ein-Bit-Feld veranschaulicht ist, ist die Erfindung nicht darauf beschränkt (das heißt, das generische vektorfreundliche Anweisungsformat 1100 sieht andere Größen des Datenelementbreitenfeldes 1164 vor).
  • Das generische vektorfreundliche Anweisungsformat 1100 umfasst die folgenden Felder, die nachstehend in der in 13A veranschaulichten Reihenfolge aufgelistet sind.
  • EVEX-Präfix (Bytes 0-3) 1202 – ist für eine Vier-Byte-Form codiert.
  • Formatfeld 1140 (EVEX-Byte 0, Bits [7:0]) – das erste Byte (EVEX-Byte 0) ist das Formatfeld und enthält 0×62 (den eindeutigen Wert, der in einer Ausführungsform der Erfindung zum Unterscheiden des vektorfreundlichen Anweisungsformats verwendet wird).
  • Die zweiten vier Bytes (EVEX-Bytes 1-3) umfassen eine Anzahl von Bitfeldern, die eine spezifische Fähigkeit bereitstellen.
  • REX-Feld 1205 (EVEX-Byte 1, Bits [7-5]) – besteht aus einem EVEX.R-Bitfeld (EVEX Byte 1, Bit [7]-R), EVEX.X-Bitfeld (EVEX-Byte 1, Bit [6]-X) und 1157BEX-Byte 1, Bit [5]- B). Die EVEX.R-, EVEX.X- und EVEX.B-Bitfelder stellen die gleiche Funktionalität wie die entsprechenden VEX-Bitfelder bereit und sind unter Verwendung der Einerkomplementform codiert, d. h. ZMM0 ist als 1111B codiert, ZMM15 ist als 0000B codiert. Andere Felder der Anweisungen codieren die unteren drei Bits der Registerindizes so, wie auf dem Fachgebiet bekannt (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Hinzufügen von EVEX.R, EVEX.X und EVEX.B gebildet werden können.
  • REX'-Feld 1110 – dies ist der erste Teil des REX'-Feldes 1110 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4]-R'), das verwendet wird, um entweder die oberen 16 oder die unteren 16 des erweiterten 32er-Registersatzes zu codieren. In einer Ausführungsform der Erfindung wird dieses Bit zusammen mit anderen, wie unten dargelegt, zum Unterscheiden (im allgemein bekannten 32-Bit-Modus von x86) von der BOUND-Anweisung, deren Realer-Opcode-Byte 62 ist, in einem bitinvertierten Format gespeichert, akzeptiert aber im MOD R/M-Feld (nachstehend beschrieben) den Wert von 11 im MOD-Feld nicht; alternative Ausführungsformen speichern dieses und die anderen unten angegebenen Bits nicht im invertierten Format. Zum Codieren der unteren 16 Register wird ein Wert von 1 verwendet. Mit anderen Worten wird R'Rrrr durch Kombinieren von EVEX.R', EVEX.R gebildet, und das andere RRR aus anderen Feldern.
  • Opcode-Abbildungsfeld 1215 (EVEX-Byte 1, Bits [3:0]-mmmm) – sein Inhalt codiert ein implizites führendes Opcode-Byte (0F, 0F 38 oder 0F 3).
  • Datenelementbreitenfeld 1164 (EVEX-Byte 2, Bit [7]-W) – wird durch die Schreibweise EVEX.W dargestellt. EVEX.W wird zum Definieren der Granularität (Größe) des Datentyps verwendet (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente).
  • EVEX.vvvv 1220 (EVEX-Byte 2, Bits [6:3]-vvvv) – die Funktion von EVEX.vvvv kann Folgendes umfassen: 1) EVEX.vvvv codiert den ersten Quellenregisteroperanden, der in invertierter (Einerkomplement-)Form spezifiziert und für Anweisungen mit 2 oder mehr Quellenoperanden gültig ist; 2) EVEX.vvvv codiert den Zielregisteroperanden, der in Einerkomplementform für bestimmte Vektorverschiebungen spezifiziert ist; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Demnach codiert das EVEX.vvvv-Feld 1220 die 4 niederwertigen Bits des ersten Quellenregisterspezifizierers, der in invertierter (Einerkomplement-)Form gespeichert ist. In Abhängigkeit von der Anweisung kann ein zusätzliches, verschiedenes EVEX-Bitfeld zum Erweitern der Spezifizierergröße auf 32er-Register verwendet werden.
  • EVEX.U 1168 Klassenfeld (EVEX-Byte 2, Bit [2]-U) – Wenn EVEX.U = 0, zeigt dies Klasse A oder EVEX.U0 an; wenn EVEX.U = 1, zeigt dies Klasse B oder EVEX.U1 an.
  • Präfixcodierfeld 1225 (EVEX-Byte 2, Bits [1:0]-pp) – stellt zusätzliche Bits für das Basisoperationsfeld bereit. Neben dem Bereitstellen von Unterstützung für die älteren SSE-Anweisungen im EVEX-Präfixformat hat dies außerdem den Vorteil des Kompaktierens des SIMD-Präfixes (statt ein Byte zum Ausdrücken des SIMD-Präfixes zu erfordern, benötigt das EVEX-Präfix nur 2 Bit). Um ältere SSE-Anweisungen, die ein SIMD-Präfix (66H, F2H, F3H) verwenden, sowohl im älteren Format als auch im EVEX-Präfixformat zu unterstützen, sind diese älteren SIMD-Präfixe in einer Ausführungsform in das SIMD-Präfixcodierfeld codiert; und werden zur Laufzeit in das ältere SIMD-Präfix ausgedehnt, bevor sie dem PLA des Decodierers zugeführt werden (so dass das PLA sowohl das ältere als auch das EVEX-Format dieser älteren Anweisungen ohne Modifikation ausführen kann). Obwohl neuere Anweisungen den Inhalt des EVEX-Präfixcodierfeldes direkt als eine Opcode-Erweiterung verwenden könnten, erweitern bestimmte Ausführungsformen der Einheitlichkeit halber auf ähnliche Weise, ermöglichen aber die Spezifizierung anderer Bedeutungen durch diese älteren SIMD-Präfixe. Eine alternative Ausführungsform kann das PLA neu auslegen, um die 2-Bit-SIMD-Präfixcodierungen zu unterstützen, sodass keine Erweiterung erforderlich ist.
  • Alpha-Feld 1152 (EVEX-Byte 3, Bit [7]-EH; auch als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.Schreibmaskensteuerung und EVEX.N bekannt; auch als α veranschaulicht) – wie bereits erwähnt, ist dieses Feld kontextspezifisch.
  • Beta-Feld 1154 (EVEX-Byte 3, Bits [6:4]-SSS, auch als EVEX.s2-0, EVEX.r2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB bekannt; auch als βββ veranschaulicht) – wie bereits erwähnt, ist dieses Feld kontextspezifisch.
  • REX'-Feld 1110 – dies ist der Rest des REX'-Feldes und ist das EVEX.V'-Bitfeld (EVEX-Byte 1, Bit [3]-V'), das verwendet werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32er-Registersatzes zu codieren. Dieses Bit wird im bitinvertierter Format gespeichert. Zum Codieren der unteren 16 Register wird ein Wert von 1 verwendet. Mit anderen Worten wird V'VVVV durch Kombinieren von EVEX.V', EVEX.vvvv gebildet.
  • Schreibmaskenfeld 1170 (EVEX-Byte 3, Bits [2:0]-kkk) – sein Inhalt spezifiziert den Index eines Registers in den Schreibmaskenregistern, wie bereits erwähnt. In einer Ausführungsform weist der spezifische Wert EVEX.kkk = 000 ein spezielles Verhalten auf, das umfasst, dass keine Schreibmaske für die jeweilige Anweisung verwendet wird (dies kann auf eine Vielzahl von Arten und Weisen implementiert werden, welche die Verwendung einer Schreibmaske umfassen, die mit allen Einsen oder Hardware festverdrahtet ist, welche die Maskierungshardware umgeht).
  • Realer-Opcode-Feld 1230 (Byte 4) – ist auch als das Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert.
  • MOD R/M-Feld 1240 (Byte 5) – umfasst das MOD-Feld 1242, das Reg-Feld 1244 und das R/M-Feld 1246. Wie bereits erwähnt, unterscheidet der Inhalt des MOD-Feldes 1242 zwischen Operationen mit Speicherzugriff und ohne Speicherzugriff. Die Funktion des Reg-Feldes 1244 lässt sich auf zwei Situationen zusammenfassen: Codieren entweder des Zielregisteroperanden oder eines Quellenregisteroperanden oder Behandeltwerden als eine Opcode-Erweiterung und Nichtverwendetwerden zum Codieren eines Anweisungsoperanden. Die Funktion des R/M-Feldes kann Folgendes umfassen: Codieren des Anweisungsoperanden, der auf eine Speicheradresse verweist, oder Codieren entweder des Zielregisteroperanden oder eines Quellenregisteroperanden.
  • Skala, Index, Basis (SIB) Byte (Byte 6) – Wie bereits erwähnt, wird der Inhalt des Skalierfeldes 1150 zur Speicheradressgenerierung verwendet. SIB.xxx 1254 und SIB.bbb 1256 – die Inhalte dieser Felder wurden zuvor in Bezug auf die Registerindizes Xxxx und Bbbb erwähnt.
  • Verschiebungsfeld 1162A (Bytes 7-10) – wenn das MOD-Feld 1242 10 enthält, sind die Bytes 7 bis 10 das Verschiebungsfeld 1162A, und es funktioniert gleich wie die ältere 32-Bit-Verschiebung (disp32) und arbeitet bei Byte-Granularität.
  • Verschiebungsfaktorfeld 1162E (Byte 7) – wenn das MOD-Feld 1242 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 1162B. Die Position dieses Feldes ist gleich wie die der 8-Bit-Verschiebung (disp8) des älteren x86-Anweisungssatzes, die bei Byte-Granularität arbeitet. Da disp8 vorzeichenerweitert ist, kann sie nur Offsets zwischen von –128 und 127 Byte adressieren; in Bezug auf 64-Byte-Cachezeilen verwendet disp8 8 Bit, die auf nur vier wirklich brauchbare Werte –128, –64, 0 und 64 gesetzt werden können; da oft ein größerer Bereich benötigt wird, wird disp32 verwendet; disp32 erfordert jedoch 4 Byte. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 1162B eine Neuinterpretation von disp8; bei Verwenden des Verschiebungsfaktorfeldes 1162B wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfeldes multipliziert mit der Größe des Speicheroperandenzugriffs (N) bestimmt. Dieser Typ von Verschiebung wird als disp8·N bezeichnet. Dies reduziert die mittlere Anweisungslänge (ein einziges Byte wird zur Verschiebung verwendet, aber mit einem wesentlichen größeren Bereich). Solch eine komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung ein Vielfaches der Granularität des Speicherzugriffs ist, so dass die redundanten niederwertigen Bits des Adressoffsets nicht codiert zu werden brauchen. Mit anderen Worten ersetzt das Verschiebungsfaktorfeld 1162B die 8-Bit-Verschiebung des älteren x86-Anweisungssatzes. Demnach wird das Verschiebungsfaktorfeld 1162B gleich codiert wie eine 8-Bit-Verschiebung des älteren x86-Anweisungssatzes (daher keine Änderungen der ModRM/SIB-Codierungsregeln) mit der einzigen Ausnahme, dass disp8 zu disp8·N überladen wird. Mit anderen Worten gibt es keine Änderungen an den Codierungsregeln oder Codierungslängen, außer bei der Interpretation des Verschiebungswerts durch Hardware (welche die Verschiebung um die Größe des Speicheroperanden skalieren muss, um einen byteweisen Adressoffset zu erhalten).
  • Unmittelbares Feld 1172 – funktioniert so, wie bereits erwähnt.
  • Vollständiges Opcode-Feld
  • 13B ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 1200 veranschaulicht, welche das vollständige Opcode-Feld 1174 gemäß einer Ausführungsform der Erfindung bilden. Konkret umfasst das vollständige Opcode-Feld 1174 das Formatfeld 1140, das Basisoperationsfeld 1142 und das Datenelementbreiten(W)-Feld 1164. Das Basisoperationsfeld 1142 umfasst das Präfixcodierfeld 1225, das Opcode-Zuordnungsfeld 1215 und das Realer-Opcode-Feld 1230.
  • Registerindexfeld
  • 13C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 1200 veranschaulicht, welches das Registerindexfeld 1144 gemäß einer Ausführungsform der Erfindung bilden. Konkret umfasst das Registerindexfeld 1144 das REX-Feld 1205, das REX'-Feld 1210, das MODR/M.reg-Feld 1244, das MODR/M.r/m-Feld 1246, das VVVV-Feld 1220, xxx-Feld 1254 und das bbb-Feld 1256.
  • Erweiterungsoperationsfeld
  • 13C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 1200 veranschaulicht, welche das Erweiterungsoperationsfeld 1150 gemäß einer Ausführungsform der Erfindung bilden. Wenn das Klassen(U)-Feld 1169 0 enthält, bedeutet dies EVEX.U0 (Klasse A 1168A); wenn es 1 enthält, bedeutet dies EVEX.U1 (Klasse B 1168B). Wenn U = 0 und das MOD-Feld 1242 11 enthält (was eine Operation ohne Speicherzugriff bedeutet), wird das Alpha-Feld 1152 (EVEX-Byte 3, Bit [7]-EH) als das rs-Feld 1152A interpretiert. Wenn das rs-Feld 1152A eine 1 enthält (Rundung 1152A.1), wird das Beta-Feld 1154 (EVEX-Byte 3, Bits [6:4]-SSS) als das Rundungssteuerungsfeld 1154A interpretiert. Das Rundungssteuerungsfeld 1154A umfasst ein Ein-Bit-SAE-Feld 1156 und ein Zwei-Bit-Rundungsoperationsfeld 1158. Wenn das rs-Feld 1152A eine 0 enthält (Datenumwandlung 1152A.2), wird das Beta-Feld 1154 (EVEX-Byte 3, Bits [6:4]-SSS) als ein Drei-Bit-Datenumwandlungsfeld 1154B interpretiert. Wenn U = 0 und das MOD-Feld1242 00, 01 oder 10 enthält (was eine Operation mit Speicherzugriff bedeutet), wird das Alpha-Feld 1152 (EVEX-Byte 3, Bit [7]-EH) als das Entfernungshinweis(EH)-Feld 1152B interpretiert, und das Beta-Feld 1154 (EVEX-Byte 3, Bits [6:4]-SSS) wird als ein Drei-Bit-Datenbearbeitungsfeld 1154C interpretiert.
  • Wenn U = 1, wird das Alpha-Feld 1152 (EVEX-Byte 3, Bit [7]-EH) als das Schreibmaskensteuerungs(Z)-Feld 1152C interpretiert. Wenn U = 1 und das MOD-Feld 1242 11 enthält (was eine Operation ohne Speicherzugriff bedeutet), wird ein Teil des Beta-Feldes 1154 (EVEX-Byte 3, Bit [4]-S0) als das RL-Feld 1157A interpretiert; wenn es eine 1 enthält (Rundung 1157A.1), wird der Rest des Beta-Feldes 1154 (EVEX-Byte 3, Bit [6-5]-S2-1) als das Rundungsoperationsfeld 1159A interpretiert, während, wenn das RL-Feld 1157A eine 0 enthält (VSIZE 1157.A2), der Rest des Beta-Feldes 1154 (EVEX-Byte 3, Bit [6-5]-S2-1) als das Vektorlängenfeld 1159B (EVEX-Byte 3, Bit [6-5]-L1-0) interpretiert wird. Wenn U = 1 und das MOD-Feld 1242 00, 01 oder 10 enthält (was eine Operation mit Speicherzugriff bedeutet), wird das Beta-Feld 1154 (EVEX-Byte 3, Bits [6:4]-SSS) als das Vektorlängenfeld 1159B (EVEX-Byte 3, Bit [6-5]-L1-0) und das Broadcast-Feld 1157B (EVEX-Byte 3, Bit [4]-B) interpretiert.
  • 14 ist Blockdiagramm einer Registerarchitektur 1300 gemäß einer Ausführungsform der vorliegenden Erfindung. In der veranschaulichten Ausführungsform gibt es 32 Vektorregister 1310 mit einer Breite von 512 Bit; diese Register werden zmm0 bis zmm031 bezeichnet. Die niedrigerwertigen 256 Bits der unteren 16 zmm-Register überlagern Registern ymm0 bis ymm16. Die niedrigerwertigen Bits der unteren 16 zmm-Register (die niedrigerwertigen 128 Bits der ymm-Register) überlagern Register xmm0 bis xmm15. Das spezifische vektorfreundliche Anweisungsformat 1200 wirkt auf diese übereinander liegenden Registerdateien, wie in den nachstehenden Tabellen veranschaulicht.
    Anpassbare Vektorlänge Klasse Operationen Register
    Anweisungsvorlagen, die das Vektorlängenfeld 1159B nicht umfassen. A (Figur 12A; U = 0) 1110, 1115, 1125, 1130 zmm-Register (die Vektorlänge beträgt 64 Byte)
    B (Figur 12B; U = 1) 1112 zmm-Register (die Vektorlänge beträgt 64 Byte)
    Anweisungsvorlagen, die das Vektorlängenfeld 1159B nicht umfassen. B (Figur 12B; U = 1) 1117, 1127 zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Byte, 32 Byte oder 16 Byte) abhängig vom Vektorlängenfeld 1159B
  • Mit anderen Worten wählt das Vektorlängenfeld 1159B zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen aus, wobei jede solche kürzere Länge die Hälfte der Länge der vorhergehenden Länge ist; und Anweisungsvorlagen ohne das Vektorlängenfeld 1158B wirken auf die maximale Vektorlänge. Ferner wirken die Anweisungsvorlagen des spezifischen vektorfreundlichen Anweisungsformats 1200 in einer Ausführungsform auf gepackte oder Gleitkomma-Daten mit einfacher/doppelter Genauigkeit und gepackte oder skalare Ganzzahl-Daten. Skalar-Operationen sind Operationen, die an den niedrigstwertigen Datenelementposition in einem zmm-/ymm-/xmm-Register ausgeführt werden; die höherwertigen Datenelementpositionen werden in Abhängigkeit von der Ausführungsform entweder gleich gelassen, wie sie vor der Anweisung waren, oder auf null gesetzt.
  • Schreibmaskenregister 1315 – in der veranschaulichten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), jeweils mit einer Größe von 64 Bit. In einer alternativen Ausführungsform weisen die Schreibmaskenregister 1315 eine Größe von 16 Bit auf. Wie bereits erwähnt, kann das Vektormaskenregister k0 in einer Ausführungsform der Erfindung nicht als Schreibmaske verwendet werden; bei der Codierung, die normalerweise anzeigen würde, dass k0 für eine Schreibmaske verwendet wird, wählt es eine festverdrahtete Schreibmaske von 0xFFFF aus, wodurch Schreibmaskierung für die Anweisung effektiv deaktiviert wird.
  • Universalregister 1325 – in der veranschaulichten Ausführungsform gibt es sechzehn 64-Bit-Universalregister, die zusammen mit den bestehenden x86-Adressiermodi zum Adressieren von Speicheroperanden verwendet werden. Diese Register sind mit den Benennungen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 gekennzeichnet.
  • Skalare Gleitkomma-Stapelregisterdatei (x87-Stapel) 1345, in welcher die gepackte ganzzahlige flache MMX-Registerdatei 1350 aliasiert ist – in der veranschaulichten Ausführungsform ist der x87-Stapel ein Stapel von acht Elementen, der zum Durchführen von skalaren Gleitkommaoperationen an 32-/64-/80-Bit-Gleitkommadaten unter Verwendung der x87-Anweisungssatzerweiterung verwendet wird; während die MMX-Register zum Ausführen von Operationen an gepackten ganzzahligen 64-Bit-Daten sowie zum Speichern von Operanden für einige Operationen verwendet werden, die zwischen den MMX- und XMM-Registern ausgeführt werden.
  • Alternative Ausführungen der Erfindung können breitere oder schmalere Register verwenden. Außerdem können alternative Ausführungsformen der Erfindung mehr, weniger oder andere Registerdateien und Register verwenden.
  • Beispielhaftes Computersystem
  • 15 ist ein Blockdiagramm, das beispielhafte Clients und Server veranschaulicht, die in einigen Ausführungsformen der Erfindung verwendet werden können. Es versteht sich von selbst, dass, obwohl 15 verschiedene Komponenten eines Computersystems 1500 veranschaulicht, nicht die Absicht besteht, eine bestimmte Architektur oder eine bestimmte Art der Verbindung zwischen Komponenten darzustellen, da solche Details für die Ausführungsformen der Erfindung nicht relevant sind. Es versteht sich von selbst, dass andere Computersysteme, die weniger Komponenten oder mehr Komponenten aufweisen, ebenfalls mit den Ausführungsformen der Erfindung verwendet werden können.
  • Wie in 15 veranschaulicht, umfasst das Computersystem 1500, das eine Form eines Datenverarbeitungssystems ist, die Zwischenverbindung(en)/Bus(se) 1501 umfasst, welche die Prozessorcluster 804 kommunikativ mit den verschiedenen anderen Systemkomponenten koppeln. Die Zwischenverbindungen/Busse umfassen verschiedene Zwischenverbindungsstufen, die durch verschiedene Brücken, Steuerungen und/oder Adapter miteinander verbunden sein können, wie auf dem Fachgebiet bekannt. Als Beispiel können die Zwischenverbindung(en) 1501 eine Quick Path Interconnect(QPI)-Komponente, eine Peripheral Component Interconnect Express(„PCI Express”)-Komponente oder andere Technologien zum Verbinden der verschiedenen Komponenten mit den Prozessorcluster(n) 804 umfassen. Die der Erfindung zugrunde liegenden Prinzipien sind jedoch auf keine bestimmten Zwischenverbindungen oder Busse beschränkt.
  • Obwohl in 15 als eine separate Komponente veranschaulicht, können der oder die Beschleuniger 801 in den bzw. die Prozessorcluster 804 integriert sein. Alternativ können einige Beschleuniger in den bzw. die Prozessorcluster integriert sein, und einige können über Zwischenverbindung(en)Bus(se) mit dem Computersystem verbunden sein. Wie zuvor ausführlich beschrieben, sind die Beschleuniger so ausgelegt, dass sie bestimmte Typen von Programmcode (z. B. Vektor-/SIMD-Operationen, Grafikoperationen, Sortier- und Schleifenoperationen usw.) effizient ausführen. Als Beispiel kann der Universalprozessorcluster 804 Ausführungslogik innerhalb eines Prozessorkerns zum Ausführen von Universalanweisungen, wie beispielsweise x86-Anweisungen, umfassen, welche Anweisungen umfassen, die Befehle in den Beschleunigerclustern 801 aufrufen. Die der Erfindung zugrunde liegenden Prinzipien sind jedoch auf keinen bestimmten Typ von Universalclustern oder Beschleunigerclustern beschränkt.
  • Die in 15 veranschaulichte Ausführungsform umfasst außerdem eine Speicherschnittstelle 1520 zum Koppeln von Speichermodulen 1525 des Computersystems. In einer Ausführungsform sind die Speichermodule Dual-Inline-Speichermodule (DIMMs für engl. dual in-line memory modules), wie beispielsweise Direktzugriffsspeicher(RAM)-Module, und die Speicherschnittstelle kann die elektrische Signalisierung erzeugen, die zum Zugreifen auf die Speichermodule 1525 erforderlich ist (wie z. B. Strobe-Signal für Spaltenadressierung (CAS für engl. column address strobe), Strobe-Signal für Reihenadressierung (RAS für engl. row address strobe), Schreibfreigabe (WE für engl. write enable)- und Ausgabefreigabe OE für engl. output enable)-Signale).
  • In einer Ausführungsform umfasst die Speicherschnittstelle 1520 Logik und Schaltungsanordnung zur Verbindung mit verschiedenen Typen von Speichermodulen, einschließlich flüchtiger Speichermodule, wie beispielsweise RAM, und nichtflüchtiger Speichermodule, wie beispielsweise Phasenwechselspeicher (PCM für engl. Phase-Change Memory), manchmal auch als Phasenwechsel-Direktzugriffsspeicher (PRAM oder PCRAM), PCME, Ovonic Unified Memory oder Chalkogenid-Speicher (C-RAM) bezeichnet. Eine Ausführungsform des Computersystems 1500 implementiert zum Beispiel eine zweistufige (2L) Speicherhierarchie, die einen „Nahspeicher”-Abschnitt, der ein flüchtiger Speicher, wie beispielsweise ein RAM, sein kann, und einen „Fernspeicher”-Abschnitt umfasst, der als ein Phasenwechselspeicher (PCM) implementiert sein kann. In solch einem Fall kann die Speicherschnittstelle die Logik und die Schaltungsanordnung umfassen, die zum Zugreifen auf beide Speichertypen erforderlich sind.
  • Die veranschaulichte Ausführungsform 1500 umfasst außerdem eine oder mehrere Speicherschnittstellen 1518 zur Verbindung mit Speichereinrichtungen, wie beispielsweise Festplatten oder anderen nichtflüchtigen Speichereinrichtungen. In einer Ausführungsform umfasst die Speicherschnittstelle 1518 eine Serial-ATA-Speicherschnittstelle, und die Festplatte umfasst ein Festkörperlaufwerk (SSD für engl. solid state drive) oder eine magnetische Speichereinrichtung. In einer Ausführungsform der Erfindung, welche 2LM-Speicher (wie zuvor erörtert) verwendet, kann ein Abschnitt des Speichers der Speichereinrichtung 1519 für einen „Fernspeicher” (oder einen Abschnitt eines „Fernspeichers”) verwendet werden.
  • Die veranschaulichte Ausführungsform 1500 umfasst außerdem eine Grafikschnittstelle 1502 zur Verbindung mit einer oder mehreren Grafikverarbeitungseinheiten 1503. Die GPUs können auf einer Hauptplatine des Computersystems eingebettet oder auf einer separaten Karte sein, die in die Hauptplatine eingefügt ist (z. B. über eine PCI Express-Grafikschnittstelle oder ein andere Hochgeschwindigkeits-Grafikschnittstelle). Eine Videoausgabeschnittstelle 1504, wie beispielsweise eine digitale Videoschnittstelle (DVI für engl. digital video interface), Hochgeschwindigkeits-Multimedia-Schnittstelle (HDMI für engl. High-Definition Multimedia Interface) oder DisplayPort-Videoausgabeschnittstelle, gibt einen Videostrom an einen Monitor 1505 aus, der Video für den Endbenutzer wiedergibt. Wie bereits erwähnt, können die CPUs als Beschleunigerkomponenten zum Ausführen von Grafikprogrammcode unter Verwendung einer der hierin beschriebenen Ausführungsformen implementiert sein.
  • Die veranschaulichte Ausführungsform 1500 umfasst außerdem eine Audioauseingabeschnittstelle 1516 zum Empfangen von mehreren digitalen und analogen Audioeingaben. Zum Beispiel kann ein Mikrofon mit einer der Audioeingabeschnittstellen gekoppelt sein, um eine Stimme des Benutzers zu erfassen (z. B. bei Web-Chats und Telefonanrufen oder zum Aufzeichnen von Audio). Außerdem kann eine digitale Audioeingabe, wie beispielsweise eine Toslink-Schnittstelle, verwendet werden.
  • Die veranschaulichte Ausführungsform 1500 umfasst außerdem einen Sensorhub 1515 zum Sammeln von Daten von verschiedenen Systemsensoren 1509. Als Beispiel und ohne Einschränkung können die Sensoren 1509 mechanische Sensoren, Bewegungssensoren und Positionssensoren zum Erfassen einer Position und Ausrichtung des Computersystems 1500 umfassen. Zum Beispiel können die Sensoren in einer Ausführungsform mehrachsige Beschleunigungsmesser zum Erfassen von Beschleunigungswerten entlang der X-, Y- und Z-Achsen und Melden der Daten an den Sensor-Hub umfassen. Der Sensorhub kann dann Berechnungen durchführen, um eine aktuelle Ausrichtung des Computersystems 1500 zu bestimmen. Wenn das Computersystem 1500 zum Beispiel ein Notebook-Computer ist, kann der Sensorhub eine aktuelle Position des Computermonitors erfassen. Die Sensoren 1509 können außerdem Trägheitssensoren zum Erfassen von Versetzungen von einer Referenzposition und/oder Näherungssensoren zum Erfassen der Annäherung eines Benutzers oder einer anderen Einrichtung umfassen. In einer Ausführungsform umfassen die Sensoren 1509 einen Sensor eines globalen Positionsbestimmungssystems (GPS) oder einen anderen Sensor zum Bestimmen der aktuellen globalen Position des Computersystems. Die Sensoren 1509 können außerdem ein Magnetometer zum Erfassen der Ausrichtung des elektrischen Feldes der Erde (d. h. zum Bestimmen einer aktuellen Position des Computersystems in Bezug auf den Norden) umfassen. Die Sensoren 1509 können auch ein Kreisel zum Erfassen von Änderungen der Ausrichtung und einen Umgebungslichtsensor zum Erfassen von aktuellen Beleuchtungsbedingungen umfassen (so dass z. B. der Sensorhub oder eine andere Systemkomponente in Reaktion darauf die Helligkeit des Monitors 1505 anpassen kann).
  • Alle der von den verschiedenen Sensoren 1509 gesammelten Daten können zum Bestimmen eines aktuellen Betriebsmodus und Anpassen des Betriebs des Computergeräts 1500 in Reaktion darauf verwendet werden. Zum Beispiel kann das Computergerät in Reaktion auf die Signale von den Sensoren 1509 in einen ersten Betriebsmodus, in welchem die hierin beschriebenen Beschleunigeraufrufe aktiviert sind, und in einen zweiten Betriebsmodus eintreten, in welchem die hierin beschriebenen Beschleunigeraufrufe deaktiviert sind.
  • Die veranschaulichte Ausführungsform 1500 umfasst außerdem eine Kameraschnittstelle 1514 zum Koppeln mit einer Videokamera, die zum Aufnehmen von Laufbildvideo und Standbildern verwendet werden kann. Zum Beispiel erfasst die Kameraschnittstelle 1514 in einer Ausführungsform Laufbildvideo für Videokonferenzanwendungen, in welchen die hierin beschriebenen Beschleunigeraufruftechniken verwendet werden können. Zum Beispiel kann ein Beschleuniger so konfiguriert sein, dass er Videoströme effektiv in das H.264/MPEG-4 AVC-Format codiert. Es ist jedoch zu erwähnen, dass die der Erfindung zugrunde liegenden Prinzipien auf kein bestimmtes Videokompressionsformat beschränkt sind.
  • Die veranschaulichte Ausführungsform 1500 umfasst außerdem eine serielle Busschnittstelle zum Herstellen von serieller Datenkommunikation mit angeschlossenen Einrichtungen (z. B. Mobiltelefonen, Tablets, Druckern, externen Kameras, MIDI-Geräten usw.). Diese Ausführungsform umfasst ferner eine Ethernet-Schnittstelle 1512 zum Herstellen von Netzverbindungen über ein Ethernet-Netz und eine Zellularschnittstelle 1511 zum Herstellen von Sprach- und Datenverbindungen über ein Zellularnetz unter Verwendung von Zellularkommunikationsprotokollen. Es können verschiedenen Zellulartechnologien eingesetzt werden, die Codemultiplexzugriffstechnologien (z. B. CDMA2000 Technologie unter Verwendung von 1xRTT/EVDO/eHRPD); Long Term Evolution(LTE)-Technologie und/oder LTE-Advanced(LTE-A)-Technologie des Partnerschaftsprojekts der dritten Generation (z. B. 3GPP2); und Universal Mobile Telecommunications System(UMTS)-Technologie, wie beispielsweise WCDMA/TDSCDMA, umfassen, ohne darauf beschränkt zu sein. Außerdem umfasst die dargestellte Ausführungsform auch eine WiFi- und/oder Bluetooth-Schnittstelle 1510 zum Herstellen von Kommunikation über WiFi-Kanäle (z. B. 802.11-Kanäle) bzw. Bluetooth-Kanäle. Jede der Ethernet-, Zellular- und WiFi-Kommunikationsschnittstellen umfasst einen Sendeempfänger und andere Schaltungsanordnung zum Erzeugen von analogen Übertragungssignalen unter Verwendung der entsprechenden Technologie. In einer Ausführungsform kann ein Beschleuniger auch aufgerufen werden, um den Netzkommunikationsprozess zu unterstützen (z. B. zum Ausführen von Netz-Basisbandfunktionen, wie beispielsweise Datencodierung).
  • Die veranschaulichte Ausführungsform 1500 umfasst außerdem eine Leistungsverwaltungsschnittstelle 1517, um aktuelle Bedingungen innerhalb des Computersystems (z. B. thermische, Leistungsnutzung, Batterielebensdauer usw.) zu erfassen und in Reaktion darauf die Leistungsnutzung an jede der verschiedenen Systemkomponenten anzupassen. Zum Beispiel kann die Leistungsverwaltungsschnittstelle 1517 unter bestimmten Bedingungen die hierin beschriebenen Beschleunigerfunktionen ausschalten, um Leistung zu sparen (z. B. wenn die Batterie unter einen Schwellenwert fällt).
  • Die veranschaulichte Ausführungsform 1500 umfasst außerdem eine Leistungsverwaltungsschnittstelle 1517, kann außerdem verschiedene Typen von Eingabe-/Ausgabe-Einrichtungen, wie beispielsweise eine Cursorsteuerung (z. B. Maus, Berührungsbildschirm, Touchpad usw.), eine Tastatur usw. zum Empfangen von Benutzereingabe umfassen.
  • Es versteht sich von selbst, dass in bestimmten Ausführungsformen der Erfindung auch zusätzliche Komponente, die in 15 nicht dargestellt sind, Teil des Datenverarbeitungssystems 1500 umfasst außerdem eine Leistungsverwaltungsschnittstelle 1517, sein können, und in bestimmten Ausführungsformen der Erfindung weniger Komponenten, als in 15 dargestellt, verwendet werden können. Außerdem versteht es sich von selbst, dass ein oder mehrere Busse und/oder Zwischenverbindungen, die in 15 nicht dargestellt sind, verwendet werden können, um die verschiedenen Komponenten miteinander zu verbinden, wie auf dem Fachgebiet allgemein bekannt ist.
  • Ausführungsformen der Erfindung können verschiedene Schritte umfassen, die vorstehend beschrieben wurden. Die Schritte können in maschinenausführbaren Anweisungen realisiert sein, die verwendet werden können, um einen Universal- oder Spezialprozessor zu veranlassen, die Schritte auszuführen. Alternativ können diese Schritte durch spezifische Hardwarekomponenten, welche festverdrahtete Logik zum Ausführen der Schritte umfassen können, oder eine beliebige Kombination von programmierten Computerkomponenten und maßgeschneiderten Hardwarekomponenten ausgeführt werden.
  • Wie hierin beschrieben, können sich Anweisungen auf spezifische Konfigurationen von Hardware, wie beispielsweise anwendungsspezifische integrierte Schaltungen (ASICs), die so konfiguriert sind, dass sie bestimmte Operationen ausführen oder eine vorbestimmte Funktionalität aufweisen, oder Softwareanweisungen beziehen, die in einem Speicher gespeichert sind, der auf einem nicht-transitorischen computerlesbaren Medium enthalten ist.
  • Demnach können die in den Figuren dargestellten Techniken unter Verwendung von Code und Daten implementiert werden, die auf einer oder mehreren elektronischen Einrichtungen (z. B. einer Endstation, einem Netzelement usw.) gespeichert und ausgeführt werden. Solche elektronischen Einrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Einrichtungen über ein Netz) Code und Daten unter Verwendung von computermaschinenlesbaren Medien, wie beispielsweise nicht-transitorischen computermaschinenlesbaren Speichermedien (z. B. Magnetplatten, optischen Platten; Direktzugriffsspeicher; Festwertspeicher; Flash-Speichereinrichtungen; Phasenwechselspeicher) und transitorischen computermaschinenlesbaren Kommunikationsmedien (z. B. elektrischen, optischen, akustischen oder einer anderen Form von übertragenen Signalen – wie beispielsweise Trägerwellen, Infrarotsignalen, digitalen Signalen usw.). Außerdem umfassen solche elektronischen Einrichtungen typischerweise einen Satz von einem oder mehreren Prozessoren, die mit einer oder mehreren anderen Komponenten, wie beispielsweise einer oder mehreren Speichereinrichtungen (nicht-transitorischen Speichermedien), Benutzer-Eingabe-/Ausgabeeinrichtungen (z, B. einer Tastatur, einem Berührungsbildschirm und/oder einer Anzeige) und Netzverbindungen, gekoppelt sind. Das Koppeln des Satzes von Prozessoren und anderer Komponenten erfolgt typischerweise durch einen oder mehrere Busse und Brücken (auch als Buscontroller bezeichnet). Die Speichereinrichtung und die Signale, welche den Netzverkehr übertragen, stellen ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien dar. Demnach speichert die Speichereinrichtung einer bestimmten elektronischen Einrichtung typischerweise Code und/oder Daten zur Ausführung auf dem Satz des einen oder der mehreren Prozessoren dieser elektronischen Einrichtung. Natürlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung von verschiedenen Kombinationen von Software, Firmware und/oder Hardware implementiert sein. Die gesamte ausführliche Beschreibung hindurch wurden zu Erläuterungszwecken zahlreiche spezifische Details dargelegt, um ein umfassendes Verständnis der vorliegenden Erfindung zu vermitteln. Für Fachleute ist jedoch zu erkennen, dass die Erfindung ohne einige dieser spezifischen Details realisiert werden kann. In bestimmten Fällen wurden allgemein bekannte Strukturen und Funktionen nicht im Detail beschrieben, um ein Verkomplizieren des Gegenstands der vorliegenden Erfindung zu vermeiden. Demgemäß sollten der Schutzbereich und das Wesen der Erfindung nur in Bezug auf die folgenden Ansprüche beurteilt werden.

Claims (24)

  1. Prozessor, umfassend: ein Befehlsregister zum Speichern von Befehlsdaten, die einen auszuführenden Befehl identifizieren; ein Ergebnisregister zum Speichern eines Ergebnisses des Befehls oder von Daten, die einen Grund dafür angeben, warum der Befehl nicht ausgeführt werden konnte; Ausführungslogik zum Ausführen einer Mehrzahl von Anweisungen, die eine Beschleunigeraufrufanweisung zum Aufrufen eines oder mehrerer Beschleunigerbefehle umfassen, wobei die Beschleunigeraufrufanweisung, Befehlsdaten zu Speichern, den Befehl innerhalb des Befehlsregister spezifiziert; einen oder mehrere Beschleuniger zum Auslesen der Befehlsdaten aus dem Befehlsregister und Versuchen in Reaktion darauf, den durch die Befehlsdaten identifizierten Befehl auszuführen, wobei, wenn der eine oder die mehreren Beschleuniger den Befehl erfolgreich ausführen, der eine oder die mehreren Beschleuniger Ergebnisdaten, welche die Ergebnisse des Befehls umfassen, im Ergebnisregister speichern sollen; und wenn der eine oder die mehreren Beschleuniger den Befehl nicht erfolgreich ausführen können, der eine oder die mehreren Beschleuniger Ergebnisdaten speichern sollen, welche einen Grund dafür angeben, warum der Befehl nicht ausgeführt werden kann, wobei die Ausführungslogik die Ausführung vorübergehend anhalten soll, bis der Beschleuniger die Ausführung abschließt oder unterbrochen wird, wobei der Beschleuniger Logik zum Speichern seines Zustands bei Unterbrechung umfasst, so dass er die Ausführung zu einem späteren Zeitpunkt fortsetzen kann.
  2. Prozessor nach Anspruch 1, wobei das Befehlsregister und das Ergebnisregister Universalregister (GPRs) innerhalb einer GPR-Datei eines Prozessorkerns sind.
  3. Prozessor nach Anspruch 1, wobei die Ausführungslogik x86-Ausführungslogik umfasst.
  4. Prozessor nach Anspruch 1, wobei die Ausführungslogik und der eine oder die mehreren Beschleuniger innerhalb eines einzigen Prozessorkerns enthalten sind.
  5. Prozessor nach Anspruch 1, wobei, wenn der eine oder die mehreren Beschleuniger den Befehl nicht erfolgreich ausführen können, der eine oder die mehreren Beschleuniger Ergebnisdaten speichern, die anzeigen, ob ein anschließender Versuch, den gleichen Befehl auszuführen, erfolglos sein wird.
  6. Prozessor nach Anspruch 5, wobei die Ergebnisdaten ein Bit umfassen, wobei ein erster Wert des Bits anzeigt, dass ein anschließender Versuch, den gleichen Befehl auszuführen, erfolglos sein wird, und ein zweiter Wert des Bits anzeigt, dass ein anschließender Versuch, den gleichen Befehl auszuführen, erfolgreich sein kann.
  7. Prozessor nach Anspruch 6, wobei eine anschließende Anweisung das Bit ausliest, um zu bestimmen, ob versucht werden soll, den gleichen Befehl auszuführen.
  8. Prozessor nach Anspruch 6, wobei die Ergebnisdaten einen Ergebniscode umfassen, der einen spezifischen Grund für das Misslingen der Ausführung des Befehls angibt.
  9. Prozessor nach Anspruch 1, ferner umfassend: ein Parameterregister zum Speichern von Parametern, die mit dem Befehl assoziiert sind, wobei der eine oder die mehreren Beschleuniger die Parameter auslesen, um den Befehl auszuführen.
  10. Prozessor nach Anspruch 1, wobei mindestens einer der Beschleuniger einen Beschleuniger mit fester Funktion umfasst.
  11. Prozessor nach Anspruch 1, wobei mindestens einer der Beschleuniger einen Beschleuniger mit programmierbaren Funktionen umfasst.
  12. Prozessor nach Anspruch 1, wobei das Befehlsregister einen Identifikationscode speichern soll, um einen der Beschleuniger zum Ausführen des Befehls zu identifizieren.
  13. Computerimplementiertes Verfahren, umfassend: Speichern von Befehlsdaten in einem Befehlsregister, um einen auszuführenden Befehl zu identifizieren; Speichern eines Ergebnisses des Befehls oder von Daten, die einen Grund dafür angeben, warum der Befehl nicht ausgeführt werden konnte, in einem Ergebnisregister; Ausführen einer Mehrzahl von Anweisungen, die eine Beschleunigeraufrufanweisung zum Aufrufen eines oder mehrerer Beschleunigerbefehle umfassen, wobei die Beschlunigeraufurfanweisung, Befehlsdaten zu speichern, den Befehl innerhalb des Befehlsregister spezifiziert; Auslesen der Befehlsdaten aus dem Befehlsregister, wobei einer oder mehrere Beschleuniger in Reaktion darauf versuchen, den durch die Befehlsdaten identifizierten Befehl auszuführen, wobei, wenn der eine oder die mehreren Beschleuniger den Befehl erfolgreich ausführen, der eine oder die mehreren Beschleuniger Ergebnisdaten, welche die Ergebnisse des Befehls umfassen, im Ergebnisregister speichern sollen; und wenn der eine oder die mehreren Beschleuniger den Befehl nicht erfolgreich ausführen können, der eine oder die mehreren Beschleuniger Ergebnisdaten speichern sollen, welche einen Grund dafür angeben, warum der Befehl nicht ausgeführt werden kann, wobei die Ausführungslogik die Ausführung vorübergehend anhalten soll, bis der Beschleuniger die Ausführung abschließt oder unterbrochen wird, wobei der Beschleuniger Logik zum Speichern seines Zustands bei Unterbrechung umfasst, so dass er die Ausführung zu einem späteren Zeitpunkt fortsetzen kann.
  14. Verfahren nach Anspruch 13, wobei das Befehlsregister und das Ergebnisregister Universalregister (GPRs) innerhalb einer GPR-Datei eines Prozessorkerns sind.
  15. Verfahren nach Anspruch 13, wobei die Ausführungslogik x86-Ausführungslogik umfasst.
  16. Verfahren nach Anspruch 13, wobei die Ausführungslogik und der eine oder die mehreren Beschleuniger innerhalb eines einzigen Prozessorkerns enthalten sind.
  17. Verfahren nach Anspruch 13, wobei, wenn der eine oder die mehreren Beschleuniger den Befehl nicht erfolgreich ausführen können, der eine oder die mehreren Beschleuniger Ergebnisdaten speichern, die anzeigen, ob ein anschließender Versuch, den gleichen Befehl auszuführen, erfolglos sein wird.
  18. Verfahren nach Anspruch 17, wobei die Ergebnisdaten ein Bit umfassen, wobei ein erster Wert des Bits anzeigt, dass ein anschließender Versuch, den gleichen Befehl auszuführen, erfolglos sein wird, und ein zweiter Wert des Bits anzeigt, dass ein anschließender Versuch, den gleichen Befehl auszuführen, erfolgreich sein kann.
  19. Verfahren nach Anspruch 18, wobei eine anschließende Anweisung das Bit ausliest, um zu bestimmen, ob versucht werden soll, den gleichen Befehl auszuführen.
  20. Verfahren nach Anspruch 18, wobei die Ergebnisdaten einen Ergebniscode umfassen, der einen spezifischen Grund für das Misslingen der Ausführung des Befehls angibt.
  21. Verfahren nach Anspruch 13, ferner umfassend: Speichern von Parametern, die mit dem Befehl assoziiert sind, in einem Parameterregister, wobei der eine oder die mehreren Beschleuniger die Parameter auslesen, um den Befehl auszuführen.
  22. Verfahren nach Anspruch 13, wobei mindestens einer der Beschleuniger einen Beschleuniger mit fester Funktion umfasst.
  23. Verfahren nach Anspruch 13, wobei mindestens einer der Beschleuniger einen Beschleuniger mit programmierbaren Funktionen umfasst.
  24. Verfahren nach Anspruch 13, wobei das Befehlsregister einen Identifikationscode speichern soll, um einen der Beschleuniger zum Ausführen des Befehls zu identifizieren.
DE112013005338.1T 2012-12-28 2013-06-20 Vorrichtung und Verfahren für Beschleunigeraufruf mit geringer Latenz Pending DE112013005338T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/729,915 2012-12-28
US13/729,915 US9361116B2 (en) 2012-12-28 2012-12-28 Apparatus and method for low-latency invocation of accelerators
PCT/US2013/046863 WO2014105148A1 (en) 2012-12-28 2013-06-20 Apparatus and method for low-latency invocation of accelerators

Publications (1)

Publication Number Publication Date
DE112013005338T5 true DE112013005338T5 (de) 2015-07-23

Family

ID=51018707

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112013005338.1T Pending DE112013005338T5 (de) 2012-12-28 2013-06-20 Vorrichtung und Verfahren für Beschleunigeraufruf mit geringer Latenz

Country Status (5)

Country Link
US (4) US9361116B2 (de)
KR (3) KR101764187B1 (de)
CN (2) CN104813280B (de)
DE (1) DE112013005338T5 (de)
WO (1) WO2014105148A1 (de)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013147885A1 (en) 2012-03-30 2013-10-03 Intel Corporation Apparatus and method for accelerating operations in a processor which uses shared virtual memory
US10140129B2 (en) 2012-12-28 2018-11-27 Intel Corporation Processing core having shared front end unit
US9417873B2 (en) 2012-12-28 2016-08-16 Intel Corporation Apparatus and method for a hybrid latency-throughput processor
US9361116B2 (en) 2012-12-28 2016-06-07 Intel Corporation Apparatus and method for low-latency invocation of accelerators
US9542193B2 (en) 2012-12-28 2017-01-10 Intel Corporation Memory address collision detection of ordered parallel threads with bloom filters
US10346195B2 (en) 2012-12-29 2019-07-09 Intel Corporation Apparatus and method for invocation of a multi threaded accelerator
US9465618B2 (en) * 2014-01-08 2016-10-11 Oracle International Corporation Methods and systems for optimally selecting an assist unit
US10031770B2 (en) * 2014-04-30 2018-07-24 Intel Corporation System and method of delayed context switching in processor registers
JP6329318B2 (ja) * 2015-02-25 2018-05-23 株式会社日立製作所 情報処理装置
US9747108B2 (en) 2015-03-27 2017-08-29 Intel Corporation User-level fork and join processors, methods, systems, and instructions
US10275853B2 (en) * 2015-04-15 2019-04-30 Intel Corporation Media hub device and cache
US9703603B1 (en) * 2016-04-25 2017-07-11 Nxp Usa, Inc. System and method for executing accelerator call
US10929059B2 (en) 2016-07-26 2021-02-23 MemRay Corporation Resistance switching memory-based accelerator
US20180069767A1 (en) * 2016-09-06 2018-03-08 Advanced Micro Devices, Inc. Preserving quality of service constraints in heterogeneous processing systems
US10210032B2 (en) * 2017-03-30 2019-02-19 Intel Corporation Processing commands via dedicated register pairs for each thread of a plurality of threads
US10437739B2 (en) * 2017-09-26 2019-10-08 Intel Corporation Low-latency accelerator
CN110300132A (zh) * 2018-03-22 2019-10-01 贵州白山云科技股份有限公司 服务器数据缓存方法、装置和系统
US10795713B2 (en) 2018-05-25 2020-10-06 Vmware, Inc. Live migration of a virtualized compute accelerator workload
US10684887B2 (en) * 2018-05-25 2020-06-16 Vmware, Inc. Live migration of a virtualized compute accelerator workload
GB2575294B8 (en) * 2018-07-04 2022-07-20 Graphcore Ltd Host Proxy On Gateway
KR102587648B1 (ko) * 2018-07-23 2023-10-11 삼성전자주식회사 적층형 메모리 장치, 이를 포함하는 메모리 시스템 및 적층형 메모리 장치의 테스트 방법
US11243817B2 (en) * 2019-03-29 2022-02-08 Intel Corporation Technologies for data migration between edge accelerators hosted on different edge locations
US11263122B2 (en) * 2019-04-09 2022-03-01 Vmware, Inc. Implementing fine grain data coherency of a shared memory region
US11372711B2 (en) 2019-06-29 2022-06-28 Intel Corporation Apparatus and method for fault handling of an offload transaction
US10983796B2 (en) 2019-06-29 2021-04-20 Intel Corporation Core-to-core end “offload” instruction(s)
US11321144B2 (en) 2019-06-29 2022-05-03 Intel Corporation Method and apparatus for efficiently managing offload work between processing units
US10929129B2 (en) * 2019-06-29 2021-02-23 Intel Corporation Apparatus and method for modifying addresses, data, or program code associated with offloaded instructions
US11182208B2 (en) 2019-06-29 2021-11-23 Intel Corporation Core-to-core start “offload” instruction(s)
US11016766B2 (en) 2019-06-29 2021-05-25 Intel Corporation Apparatus and method for compiler hints for inter-core offload
US11030000B2 (en) 2019-06-29 2021-06-08 Intel Corporation Core advertisement of availability
US10789094B1 (en) * 2019-08-22 2020-09-29 Micron Technology, Inc. Hierarchical memory apparatus
US11409572B2 (en) 2019-09-27 2022-08-09 Intel Corporation Methods of hardware and software coordinated opt-in to advanced features on hetero ISA platforms
US11231930B2 (en) * 2019-11-25 2022-01-25 Alibaba Group Holding Limited Methods and systems for fetching data for an accelerator
KR102418794B1 (ko) * 2020-06-02 2022-07-08 오픈엣지테크놀로지 주식회사 하드웨어 가속기를 위한 파라미터를 메모리로부터 액세스하는 방법 및 이를 이용한 장치
US11893419B2 (en) * 2020-08-28 2024-02-06 Apple Inc. Hardware accelerators using shared interface registers
KR20220031776A (ko) 2020-09-03 2022-03-14 삼성전자주식회사 반도체 메모리 장치 및 그것의 동작 방법
KR102650569B1 (ko) * 2020-11-12 2024-03-26 한국전자통신연구원 범용 연산 가속기 및 그것의 동작 방법
US11775303B2 (en) 2020-11-12 2023-10-03 Electronics And Telecommunications Research Institute Computing accelerator for processing multiple-type instruction and operation method thereof
WO2022133718A1 (en) * 2020-12-22 2022-06-30 Alibaba Group Holding Limited Processing system with integrated domain specific accelerators

Family Cites Families (131)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4943915A (en) * 1987-09-29 1990-07-24 Digital Equipment Corporation Apparatus and method for synchronization of a coprocessor unit in a pipelined central processing unit
US4982402A (en) 1989-02-03 1991-01-01 Digital Equipment Corporation Method and apparatus for detecting and correcting errors in a pipelined computer system
US5276798A (en) 1990-09-14 1994-01-04 Hughes Aircraft Company Multifunction high performance graphics rendering processor
US5329615A (en) 1990-09-14 1994-07-12 Hughes Aircraft Company Concurrent general purpose and DMA processing in a graphics rendering processor
CA2050658C (en) * 1990-09-14 1997-01-28 John M. Peaslee Dual hardware channels and hardware context switching in a graphics rendering processor
US5444853A (en) * 1992-03-31 1995-08-22 Seiko Epson Corporation System and method for transferring data between a plurality of virtual FIFO's and a peripheral via a hardware FIFO and selectively updating control information associated with the virtual FIFO's
US5423025A (en) 1992-09-29 1995-06-06 Amdahl Corporation Error handling mechanism for a controller having a plurality of servers
US5430841A (en) * 1992-10-29 1995-07-04 International Business Machines Corporation Context management in a graphics system
JPH07219774A (ja) * 1994-02-07 1995-08-18 Fujitsu Ltd データ処理装置および例外処理方法
US5550988A (en) 1994-03-01 1996-08-27 Intel Corporation Apparatus and method for performing error correction in a multi-processor system
US6341324B1 (en) 1995-10-06 2002-01-22 Lsi Logic Corporation Exception processing in superscalar microprocessor
US5778211A (en) 1996-02-15 1998-07-07 Sun Microsystems, Inc. Emulating a delayed exception on a digital computer having a corresponding precise exception mechanism
US6061711A (en) 1996-08-19 2000-05-09 Samsung Electronics, Inc. Efficient context saving and restoring in a multi-tasking computing system environment
CN100373331C (zh) 1996-08-27 2008-03-05 松下电器产业株式会社 独立处理多个指令流、软式控制各指令流的处理功能的多线程处理器
US6247040B1 (en) 1996-09-30 2001-06-12 Lsi Logic Corporation Method and structure for automated switching between multiple contexts in a storage subsystem target device
US6148326A (en) 1996-09-30 2000-11-14 Lsi Logic Corporation Method and structure for independent disk and host transfer in a storage subsystem target device
US6081849A (en) 1996-10-01 2000-06-27 Lsi Logic Corporation Method and structure for switching multiple contexts in storage subsystem target device
US6275497B1 (en) 1997-02-10 2001-08-14 Hybrid Networks, Inc. Method and apparatus for controlling communication channels using contention and polling schemes
US6075546A (en) * 1997-11-10 2000-06-13 Silicon Grahphics, Inc. Packetized command interface to graphics processor
US6397240B1 (en) * 1999-02-18 2002-05-28 Agere Systems Guardian Corp. Programmable accelerator for a programmable processor system
GB2352066B (en) 1999-07-14 2003-11-05 Element 14 Ltd An instruction set for a computer
US6543026B1 (en) 1999-09-10 2003-04-01 Lsi Logic Corporation Forward error correction apparatus and methods
JP3621315B2 (ja) * 1999-11-22 2005-02-16 Ｎｅｃエレクトロニクス株式会社 マイクロプロセッサシステム
US6691143B2 (en) * 2000-05-11 2004-02-10 Cyberguard Corporation Accelerated montgomery multiplication using plural multipliers
EP1182569B8 (de) * 2000-08-21 2011-07-06 Texas Instruments Incorporated TLB-Ver- und Entriegelungsoperation
EP1182568A3 (de) * 2000-08-21 2004-07-21 Texas Instruments Incorporated Auf Task-Kennzeichnung basierte TLB-Operation
US6742104B2 (en) 2000-08-21 2004-05-25 Texas Instruments Incorporated Master/slave processing system with shared translation lookaside buffer
JP3729087B2 (ja) 2001-05-23 2005-12-21 日本電気株式会社 マルチプロセッサシステム、データ依存投機実行制御装置およびその方法
JP2003015900A (ja) 2001-06-28 2003-01-17 Hitachi Ltd 追走型多重化システム、及び追走により信頼性を高めるデータ処理方法
US20030028751A1 (en) 2001-08-03 2003-02-06 Mcdonald Robert G. Modular accelerator framework
US7209996B2 (en) 2001-10-22 2007-04-24 Sun Microsystems, Inc. Multi-core multi-thread processor
US7228401B2 (en) 2001-11-13 2007-06-05 Freescale Semiconductor, Inc. Interfacing a processor to a coprocessor in which the processor selectively broadcasts to or selectively alters an execution mode of the coprocessor
US20030126416A1 (en) 2001-12-31 2003-07-03 Marr Deborah T. Suspending execution of a thread in a multi-threaded processor
US7313734B2 (en) * 2002-01-14 2007-12-25 International Business Machines Corporation Method and system for instruction tracing with enhanced interrupt avoidance
US20030135718A1 (en) * 2002-01-14 2003-07-17 International Business Machines Corporation Method and system using hardware assistance for instruction tracing by revealing executed opcode or instruction
US20030135719A1 (en) * 2002-01-14 2003-07-17 International Business Machines Corporation Method and system using hardware assistance for tracing instruction disposition information
US20040215444A1 (en) 2002-03-25 2004-10-28 Patel Mukesh K. Hardware-translator-based custom method invocation system and method
US6944746B2 (en) * 2002-04-01 2005-09-13 Broadcom Corporation RISC processor supporting one or more uninterruptible co-processors
US7200735B2 (en) 2002-04-10 2007-04-03 Tensilica, Inc. High-performance hybrid processor with configurable execution units
GB2388447B (en) * 2002-05-09 2005-07-27 Sun Microsystems Inc A computer system method and program product for performing a data access from low-level code
US6952214B2 (en) 2002-07-12 2005-10-04 Sun Microsystems, Inc. Method for context switching a graphics accelerator comprising multiple rendering pipelines
US7313797B2 (en) 2002-09-18 2007-12-25 Wind River Systems, Inc. Uniprocessor operating system design facilitating fast context switching
US20040111594A1 (en) 2002-12-05 2004-06-10 International Business Machines Corporation Multithreading recycle and dispatch mechanism
US7673304B2 (en) 2003-02-18 2010-03-02 Microsoft Corporation Multithreaded kernel for graphics processing unit
US7079147B2 (en) * 2003-05-14 2006-07-18 Lsi Logic Corporation System and method for cooperative operation of a processor and coprocessor
US7714870B2 (en) * 2003-06-23 2010-05-11 Intel Corporation Apparatus and method for selectable hardware accelerators in a data driven architecture
US7082508B2 (en) * 2003-06-24 2006-07-25 Intel Corporation Dynamic TLB locking based on page usage metric
US7765388B2 (en) * 2003-09-17 2010-07-27 Broadcom Corporation Interrupt verification support mechanism
US8566828B2 (en) 2003-12-19 2013-10-22 Stmicroelectronics, Inc. Accelerator for multi-processing system and method
US7302627B1 (en) 2004-04-05 2007-11-27 Mimar Tibet Apparatus for efficient LFSR calculation in a SIMD processor
US20050257186A1 (en) 2004-05-13 2005-11-17 Michael Zilbershlag Operation system for programmable hardware
US7370243B1 (en) 2004-06-30 2008-05-06 Sun Microsystems, Inc. Precise error handling in a fine grain multithreaded multicore processor
US8190863B2 (en) 2004-07-02 2012-05-29 Intel Corporation Apparatus and method for heterogeneous chip multiprocessors via resource allocation and restriction
US7388588B2 (en) * 2004-09-09 2008-06-17 International Business Machines Corporation Programmable graphics processing engine
US7437581B2 (en) 2004-09-28 2008-10-14 Intel Corporation Method and apparatus for varying energy per instruction according to the amount of available parallelism
US7676649B2 (en) * 2004-10-01 2010-03-09 Lockheed Martin Corporation Computing machine with redundancy and related systems and methods
US7350055B2 (en) 2004-10-20 2008-03-25 Arm Limited Tightly coupled accelerator
US7598958B1 (en) * 2004-11-17 2009-10-06 Nvidia Corporation Multi-chip graphics processing unit apparatus, system, and method
US8788787B2 (en) 2005-03-02 2014-07-22 The Boeing Company Systems, methods and architecture for facilitating software access to acceleration technology
US20060288193A1 (en) * 2005-06-03 2006-12-21 Silicon Integrated System Corp. Register-collecting mechanism for multi-threaded processors and method using the same
US7426626B2 (en) 2005-08-23 2008-09-16 Qualcomm Incorporated TLB lock indicator
US7583268B2 (en) 2005-11-10 2009-09-01 Via Technologies, Inc. Graphics pipeline precise interrupt method and apparatus
US7545381B2 (en) 2005-11-10 2009-06-09 Via Technologies, Inc. Interruptible GPU and method for context saving and restoring
US8212824B1 (en) * 2005-12-19 2012-07-03 Nvidia Corporation Apparatus and method for serial save and restore of graphics processing unit state information
US7725624B2 (en) 2005-12-30 2010-05-25 Intel Corporation System and method for cryptography processing units and multiplier
US7509481B2 (en) 2006-03-03 2009-03-24 Sun Microsystems, Inc. Patchable and/or programmable pre-decode
US7480838B1 (en) 2006-03-23 2009-01-20 Intel Corporation Method, system and apparatus for detecting and recovering from timing errors
US7746350B1 (en) * 2006-06-15 2010-06-29 Nvidia Corporation Cryptographic computations on general purpose graphics processing units
US7487341B2 (en) 2006-06-29 2009-02-03 Intel Corporation Handling address translations and exceptions of a heterogeneous resource of a processor using another processor resource
US8959311B2 (en) 2006-08-25 2015-02-17 Texas Instruments Incorporated Methods and systems involving secure RAM
US9478062B2 (en) * 2006-09-19 2016-10-25 Imagination Technologies Limited Memory allocation in distributed memories for multiprocessing
US7949887B2 (en) 2006-11-01 2011-05-24 Intel Corporation Independent power control of processing cores
US8127113B1 (en) 2006-12-01 2012-02-28 Synopsys, Inc. Generating hardware accelerators and processor offloads
US7827383B2 (en) 2007-03-09 2010-11-02 Oracle America, Inc. Efficient on-chip accelerator interfaces to reduce software overhead
US7937568B2 (en) 2007-07-11 2011-05-03 International Business Machines Corporation Adaptive execution cycle control method for enhanced instruction throughput
US7743232B2 (en) 2007-07-18 2010-06-22 Advanced Micro Devices, Inc. Multiple-core processor with hierarchical microcode store
US8345052B1 (en) 2007-11-08 2013-01-01 Nvidia Corporation Method and system for using a GPU frame buffer in a multi-GPU system as cache memory
US8339404B2 (en) 2007-11-29 2012-12-25 Accelereyes, Llc System for improving utilization of GPU resources
US8140823B2 (en) * 2007-12-03 2012-03-20 Qualcomm Incorporated Multithreaded processor with lock indicator
US7865675B2 (en) 2007-12-06 2011-01-04 Arm Limited Controlling cleaning of data values within a hardware accelerator
GB2455344B (en) * 2007-12-06 2012-06-13 Advanced Risc Mach Ltd Recovering from control path errors
US8780123B2 (en) 2007-12-17 2014-07-15 Nvidia Corporation Interrupt handling techniques in the rasterizer of a GPU
US7793080B2 (en) 2007-12-31 2010-09-07 Globalfoundries Inc. Processing pipeline having parallel dispatch and method thereof
US7877582B2 (en) 2008-01-31 2011-01-25 International Business Machines Corporation Multi-addressable register file
US8055872B2 (en) * 2008-02-21 2011-11-08 Arm Limited Data processor with hardware accelerator, accelerator interface and shared memory management unit
US8776077B2 (en) 2008-04-02 2014-07-08 Oracle America, Inc. Method for multithreading an application using partitioning to allocate work to threads
US8776030B2 (en) 2008-04-09 2014-07-08 Nvidia Corporation Partitioning CUDA code for execution by a general purpose processor
US8141102B2 (en) * 2008-09-04 2012-03-20 International Business Machines Corporation Data processing in a hybrid computing environment
US8230442B2 (en) * 2008-09-05 2012-07-24 International Business Machines Corporation Executing an accelerator application program in a hybrid computing environment
US8082426B2 (en) * 2008-11-06 2011-12-20 Via Technologies, Inc. Support of a plurality of graphic processing units
US20100274972A1 (en) 2008-11-24 2010-10-28 Boris Babayan Systems, methods, and apparatuses for parallel computing
US7930519B2 (en) * 2008-12-17 2011-04-19 Advanced Micro Devices, Inc. Processor with coprocessor interfacing functional unit for forwarding result from coprocessor to retirement unit
US8281185B2 (en) * 2009-06-30 2012-10-02 Oracle America, Inc. Advice-based feedback for transactional execution
US20110040924A1 (en) * 2009-08-11 2011-02-17 Selinger Robert D Controller and Method for Detecting a Transmission Error Over a NAND Interface Using Error Detection Code
US8458677B2 (en) 2009-08-20 2013-06-04 International Business Machines Corporation Generating code adapted for interlinking legacy scalar code and extended vector code
US8719547B2 (en) 2009-09-18 2014-05-06 Intel Corporation Providing hardware support for shared virtual memory between local and remote physical memory
US8405666B2 (en) * 2009-10-08 2013-03-26 Advanced Micro Devices, Inc. Saving, transferring and recreating GPU context information across heterogeneous GPUs during hot migration of a virtual machine
US8244946B2 (en) 2009-10-16 2012-08-14 Brocade Communications Systems, Inc. Interrupt moderation
US8316194B2 (en) * 2009-12-15 2012-11-20 Intel Corporation Mechanisms to accelerate transactions using buffered stores
US8166437B2 (en) 2009-12-15 2012-04-24 Apple Inc. Automated pad ring generation for programmable logic device implementation of integrated circuit design
US8095824B2 (en) * 2009-12-15 2012-01-10 Intel Corporation Performing mode switching in an unbounded transactional memory (UTM) system
US8970608B2 (en) 2010-04-05 2015-03-03 Nvidia Corporation State objects for specifying dynamic state
US9015443B2 (en) * 2010-04-30 2015-04-21 International Business Machines Corporation Reducing remote reads of memory in a hybrid computing environment
JP4818450B1 (ja) * 2010-06-30 2011-11-16 株式会社東芝 グラフィクスプロセッシングユニットおよび情報処理装置
US20120023314A1 (en) 2010-07-21 2012-01-26 Crum Matthew M Paired execution scheduling of dependent micro-operations
US8667253B2 (en) 2010-08-04 2014-03-04 International Business Machines Corporation Initiating assist thread upon asynchronous event for processing simultaneously with controlling thread and updating its running status in status register
US9552206B2 (en) * 2010-11-18 2017-01-24 Texas Instruments Incorporated Integrated circuit with control node circuitry and processing circuitry
US20120159090A1 (en) * 2010-12-16 2012-06-21 Microsoft Corporation Scalable multimedia computer system architecture with qos guarantees
US20120166777A1 (en) 2010-12-22 2012-06-28 Advanced Micro Devices, Inc. Method and apparatus for switching threads
CN102567556A (zh) * 2010-12-27 2012-07-11 北京国睿中数科技股份有限公司 一种面向调试的处理器验证方法及验证设备
CN102270166A (zh) * 2011-02-22 2011-12-07 清华大学 基于模拟器的处理器故障注入及跟踪方法及模拟器
US8683175B2 (en) * 2011-03-15 2014-03-25 International Business Machines Corporation Seamless interface for multi-threaded core accelerators
US8892924B2 (en) 2011-05-31 2014-11-18 Intel Corporation Reducing power consumption of uncore circuitry of a processor
US8793515B2 (en) 2011-06-27 2014-07-29 Intel Corporation Increasing power efficiency of turbo mode operation in a processor
US9003102B2 (en) * 2011-08-26 2015-04-07 Sandisk Technologies Inc. Controller with extended status register and method of use therewith
CN104011705A (zh) 2011-12-01 2014-08-27 新加坡国立大学 多形异构性多核架构
US20130159630A1 (en) 2011-12-20 2013-06-20 Ati Technologies Ulc Selective cache for inter-operations in a processor-based environment
US9436512B2 (en) 2011-12-22 2016-09-06 Board Of Supervisors Of Louisana State University And Agricultural And Mechanical College Energy efficient job scheduling in heterogeneous chip multiprocessors based on dynamic program behavior using prim model
US9268596B2 (en) * 2012-02-02 2016-02-23 Intel Corparation Instruction and logic to test transactional execution status
US9396020B2 (en) * 2012-03-30 2016-07-19 Intel Corporation Context switching mechanism for a processing core having a general purpose CPU core and a tightly coupled accelerator
WO2013147885A1 (en) * 2012-03-30 2013-10-03 Intel Corporation Apparatus and method for accelerating operations in a processor which uses shared virtual memory
US20130332937A1 (en) 2012-05-29 2013-12-12 Advanced Micro Devices, Inc. Heterogeneous Parallel Primitives Programming Model
US9753778B2 (en) 2012-07-20 2017-09-05 Microsoft Technology Licensing, Llc Domain-agnostic resource allocation framework
US9123128B2 (en) * 2012-12-21 2015-09-01 Nvidia Corporation Graphics processing unit employing a standard processing unit and a method of constructing a graphics processing unit
US9417873B2 (en) 2012-12-28 2016-08-16 Intel Corporation Apparatus and method for a hybrid latency-throughput processor
US20140189333A1 (en) * 2012-12-28 2014-07-03 Oren Ben-Kiki Apparatus and method for task-switchable synchronous hardware accelerators
US9053025B2 (en) * 2012-12-28 2015-06-09 Intel Corporation Apparatus and method for fast failure handling of instructions
US9361116B2 (en) 2012-12-28 2016-06-07 Intel Corporation Apparatus and method for low-latency invocation of accelerators
US9086813B2 (en) 2013-03-15 2015-07-21 Qualcomm Incorporated Method and apparatus to save and restore system memory management unit (MMU) contexts
US10031770B2 (en) 2014-04-30 2018-07-24 Intel Corporation System and method of delayed context switching in processor registers
US9703603B1 (en) 2016-04-25 2017-07-11 Nxp Usa, Inc. System and method for executing accelerator call

Also Published As

Publication number Publication date
KR20160124267A (ko) 2016-10-26
KR20150076198A (ko) 2015-07-06
WO2014105148A1 (en) 2014-07-03
KR101791811B1 (ko) 2017-10-30
US10089113B2 (en) 2018-10-02
US10083037B2 (en) 2018-09-25
US20140189332A1 (en) 2014-07-03
CN104813280B (zh) 2018-11-09
KR101764187B1 (ko) 2017-08-02
US9361116B2 (en) 2016-06-07
CN104813280A (zh) 2015-07-29
KR20160127156A (ko) 2016-11-02
US10095521B2 (en) 2018-10-09
US20170017492A1 (en) 2017-01-19
US20160246597A1 (en) 2016-08-25
US20170017491A1 (en) 2017-01-19
CN106547518A (zh) 2017-03-29
CN106547518B (zh) 2019-02-01

Similar Documents

Publication Publication Date Title
DE112013005338T5 (de) Vorrichtung und Verfahren für Beschleunigeraufruf mit geringer Latenz
DE112013005418T5 (de) Vorrichtung und Verfahren zur schnellen Befehlsfehlerbehandlung
US10664284B2 (en) Apparatus and method for a hybrid latency-throughput processor
DE112017001804T5 (de) Vorrichtung und Verfahren für träge synchrone Seitentabellenaktualisierungen mit geringem Aufwand
DE112012007119T5 (de) Threadmigration-Unterstützung für Kerne unterschiedlicher Architektur
DE112016005849T5 (de) Hardwarebeschleuniger und Verfahren für zustandsbehafetete Komprimierungs- und Dekomprimierungsoperationen
DE112011105122T5 (de) Systeme, Vorrichtungen und Verfahren zum Vermischen zweier Quelloperanden in einem einzigen Ziel unter Verwendung einer Schreibmaske
DE102018125817A1 (de) Systeme und Verfahren zum Laden eines Kachelregisterpaars
DE112011105666T5 (de) Befehl und Logik zum Bereitstellen von Vektor-Lade-OP/Speicher-OP mit Schritt-Funktionalität
DE102008061062A1 (de) Befehle und Logik zum Durchführen von Maskenlade- und -speicheroperationen
DE202019005682U1 (de) Hardwaregestützte Paging-Mechanismen
DE112012007063T5 (de) Zusammenfügen von benachbarten Sammel-/Streuoperationen
DE112019002389T5 (de) Architektur zur dynamischen umwandlung einer speicherkonfiguration
DE202016009016U1 (de) Befehle und Logik für wiederkehrende benachbarte Sammlungen
DE102018124945A1 (de) Einrichtung und verfahren für komplexe multiplikation
DE102018132521A1 (de) Vorrichtung und verfahren zur verflachung und reduktion von schleifen in einer single instruction, multiple data- (simd-) pipeline
US20140189333A1 (en) Apparatus and method for task-switchable synchronous hardware accelerators
DE112011105665T5 (de) Befehl und Logik zum Liefern von Vektorladen und -speichern mit Schritt- und Maskierfunktionalität
DE102018130225A1 (de) Entfernte atomare Operationen in Multi-Sockel-Systemen
DE102018131816A1 (de) Bedarfsgesteuerte speicherdeduplizierung
DE102015002253A1 (de) Verfahren und Vorrichtung zum Ausführen mehrerer Multiplikationsoperationen
DE102018126036A1 (de) Systeme und verfahren zum setzen eines kachelregisterpaars auf null
DE112016005909T5 (de) Einrichtung und verfahren zum beschleunigen von graphenanalyse
DE102014003659A1 (de) Systeme, vorrichtungen und verfahren zum bestimmen eines folgenden niedrigstwertigen maskierungsbits eines schreibmaskenregisters
DE102018128626A1 (de) Systeme, Verfahren und Vorrichtungen für Matrixoperationen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R130 Divisional application to

Ref document number: 112013007748

Country of ref document: DE

Ref document number: 112013007747

Country of ref document: DE

R016 Response to examination communication