DE102019104394A1 - Befehlssatzarchitektur zum ermöglichen von energieeffizientem rechnen für exascalearchitekturen - Google Patents

Befehlssatzarchitektur zum ermöglichen von energieeffizientem rechnen für exascalearchitekturen Download PDF

Info

Publication number
DE102019104394A1
DE102019104394A1 DE102019104394.8A DE102019104394A DE102019104394A1 DE 102019104394 A1 DE102019104394 A1 DE 102019104394A1 DE 102019104394 A DE102019104394 A DE 102019104394A DE 102019104394 A1 DE102019104394 A1 DE 102019104394A1
Authority
DE
Germany
Prior art keywords
instructions
dual
memory
packet
read
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
DE102019104394.8A
Other languages
English (en)
Inventor
Joshua B. Fryman
Jason M. Howard
Priyanka SURESH
Banu Meenakshi Nagasundaram
Srikanth Dakshinamoorthy
Ankit More
Robert Pawlowski
Samkit Jain
Pranav YEOLEKAR
Avinash M. SEEGEHALLI
Surhud Khare
Dinesh Somasekhar
David S. Dunning
Romain E. Cledat
William Paul GRIFFIN
Bhavitavya B. BHADVIYA
Ivan B. Ganev
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 DE102019104394A1 publication Critical patent/DE102019104394A1/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/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/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
    • 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/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • 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/30047—Prefetch instructions; cache control instructions
    • 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/3005—Arrangements for executing specific machine instructions to perform operations for flow control
    • 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/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/30087—Synchronisation or serialisation instructions
    • 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/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
    • 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
    • G06F9/3814—Implementation provisions of instruction buffers, e.g. prefetch buffer; banks
    • 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/3867—Concurrent instruction execution, e.g. pipeline or look ahead using instruction pipelines
    • 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
    • G06F9/3881—Arrangements for communication of instructions and data
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Advance Control (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

Offenbarte Ausführungsformen betreffen eine Befehlssatzarchitektur zum Ermöglichen von energieeffizientem Rechnen für Exascale-Architekturen. In einer Ausführungsform enthält ein Prozessor eine Vielzahl von Beschleunigerkernen, die jeweils eine entsprechende Befehlssatzarchitektur (ISA) aufweisen; einen Abrufschaltkreis zum Abrufen eines oder mehrerer Befehle, die einen der Beschleunigerkerne angeben, einen Decodierschaltkreis, um den einen oder die mehreren abgerufenen Befehle zu decodieren, und einen Erteilungsschaltkreis, um den einen oder die mehreren decodierten Befehle in die ISA zu übersetzen, die dem angegebenen Beschleunigerkern entspricht, den einen oder die mehreren übersetzten Befehle in ein Befehlspaket zu vereinigen und das Befehlspaket an den angegebenen Beschleunigerkern auszugeben; und wobei die Vielzahl der Beschleunigerkerne eine Arbeitsspeicherengine (MENG), eine Kollektivengine (CENG), eine Warteschlangenengine (QENG) und eine Kettenverwaltungseinheit (CMU) enthält.

Description

  • Diese Erfindung erfolgte mit Regierungsunterstützung im Rahmen der Vertragsnummern B608115 und B600747, vergeben vom US-Department of Energy. Die Regierung hat bestimmte Rechte an dieser Erfindung.
  • GEBIET DER ERFINDUNG
  • Das Gebiet der Erfindung betrifft allgemein eine Computerprozessorarchitektur und genauer eine Befehlssatzarchitektur zum Ermöglichen von energieeffizientem Rechnen für Exascale-Architekturen.
  • STAND DER TECHNIK
  • Exascale-Rechnen bezeichnet Computersysteme, die mindestens ein ExaFLOPS oder eine Milliarde Milliarde Berechnungen pro Sekunden durchführen können. Exascale-Systeme stellen eine komplexe Gruppe von Herausforderungen dar: Energie für Datenbewegungen kann die des Rechnens überschreiten und das Ermöglichen, dass Anwendungen die Fähigkeiten von Exascale-Rechensystemen vollständig unter Verwendung einer herkömmlichen Befehlssatzarchitektur (ISA) ausnutzen können, ist nicht einfach.
  • Figurenliste
  • Die vorliegende Erfindung wird in den Figuren der beiliegenden Zeichnungen beispielhaft, jedoch nicht einschränkend illustriert, in denen gleiche Referenzen ähnliche Elemente anzeigen und in denen gilt:
    • 1 veranschaulicht ein Beispiel einer Beschleunigerarchitektur zum Implementieren einer Befehlssatzarchitektur, um energieeffizientes Rechnen für Exascale-Architekturen zu ermöglichen;
    • 2 ist ein Blockdiagramm, das eine strategische Integration mehrerer Beschleunigerengines in ein Rechensystem nach einigen Ausführungsformen veranschaulicht;
    • 3 ist ein Blockdiagramm, das eine Integration einer Kollektivengine (CENG) in eine Kernpipeline nach einigen Ausführungsformen veranschaulicht;
    • 4 veranschaulicht Verhaltensweisen einiger weniger der kollektiven Vorgänge, die von der offenbarten Befehlssatzarchitektur unterstützt werden, nach einigen Ausführungsformen;
    • 5 veranschaulicht ein Zustandsablaufdiagramm für eine Reduktionszustandsmaschine nach einigen Ausführungsformen;
    • 6 veranschaulicht ein Zustandsablaufdiagramm für eine Multicastzustandsmaschine nach einigen Ausführungsformen;
    • 7 veranschaulicht eine Zustandsmaschine, die von einer Arbeitsspeicherengine (MENG) auf einer Pro-Thread-Basis implementiert wird, nach einigen Ausführungsformen;
    • 8 veranschaulicht ein Verhalten eines beispielhaften Copystride-Befehls mit direktem Arbeitsspeicherzugriff (DMA) nach einer Ausführungsform;
    • 9 ist ein Diagramm, das die Beziehung von Speicherung im maßgeschneiderten Zielbefehlsformat und Sammlung durch einen in den Arbeitsspeicher abgebildeten Übersetzer-Sammler-Eingabe/Ausgabe(TMMIO)-Block vor der Ausgabe an die Beschleuniger veranschaulicht, nach einer Ausführungsform;
    • 10 ist ein Blockablaufdiagramm, das eine Ausführung eines Arbeitsspeicherzugriffsbefehls durch einen in den Arbeitsspeicher abgebildeten Übersetzer-Sammler-Eingabe/Ausgabe(TMMIO)-Block veranschaulicht, nach einigen Ausführungsformen;
    • 11 ist ein Blockdiagramm, das eine Implementierung einer Warteschlangenengine (QENG) nach einigen Ausführungsformen veranschaulicht;
    • 12A ist ein Zustandsablaufdiagramm, das das offenbarte Zwischenspeicherkohärenzprotokoll nach einigen Ausführungsformen veranschaulicht;
    • 12B ist ein Blockdiagramm, das einen Zwischenspeichersteuerschaltkreis nach einer Ausführungsform veranschaulicht;
    • 13 ist ein Ablaufdiagramm, das einen von einer Zwischenspeichersteuerverschaltung durchgeführten Prozess nach einigen Ausführungsformen veranschaulicht;
    • 14 ist ein Diagramm eines Teils einer geschalteten Bus-Fabric zur Verwendung mit der offenbarten Befehlssatzarchitektur, nach einer Ausführungsform;
    • 15 ist ein Blockdiagramm, das eine Kapereinheit nach einigen Ausführungsformen zeigt;
    • 16 ist ein Blockdiagramm, das eine Kapereinheit nach einigen Ausführungsformen veranschaulicht;
    • 17 ist ein Blockdiagramm, das einen einzigen Ausführungsblock einer Kapereinheit nach einigen Ausführungsformen veranschaulicht;
    • 18A-18B sind Blockdiagramme, die ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen davon gemäß Ausführungsformen der Erfindung veranschaulichen;
    • 18A ist ein Blockdiagramm, das ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen der Klasse A davon nach Ausführungsformen der Erfindung illustriert;
    • 18B ist ein Blockdiagramm, das das generische vektorfreundliche Befehlsformat und Befehlsvorlagen der Klasse B davon nach Ausführungsformen der Erfindung illustriert;
    • 19A ist ein Blockdiagramm, das ein beispielhaftes spezifisches vektorfreundliches Befehlsformat nach Ausführungsformen der Erfindung illustriert;
    • 19B ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats illustriert, die das vollständige Opcode-Feld nach einer Ausführungsform der Erfindung bilden;
    • 19C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats illustriert, die das Registerindexfeld nach einer Ausführungsform der Erfindung bilden;
    • 19D ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats illustriert, das ein Operationszusatzfeld nach einer Ausführungsform der Erfindung bildet;
    • 20 ist ein Blockdiagramm einer Registerarchitektur nach einer Ausführungsform der Erfindung;
    • 21A ist ein Blockdiagramm, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline nach Ausführungsformen der Erfindung illustriert;
    • 21B ist ein Blockdiagramm, das sowohl ein Ausführungsbeispiel eines Kerns mit In-Order-Architektur als auch eines Kerns mit Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungsarchitektur illustriert, die in einem Prozessor nach Ausführungsformen der Erfindung enthalten sein sollen;
    • 22A-B illustrieren ein Blockdiagramm einer spezifischeren beispielhaften In-Order-Kernarchitektur, wobei der Kern einer von mehreren logischen Blöcken (die andere Kerne des gleichen Typs und/oder anderer Typen enthalten) in einem Chip wäre;
    • 22A ist ein Blockdiagramm eines einzelnen Prozessorkerns, zusammen mit seiner Verbindung an das chipinterne Verbindungsnetz und mit seinem lokalen Teilsatz des Level-2(L2)-Zwischenspeichers ist, nach Ausführungsformen der Offenbarung;
    • 22B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 22A nach Ausführungsformen der Erfindung;
    • 23 ist ein Blockdiagramm eines Prozessors, der nach Ausführungsformen der Erfindung mehr als einen Kern aufweisen kann, eine integrierte Arbeitsspeichersteuerung aufweisen kann und integrierte Grafik aufweisen kann;
    • 24-27 sind Blockdiagramme von beispielhaften Computerarchitekturen;
    • 24 zeigt ein Blockdiagramm eines Systems nach einer Ausführungsform der vorliegenden Erfindung;
    • 25 ist ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems nach einer Ausführungsform der vorliegenden Erfindung;
    • 26 ist ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems nach einer Ausführungsform der vorliegenden Erfindung;
    • 27 ist ein Blockdiagramm eines Ein-Chip-Systems (SoC) in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung; und
    • 28 ist ein Blockdiagramm, das die Verwendung eines Softwarebefehlswandlers gegenüberstellt, um binäre Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz nach Ausführungsformen der Erfindung umzuwandeln.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt. Es ist jedoch klar, dass Ausführungsformen der Erfindung ohne diese spezifischen Details praktiziert werden können. In anderen Fällen wurden wohlbekannte Schaltkreise, Strukturen und Techniken nicht im Detail gezeigt, um das Verständnis dieser Beschreibung nicht zu verschleiern.
  • Bezugnahmen in der Beschreibung auf „eine Ausführungsform“, „ein Ausführungsbeispiel“ usw. zeigen an, dass die beschriebene Ausführungsform ein Merkmal, eine Struktur oder Eigenschaft enthalten kann, aber jede Ausführungsform muss nicht notwendigerweise das Merkmal, die Struktur oder Eigenschaft enthalten. Darüber hinaus beziehen sich solche Formulierungen nicht notwendigerweise auf die gleiche Ausführungsform. Ferner, wenn ein Merkmal, eine Struktur oder Eigenschaft einer Ausführungsform beschrieben wird, wird vorgebracht, dass es im Wissen von Fachleuten liegt, ein solches Merkmal, eine solche Struktur oder Eigenschaft anderer Ausführungsformen zu erwirken, falls es bzw. sie explizit beschrieben wird.
  • Es wird erwartet, dass eine verbesserte Befehlssatzarchitektur (ISA), wie sie hierin offenbart wird, neue Programmiermodelle mit reduzierter Kerngröße und Gesamtsystemenergieeffizienz ermöglicht. Die offenbarte ISA beseitigt einige der einzigartigen Herausforderungen von Exascale-Architekturen. Exascale-Systeme stellen einen komplexe Gruppe von Herausforderungen: (1) Ein Energieaufwand für Datenbewegungen überschreitet den für das Rechnen; (2) bestehende Architekturen weisen keine Befehlssemantik auf, um eine energieeffiziente Datenbewegung anzugeben; und (3) eine Beibehaltung von Kohärenz ist eine Herausforderung.
  • Die hierin offenbarte ISA versucht, diese Probleme mit spezifischen Befehlen für eine effiziente Datenbewegung, softwareverwaltete (SW-verwaltete) Kohärenz, hardwareunterstützte (HW-unterstützte) Warteschlangenverwaltung und Kollektivoperationen zu lösen. Die offenbarte ISA enthält mehrere Typen von Kollektivoperationen, einschließlich unter anderem Reduktionen, vollständiger Reduktionen (Reduktion-auf-alle), Multicasts, Broadcasts, Barrieren und paralleler Präfixoperationen. Die offenbarte ISA enthält mehrere Klassen von Befehlen, von denen erwartet wird, dass sie Programmiermodelle mit reduziertem Gesamtsystemenergieverbrauch unterstützen. Diese mehreren Typen von Rechenoperationen werden unten beschrieben, einschließlich in Abschnitten mit den folgenden Überschriften:
    • • Kollektivsystemarchitektur;
    • • vereinfachte asynchrone Kollektivengine (CENG) mit niedrigem Mehraufwand;
    • • eine ISA-unterstützte Mikro-DMA-Engine und Arbeitsspeicherengine (MENG);
    • • duale Arbeitsspeicher-ISA-Operationen;
    • • in den Arbeitsspeicher abgebildete Eingabe/Ausgabe(E/A)-basierte ISA-Erweiterung und Übersetzung;
    • • vereinfachte hardwareunterstützte Warteschlangenengine (QENG);
    • • Befehlsverkettung für strenge Gliederung;
    • • Zwischenspeicherkohärenzprotokoll mit Weiterleitungs-/Eigenzustand zur Arbeitsspeicherzugriffsreduktion in einer Mehrkern-CPU;
    • • geschaltete Bus-Fabric zum Verbinden mehrerer Kommunikationseinheiten; und
    • • Paketkapermechanismus mit Leitungsgeschwindigkeit für lokale Analyse, Modifikation und/oder Ablehnung.
  • 1 veranschaulicht ein Beispiel einer Beschleunigerarchitektur zum Implementieren einer Befehlssatzarchitektur, um energieeffizientes Rechnen für Exascale-Architekturen zu ermöglichen (d. h. Rechensysteme, die mindestens ein Exaflop, oder eine Milliarde Milliarden Berechnungen pro Sekunde durchführen können). Wie gezeigt enthält System 100 Daten- und Befehlszwischenspeicher auf erster Ebene, einen Befehlszwischenspeicher erster Ebene (L1 I
    Figure DE102019104394A1_0001
    102) mit einem Zwischenspeichersteuerschaltkreis (CC 102A) und einen Datenzwischenspeicher erster Ebene (L1 D 104) mit einem Zwischenspeichersteuerschaltkreis (CC 104A) und einen L1-Scratch-Block (SPAD) 106 und einen SPAD-Steuerschaltkreis (SC 106A). Jeder der Arbeitsspeicher der ersten Ebene, L1 I 102, L1 D 104 und der L1-Scratch-Block (SPAD 106) kann eine Schnittstelle mit Zwischenspeichergröße zu einem entsprechenden Arbeitsspeicher einer zweiten Ebene aufweisen.
  • Das System 100 enthält auch einen Kern 108, der einen Abrufschaltkreis 110 (der über die Zwischenspeichersteuerung (CC102A) mit dem Befehlszwischenspeicher auf erster Ebene (L1 I 102) verbunden ist), einen Decodier- und Operandenabrufschaltkreis 112 (der über die SPAD-Steuerung (SC 106A) und eine Registerdatei 136 mit einem Nachrichtentransportpuffer 128, der Registerdatei 136 und dem Scratch-Block (SPAD 106) verbunden ist), einen Integer-Schaltkreis 114 (um ganzzahlige Operationen durchzuführen), einen Lade-/Speicher-/atomaren Schaltkreis 116 (der über CC 102A mit L1 I 102, über CC 104A mit L1 D 104, über 106A mit L1 SPAD 106 und dem Nachrichtentransportpuffer 128 verbunden ist) und einen Festschreib-Stilllegungs-/Registerdatei(RF)-Aktualisierungsschaltkreis 118 enthält. Wie gezeigt ist der Decodier- und Operandenabrufschaltkreis 112 über drei 64-Bit-Anschlüsse an die Registerdatei 136 gekoppelt, was ermöglicht, dass gleichzeitig auf mehrere Register zugegriffen wird. (Es ist anzumerken, dass mehrere Verbindungsleitungen oder Busse in 1 eine Bitbreitenkennzeichnung wie „/64b“ enthalten, um die Breite der Leitung anzuzeigen. Steuer- und Adressleitungen sind nicht gezeigt. Es ist auch anzumerken, dass die ausgewählten Bitbreiten und Anschlussgrößen nur Implementierungswahlen der Ausführungsform sind und die Erfindung nicht einschränken sollen.) Der Nachrichtentransportpuffer 128 enthält eine atomare Einheit (AU 130), einen Puffer 132 (der zweiundreißig 32B-Puffereinträge und sieben Lese/Schreib-Anschlüsse enthält) und einen Arbiter (ARB) 134. Der Nachrichtentransportpuffer 128 ist über 64-Bit-Leitungen an ein Netzwerk zwischen den Beschleunigern 138 und über 64-bit-Leitungen an den Decodier- und Operandenabrufschaltkreis 112, an den Lade-/Speicher-/atomaren Schaltkreis 116, an die Registerdatei 136 und an die Beschleunigerengines 120 gekoppelt, die eine Arbeitsspeicherengine (MENG 122), eine Warteschlangenengine (QENG 124) und eine Kollektivengine (CENG 126) enthalten.
  • Im Betrieb hat der Kern 108 DMA-Befehle zu generieren und diese an die Arbeitsspeicherengine zu senden (MENG 122, wie weiter hierin im Abschnitt mit dem Titel „ISAgestützte Mikro-DMA-Engine“ beschrieben), Befehle zur Warteschlangenengine hinzuzufügen und aus dieser zu entfernen (QENG 124, wie weiter hierin im Abschnitt mit dem Titel „Vereinfachte hardwareunterstützte Warteschlange“ beschrieben) und Kollektivoperationsbefehle unter Verwendung der Kollektivengine auszuführen (CENG 126, wie weiter hierin im Abschnitt mit dem Titel „Kollektivsystemarchitektur“ beschrieben).
  • In einigen Ausführungsformen wird die CENG 126 verwendet, um den Kern 108 mit anderen Kernen (nicht gezeigt) über das Netzwerk zwischen Beschleunigern 138 zu gruppieren. Insbesondere kann die CENG 126 und jede CENG in anderen Kernen einen Satz von drei „Eingabe“-Registern, ein „Ausgabe“-Register sowie Status- und Steuerregister enthalten, wobei ein Eingaberegister für den lokalen Kern reserviert ist und die anderen zwei Eingaberegister von Software programmiert sind, um entweder auf NULL (keine Eingabe erwartet) oder die Adresse eines Ausgaberegisters eines anderen Kerns zu zeigen. Die Paarung von der „Eingaberegisteradresse an Kern K“ entsprechenden „Ausgaberegisteradresse an Kern J“ erzeugt tatsächlich eine doppelt verknüpfte softwaregesteuerte Liste. Dies ermöglicht eine Traversierung in beide Richtungen innerhalb des definierten Graphen, den diese Ausgänge und Eingänge definieren.
  • Wie gezeigt kommuniziert die CENG 126 mit ihren Nachbarknoten, die in ihre drei „Eingabe“-Register und ein „Ausgabe“-Register programmiert sind, unter Verwendung des Netzwerks zwischen Beschleunigern 138 über den Nachrichtentransportpuffer 128. Jeder im resultierenden Graphen enthaltene Agent wird als Vertex angesehen. Auf diese Weise wird durch Software ein pseudo-ternärer Baum konstruiert, um das Kommunikationsmuster - einschließlich aller notwendigen Reihenfolgen - für mathematische Eigenschaften (wie Gleitkomma(FP)-Assoziativität) darzustellen - die entweder vorwärts oder rückwärts verlaufen können. Ein „Ausgabe“-Register mit einem NULL-Wert definiert den Wurzelknoten eines Baums, da es über diesen Agenten hinaus keine Kommunikation gibt. Der Kern und die Ausführungsverschaltung von offenbarten Ausführungsformen werden zumindest in Bezug auf 5-7, 10 und 20-23 weiter beschrieben und veranschaulicht. Die Architektur des Rechensystems 100 wird unten weiter beschrieben und veranschaulicht, zumindest in Bezug auf 24-28.
  • Mehrere Instanzen der CENG und des Zustands können pro Kern vorhanden sein, was ermöglicht, dass mehrere Bäume gleichzeitig und optional überlappend definiert und ohne Nachteil verwendet werden.
  • 2 ist ein Blockdiagramm, das eine strategische Integration mehrerer Beschleunigerengines in ein Rechensystem nach einigen Ausführungsformen veranschaulicht. Wie gezeigt enthält ein Rechensystem 200 einen Prozessor 201, einen Chipsatz 222, einen optionalen Coprozessor 224 und einen Systemarbeitsspeicher 226. Der Prozessor 201 enthält mehrere Kerne 204, 206, 208 und 210, sowie einen Grafikprozessor 212, einen gemeinsam genutzten Level-3(L3)-Zwischenspeicher 214, einen Zwischenspeichersteuerschaltkreis 215, eine Arbeitsspeicherschnittstelle 216 (die an den Systemarbeitsspeicher 226 gekoppelt ist), einen Systemagenten 218 (der an den Chipsatz 222 gekoppelt ist) und eine Arbeitsspeichersteuerung 220. Eine Zwischenverbindung 202 koppelt alle der Komponenten 204, 206, 208, 210, 212, 214, 216, 218 und 220 des Prozessors 201 kommunikativ. In einigen Ausführungsformen ist ein Kaperschaltkreis 203 wie gezeigt in den Systemagenten 218 eingebunden. Es ist anzumerken, dass die spezifische Platzierung der Engines in Bezug auf die Pipeline und andere Merkmale ohne Einschränkung variieren kann; Engines können auf Grundlage von Überlegungen in Bezug auf Kosten, Fläche und Leistung bewegt oder auf unterschiedliche Weise miteinander verbunden sein. Der Zwischenspeichersteuerschaltkreis 215 und das durch offenbarte Ausführungsformen angewandte Zwischenspeicherkohärenzprotokoll werden unten weiter beschrieben und veranschaulicht, zumindest in Bezug auf 12A-12B. Die Kaperschaltkreise werden unten weiter beschrieben und veranschaulicht, zumindest in Bezug auf 15-17. Die Architektur des Prozessors 201 wird weiter in Bezug auf 20-23 beschrieben und veranschaulicht. Die Architekturen des Rechensystems 200 und des Prozessors 201 werden unten weiter beschrieben und veranschaulicht, zumindest in Bezug auf 24-28.
  • Der Kern 204 enthält eine Pipeline 204A, CENG 204B, QENG 204C, MENG 204D, Level-Eins-Befehlszwischenspeicher (L1I 204E), Level-Eins-Datenzwischenspeicher (L1D 204F) und einen vereinten Level-Zwei-Zwischenspeicher (L2 204G). Gleichermaßen enthält der Kern 206 eine Pipeline 206A, CENG 206B, QENG 206C, MENG 206D, Level-Eins-Befehlszwischenspeicher (L1I 206E), Level-Eins-Datenzwischenspeicher (L1D 206F) und einen vereinten Level-Zwei-Zwischenspeicher (L2 206G). Gleichfalls enthält der Kern 208 eine Pipeline 208A, CENG 208B, QENG 208C, MENG 208D, Level-Eins-Befehlszwischenspeicher (L1I 208E), Level-Eins-Datenzwischenspeicher (L1D 208F) und einen vereinten Level-Zwei-Zwischenspeicher (L2 208G). Der Kern 210 enthält auch eine Pipeline 210A, CENG 210B, QENG 210C, MENG 210D, Level-Eins-Befehlszwischenspeicher (L1I 210E), Level-Eins-Datenzwischenspeicher (L1D 210F) und einen vereinten Level-Zwei-Zwischenspeicher (L2 210G). Die Komponenten und das Layout der Prozessoren und Rechensysteme der offenbarten Ausführungsformen werden weiter beschrieben und veranschaulicht, zumindest in Bezug auf 23-28.
  • Es ist anzumerken, dass jede der Engines, MENG, CENG und QENG, wie gezeigt strategisch in ihren assoziierten Kern eingebunden wurde, wobei eine Strategie ausgewählt wurde, um die Leistung zu maximieren und Kosten und Energieverbrauch zu minimieren. Im Kern 204 wurde die MENG 204D zum Beispiel gleich neben die Level-1- und Level-2-Zwischenspeicher platziert.
  • KOLLEKTIVOPERATIONEN
  • In „Kollektivreduktionen“, wobei jeder Kern möglicherweise dazu beiträgt, einen Wert (wie ein „globales Maximum“) zu finden, verläuft der Baum von Blattknoten zum Vertex; sobald der endgültige Wert („das globale Maximum“) am Wurzelknoten gefunden wird, wird der Baum rückwärts durchlaufen, um den Ergebniswert zurück an jeden teilnehmenden Kern via Broadcast zu übermitteln.
  • Auf ähnliche Weise kann der Baum auch Broadcast-/Multicast-Operationen durchführen, indem er den „über Multicast zu übermittelnden Wert“ direkt an den Wurzelknoten weiterzuleiten, wonach der Wurzelknoten die Nachricht zurück hinunter an die Blattknoten weiterleitet, wobei der Graph rückwärts gefolgt wird.
  • Ähnliche Modifikationen können verwendet werden, um Barrieren zu unterstützen, die eine Mischung von Reduktions- und Multicast-Verhalten sind.
  • Die offenbarte ISA unterstützt zumindest die in Tabelle 1 und Tabelle 2Error! Reference source not found. aufgelisteten Kollektivoperationsbefehle. Die aufgelisteten Befehle können auf ISA-Ebene aufgerufen werden.
  • Um der CENG zu ermöglichen, Kollektivoperationen durchzuführen, konfiguriert Software die CENG durch Programmieren einiger modellspezifischer Register (MSRs) innerhalb jeder der teilnehmenden CENGs. Mehrere gleichzeitige Sequenzen (bis zu N Operationen) würden naturgemäß N Kopien der jeweiligen MSRs definieren. Software konfiguriert das Kollektivsystem folgendermaßen. Vor Beginn aller CENG-Operationen hat Software zuerst einige MSRs innerhalb der CENG zu konfigurieren. Eine Barrierenkonfiguration erfolgt auf Blockebene, während eine Reduktions- und Multicast-Konfiguration auf Ebene von Ausführungseinheiten (XE) erfolgt. Software programmiert danach „Eingabe“- und „Ausgabe“-Adress-MSRs für Reduktion und Multicast. Danach setzt die Software die entsprechenden Aktivierungsbits im REDUCE_CFG/MCAST_CFG-Register. Die Software setzt dann das Aktivierungsbit, um den CENG-FSM zu konfigurieren, vor dem Durchführen der Reduktions-/Multicast-Operation auf die richtige Anzahl von Eingaben zu warten.
  • KOLLEKTIVSYSTEMARCHITEKTUR
  • VEREINFACHTE ASYNCHRONE KOLLEKTIVENGINE (CENG) MIT NIEDRIGEM MEHRAUFWAND
  • Kollektivoperationen sind häufige und kritische Operationen in Parallelanwendungen. Beispiele von Kollektivoperationen enthalten unter anderem: Reduktionen, vollständiger Reduktionen (Reduktion-auf-alle), Broadcasts, Barrieren und paralleler Präfixoperationen. Die offenbarte Befehlssatzarchitektur enthält spezifische Befehle, um eine Ausführung von Kollektivoperationen zu ermöglichen.
  • Die offenbarte Befehlssatzarchitektur definiert eine Kollektivengine (CENG), die Verschaltung enthält, um eine oder mehrere Zustandsmaschinen zu pflegen, um eine Ausführung von Kollektivoperationen zu verwalten. In einigen Ausführungsformen enthält die CENG Hardware-Zustandsmaschinen, die eine Ausführung von Kollektivoperationen verwalten, egal ob in Form von Barrieren, Reduktionen, Broadcast oder Multicast. In einigen Ausführungsformen ist die CENG eine vereinfachte asynchrone Auslagerungsengine, die eine beliebige Architekturplattform und ISA unterstützen kann. Sie stellt eine einheitliche Schnittstelle dar, die Broadcast, Multicast, Reduktionen und Barrieren über maßgeschneiderte (softwaredefinierte) Sammlungen von Kernen ermöglicht. Ohne die offenbarte CENG und spezifische Kollektivoperationsbefehle würde Software mehrere Speichervorgänge ausgeben müssen, um einen in den Arbeitsspeicher abgebildeten Eingabe/Ausgabe(MMIO)-Block zu konfigurieren, um den Transfer zu starten.
  • 3 ist ein Blockdiagramm, das eine Integration einer Kollektivengine (CENG) in eine Kernpipeline nach einigen Ausführungsformen veranschaulicht. Wie gezeigt ist die Eingabeschnittstelle 302 gekoppelt, um Befehle von der Enginesequenzierungswarteschlange (ESQ) und einem Universalarbiter (UARB) über einen Pfad ESQ→UARB 314 oder vom Universalarbiter (UARB 316, manchmal als „ubiquitärer“ Arbiter bezeichnet) zu empfangen. Die Eingabeschnittstelle 302 enthält Puffer (nicht gezeigt), um empfangene Befehle zu speichern. In einigen Ausführungsformen enthält die Eingabeschnittstelle 302 einen Befehlsdecodierschaltkreis 304, um empfangene Befehle zu decodieren. Die Eingabeschnittstelle 302 ist über einen Pfad 318 an einen CENG-Datenpfad 308 und über einen Pfad 320 an eine endliche CENG-Zustandsmaschine (CENG-FSM 310) gekoppelt. Die CENG 306 ist über einen Pfad 322 an eine Ausgabeschnittstelle 312 gekoppelt. In einigen Ausführungsformen ist die Ausgabeschnittstelle 312 an die Kernpipeline gekoppelt, um zum Beispiel Ergebnisse an eine Decodierstufe oder an eine Festschreib-/Stilllegungsstufe zu senden.
  • Im Betrieb empfängt die Eingabeschnittstelle 302 in dem Fall, dass ein Kollektivoperationsbefehl von einer Kernpipeline im gleichen Kern wie die CENG 306 generiert wird, über den Pfad ESQ→UARB 314 einen Kollektivoperationsbefehl von der Enginesequenzierungswarteschlange (ESQ) und dem Universalarbiter (UARB). Für Kollektivoperationsbefehle, die von einer anderen CENG in einem anderen Kern ausgehen, empfängt die Eingabeschnittstelle 302 den Kollektivoperationsbefehl von einem Nachrichtentransportpuffer (MTB) und dem Universalarbiter (UARB) über einen Pfad MTB→UARB 316.
  • Die Eingabeschnittstelle 302 puffert die empfangenen Kollektivoperationsbefehle in Puffern, bis sie ausgeführt worden sind oder an die Kernpipeline zurückgeleitet worden sind. In einigen Ausführungsformen puffert die Eingabeschnittstelle 302 eingehende Kollektivoperationsbefehle in einem First-in-First-out(FIFO)-Puffer (nicht gezeigt). In einigen Ausführungsformen puffert die Eingabeschnittstelle 302 eingehende Kollektivoperationsbefehle in einem statischen Direktzugriffsspeicher (SRAM) (nicht gezeigt). In einigen Ausführungsformen puffert die Eingabeschnittstelle 302 eingehende Kollektivoperationsbefehle in einer Registerbank (nicht gezeigt).
  • Die CENG 306 verarbeitet die empfangenen Kollektivoperationsbefehle unter Verwendung des CENG-Datenpfads 308 zusammen mit der endlichen CENG-Zustandsmaschine (CENG-FSM 310). Ein veranschaulichendes Beispiel der CENG-FSM 310 wird unten veranschaulicht und besprochen, zumindest in Bezug auf 6. Nach dem Abschluss kommuniziert die CENG 306 die Nachricht über den Pfad 322 an die Ausgabeschnittstelle 312. Die Ausgabeschnittstelle 312 kommuniziert dann mit dem Universal- oder ubiquitären Arbiter (URAB) und der Registerdatei (RF) über einen Pfad UARB→RF 324 und mit dem UARB→MTB über einen Pfad UARB→MTB 326. Kollektivoperationen können viele kleine Nachrichten erfordern und erfordern oft Barrieren nach dem Einrichten teilnehmender Kerne und bevor die erste Operation stattfinden kann.
  • 4 veranschaulicht Verhaltensweisen einiger weniger der kollektiven Vorgänge, die von der offenbarten Befehlssatzarchitektur unterstützt werden, nach einigen Ausführungsformen. Wie gezeigt nehmen mehrere (hier fünf) Knoten eines parallelen Verarbeitungssystems an beispielhaften Kollektivoperationen teil. Veranschaulichte Kollektivoperationen 400 enthalten einen Broadcast 402, durch den ein Wurzelwert von ,9' von einer Wurzel an die teilnehmenden Knoten per Broadcast ausgesandt wird; eine Streuung 404, durch die jedes Element eines Arrays von vier Werten von einem Wurzelknoten an vier teilnehmende Knoten gestreut wird; eine Reduktion (Add.) 406, durch die eine Summe ,8' der Werte der anderen Knoten am Wurzelknoten zusammengestellt wird; eine Sammlung 408, durch die vier Werte von vier Knoten gesammelt werden und in ein Array am Wurzelknoten gespeichert werden; eine Reduktion (Mul.) 410, durch die ein Produkt ,18' der Werte der anderen Knoten am Wurzelknoten gesammelt wird; und eine Reduktion (bitweises ODER) 412, durch die ein bitweises ODER an einem Wurzelknoten von den vier anderen Knoten zusammengestellt wird. Im Betrieb können die verschiedenen teilnehmenden Knoten unterschiedliche Zeitmengen zum Bereitstellen ihrer Ergebnisse benötigen, sodass der Wurzelknoten möglicherweise auf ein Eintreffen mehrerer derartiger Elemente warten muss. In einigen Ausführungsformen kann bzw. können der endgültige Wert oder inkrementelle Werte, der bzw. die durch einen Knoten generiert wird bzw. werden, der an einer Kollektivoperation teilnimmt, an diese Knoten zurück propagiert werden, die vor diesem teilgenommen haben.
  • Durch Bereitstellen von Befehlen zur Unterstützung von Kollektivoperationen stellt die offenbarte ISA eine Verbesserung an einer Prozessorarchitektur dar, zumindest dahingehend, dass sie für den Programmierer natürlich ist und dies ein effizientes Mittel bieten kann, zwischen einem Pool von Prozessoren zu kommunizieren. Tabelle 1 führt unten einige der von der offenbarten ISA unterstützten Kollektivoperationen auf und Tabelle 2 listet einige Aufrufformate für Kollektivoperationen einschließlich der Anzahl von Operanden, die die offenbarte ISA erzeugen. Tabelle 1
    Befehl Beschreibung
    All-to-All Jeder Knoten streut und sammelt ein Array
    AllGather Eine Sammlung, gefolgt von einem Broadcast
    AllReduce Eine Reduktion, gefolgt von einem Broadcast
    Barrier Warten, bis jeder Knoten eine gleiche Barriere erreicht
    Broadcast Senden eines Elements an alle teilnehmenden Knoten
    Gather Sammeln eines Elements von allen teilnehmenden Knoten
    Multicast Senden eines Elements an mehrere Knoten
    Prefix Eine Reduktion, wobei die Teilergebnisse behalten werden
    Reduktion Sammeln eines Elements von allen teilnehmenden Knoten und Durchführen einer Operation (z. B. min, max, Summe, Produkt, logisch), um ein Ergebnis zu erzeugen
    Scatter Verteilen eines Arrays von Werten, wobei jedem teilnehmenden Knoten ein anderer Wert gegeben wird
    Tabelle 2
    Befehl Operanden Details
    barrier.init Initialisieren einer Barriere
    barrier.wait Warten, bis Barriere erreicht ist
    barrier.poll r1 r1=Status der Barriere (nicht blockierend)
    mcast.reg r1, r2 r1=Zielreg. am teilnehmenden XE, r2=Quellreg., von dem mcast
    mcast.mem r1, r2 r1=Zielreg. am teilnehmenden XE, r2=Arbeitssp.adresse, von der mcast
    reduce.wait Warten (Anhalten der XE-Pipeline), bis die Reduktion abgeschlossen ist
    reduce.poll r1 r1=Status der Reduktion (nicht blockierend)
    reduce.maxF r1, r2 r1=Zielreg., r2=Quellreg., von dem max zu reduzieren ist (auch Zieladresse)
    reduce.maxU r1, r2 r1=Zielreg., r2=Quellreg., von dem max zu reduzieren ist (auch Zieladresse)
    reduce.maxS r1, r2 r1=Zielreg., r2=Quellreg., von dem max zu reduzieren ist (auch Zieladresse)
    reduce.minF r1, r2 r1=Zielreg., r2=Quellreg., von dem min zu reduzieren ist (auch Zieladresse)
    reduce.minU r1, r2 r1=Zielreg., r2=Quellreg., von dem min zu reduzieren ist (auch Zieladresse)
    reduce.minS r1, r2 r1=Zielreg., r2=Quellreg., von dem min zu reduzieren ist (auch Zieladresse)
    reduce.addF r1, r2 r1=Zielreg., r2=zu addierendes Quellreg.
    reduce.addl r1, r2 r1=Zielreg., r2=zu addierendes Quellreg.
    reduce.mulF r1, r2 r1=Zielreg., r2=zu multiplizierendes Quellreg.
    reduce.mull r1, r2 r1=Zielreg., r2=zu multiplizierendes Quellreg.
    reduce.bitop1 r1, r2 r1=Zielreg., r2=Quellreg., an dem Bitoperation durchzuführen ist (und, oder, xor, ..)
  • Die offenbarte Befehlssatzarchitektur integriert spezifische Befehle in die ISA zum Durchführen von Kollektivoperationen. Software kann Barriere-/Reduktions-/Multicast-Netzwerke aufbauen und verwalten und diese Operationen entweder auf blockierende oder nicht blockierende Weise durchführen (d. h. aus der Kernpipeline ausgelagert). In einigen Ausführungsformen ist eine „Abruf“-Funktion enthalten und ermöglicht einen nicht blockierenden Betrieb, wenn mehr Arbeit durchgeführt werden kann und die Ressource noch nicht im Kollektiv aufgelöst wurde. Die offenbarte ISA sieht drei Gruppen von Kollektivoperationen vor - Initialisierung, Abrufen und Warten. Das Initialisieren startet die Kollektivoperation. Warten hält einen Kern an, bis die Kollektivoperation abgeschlossen ist. Abrufen gibt den Status der Kollektivoperation zurück.
  • Die offenbarte ISA beschreibt auch Verschaltung, die verwendet werden kann, um die spezifischen Kollektivbefehle auszuführen. Für Barriereoperationen wählt nach der offenbarten ISA ein Blockebenen-Einzelbit- UND/ODER-Baum-Barrierenetzwerk mit einer softwareverwalteten Konfiguration Ausführungseinheiten (XEs) zur Teilnahme an jeder Barriere aus. In einigen Ausführungsformen gibt es eine CENG-Instanz in jedem Beschleunigerkern mit einem adressbasierten Reduktions-/Multicast-Netzwerk, das durch Software konfigurierbar ist.
  • 5 veranschaulicht ein Zustandsablaufdiagramm für eine Reduktionszustandsmaschine, die durch eine Kollektivengine (CENG) implementiert ist, nach einigen Ausführungsformen. Reduktionen sind einer von mehreren Typen von Kollektivoperationen, die von der offenbarten ISA vorgesehen sind und von der CENG implementiert werden. Mindestens einige der von der offenbarten ISA unterstützten Kollektivoperationen sind in Bezug auf Tabelle 1 und Tabelle 2 aufgelistet und beschrieben.
  • Wie in 5 gezeigt enthält eine endliche Reduktions-Zustandsmaschine 500 sechs Zustände: (Leerlauf 502), (Ergebnisweiterleitung 504), (Ergebnismulticast 506), (Befehlsprüfung 508), (Ausführung 512) und (Ergebnisverarbeitung 510).
  • In Betrieb beginnt die CENG, die die Reduktions-Zustandsmaschine implementiert, beispielsweise nach einer Rücksetzung 514 oder einem Einschalten im Zustand (des Leerlaufs 502), in dem sie auf einen Befehl wartet. Wenn eine neue Eingabe (z. B. ein Wert von einem an der Reduktionsoperation teilnehmenden Knoten) oder ein Befehl (z. B. ein Reduktionsbefehl) eintrifft, geht die Zustandsmaschine über einen Bogen 522 in den Zustand (der Befehlsprüfung 508), in dem sie ermittelt, ob weitere Eingaben erwartet werden (z. B. von anderen Knoten, die an der Reduktionsoperation teilnehmen) oder ob der Befehl bereit ist, verarbeitet zu werden. Falls weitere Eingaben erwartet werden, geht die Zustandsmaschine über einen Bogen 520 zurück in den Zustand (des Leerlaufs 502), um auf weitere Eingaben zu warten.
  • Andernfalls, falls keine weiteren Eingaben erwartet werden und nur lokale Eingaben (d. h. von diesem Knoten) involviert sind, geht die CENG-Zustandsmaschine über einen Bogen 532 in den Zustand (der Ergebnisverarbeitung 510) über, in dem die Reduktionsoperation (z. B. eine Addition, Multiplikation, Logik) durchgeführt wird. In einigen Szenarien ermittelt die CENG im Zustand (der Befehlsprüfung 508), dass eine Eingabe von einem anderen Knoten erforderlich ist, wobei die Zustandsmaschine in diesem Fall über einen Bogen 536 in den Zustand (der Ausführung 512) übergeht, wonach die CENG über einen Bogen 538 den Befehl an den Nachrichtentransferpuffer (MTB) sendet, sodass er von einem anderen Knoten verarbeitet wird, und wartet auf ein Ergebnis von dem anderen Knoten. Sobald ein Ergebnis erhalten wurde, geht die CENG über einen Bogen 534 in den Zustand (der Ergebnisverarbeitung 510) über, in dem die Reduktionsoperation (z. B. Addition, Multiplikation oder Logik) durchgeführt wird.
  • Im Zustand (der Ergebnisverarbeitung 510) verarbeitet die CENG den Befehl und generiert ein Ergebnis, zum Beispiel durch Ausführen der angegebenen Operation an den empfangenen Eingaben. Die durchzuführende Operation kann sein, ein Minimum, ein Maximum, eine Summe, ein Produkt und eine bitweise Logikoperation zu generieren, um einige nicht einschränkende Beispiele zu nennen.
  • Nach dem Generieren eines Ergebnisses ermittelt die CENG im Zustand (der Ergebnisverarbeitung 510), ob das Ergebnis an einen anderen teilnehmenden Knoten zu senden ist. Falls das Ergebnis an einen anderen Knoten zu senden ist, geht die CENG über einen Bogen 526 in den Zustand (der Ergebnisweiterleitung 504) über, leitet das Ergebnis an einen anderen teilnehmenden Knoten weiter, wartet über den Bogen 524 darauf, dass globale Ergebnisse abgeschlossen werden, und setzt eine Erledigt-Markierung. Falls das Ergebnis an mehrere andere Knoten zu senden ist (z. B. als Reaktion auf einen AllReduce-Befehl), geht die CENG über einen Bogen 530 in den Zustand (Ergebnismulticast 506) über und sendet das Ergebnis via Multicast an mehrere andere teilnehmende Knoten und setzt die Erledigt-Markierung. Falls die Kollektivoperation andererseits nur lokal ist und nicht an einen anderen Knoten weiterzuleiten ist, setzt die CENG die Erledigt-Markierung. Schließlich, sobald die Erledigt-Markierung gesetzt wurde, geht die CENG über die Bögen 516, 518 oder 528 zurück in den Zustand (des Leerlaufs 502) über, in dem die CENG die Erledigt-Markierung rücksetzt und auf einen nächsten Befehl wartet.
  • Es ist anzumerken, dass die CENG-Reduktions-Zustandsmaschine 500 einen Vorteil zum Unterstützen mehrerer unterschiedlicher Typen von Reduktionsoperationen bietet, einschließlich einer Reduktion-auf-alle, einer Reduktion-auf-Broadcast und einer einfachen Reduktion, unter Verwendung von Teilen der gleichen Zustände und Zustandsübergänge, zumindest in Bezug auf die Zustände (des Leerlaufs 502), (der Befehlsprüfung 508), (der Ausführung 512) und (der Ergebnisverarbeitung 510). Das Einbinden der CENG-Reduktions-Zustandsmaschine 500 verbessert das Rechensystem, indem es einen einfachen Schaltkreis mit niedrigen Kosten und niedriger Energienutzung bietet.
  • 6 veranschaulicht ein Zustandsablaufdiagramm für eine Multicastzustandsmaschine, die durch eine Kollektivengine (CENG) implementiert ist, nach einigen Ausführungsformen. Multicasts sind einer von mehreren Typen von Kollektivoperationen, die von der offenbarten ISA vorgesehen sind und von der CENG implementiert werden. Broadcasts sind ähnlich. Mindestens einige der von der offenbarten ISA unterstützten Kollektivoperationen sind in Bezug auf Tabelle 1 und Tabelle 2 aufgelistet und beschrieben.
  • Wie in 6 gezeigt enthält eine Multicast-Zustandsmaschine 600 Zustände (des Leerlaufs 602), (der Befehlsprüfung 604), (der Ausführung 606) und (des MCastverarbeitungsabschlusses 608).
  • In Betrieb beginnt die CENG, die die Multicast-Zustandsmaschine implementiert, beispielsweise nach einer Rücksetzung oder einem Einschalten im Zustand (des Leerlaufs 602), in dem sie auf einen Befehl wartet. Wenn ein neuer Befehl eintrifft, zum Beispiel von der Enginesequenzierungswarteschlange (ESQ) und dem Universalarbiter (UARB) (siehe 2), geht die Zustandsmaschine über einen Bogen 616 in den Zustand (der Befehlsprüfung 604) über, in dem die Befehlseingaben, wie die Adresse und der Operand bzw. die Operanden, gültig sind. Falls nicht, geht die Zustandsmaschine über einen Bogen 614 zurück in den Zustand (des Leerlaufs 602). Falls die Eingaben jedoch gültig sind, geht die Zustandsmaschine über einen Bogen 620 in den Zustand (der Ausführung 606) über, während dessen die CENG ermittelt, welche der Knoten den Multicast empfangen sollen. In einigen Ausführungsformen kann eine derartige Ermittlung durch Zugreifen auf eine Tabelle erfolgen, die die Multicastempfänger auflistet.
  • Die CENG-Multicast-Zustandsmaschine geht dann über einen Bogen 626 in den Zustand (des MCastverarbeitungsabschlusses 608) über, in dem sie wartet, bis die Multicastoperation abgeschlossen ist. Falls der Knoten, in den die CENG eingebunden ist, ein Blattknoten in einem Binärbaum von Teilnehmern ist, wartet die CENG über einen Bogen 624 im Zustand (des MCastverarbeitungsabschlusses 608), bis alle teilnehmenden Knoten fertig sind, wonach die CENG über einen Bogen 618 in den Zustand (des Leerlaufs 602) übergeht. Falls die CENG andererseits nicht Teil eines Blattknotens ist, geht sie über Bogen 612 zurück in den Zustand (des Leerlaufs 602) über.
  • Es wird erwartet, dass die offenbarten CENG-Implementierungen im Vergleich zu anderen Lösungen einfacher sind und geringere Kosten und einen niedrigeren Energieverbrauch aufweisen.
  • DUALE ARBEITSSPEICHER-ISA-OPERATIONEN
  • Die offenbarte Befehlssatzarchitektur enthält eine Klasse von Befehlen zum Durchführen verschiedener dualer Arbeitsspeicheroperationen, die in Parallel-, Multithread- und Mehrprozessoranwendungen üblich sind. Die offenbarten „dualen Arbeitsspeicher“-Befehle verwenden zwei Adressen bei Lade-/Speicher-/atomaren Operationen. Diese sind in Form einer (D)oppelarbeitsspeicheroperation dargestellt, die aus (R)Lese-, (W)Schreib- oder (X)atomaren Operationen bestehen, wie zum Beispiel: DRR, DRW, DWW, DRX, DWX. Diese Operationen sind alle „atomar“, in dem Sinn, dass beide involvierten Arbeitsspeicheradressen aktualisiert werden, ohne dass dazwischenliegende Operationen während der Doppeladressenaktualisierung erlaubt sind.
  • In einer Ausführungsform verwendet der duale Arbeitsspeicherbefehl eine Namenskonvention von „dual_op1_op2“, wobei „dual“ anzeigt, dass zwei Arbeitsspeicherpositionen Verwendung finden, „op1“ repräsentiert den Typ der Operation an die erste Arbeitsspeicherposition und „op2“ repräsentiert den Typ der Operation an die zweite Arbeitsspeicherposition. Offenbarte Ausführungsformen enthalten zumindest die in Tabelle 3 aufgelisteten dualen Arbeitsspeicherbefehle: Tabelle 3
    Dual_read_read
    Dual_read_write
    Dual_writea_write
    Dual_xchg_read
    Dual_xchg_write
    Dual_cmpxchg_read
    Dual_cmpxchg_write
    Dual_compare&read_read
    Dual_compare&read_write
  • Wie oben beschrieben sind die dualen Arbeitsspeicherbefehle hauptsächlich ein Satz von Befehlserweiterungen, die zwei Arbeitsspeicherpositionen auf atomare Weise antasten. Einige Ausführungsformen nutzen die Struktur des von bestehender Hardware verwendeten physischen Layouts, um die Komplexität der Operation vorteilhaft zu vereinfachen, indem sie verlangen, dass die dualen Arbeitsspeicherpositionen durch einen Befehl manipuliert werden, der in der gleichen physischen Struktur haust - dem gleichen Zwischenspeicher, der gleichen Bank eines großen SRAM oder hinter der gleichen Arbeitsspeichersteuerung.
  • VOLL/LEER(F/E)-BEFEHLE
  • Unter vielen möglichen Anwendungen der offenbarten dualen Arbeitsspeicheroperationen gibt es die Fähigkeit, unter vielen gleichzeitigen Prozessen, wie zum Beispiel denen in einer Exascale-Architektur, eine feingranulare Synchronisierung durchzuführen.
  • Ein Ansatz bei einer feingranularen Synchronisierung verwendet Voll/leer(F/E)-Bis, wobei jedes Datenelement im Arbeitsspeicher ein assoziiertes F/E-Bit aufweist. Operationen können ihre Ausführung durch Bedingen von Lese- und Schreibvorgängen in das Datenelement auf Grundlage des Werts des F/E-Bits synchronisieren. Operationen können auch das F/E-Bit setzen oder löschen.
  • Eine Anwendung kann zum Beispiel das F/E-Bit verwenden, um einen Informatikgraphen mit vielen Knoten zu verarbeiten, wobei jeder Knoten im Arbeitsspeicher durch einen Datenwert mit einem assoziierten F/E-Bit repräsentiert wird. Wenn eine Vielzahl von Prozessen in einem gemeinsam genutzten Arbeitsspeicher auf den Informatikgraphen zugreift, kann das F/E-Bit gesetzt werden, wenn ein Prozess auf einen Knoten des Graphen zugreift. Auf diese Weise kann eine feingranulare Synchronisierung unter der Vielzahl der Prozesse unter Verwendung des F/E-Bits erzielt werden, das anzeigt, wenn es gesetzt ist, dass ein Graphknoten bereits „besucht“ wurde. Die Verwendung von F/E-Bits kann auch die Leistung verbessern und einen Arbeitsspeicherplatzbedarf reduzieren, indem kritische Bereiche vereinfacht werden. Die Verwendung von F/E-Bits kann auch eine Parallelisierung mehrerer gleichzeitig laufender Threads ermöglichen.
  • Die Verwendung eines F/E-Bits kann jedoch einigen Arbeitsspeichermehraufwand verursachen, zum Beispiel ein Hinzufügen eines zusätzlichen Bits pro Byte (12,5 % Mehraufwand), das für diesen Zweck reserviert ist, oder eines Bits pro „Wort“ (3 % Mehraufwand). In jeder Anwendung, die derartige Bits nicht benötigt bzw. diese nicht verwenden kann, läuft diese zusätzliche Belastung der Hardware, des Arbeitsspeichersubsystems usw. auf eine wesentliche Last hinaus, die nicht ohne weitere Hardwarekomplexität vermieden werden kann. Dieser Mehraufwand beeinflusst auch die Zweierpotenzorganisation von Maschinen und/oder DRAM, was wirtschaftlich nicht realistisch ist.
  • Die offenbarten dualen Arbeitsspeicherbefehle können jedoch verwendet werden, um ein F/E-Bit zu emulieren, und vermeiden den Bedarf, dass ein F/E-Bit mit jedem Datenelement im Arbeitsspeicher gespeichert wird.
  • Die wesentliche Eigenschaft der F/E-Unterstützung kann mit zwei (von vielen) F/E-Befehlen verstanden werden, wie sie von Cray-Programmierern verwendet werden. Die zwei repräsentativen Befehle sind unten zusammengefasst:
    • • Write_If_Empty (Adresse, Wert): Falls das der „Adresse“ entsprechende F/E-Bit nicht gesetzt ist, Schreiben des Daten„werts“ in die Adresse und Setzen des F/E-Bits. Die Schreibvorgänge in sowohl das F/E-Bit und die Adressposition sind in Bezug auf Beobachtbarkeit „atomar“ und sind entweder gemeinsam erfolgreich oder schlagen gemeinsam fehl, wie bei transaktionaler Arbeitsspeichersemantik.
    • • Read_And_Clear_If_Full (Adresse, &Wert, &Ergebnis): Falls das der „Adresse“ entsprechende F/E-Bit gesetzt ist, dann Lesen des Datenelement aus dieser Adresse und Rückgeben im „Wert“-Feld, gleichzeitiges Löschen des F/E-Bits auf nicht gesetzt und Rückgeben eines Erfolgscodes im „Ergebnis“-Feld; falls das F/E-Bit nicht gesetzt ist, dann wird das „Ergebnis“-Feld gesetzt, um einen Fehler anzuzeigen. Wie im Fall von „Write_If_Empty“ ist der Lesevorgang aus der Adressposition und das Löschen des F/E-Bits sowohl atomar als auch transaktional.
  • Grundlegend arbeiten beide Operationen (und ähnliche F/E-Befehle) durch Manipulieren zweier verschiedener Arbeitsspeicherpositionen auf atomare und transaktionale Weise. In den Cray-Implementierungen sind die zwei Arbeitsspeicherpositionen in eine „Maschinendatenelementeinheit“ eingebettet, wie ein Umwandeln jedes Bytes in 9 Bits anstatt 8 oder jedes 32-Bit-Datenelements in eine physische 33-Bit-Einheit. Der F/E-Befehl manipuliert dann das zusätzliche Bit des Zustands in Übereinstimmung mit einem wohldefinierten Satz von Regeln und Eigenschaften.
  • Der Nachteil dieses Schemas ist wie vorher beschrieben - die wesentliche Mehraufwandbelastung der zusätzlichen Speicherung in den Arbeitsspeicher-Teilsystemen, wenn nicht alle Anwendungen diese Konstruktionen verwenden werden, und auch bei Anwendungen, die sie verwenden, muss nicht jede Arbeitsspeicherposition durch derartige Einrichtungen geschützt werden.
  • Die Emulation der F/E-Bit-Operationen wird trivial durch die offenbarten dualen Arbeitsspeicheroperationen unterstützt, wobei Software nur dann eine zusätzliche F/E-Bit-Speicherung reserviert, falls erforderlich - wenn überhaupt. Zum Beispiel wird „Lesen-und-Löschen“ zu „dual_read_write()“, wobei der „Lesevorgang“ auf das zu lesende Datenelement abzielt und der Schreibvorgang einen Nullwert in den F/E-Emulationsraum schiebt. Gleichermaßen wird „Schreiben-falls-leer“ zu „dual_cmpxchg_write“ - wobei der F/E-Emulationsspeicher mit dem gewünschten Wert (leer) verglichen wird. Die offenbarten dualen Arbeitsspeicherbefehle entfernen auch die Einschränkung eines F/E-Bits, das nur einen Wert aufweist. Stattdessen bieten die offenbarten dualen Arbeitsspeicherbefehle einen Universalalgorithmus für zwei unterschiedliche Adressen, die als eine atomare Einheit modifiziert werden. Der Universalalgorithmus kann verwendet werden, um ein F/E-Bit, klassische Atomarvorgänge, Schutzpunktbits und andere Softwarealgorithmen zu implementieren. Ein Vorteil der offenbarten dualen Arbeitsspeicherbefehle ist es, die Notwendigkeit zu vermeiden, dass die Hardware ein zusätzliches Bit für jedes Datenelement aufweist. Stattdessen erstellt die Software bei Bedarf ein Metadatenfeld und eine Struktur und verwendet diese.
  • Dadurch, dass nicht verlangt wird, dass jedes Datenelement mit einem gespeicherten F/E-Bit assoziiert ist, berücksichtigen die offenbarten dualen Arbeitsspeicheroperationen die zugrunde liegenden Konstruktionsziele der F/E-Bit-Unterstützung, ohne einen derartigen Hardwaremehraufwand mit Ausnahme der Anwendungen zu verlangen, die diesen verwenden.
  • Ein Nachteil der expliziten Benennung jeder Arbeitsspeicherposition innerhalb einer vereinheitlichten Struktur ist das Wachsen der Operanden - „dual_cmpxchg_write“ würde möglicherweise zwei Quelladressen, zwei Datenwerte und einen Vergleichswert erfordern. Es wird angenommen, dass die Rückgabewerte die Datenwerte ersetzen. In einigen Ausführungsformen, um die Anzahl der Argumente auf 4 zu reduzieren, bindet Hardware die „dualen“ Operationen, die mehr als 4 Argumente annehmen, sodass sie immer einen bekannten Offset relativ zum ersten Term oder fortlaufende Adressen für das zweite Datenelement - das heißt, die Hardware verlangt, dass die zwei Werte zusammenhängen oder anderweitig um einen bekannten, festen Offset im Arbeitsspeicher versetzt sind.
  • Die angegebenen dualen Arbeitsspeicherpositionen sind beliebig, aber einige Ausführungsformen verbessern die Effizienz, indem sie erfordern, dass auf die Arbeitsspeicherpositionen von der gleichen Arbeitsspeichersteuerung zugegriffen wird.
  • Die offenbarte Befehlssatzarchitektur ermöglicht auch andere, erweiterte Nutzungen, wie ein Markieren von Arbeitsspeicher für automatische Speicherbereinigung, Markieren von Arbeitsspeicher für gültige Zeiger oder andere „Markierungs-“ oder „Assoziations“-Wünsche bei der Softwarenutzung zum Hinzufügen von semantischen Informationen zu in den Arbeitsspeicher platzierten Werten zu Daten oder Code. Sie könnte auch eine neue Klasse von sperrelosen Softwarekonstrukten, wie ultraeffiziente Warteschlangen, Stapel und ähnliche Mechanismen, ermöglichen.
  • Andere Nutzungen dieser Befehle verallgemeinern auf typische Datenstrukturbedürfnisse, um zwei Felder hinter einem kritischen Bereich zu aktualisieren, wie bei Verwaltung verknüpfter Listen, erweiterten Sperrstrukturen wie MCS-Sperren usw. Die Dualarbeitsspeicheroperationen ermöglichen eine Entfernung einiger wichtiger Abschnitte in diesen Nutzungsfällen, aber sind in dieser Form nicht ausreichend, um alle derartigen kritischen Abschnitte zu entfernen.
  • Ähnliche interessierende Verwendungen können in Speicherbereinigungsalgorithmen gefunden werden, die auf einem Markierungs-und-Aufräum-Merkmal wie die Eigenschaft der F/E-Bits beruhen. Die Markierung von Stapel- oder Heappositionen zur Nachverfolgung von Leerstellen-/Nutzungsinformationen oder zur Markierung von Pufferüberläufen (Debuggen oder Überwachung auf Sicherheitsangriffe) sind ebenfalls Kandidatenbereiche für derartige ISA-Erweiterungen.
  • EIN ACK-LOSER MECHANISMUS FÜR DIE SICHTBARKEIT VON SPEICHERBEFEHLEN
  • Die offenbarte Befehlssatzarchitekur enthält Speichervorgänge mit Bestätigung und Speichervorgänge ohne Bestätigung. Der offenbarte Befehlssatz enthält auch blockierende Speichervorgänge und nicht blockierende Speichervorgänge. Durch das Bereitstellen verschiedener Arten von Speichervorgängen verbessert die offenbarte Befehlssatzarchitektur das Exascale-System oder einen anderen Prozessor, in dem sie implementiert ist, indem sie der Software Flexibilität bietet.
  • Ein Vorteil von Speichervorgängen mit einer Bestätigung ist die Fähigkeit, Einsicht in den Kohärenzzustand der Hardware zu erhalten. In einigen Ausführungsformen, wenn ein derartiger Speichervorgang auf einen Fehler stößt, gibt er einen Fehlercode zurück, der den Fehler beschreibt.
  • Ein Vorteil der Speichervorgänge ohne eine Bestätigung ist die Fähigkeit für Software, „abzudrücken und zu vergessen“. Anders ausgedrückt kann der Befehl ohne weitere erforderliche Verwaltung durch den Code abgerufen, decodiert und zur Ausführung durch einen Prozessor geplant werden.
  • Die offenbarte Befehlssatzarchitektur enthält einen Leerungs-Befehl. Dieser Befehl stellt sicher, dass alle ausstehenden Speichervorgänge ohne Bestätigung aufgelöst wurden, bevor dem Prozessor erlaubt wird, fortzufahren. Bei Bedarf bietet dies Einsicht in den Kohärenzzustand, wenn Speichervorgänge ohne Bestätigung verwendet werden.
  • EINE ISA-UNTERSTÜZTE MIKRO-DMA-ENGINE UND ARBEITSSPEICHERENGINE (MENG)
  • Die offenbarte Befehlssatzarchitektur enthält eine Arbeitsspeicherengine (MENG, zum Beispiel die MENG 122 von 1), die ermöglicht, dass Arbeitsspeicherzugriffe von einer Ausführungskernpipeline entkoppelt werden, und im Fall einiger nicht blockierender Arbeitsspeicherzugriffe der Pipeline ermöglicht, mit der Durchführung nützlicher Arbeit fortzufahren, ohne auf einen Abschluss des Arbeitsspeicherzugriffs zu warten. Die offenbarte Befehlssatzarchitektur enthält Befehle, die bewirken, dass ein direkter Arbeitsspeicherzugriff (DMA) Blöcke von Daten sendet oder aus dem Arbeitsspeicher empfängt, wie von der MENG verwaltet. Ohne die offenbarten DMA-Befehle und MENG-Fähigkeiten, würde Software mehrere Speichervorgänge ausgeben müssen, wie zum Beispiel 3 oder 4 Speichervorgänge, um einen in den Arbeitsspeicher abgebildeten Eingabe/Ausgabe(MMIO)-Block zu konfigurieren, um den Transfer zu starten. Stattdessen die offenbarten DMA-Befehle als Teil der Kern-ISA, wodurch die MMIO-Abhängigkeit beseitigt wird und zusätzliche Datenbewegungsmerkmale hinzugefügt werden.
  • Die MENG ist eine Beschleunigerengine, die einem Kern für Arbeitsspeicherbewegungen im Hintergrund zur Verfügung steht. Ihre primäre Aufgabe ist ein Kopieren im DMA-Stil sowohl für zusammenhängenden als auch abgestuften Arbeitsspeicher, mit optionalen fliegenden Transformationen. Die MENG unterstützt zu einem gegebenen Zeitpunkt bis zu N (z. B. 8) verschiedene Befehle oder Threads und ermöglicht, dass alle N Threads parallel bearbeitet werden.
  • Aufgrund der Konstruktion weisen individuelle Operationen keine Ordnungseigenschaften in Bezug aufeinander auf. Software kann jedoch festlegen, dass Operationen in Reihe ausgeführt werden, falls eine strengere Reihenfolge benötigt wird.
  • In einigen Ausführungsformen stellt der offenbarte DMA-Befehl einen Rückgabewert bereit, der anzeigt, ob der DMA-Transfer abgeschlossen wurde oder ob auf Fehler gestoßen wurde. Ohne den offenbarten DMA-Befehl würde Software wiederholt auf den MMIO-Block zugreifen müssen, um zu wissen, ob und wann der DMA-Transfer abgeschlossen wurde. Durch Elimination des Verlassens auf MMIO-Transaktionen verbessert die offenbarte MENG Leistung und Energienutzung, indem diese wiederholten MMIO-Zugriffe vermieden werden.
  • In einigen Ausführungsformen bindet ein System eine oder mehrere Instanzen von CENG-, MENG- und QENG-Engines strategisch ein, wobei eine Strategie ausgewählt wird, um eines oder mehrere von Leistung, Kosten und Energieverbrauch zu optimieren. Eine MENG-Engine kann zum Beispiel nahe an einem Arbeitsspeicher platziert sein. Eine CENG-Engine oder eine QENG-Engine kann zum Beispiel strategisch nahe an einer Pipeline und einer Registerdatei platziert sein. In einigen Ausführungsformen enthält ein System mehrere MENGs, von denen einige nahe jedem der Arbeitsspeicher angeordnet sind, um den Datentransfer durchzuführen. In einigen Ausführungsformen stellt die MENG die Fähigkeit bereit, eine Operation an den Daten durchzuführen, wie zum Beispiel schrittweises Erhöhen, Transponieren, erneutes Formatieren und Packen und Entpacken der Daten. Wenn mehrere MENGs in einem System enthalten sind, kann die MENG, die ausgewählt wird, um die Operation durchzuführen, diejenige sein, die dem Arbeitsspeicherblock am nächsten ist, der die adressierte Zielzwischenspeicherzeile enthält. In einigen Ausführungsformen empfängt eine Mikro-DMA-Engine einen DMA-Befehl und beginnt sofort mit dessen Ausführung. In anderen Ausführungsformen leitet die Mikro-DMA-Engine den DMA-Befehl als einen entfernten DMA-Befehl (RDMA-Befehl) an einen anderen Mikro-DMA-Kern an einer anderen Position weiter, um den Decodiervorgang durchzuführen. Die optimale Mikro-DMA-Engine, um den RDMA auszuführen, wird auf Grundlage einer Nähe zu einer physischen Arbeitsspeicherposition ermittelt, die in der DMA-Operation involviert ist, sodass entfernte Arbeitsspeicherlesevorgänge und -schreibvorgänge über das Netzwerk minimiert werden. Die Mikro-DMA-Engine, die in der Nähe des Quellarbeitsspeichers einer unstrukturierten DMA-Kopie angeordnet ist, wird zum Beispiel die vollständige Operation durchführen. Die Mikro-DMA-Engine, die de RDMA gesendet hat, wird Befehlsinformationen beibehalten, um der anfordernden Pipeline eine Statusrückmeldung bereitzustellen.
  • In einigen Ausführungsformen implementiert die MENG einen Satz von modellspezifischen Registern (MSRs) zur Softwaresteuerung und Einsicht. MSRs sind Steuerregister, die zum Debuggen, Ablaufverfolgung der Programmausführung, Überwachung der Computerleistung und Ein- und Ausschalten bestimmter CPU-Merkmale verwendet werden. An jedem Befehlsschlitz ist ein Satz von MSRs vorhanden, um den aktuellen Status von Befehlen sowie eine spezifische MSR für die aktuelle MENG-Konstruktion bereitzustellen. Tabelle 4 zeigt einige der MSRs und Beschreibungen: Tabelle 4
    Register Beschreibung
    DSPEC Schreibgeschütztes Register für Software, die definiert: Version, Anzahl der Puffer, Maximalanzahl der Befehle usw.
    DBUF0 Schreibgeschütztes Register, das dem Befehls-PC entspricht, der aktuell Puffer_0 verwendet
    DSTATUS0 Statusbitfeld von Puffer_0
    DADD0 Schreibgeschützes Register, das die zuletzt vom Puffer_0 verwendete Arbeitsspeicheradresse setzt
    ... ...
    QBUFn Schreibgeschütztes Register, das dem Befehls-PC entspricht, der aktuell diesen Puffer_n verwendet
    QSTATUSn Status-Bitfeld von Puffer_n
    DADDn Schreibgeschützes Register, das die zuletzt vom Puffer_n verwendete Arbeitsspeicheradresse setzt
  • 7 veranschaulicht eine Zustandsmaschine, die von einer Arbeitsspeicherengine (MENG) auf einer Pro-Thread-Basis implementiert wird, nach einigen Ausführungsformen. Wie gezeigt beginnt die Zustandsmaschine in (Leerlauf 702), wobei sie regelmäßig über Zustand (Q-Prüfung 706) prüft, ob irgendwelche Befehle in einer Warteschlange sind, oder über Zustand (Sonstiges-Prüfung 708) prüft, ob irgendwelche sonstigen Befehle anstehen. Es ist anzumerken, dass die Bögen zu den Zuständen (Q-Prüfung 706) und (Sonstiges-Prüfung 708) mit Pfeilen an beiden Enden gezeigt sind, da die Zustandsmaschine in den Zustand (des Leerlaufs 702) zurückkehrt, wenn keine Befehle anstehen. Aus dem Zustand (Q-Prüfung 706) geht die Zustandsmaschine in einen Zustand (Anf.-Senden 710), falls ein Befehl in der Warteschlange steht, oder in den Zustand (Wr-Warten 704) über, falls keine Befehle in der Warteschlange stehen, aber eine Aktualisierung erforderlich ist. Gleichermaßen geht die Zustandsmaschine aus dem Zustand (Sonstiges-Prüfung 708) in den Zustand (Anf.-Senden 710) über, falls ein sonstiger Befehl darauf wartet, versandt zu werden. Im Zustand (Anf.-Senden 710) bewirkt die MENG-Zustandsmaschine, dass eine Anforderung gesendet wird, und wartet auf eine Bewilligung, nach der die Zustandsmaschine in den Zustand (Wr-Warten 704) übergeht, um modellspezifische Register (MSRs) und die Befehlswarteschlange zu aktualisieren. Es wird zum Beispiel ein für Software zugängliches MSR aktualisiert, um den Status des Befehls bereitzustellen. Die Zustandsmaschine bleibt im Zustand (Wr-Warten 704), während sie darauf wartet, dass ein Schreibvorgang abgeschlossen wird.
  • Wenn mehrere Threads in einem Kern ausgeführt werden, pflegt jeder Thread eine MENG-Zustandsmaschine, die dafür verantwortlich ist, den Status der aktuellen Operation nachzuverfolgen und etwaige Lade-/Speichervorgänge aus bzw. in die Arbeitsspeicheradresse erteilt, die bearbeitet wird.
  • Tabelle 5 listet einige der MENG-Befehle auf, wobei Verhaltensweisen folgendermaßen definiert sind:
  • copy: direktes Kopieren von Arbeitsspeicherinhalten, genau wie der C-Aufruf von memcpy()
  • copystride: Kopieren von Arbeitsspeicherinhalten beim „Durchstreifen“ entweder der Quelle oder des Ziels, einer Packen-/Entpacken-Funktionalität entsprechend
  • gather: Sammeln aus mehreren diskreten Adressen im Arbeitsspeicher, Kopieren der Inhalte an eine dichte Position anderswo
  • scatter: Streuen eines dichten Datensatzes in mehrere diskrete Adressen im Arbeitsspeicher, wobei der Inhalt kopiert wird. Tabelle 5
    DMA-Befehle
    Mnemonik ASM-Form und Argumente
    dma.copy r1, rfgh, r3, DMATyp, GRÖSSE
    dma.copystride.1 r1, r2, r3, GRÖSSE
    dma.copystride.2 r4, r5, r6, DMATyp
    dma.gather.1 r1, r2, r3, GRÖSSE
    dma.gather.2 r4, r5, DMATyp
    dma.scatter.1 r1, r2, r3, GRÖSSE
    dma.scatter.2 r4, r5, DMATyp
  • Wie in der Tabelle gezeigt, nehmen die meisten MENG-Operationen ein zusätzliches Argument an, DMATyp genannt. Dieses unmittelbar codierte Feld ist eine Tabelle, die zusätzliche Funktionalität der MENG-Operation lenkt. Tabelle 6 gibt die DMATyp-Struktur an, ein 12-Bit-Feld, das mehrere Felder enthält, wie in der Tabelle definiert: Tabelle 6 „DMATyp“-Bitmaske aktiviert
    Bits Definition/Zweck
    0 Transponieren, falls auf eins gesetzt
    1 Adressmoduserfassung der Operation:
    Falls im Gather-/Scatter-Modus, 64b-Basisadresse mit einer Sammlung von SIZE signierten Offsets zur Basis (Bit auf null gesetzt) oder einer Sammlung von vollen 64b-Adressformen (Bit auf eins gesetzt);
    Falls im CopyStride-Modus, zeigt dieses Bit an, ob Durchlauf zu verwenden ist (Bit auf null gesetzt) oder andernfalls Durchführen von Pack-/Entpackoperationen [Dicht->Schwach besetzt oder Schwach besetzt->Dicht] (Bit auf eins gesetzt)
    2 Richtung der Operation: Bei einer GSU-Operation zeigt dies eine „gather“-Operation an (Bit auf null gesetzt) oder andernfalls eine „scatter“-Operation ab (Bit auf eins gesetzt);
    bei einem Stride-Copy, was Packen/Entpacken ist: Transformieren von schwach besetzt->dicht in der „Packungs“-Sequenz (Bit auf null gesetzt) oder andernfalls dicht>schwach besetzt in der „Entpackungs“-Sequenz (Bit auf eins gesetzt)
    3 Komplementieren des eingehenden Werts (aus Quelle)
    4 Komplementieren eines bestehenden Werts (am Ziel gefunden)
    5:6 Operandentyp (falls zutreffend)
    2b00 Rohe Bits; als ~VAL komplementieren
    2b01 Ganze Zahl; als 2-er-Komplement-Operation komplementieren
    2b10 Gleitkomma; mit „-1,0 * Wert“ komplementieren
    2b11 -reserviert-
    7:9 Am Ziel durchzuführende Operation (pro Datenelement) [diese werden atomar durchgeführt]
    3b000 Überschreiben
    3b001 Addieren
    3b010 Mul
    3b011 Bitweises UND
    3b100 Bitweises ODER
    3b101 Bitweises XOR
    10:11 -reserviert-
  • Es ist anzumerken, dass nicht alle Felder dieses DMATyp-Modifizierers für alle Operationen gelten und einige Felder, wie sie in der Tabelle beschrieben sind, weisen Verhaltensweisen auf, die von der Natur der zugrunde liegenden DMA-Operation abhängen. Bestimmte Fälle, was erlaubt ist und was nicht, werden pro Befehl beschrieben.
  • 8 veranschaulicht ein Verhalten eines beispielhaften Copystride-DMA-Befehls nach einer Ausführungsform. Wie gezeigt enthält eine Quellenarbeitsspeicherabbildung 800 Datenpaare 0,1 bei 802, 2,3 bei 804, 4,5 bei 806, 6,7 bei 808, 8,9 bei 810, 10,11 bei 812, 12,13 bei 814, 14,15 bei 816 und 16,17 bei 818. Nach Ausführen des Befehls DMA-Copystride DST, SRC, 9, 12, 2, 2 (Transponieren, Transformieren, Packen, Überschreiben), 64b DST, enthält die Zielarbeitsspeicherabbildung 820 die geraden, bei 822 gepackten Elemente und die ungeraden, bei 824 gepackten Elemente. Nach Ausführen eines DMA-Copystride-Befehls nach einer Ausführungsform hält das Zielregister 822 die geraden Datenwerte aus der Quellarbeitsspeicherabbildung und das Zielregister 824 hält die ungeraden Werte.
  • IN DEN ARBEITSSPEICHER ABGEBILDETE E/A-BASIERTE (MMIO-BASIERTE) ISA-ERWEITERUNG UND ÜBERSETZUNG
  • Zusammen mit und zur Unterstützung von der offenbarten Befehlssatzarchitektur hat eine in einen Arbeitsspeicher abgebildete Befehlsübersetzungs-Sammel-Eingabe/Ausgabe (TCMMIO) Anforderungen von einem Hauptprozessor an eine oder mehrere Instanzen eines oder mehrerer Typen von Beschleunigerkernen oder Engines zu übersetzen, zu sammeln und weiterzuleiten. Für den Hauptprozessor erscheinen Zugriffe auf die Beschleunigerkerne oder Engines als einfache in den Arbeitsspeicher abgebildete Eingabe/Ausgabe(E/A)-Zugriffe auf Lade- und Speichervorgänge. Für den Beschleunigerkern verhält sich die TCMMIO wie eine Befehlserteilungs-/Warteschlangenhandhabungseinheit und diese nimmt die resultierende Schreibantwort gegebenenfalls vom Beschleunigerkern an. Anders als eine herkömmliche in den Arbeitsspeicher abgebildete E/A-Schnittstelle (MMIO-Schnittstelle), wobei der Master und Slave mehrere Schreibvorgänge/Lesevorgänge für E/A-Treiber/Empfänger austauschen, sammelt die hierin offenbarte TCMMIO mehrere Ladevorgänge/Speichervorgänge vom Hauptprozessor und übersetzt die Anforderungen in Übereinstimmung mit der maßgeschneiderten ISA des Beschleunigerkerns, die dann in diesem Zustand an die Beschleunigerkerne ausgegeben werden können.
  • 9 ist ein Diagramm, das die Beziehung von Speicherung im maßgeschneiderten Zielbefehlsformat und Sammlung durch den in den Arbeitsspeicher abgebildeten Übersetzer-Sammler-Eingabe/Ausgabe(TMMIO)-Block vor der Ausgabe an die Beschleuniger veranschaulicht, nach einer Ausführungsform. Wie gezeigt enthält das maßgeschneiderte Befehlsformat 900 eine 4-Bit-Befehlskennung (CID), einen 8-Bit-Opcode und vier 64-Bit-Quelloperanden. In einigen Ausführungsformen enthält der offenbarte TCMMIO-Block mehrere, zum Beispiel sechs, in den Arbeitsspeicher abgebildete Registerschlitze 902, die jeweils fünf 64-Bit-Register bereitstellen, um mehrere Instanzen der offenbarten erweiterten ISA zu puffern. Wie gezeigt enthalten die fünf Einträge des in den Arbeitsspeicher abgebildeten Registerschlitzes Nr. 0 902 ein 64-Bit-Register, um einen Befehl zu speichern, und vier 64-Bit-Register, um Operanden zu speichern. Die offenbarte TCMMIO bietet eine verallgemeinerte Schnittstelle und kann Anforderungen von beliebigen der hierin beschriebenen Beschleuniger annehmen, einschließlich einer Kollektivengine (CENG), einer Warteschlangenengine (QENG) und einer Kettenverwaltungseinheit (CMU).
  • Indem dem Hauptprozessor ermöglicht wird, mit einer Vielfalt von maßgeschneiderten Beschleunigerkernen zu kommunizieren, einschließlich mit zukünftigen Versionen von Beschleunigerkernen, kann die offenbarte TCMMIO enorme Mengen an Software- und Treiberteam-Arbeitsstunden einsparen, egal ob für Prototypen oder für ein neues Produkt.
  • Die offenbarte TCMMIO transformiert ein bestehendes in den Arbeitsspeicher abgebildetes E/A-Konzept und erweitert die offenbarte Befehlssatzarchitektur, um mit den Beschleunigerkernen oder Engines zu kommunizieren. Wie hier offenbart, können beliebige der mehreren Beschleuniger, wie eine Arbeitsspeicherengine (MENG), eine Warteschlangenengine (QENG) und eine Kollektivengine (CENG), die TCMMIO nutzen. Anders ausgedrückt können alle der offenbarten Beschleuniger das maßgeschneiderte TCMMIO-Befehlsformat 900 verwenden, um einen Befehl an die TCMMIO zu übermitteln, wobei der Befehl einen Opcode und bis zu vier 64-Bit-Operanden enthält. Die erweiterte ISA ermöglicht dem Hauptprozessor, direkt mit den anderen Beschleunigerkernen zu kommunizieren, ohne Konstruktionsänderungen an diesen. Dieses Konzept ist hinreichend generisch, um für beliebige ISA-übergreifende Übersetzungen und Erweiterungen implementiert zu werden. Dies ermöglicht dem primären Kern, sehr vielseitig zu sein, und gibt dem Compiler mehr Optionen zum effektiveren Einplanen von maßgeschneiderten ISA-Befehlen und zum Erstellen von Arbeitslasten für die beste Nutzung der Beschleunigerkerne.
  • In einigen Ausführungsformen weisen maßgeschneiderte Beschleunigerkerne spezifische vordefinierte Funktionen und Befehle auf und die offenbarte ISA hängt einfach die Beschleunigerkennung (4 Bits) für die interne Verarbeitung des TCMMIO-Blocks an. In einigen Ausführungsformen weist ein einfaches Erweitern bestehender Befehle zur Aufnahme der 4-Bit-Kennung den Vorteil, dass die Notwendigkeit einer Decodierung eines Befehls vermieden wird, und resultiert in einer Befehlserteilung in einem einzigen Zyklus. Diese 4-Bit-Erweiterung ist vollständig intern zur TCMMIO.
  • Anders als eine herkömmliche MMIO mit einer Arbeitsspeicherabbildung, die riesig und für einen E/A-Typ spezifisch ist, erfordert ein Implementieren der offenbarten TCMMIO in Übereinstimmung mit einer Ausführungsform nur sechs universelle Befehlsschlitze. Jeder Schlitz weist wiederum fünf 64-Bit-Arbeitsspeicherpositionen auf, die mit ihm assoziiert sind. Durch die nur sechs Befehlsschlitze wird die Fläche und Energie optimiert, die von der TCMMIO verbraucht werden, wobei die Leistungsvorteile und generische Natur der Konstruktion beibehalten werden. Indem die Schlitze universal gemacht werden (d. h. nicht für irgendwelche Engines/Befehlstypen spezifisch), wird die Belastung von Software reduziert, eine spezifische Adressenabbildung nachzuverfolgen. Da die meisten Beschleunigerkernbefehle bis zu 4 Operanden und einige zusätzliche Steuerbits verwenden, wird erwartet, dass fünf 64-Bit ausreichen.
  • 10 ist ein Blockablaufdiagramm, das eine Ausführung eines Arbeitsspeicherzugriffsbefehls durch eine in den Arbeitsspeicher abgebildeten Übersetzer-Sammler-Eingabe/Ausgabe (TCMMIO) veranschaulicht, nach einigen Ausführungsformen. Wie gezeigt empfängt die TCMMIO nach dem Starten bei 1002 eine Abfrage nach einem leeren Schlitz, und wenn a, lädt in Index #EFF0. Bei 1004 speichert die TCMMIO einen ersten Operanden <r0/imm> (von X86/PrimärKern)/. Bei 1006 speichert die TCMMIO einen zweiten Operanden <r1/imm> (von X86/PrimärKern). Bei 1008 speichert die TCMMIO einen dritten Operanden <r2/imm> (von X86/PrimärKern). Bei 1010 speichert die TCMMIO einen vierten Operanden <r3/imm> (von X86/PrimärKern). Bei 1012 speichert die TCMMIO einen fünften Operanden ::INSTR ({CID}, {Uncore ISA-Format}} (aus X86/PrimärKern). Bei 1014 verknüpft die TCMMIO die gespeicherten Werte und gibt sie an die Enginesequenzierungswarteschlange (ESQ) aus. Bei 1016 gibt die ESQ verknüpfte Speichervorgänge an den Universalarbiter (UARB) (zur MMIO intern) aus. Bei 1018 hält die TCMMIO den Schlitz aktiv, falls ein Rückgabewert erwartet wird; andernfalls wird der Schlitz für den nächsten Befehl gelöscht.
  • ISA-GESTÜTZTE MIKRO-DMA-ENGINE
  • Die offenbarte Befehlssatzarchitekur enthält Befehle, die bewirken, dass ein direkter Arbeitsspeicherzugriff (DMA) Blöcke von Daten sendet oder aus dem Arbeitsspeicher empfängt. Ohne die offenbarten DMA-Befehle würde Software mehrere Speichervorgänge ausgeben müssen, wie zum Beispiel 3 oder 4 Speichervorgänge, um einen in den Arbeitsspeicher abgebildeten Eingabe/Ausgabe(MMIO)-Block zu konfigurieren, um den Transfer zu starten.
  • Stattdessen enthält die offenbarte Befehlssatzarchitektur einen Arbeitsspeicherenginebeschleuniger (MENG-Beschleuniger), der dies verbessert, indem er DMA-Befehle als Teil der Kern-ISA enthält, die MMIO-Abhängigkeit beseitigt und zusätzliche Datenbewegungsmerkmale hinzufügt. Die MENG kann von einer Ausführungskernpipeline entkoppelt sein, was im Fall eines nicht blockierenden DMA-Befehls der Pipeline ermöglicht, nützliche Arbeit durchzuführen, ohne auf einen Abschluss des nicht blockierenden DMA-Befehls zu warten. Die MENG verbessert das System, indem sie eine Hintergrund-Arbeitsspeicherbewegungsfunktionalität ermöglicht, die von der Kernpipeline entkoppelt ist, während sie direkt in die ISA integriert ist, um den Mehraufwand und die Komplexität von MMIO-Schnittstellen zu vermeiden.
  • Die MENG ist eine Beschleunigerengine, die einem Kern für Arbeitsspeicherbewegungen im Hintergrund zur Verfügung steht. Ihre primäre Aufgabe ist ein Kopieren im DMA-Stil sowohl für zusammenhängenden als auch abgestuften Operationen, mit optionalen fliegenden Transformationen.
  • Die MENG unterstützt zu einem gegebenen Zeitpunkt bis zu N (z. B. 8) verschiedene Befehle oder Threads und ermöglicht, dass alle N Threads parallel bearbeitet werden. Aufgrund der Konstruktion weisen individuelle Operationen keine Ordnungseigenschaften in Bezug aufeinander auf. Software kann festlegen, dass Operationen in Reihe ausgeführt werden, falls eine strengere Reihenfolge benötigt wird.
  • In einigen Ausführungsformen stellt der offenbarte DMA-Befehl einen Rückgabewert bereit, der anzeigt, ob der DMA-Transfer abgeschlossen wurde oder ob auf Fehler gestoßen wurde. Ohne den offenbarten DMA-Befehl würde Software wiederholt auf den MMIO-Block zugreifen müssen, um zu wissen, ob und wann der DMA-Transfer abgeschlossen wurde.
  • Durch Eliminieren der Abhängigkeit von MMIO-Transaktionen vermeidet die offenbarte MENG, beim Initiieren von Operationen großteils von MMIO-Transaktionen abzuhängen, und vermeidet die Verwendung von Einheiten, die suboptimalerweise weit entfernt sind, was eine niedrigere Bandbreite ergibt und mehr Energie verbraucht.
  • In einigen Ausführungsformen enthält ein System mehrere MENGs, von denen einige nahe jedem von mehreren Arbeitsspeicher angeordnet sind, um die Datentransfers durchzuführen. In einigen Ausführungsformen stellt die MENG die Fähigkeit bereit, eine Operation an den Daten durchzuführen, wie zum Beispiel schrittweises Erhöhen, Transponieren, erneutes Formatieren und Packen und Entpacken der Daten. Die MENG, die ausgewählt wird, um die Operation durchzuführen, kann diejenige sein, die dem Arbeitsspeicherblock am nächsten ist, der die adressierte Zielzwischenspeicherzeile enthält. In einigen Ausführungsformen empfängt eine Mikro-DMA-Engine einen DMA-Befehl und beginnt sofort mit dessen Ausführung. In anderen Ausführungsformen leitet die Mikro-DMA-Engine den DMA-Befehl an eine andere Mikro-DMA-Engine weiter, um zu versuchen, eines oder mehrere von Energie und Leistung zu verbessern.
  • VEREINFACHTE HARDWAREUNTERSTÜTZTE WARTESCHLANGENENGINE (QENG)
  • Die offenbarte Befehlssatzarchitektur enthält Befehle und eine Warteschlangenengine (QENG), um eine vereinfachte hardwareunterstützte Warteschlangenverwaltung bereitzustellen. Die QENG ermöglicht eine Kommunikation zwischen Prozessoren mit niedrigem Mehraufwand mit kurzen Nachrichten bis zu 4-8 Datenwerten, jeweils bis zu 64 Bits, ohne Informationsverlust und mit optionalen Merkmalen für erweiterte Softwarenutzungsmodelle. Es ist auch anzumerken, dass die ausgewählten Bitbreiten nur Implementierungswahlen der Ausführungsform sind und die Erfindung nicht einschränken sollen.
  • Die QENG bietet eine hardwareverwaltete Warteschlange, die „Warteschlangenereignisse“ mit atomaren Hintergrundeigenschaften in Bezug auf ein Einfügen/eine Entfernung von Datenwerten an einem von Software pro Befehl wählbaren Kopf oder Ende der Warteschlange bearbeitet. Die Warteschlangenbefehlsimplementierung ist hinreichend generisch, sodass mehrere Softwarenutzungsmodelle auf kurzgefasste Weise eingebunden sind, von türklingelähnlicher Funktionalität zu kleinen MPI-ähnlichen Sende-/Empfangs-Handshakes.
  • 11 ist ein Blockdiagramm, das eine Integration einer Kollektivengine (CENG) in eine Kernpipeline nach einigen Ausführungsformen veranschaulicht. Wie gezeigt enthält die QENG 1100 eine Eingabeschnittstelle 1102, eine modellspezifische Register-Steuerbank (MSR-Steuerbank) 1104, einen Threadsteuerschaltkreis 1106, der eine Steuereinheit 1108 enthält, einen Kopf-/Ende-Steuerschaltkreis 1110, der einen Zeigersteuerschaltkreis 1112 enthält, eine endliche QENG-Zustandsmaschine 1114 und eine Ausgabeschnittstelle 1116.
  • Im Betrieb empfängt die Eingabeschnittstelle 1102 nach einigen Ausführungsformen einen Befehl vom Universalarbiter (UARB) (der manchmal als ubiquitärer Arbiter bezeichnet wird) und speichert den Befehl in einem Befehlspuffer. In einigen Ausführungsformen enthält die Eingabeschnittstelle 1102 auch einen Befehlsdecodierschaltkreis, der verwendet wird, um den Befehl zu decodieren und seinen Opcode und seine Operanden abzuleiten. Wenn der Befehl eine Anforderung zum Zugriff auf ein MSR ist, wird der Befehl an die MSR-Steuerbank 1104 weitergeleitet, wo er auf ein in den Arbeitsspeicher abgebildetes MSR zugreift. Andernfalls wird der Befehl an den Threadsteuerschaltkreis 1106 weitergeleitet, der ermittelt, zu welchem der acht unterstützten Threads der Befehl gehört, und greift auf das entsprechende Befehlssteuerregister zu, das vom Kopf-/Ende-Steuerschaltkreis 1110 verwendet wird, um den Zeigersteuerschaltkreis 1112 zu verwenden, um die Zeiger für den Thread zu aktualisieren. Die endliche QENG-Zustandsmaschine (QENG-FSM) 1114 lenkt das QENG-Verhalten und leitet resultierende Informationen an den UARB hinaus.
  • Indem vermieden wird, Software zu belasten, um Warteschlangenpuffer zu verwalten, was oft ein zeitraubender Prozess ist, da die Software durch Bandbreite und Latenzen des Arbeitsspeichers eingeschränkt ist, gibt die QENG die Warteschlangenverwaltung in den Hintergrund unter Hardwaresteuerung. Die Software muss nur einen Warteschlangenpuffer konfigurieren und der Hardware einen Hintergrundbefehl erteilen. Dies verbessert die Leistung und Leistungsfähigkeit eines Prozessors, der die offenbarte ISA implementiert.
  • QENG-WARTESCHLANGENVERWALTUNGSBEFEHLE
  • Tabelle 7 listet einige von der offenbarten ISA bereitgestellte Warteschlangenverwaltungsbefehle auf und beschreibt diese und listet die erwartete Anzahl von Operanden für jeden auf. Um eine QENG-Operation auszuführen, erteilt ein Kern beliebige der folgenden Befehle - wobei (h/t) anzeigt, ob die Operation den Kopf (h) oder das Ende (t) der Warteschlange bearbeitet, und (w/n) ein Warte- (Blockier-) (w) oder kein Warte- (kein Blockier-) Verhalten anzeigt.
  • Warteschlangenverwaltungsbefehle, die zur ISA hinzugefügt werden und von der QENG unterstützt werden, enthalten einen Befehl, um einen Datenwert an einer Position in die Warteschlange einzureihen, und einen Befehl, um einen Datenwert von einer Position aus der Warteschlange zu entfernen. In einigen Ausführungsformen residiert die verwaltete Warteschlange in einem Arbeitsspeicher in der Nähe der QENG. QENG-Warteschlangenverwaltungsbefehle ermöglichen eine Erstellung von beliebigen Warteschlangentypen (FIFO, FILO, LIFO usw.). Warteschlangenbefehle gibt es auch sowohl in blockierenden als auch nicht blockierenden Varianten, um eine Reihenfolge sicherzustellen, falls Software dies erfordert.
  • QENG-Warteschlangeneinreihung
  • In einigen Ausführungsformen werden neue Warteschlangeneinträge an der aktuellen Zeigerposition hinzugefügt, d. h zum Hinzufügen von ,n‛ Datenelementen:
    1. 1. Daten am aktuellen Zeiger hinzuzufügen
    2. 2. Die Zeigeradresse schrittweise erhöhen
    3. 3. ,n‛-mal wiederholen
  • QENG-Warteschlangenentfernung
  • In einigen Ausführungsformen werden Warteschlangenentfernungen durch schrittweises Verringern des Zeigers um die Datengröße und danach Entfernen der Daten am Zeiger ausgeführt, d. h. zum Entfernen von ,n‛ Elementen:
    1. 1. Die Zeigeradresse schrittweise verringern
    2. 2. Daten vom Zeiger abrufen
    3. 3. ,n'-mal wiederholen
  • Eine einzelne Warteschlangenentfernung kann Daten umspannen, die unter Verwendung mehrerer Hinzufügebefehle an entweder Kopf ODER Ende hinzugefügt wurden. Tabelle 7
    Anw. Operanden Beschreibung
    qma.add1.w (h/t) r1, r2 r1- Adresse von QBUF-MSR, r2 - zur Warteschlange hinzuzufügendes Datenelement
    qma.add1.n (h/t) r1, r2, r3 r1- Register zum Empfangen des Status, r2 - Adresse von QBUF-MSR, r3 - zur Warteschlange hinzuzufügendes Datenelement
    qma.add2.w (h/t) r1, r2, r3 r1- Adresse von QBUF-MSR, r2 - zur Warteschlange hinzuzufügendes Datenelement 1, r3 - zur Warteschlange hinzuzufügendes Datenelement 2
    qma.add2.n (h/t) r1, r2, r3, r4 r1- Register zum Empfangen des Status, r2 - Adresse von QBUF-MSR, r3 - zur Warteschlange hinzuzufügendes Datenelement 1, r4 - zur Warteschlange hinzuzufügendes Datenelement 2
    qma.addx.w (h/t) r1, r2, r3 r1 - Adresse von QBUF-MSR, r2 - erste Arbeitsspeicheradresse für zur Warteschlange hinzuzufügende Daten, r3 - Anzahl der Datenwerte
    qma.addx.n (h/t) r1, r2, r3, r4 r1- Register zum Empfangen des Status, r2 - Adresse von QBUF-MSR, r3 - erste Arbeitsspeicheradresse für zur Warteschlange hinzuzufügende Daten, r4 - Anzahl der Datenwerte
    qma.rem1.w (h/t) r1, r2 r1- Register zum Empfangen des Datenelements aus der Warteschlange, r2 - Adresse von QBUF-MSR
    qma.rem1.n (h/t) r1, r2, r3 r1- Register zum Empfangen des Status, r2 - Register zum Empfangen des Datenelements aus der Warteschlange, r3 - Adresse von QBUF-MSR
    qma.rem2.w (h/t) r1, r2, r3 r1- Register für 1. Datenelement, r2 - Register zum Empfangen des Datenelements aus der Warteschlange, r3 - Adresse von QBUF-MSR
    qma.rem2.n (h/t) r1, r2, r3, r4 r1- Register zum Empfangen des Status, r2 - Register zum Empfangen des ersten Datenelements aus der Warteschlange, r3 - Register zum Empfangen des 2. Datenelements aus der Warteschlange, r4 - Adresse von QBUF-MSR
    qma.remx.w (h/t) r1, r2, r3 r1 - erste Arbeitsspeicheradresse zum Empfangen von Daten aus der Warteschlange, r2 - Anzahl der Datenwerte, r3 - Adresse von QBUF-MSR
    qma.remx.n (h/t) r1, r2, r3, r4 r1- Register zum Empfangen des Status, r2 - erste Arbeitsspeicheradresse zum Empfangen von Daten von der Warteschlange, r3 - Anzahl der Datenwerte, r4 - Adresse von QBUF-MSR
  • QENG-INITIALISIERUNG UND KONFIGURATION
  • In einigen Ausführungsformen weist jeder Kern eines Mehrkernsystems eine begleitende QENG auf, die die Hardware zur Warteschlangenverwaltung ist. In einigen Ausführungsformen weist jede QENG 8 unabhängige Threads auf, die parallel ausgeführt werden kann. Threads können jedoch auch zur seriellen Ausführung für Synchronisierungszwecke bestimmt werden.
  • Bei Software gibt es einen einmal auftretenden Programmiernachteil zum Initialisieren einer Warteschlange durch Programmieren modellspezifischer Register (MSRs) in der QENG, um zum Beispiel eine Puffergröße und eine Pufferadresse zu speichern. Die QENG kümmert sich dann um den Mehraufwand zum Nachverfolgen der Anzahl der gültigen Warteschlangeneinträge, des Kopfes der Warteschlange, von dem ein Dateneintrag per Pop zu entfernen ist, und des Endes der Warteschlange, zu dem ein neuer Dateneintrag hinzufügen ist. Anders ausgedrückt ermöglicht die ENG, sobald Software eine Warteschlange initialisiert, die mit der Warteschlange assoziierte Buchhaltung.
  • Tabelle 8 listet einige für Software zugängliche modellspezifische Register (MSRs), die von der offenbarten ISA bereitgestellt werden, um Software zu ermöglichen, die QENG zu initialisieren und zu konfigurieren. In einigen Ausführungsformen muss Software vor dem Beginn einer QENG-Operation einen Warteschlangenpuffer durch Konfigurieren von MSRs innerhalb der QENG initialisieren, einschließlich: Programmieren von QBUF mit der gewünschten Warteschlangenadresse, Programmieren von QSIZE mit der erforderlichen Warteschlangengröße und Festlegen des Aktivierungsbits (0. Bit von QSTATUS). Das Festlegen des Aktivierungsbits konfiguriert Zeiger für Kopf und Ende der Warteschlange, sodass diese auf die Adresse im QBUF-Register zeigen. Ein etwaiger QPuffer wird mit Schreibvorgängen auf QBUF, QSIZE oder das Aktivierungsbit rückgesetzt. Aktuelle Befehle für diese Warteschlange werden ohne Ausführung geleert. Befehle, die einen gemeinsamen QPuffer bearbeiten, werden in FIFO-Reihenfolge in Bezug auf den Kern verarbeitet, der diese Befehle erteilt. Tabelle 8
    Name Beschreibung
    QSPEC Schreibgeschütztes Register für Software, die definiert: Version, verfügbare Schlitze, Maximalanzahl der Befehle usw.
    QBUF Adressfeld, das einen Zeiger auf einen beliebigen gültigen Arbeitsspeicherbereich für Puffer_0 festlegt
    QSIZE Datenfeld, das die Größe von Puffer_0 in Bytes angibt
    QSTATUS Statusbitfeld von Puffer_0
    PC0 Schreibgeschütztes Register, das den PC des Endes des letzten Befehls festlegt; wirkt auf Puffer_0
    ADD0 Schreibgeschützes Register, das die zuletzt vom Puffer_0 verwendete Arbeitsspeicheradresse setzt
    QBUFn Adressfeld, das einen Zeiger auf einen beliebigen gültigen Arbeitsspeicherbereich für Puffer_n festlegt
    QSIZEn Datenfeld, das die Größe von Puffer_n in Bytes angibt
    QSTATUSn Status-Bitfeld von Puffer_n
    PCn Schreibgeschütztes Register, das den PC des Endes des letzten Befehls festlegt, der Puffer_n zu bearbeiten hat
    ADDn Schreibgeschützes Register, das die zuletzt vom Puffer_n verwendete Arbeitsspeicheradresse setzt
  • QENG-UNTERBRECHUNGEN
  • Die QENG unterstützt Unterbrechungen für mehrere QENG-Ereignisse. Diese enthalten: Erkennung von Hardwarefehlern, leere auf nicht leere QPuffer-Übergänge und nicht leere auf leere QPuffer-Übergänge. Diese Unterbrechungsbedingungen können durch Speichervorgänge in die MSR-Register aktiviert und deaktiviert werden.
  • Da die QENG Eigentümer der Verwaltung des von Software bereitgestellten Arbeitsspeicherbereichs für Warteschlangendaten ist und alle QENG-Befehle, die diesen Puffer bearbeiten, an eine spezifische QENG gesandt werden, wird die Eigenschaft der Atomarität mit Hinzufügungs-/Entfernungs-Operationen in die bzw. aus der Warteschlange der Software bereitgestellt, ohne tatsächliche Sperren oder andere gewichtige Operationen am Arbeitsspeicher zu erfordern.
  • Darüber hinaus werden bei blockierenden Operationen die QENG-Operationen zum Hinzufügen/Entfernen wiederholt versucht, bis es für einen Erfolg ausreichenden freien Platz oder für den Erfolg ausreichende Datenelemente in der Warteschlange gibt.
  • BEFEHLSVERKETTUNG FÜR STRENGE GLIEDERUNG
  • Die offenbarte Befehlssatzarchitektur enthält Einrichtungen, um Befehle bei Bedarf zu verketten, um eine strenge Reihenfolge zu bewahren. In einigen Ausführungsformen ist vorgesehen, dass in der ISA enthaltene Befehle aus der Hauptkernpipeline geworfen werden und im Hintergrund ausgeführt werden. Im Betrieb werden einige hierin enthaltene und beschriebene Befehle aus der Hauptkernpipeline geworfen und durch Engines, wie den hierin und unter Bezugnahme auf 1 beschriebenen MENG-, CENG- und QENG-Engines, ausgeführt. Die MENG-, CENG- und QENG-Engines führen deshalb offenbarte Funktionen im Hintergrund aus, was dem Kern ermöglicht, fortzufahren, nützliche Arbeit zu tun, und zeigen an, wo sie erfolgen, zum Beispiel, durch Generieren einer Unterbrechung oder Setzen eines Statusregisters, das von Software abgefragt wird.
  • In einigen Ausführungsformen werden eine oder mehrere der MENG-, CENG- und QENG-Engines repliziert und an mehrere Positionen in einem Prozessorkern oder System verteilt und sollen ISA-Befehle im Hintergrund und gleichzeitig ausführen. Aufgrund der Konstruktion weisen asynchrone Hintergrundoperationen keine Ordnungseigenschaften in Bezug aufeinander auf. Da es keine Reihung innerhalb des Systems zur Nachrichtenzustellung für Hintergrundoperationen gibt, kann eine neuere Operation vor einer älteren Operation sichtbar sein. Dies stellt für strenge Arbeitsspeichergliederung ein Problem dar.
  • Um die Einschränkung der Gliederung in einer durch Software gesteuerten Vorrichtung zu umgehen, werden „Ketten“ für Hintergrundoperationen implementiert und von Software verwendet, wenn eine strengere Gliederung notwendig ist. Jede Kette wird intern durch Hardware in strenger FIFO-Reihenfolge für alle Einträge innerhalb dieser Kette bedient. Eine Kette wird als abgeschlossen angesehen, wenn die letzte Operation in der Kette beendet wurde.
  • Die offenbarte ISA enthält deshalb eine Kettenverwaltungseinheit (CMU), einen softwaregesteuerten Prozess, wobei asynchrone Hintergrundoperationen bei Bedarf serialisiert werden können. Dies ergibt Hardwareunterstützung für Mikro-Thread-Befehlssequenzen, ähnlich wie Threads mit eingeschränkten Fähigkeiten auf Benutzerebene.
  • Anstatt „einen Bus zu sperren“ oder einen Kern anzuhalten, ermöglicht das Konzept der Ketten eine Softwaresteuerung über asynchrone Hintergrundoperationen. Mehrere Ketten können gleichzeitig parallel bedient werden, während interne Elemente einer beliebigen Kette in FIFO-Reihenfolge ausgeführt werden. Dies verbessert die Leistung, indem Software ermöglicht wird, die notwendige Kontrolle für eine korrekte Programmausführung aufzuweisen, während gleichzeitig ermöglicht wird, dass Hintergrundops ausgeführt werden, ohne den Kern anzuhalten. Ein häufiger Nutzungsfall würde ein MPI-Nachrichtensendevorgang sein, der eine Reihe von DMA-Operationen gefolgt von einem kurzen Meldeereignis an den Empfänger ist, beschrieben als eine Kette. Mehrere Ketten, die gleichzeitig ausgeführt werden, könnten mehrere schwebende MPI-Ereingisse darstellen.
  • Ketten und die Kettenverwaltungseinheit (CMU) fungieren als eine Sequenzwarteschlange für alle asynchronen Hintergrundbefehle, d. h., sie verfolgen alle asynchronen Operationen und erzwingen bei Bedarf eine Reihenfolge. Die CMU besteht im Grunde aus einer Tabelle, die alle Hintergrundbefehle protokolliert, die auszuführen sind, und ermittelt, wann sie ausgeführt werden können. Wenn Kettenbefehle vom Kern-Front-End zur CMU bewegt werden, werden alle Registerabhängigkeiten aufgelöst und die tatsächlichen Operandenwerte werden migriert, was dem Kern ermöglicht, mit einer primären Verarbeitung fortzufahren, während die Kette eine Auslagerungsaufgabe ist, die von der CMU direkt zu verwalten ist.
  • Nach offenbarten Ausführungsformen werden verkettete Befehle in der sequenziellen Reihenfolge ausgeführt, in der sie decodiert werden. Bevor ein verketteter Befehl ausgeführt wird, wird der Befehl von der CMU angehalten, bis vorangehende Befehle in der gleichen Kette abgeschlossen sind. Unterschiedliche Ketten können parallel arbeiten. Eine Verfeinerung am Kettenkonzept ist, dass, wenn sich Hintergrundbefehle außerhalb einer Kette befinden, sie automatisch als unabhängige Ketten mit einer Länge von eins angesehen werden und parallel verarbeitet werden können.
  • Ein Vorteil dieser Werkzeuge auf ISA-Ebene ist es, einem Programmierer zu ermöglichen, Software zu erstellen, die die Sichtbarkeit begründen kann, wann Daten von anderen Agenten im System beobachtet werden können, egal ob zur Leistung, Richtigkeit, Ausfallsicherheit, zum Debuggen oder für eine andere Verwendung. Als nicht einschränkendes Beispiel werden drei Kerne betrachtet, A, B und Z, wobei sich A und B im gleichen Rack (auf unterschiedlichen Platinen) befinden, während sich Z in einem anderen Rack befindet und sowohl A als auch B in Z untergebrachte Daten bearbeiten. Wenn es einen Stau zwischen A und Z, aber nicht A und B oder B und Z gibt, ermöglicht die Nutzung von offenbarten ISA-Erweiterungen, die explizit einen Status bereitstellen oder übertragen, dass ein Speichervorgang am endgültigen Ziel „festgeschrieben“ wurde, was die implizite Kenntnis mit sich bringt, dass kein Fehler aufgetreten ist, Software, die Sichtbarkeit von Daten im System insgesamt zu überdenken - wenn es für Softwareeigenschaften wichtig ist, zum Beispiel durch Senden weiterer Speichervorgänge an die gleiche Adresse oder den gleichen Adressbereich, wobei erwartet wird, dass diese weiteren Speichervorgänge erfolgreich sein werden. Das Ermöglichen, dass Software die Sichtbarkeit von Daten überdenkt, kann eine Verbesserung von Annahmen in Software zur Datenkonsistenz in Bezug auf Eigenschaften wie Richtigkeit, Leistungsanpassung, Debuggen, Belastbarkeit (Kenntnis, wann eine sichere Momentaufnahme gemacht werden kann) usw. ermöglichen.
  • Es gibt fünf Befehle, die in Tabelle 9 aufgeführt und beschrieben sind, die als Teil der Kern-ISA für die CMU implementiert wurden. Tabelle 9
    Befehl(e) Anmerkungen
    chain.init r1, r2, decr_when_done, intrpt_when_done Dies beginnt eine neue Kette.
    R1 fungiert als die Stilllegungsadresse und empfängt die eindeutige Ketten_id der CMU.
    R2 ist eine Arbeitsspeicheradresse, die atomar um eins verringert wird, falls decr_when_done hoch ist, andernfalls unverändert. Der Kern wird unterbrochen, wenn die Kette abgeschlossen wird, falls instrpt_when_done hoch ist.
    chain.end Schließt die aktuelle Kette und erhöht die chain_id
    chain.poll r1, r2 Fragt den Status einer Kette ab. R1 wird mit dem Kettenstatus aktualisiert. R2 weist die chain_id auf, die abgerufen werden soll.
    chain.wait r1 Hält den Kern an, bis eine Kette alle ihre Befehle abschließt. R1 weist die abzuschließende chain_id auf.
    chain.kill Vernichtet eine Kette. R1 weist die chain_id auf, die vernichtet werden soll.
  • Typisches Verhalten:
  • Eine Kette wird begonnen, wenn ein chain.init-Befehl ausgeführt wird. Danach wird angenommen, das alle neuen Hintergrundbefehle Teil der neuen Kette sind. Die Kette wird als abgeschlossen angesehen, wenn ein chain, end ausgeführt wird. Falls ein chain.init vor einem chain.end ausgeführt wird, wird die aktuelle Kette abgeschlossen und eine neue Kette begonnen, als ob ein chain.end gerade vor dem neuen chain.init ausgegeben worden wäre.
  • Um Software Einsicht in den Status einer Kette zu geben, kann chain.poll ausgeführt werden. Dieser Befehl gibt ein zusammengesetztes Bitfeld mit den folgenden Feldern und Werten zurück: Bits 7:0 = der Status der Kettenoperation, definiert als 0 = nicht erledigt, 1 = erledigt und 2 = Fehler aufgetreten. Bits 15:8 sind die Anzahl der aktuellen Ketten. Software kann durch chain.wait und chain.kill zusätzliche Kontrolle über Ketten ausüben.
  • ZWISCHENSPEICHERKOHÄRENZPROTOKOLL MIT WEITERLEITUNGS-/EIGENZUSTAND ZUR ARBEITSSPEICHERZUGRIFFSREDUKTION IN EINER MEHRKERN-CPU
  • Für gemeinsam genutzte Arbeitsspeicherbereiche innerhalb einer gemeinsam genutzten Kohärenzdomäne, wenn mehrere Kerne den gleichen Datensatz in ihren lokalen Zwischenspeichern manipulieren, werden Kohärenzprotokolle verwendet, um das Lesen und Schreiben von Daten zu verwalten. Diese Protokolle definieren Zustände, die die Antwort eines Zwischenspeichers auf eine Anforderung entweder von seinem eigenen assoziierten Kern oder von anderen Zwischenspeichern in der Kohärenzdomäne bestimmen. Während dies nützlich für lokalen Speicher mit niedriger Latenz ist, weisen Zwischenspeicher dahingehend eine Einschränkung auf, dass Lesefehlzugriffe und Leitungsräumungen Lese-/Schreibvorgänge in Arbeitsspeicher höherer Levels mit hoher Latenz erfordern. Lese-/Schreibzugriffe auf Arbeitsspeicher höherer Levels können einen Latenznachteil auf sich nehmen, der um Größenordnungen größer als die Zugriffszeit des lokalen Zwischenspeichers ist. Das Auftreten dieser Ereignisse kann die Leistung des Zwischenspeichers mindern. Stattdessen schränken offenbarte Ausführungsformen falsche Arbeitsspeicherzugriffe ein und maximieren die Nutzung von Daten, die zwischen Zwischenspeichern laufen.
  • Das offenbarte Zwischenspeicherkohärenzprotokoll implementiert eine Kombination der folgenden Zustände, um Kohärenz sicherzustellen, während gleichzeitig versucht wird, Arbeitsspeicher-Lese- und Schreibvorgänge zu minimieren: Modifiziert (M - inkonsistent, eigener Kern kann lesen oder schreiben, keine Mitbenutzer), Besitz (O - inkonsistent, schreibgeschützt, Mitbenutzer existieren), Weiterleiten (F - fehlerfrei, schreibgeschützt, Mitbenutzer existieren), Exklusiv (E - fehlerfrei, schreibgeschützt, keine Mitbenutzer), Geteilt (S - kann fehlerfrei oder inkonsistent sein, schreibgeschützt, Mitbenutzer existieren) und Ungültig (I).
  • Das offenbarte Zwischenspeicherkohärenzprotokoll regelt die Zwischenspeicherkohärenz in einer Kohärenzdomäne. Eine Kohärenzdomäne kann zum Beispiel alle vier Kerne eines Prozessors enthalten, wie die Kerne 0-3 von Prozessor 201, wie in 2 veranschaulicht.
  • Offenbarte Ausführungsformen ermöglichen eine gemeinsamen Nutzung von Daten zwischen Zwischenspeichern, was eine wesentlich niedrigere Latenz als ein Zugriff auf Arbeitsspeicher höherer Ebenen ergeben kann. In einigen Ausführungsformen wird ein Arbeitsspeicherlesefehler in einen ersten Zwischenspeicher durch einen anderen Zwischenspeicher in der Kohärenzdomäne bedient, der eine Kopie der Daten aufweist, anstatt einen Arbeitsspeicherlesevorgang zu erteilen. Das offenbarte Zwischenspeicherkohärenzprotokoll minimiert Arbeitsspeicherlese- und -schreibvorgänge auf mehrere Arten. Die Vorteile des Bedienens von Datenanforderungen von benachbarten Zwischenspeichern innerhalb einer Kohärenzdomäne können unabhängig von der Topologie oder Organisation der Zwischenspeicher und Kerne in einem System erzielt werden.
  • Erstens werden in einigen Ausführungsformen Arbeitsspeicherschreibvorgänge reduziert, da ein Zurückschreiben von inkonsistenten Daten nur erforderlich ist, wenn eine Zwischenspeicherzeile aufgrund einer lokalen Zwischenspeicherzeilensersetzungsrichtlinie aus dem M-Zustand in den I-Zustand geleert wird. In einigen Ausführungsformen findet kein Rückschreiben statt, wenn eine Zwischenspeicherzeile vom M-Zustand in den O-Zustand übergeht. Vielmehr findet in einem derartigen Szenario ein Rückschreiben später statt. Nachdem keine Mitbenutzer der inkonsistenten Zwischenspeicherzeile existieren, was bewirkt, dass die Zwischenspeicherzeile mit O-Zustandsbesitz in den M-Zustand zurückkehrt, wird die Zwischenspeicherzeile zurückgeschrieben, sobald sie aus dem Zwischenspeicher mit M-Zustandsbesitz geleert wird.
  • Zweitens werden Arbeitsspeicherlesevorgänge reduziert, da das Vorhandensein des F-Zustands ermöglicht, dass es eine einzige Antworteinheit für Leseanforderungen an eine gemeinsam genutzte Zeile gibt. Sobald also ein Datenelement zum ersten Mal aus dem Arbeitsspeicher gelesen wird, werden alle nachfolgenden Leseanforderungen an diese Zwischenspeicherzeile von Daten in einem oder mehreren von mehreren Zwischenspeichern bedient. Ohne den F-Zustand machen in einigen Szenarien alle Zwischenspeicher mit der Zwischenspeicherzeile im S-Zustand die Zwischenspeicherzeile ungültig und der anfordernde Zwischenspeicher liest dann die Zeile aus dem Arbeitsspeicher. Stattdessen reagiert in einigen Ausführungsformen durch die Hinzufügung des F-Zustands nur ein einziger Zwischenspeicher auf entfernte Leseanforderungen: wobei die Zwischenspeicherzeile vom F-Zustand bereitgestellt wird, falls fehlerfrei, oder vom O- oder M-Zustand, falls inkonsistent. Darüber hinaus ermöglicht die Existenz des F-Zustands den Zwischenspeichern im S-Zustand, Fehlzugriffanforderungen zu ignorieren, was Energie und Bandbreite des Kohärenznetzwerks spart.
  • Die richtige Befolgung dieses Protokolls resultiert zumindest in den folgenden Verbesserungen bei der Zwischenspeicherleistung und angewandten Zwischenspeicherkohärenzprotokollen in den offenbarten Ausführungsformen:
    1. 1. Genau ein Zwischenspeicher reagiert auf eine bestimmte Anforderung. Verbesserung der Machbarkeit der Nutzung dieses Protokolls für eine beliebige Implementierung (Snoop-Bus, Verzeichnis usw.).
    2. 2. Es gibt eine Mindestanzahl (2) von Arbeitsspeicherzugriffsfällen: (1) Einen Lesefehlzugriff, wenn die Zwischenspeicherzeile derzeit nicht in der Kohärenzdomäne existiert, und (2) ein Rückschreiben bei Entleerung einer inkonsistenten Zwischenspeicherzeile im M-Zustand (siehe 12A). Dies resultiert in einer Leistungsverbesserung gegenüber bestehenden Protokollen.
  • 12A veranschaulicht ein Zustandsablaufdiagramm für das offenbarte Zwischenspeicherkohärenzprotokoll nach einer Ausführungsform. Wie gezeigt ist Zustandsablaufdiagramm 1200 für eine (M.O.E.S.I + F)-Zustandsmaschine und enthält die Zustände modifiziert 1202, Besitz 1204, Weiterleiten 1206, exklusiv 1208, geteilt 1210 und ungültig 1212. Tabelle 10 stellt eine Legende bereit, die die Bedeutung jeder der Bogenbeschriftungen von 12A beschreibt.
  • Wie illustriert repräsentieren durchgezogene Bögen Zustandsänderungen, die als Reaktion auf einen mit dem Zwischenspeicher assoziierten Kern stattfinden, d. h. den eigenen Kern des Zwischenspeichers, zum Beispiel repräsentiert Bogen 1214 einen Kern, der eine exklusive Kopie einer Zwischenspeicherzeile möglicherweise als Reaktion auf eine Lesen-zum-Besitz-Anforderung anfordert.
  • Gestrichelte Bögen repräsentieren andererseits Zustandsänderungen, die als Reaktion auf externe Ereignisse stattfinden, wie eine Kohärenzanforderung (d. h. eine Anforderung nach einer adressieren Zwischenspeicherzeile, die von einem entfernten Zwischenspeicher oder entfernten Kern innerhalb der Kohärenzdomäne empfangen wurde). Bogen 1216 repräsentiert zum Beispiel einen entfernten Kern, der eine Kopie einer fehlerfreien Zwischenspeicherzeile in einem exklusiven Zustand anfordert, wobei die Zwischenspeicherzeilendaten bereitgestellt werden und die Zwischenspeicherzeile vom exklusiven in den Weiterleitungszustand übergeht. In einigen Ausführungsformen enthält eine Kohärenzdomäne eine Teilmenge der Zwischenspeicher in einem Rechensystem. Gestrichelte Bögen werden auch verwendet, um anzuzeigen, dass eine Zwischenspeicherzeile geleert wird (zum Beispiel aufgrund einer Zwischenspeicherzeilenaustauschrichtlinie) und von einem beliebigen Zwischenspeicherzustand in den ungültigen Zustand übergeht, wie zum Beispiel Bogen 1218. Tabelle 10
    Bezeichnung Bedeutung
    GetM Es ist eine entfernte Schreibanforderung für die Zwischenspeicherzeile erfolgt.
    GetS Es ist eine entfernte Leseanforderung für die Zwischenspeicherzeile erfolgt.
    Evict Die Zwischenspeicherzeile wird aufgrund eines lokalen Zwischenspeicherzeilenaustauschs geleert.
    WR Der lokale Kern hat eine Schreibanforderung gestellt.
    RD Der lokale Kern hat eine RD-Anforderung gestellt.
    FloatM Der Zwischenspeicher ist der letzte, der eine vorher gemeinsam genutzte inkonsistente Zeile besessen hat, Übergang in den M-Zustand.
    FloatE Der Zwischenspeicher ist der letzte, der eine vorher gemeinsam genutzte fehlerfreie Zeile besessen hat, Übergang in den E-Zustand.
    FloatO Gemeinsam genutztem Zwischenspeicher wird der O-Zustand übermittelt.
    FloatF Gemeinsam genutztem Zwischenspeicher wird der F-Zustand übermittelt.
    SendM Eine entfernte Leseanforderung für einen Zwischenspeicher im M-Zustand; Senden von Daten, Übergang in den O-Zustand.
  • ZWISCHENSPEICHERZUSTANDSÜBERGÄNGE UND ZWISCHENSPEICHERZEILEN-DATENBEWEGUNG
  • Im Betrieb, wie durch 12A veranschaulicht, werden Zwischenspeicherzeilendaten zwischen den Zwischenspeichern gemeinsam genutzt und die Zwischenspeicherzustände gehen folgendermaßen über:
  • Aus dem modifizierten Zustand 1202, wenn ein Zwischenspeicher ein GetS empfängt, Senden der Zwischenspeicherzeilendaten und Übergang in den O-Besitzzustand. Wenn der Zwischenspeicher ein GetM empfängt, Senden der Zwischenspeicherzeilendaten und Übergang in den ungültigen I-Zustand. In einigen Ausführungsformen, wenn die Zwischenspeicherzeile geleert wird, Rückschreiben der Zwischenspeicherzeilendaten und Übergang in den ungültigen I-Zustand. In einigen Ausführungsformen, wenn die Zwischenspeicherzeile im M-Zustand geleert wird, verzögert der Zwischenspeichersteuerschaltkreis einen Arbeitsspeicherschreibzugriff durch Kopieren der inkonsistenten Zwischenspeicherzeile in einen verfügbaren M-Zwischenspeicherschlitz irgendwo in der Kohärenzdomäne, anstatt zu bewirken, dass die modifizieren Daten zurückgeschrieben werden.
  • Aus dem Besitzzustand 1204, wenn ein Zwischenspeicher ein GetS empfängt, Senden der Zwischenspeicherzeilendaten und Verbleiben im O-Besitzzustand. Wenn der Zwischenspeicher ein GetM empfängt, Senden der Zwischenspeicherzeilendaten und Übergang in den ungültigen I-Zustand. Wenn die Zwischenspeicherzeile geleert wird, wenn es noch mehrere Mitbenutzer gibt, Transferieren des Besitztums an einen der Mitbenutzer und Übergang der Zwischenspeicherzeile in den ungültigen I-Zustand. Wenn es nur einen Mitbenutzer gibt und dieser Mitbenutzer entfernt wird, was diese Zwischenspeicherzeile als die einzige Instanz der inkonsistenten Daten in der Kohärenzdomäne lässt, Übergang der Zwischenspeicherzeile in den modifizierten M-Zustand (d. h. der Zwischenspeicher weist nun die einzige Kopie der modifizierten Zwischenspeicherzeile in der Kohärenzdomäne auf).
  • Aus dem Weiterleitungszustand 1206, wenn ein Zwischenspeicher ein GetS empfängt, Senden der Zwischenspeicherzeilendaten und der Zustand bleibet unverändert. Wenn der Zwischenspeicher ein GetM empfängt, Senden der Zwischenspeicherzeilendaten und Übergang in den ungültigen I-Zustand. Wenn die Zwischenspeicherzeile geleert wird und mehrere Mitbenutzer verbleiben, designiert die Zwischenspeichersteuerverschaltung einen der mehreren Mitbenutzer als den neuen Weiterleitenden und die Zwischenspeicherzeile geht in den ungültigen I-Zustand über. Aber wenn die Zwischenspeicherzeile geleert wird und es nur einen Mitbenutzer gibt, bewirkt die Zwischenspeichersteuerverschaltung, dass dieser Mitbenutzer die Zwischenspeicherzeile in den Exklusivzustand versetzt (d. h. der Mitbenutzer weist nur eine Kopie von reinen Daten in der Kohärenzdomäne auf) und die Zwischenspeicherzeile geht in den ungültigen I-Zustand über.
  • Aus dem Exklusivzustand 1208, wenn ein Zwischenspeicher ein GetS empfängt, Senden der Zwischenspeicherzeilendaten und Übergang in den F-Weiterleitungszustand. Wenn der Zwischenspeicher ein GetM empfängt, Senden der Zwischenspeicherzeilendaten und Übergang in den ungültigen I-Zustand. Wenn die Zwischenspeicherzeile geleert wird, Übergang in den ungültigen I-Zustand.
  • Aus dem geteilten Zustand 1210, wenn ein Zwischenspeicher ein WR von seinem eigenen Kern empfängt, Übergang in den modifizierten Zustand 1202. In einigen Szenarien ist eine Zwischenspeicherzeile im S-Zustand gültig und bleibt im Zwischenspeicher gültig, aber geht in einen anderen Zustand über.
  • In einigen Szenarien, war z. B. ein Zwischenspeicher ein Mitbenutzer einer inkonsistenten Zwischenspeicherzeile, die sich im Besitzzustand durch einen anderen Zwischenspeicher befand, aber die Zwischenspeicherzeile in diesem Zwischenspeicher geleert wurde, sodass die Zwischenspeicherzeile in den Besitzzustand übergeht, falls mehrere Mitbenutzer verbleiben, oder in den modifizierten Zustand, falls dies der einzige verbleibende Mitbenutzer ist, bewirkt die Zwischenspeichersteuerverschaltung, dass der Zwischenspeicher die inkonsistente Zwischenspeicherzeile behält und in den O-Besitzzustand oder in den modifizierten M-Zustand übergeht. Ein Bewirken, dass ein Zwischenspeicher die Rolle des Weiterleitenden übernimmt, wenn der vorangehende Weiterleitende geleert wird, ist ein Beispiel eines „Übermittelns“ eines Zustands an den Zwischenspeicher, der der neue Weiterleitende wird.
  • Gleichermaßen war z. B. in einigen Szenarien ein Zwischenspeicher ein Mitbenutzer einer fehlerfreien Zwischenspeicherzeile, die sich im F-Weiterleitungszustand in einem anderen Zwischenspeicher befand, aber die Zwischenspeicherzeile wurde in diesem Zwischenspeicher geleert, sodass die Zwischenspeicherzeile in den Weiterleitungszustand übergeht, falls mehrere Mitbenutzer verbleiben, und in den Exklusivzustand, falls keine Mitbenutzer verbleiben, bewirkt die Zwischenspeichersteuerverschaltung, dass der Zwischenspeicher die fehlerfreie Zwischenspeicherzeile behält und in den O-Besitzzustand oder in den Exklusivzustand übergeht.
  • Aus dem ungültigen Zustand 1220, wenn ein ungültiger Zwischenspeicher ein WR von seinem eigenen Kern empfängt, Übergang in den modifizierten Zustand 1202. Wenn eine ungültige Zwischenspeicherzeile eine RD-Anforderung von ihrem eigenen Kern empfängt, Empfangen der Zwischenspeicherzeilendaten und Übergang in den Exklusivzustand, falls der Kern den Besitz der Zwischenspeicherzeile angefordert hat, oder in den Exklusivzustand, falls RD den Besitz angefordert hat.
  • Es ist anzumerken, dass, falls ein Zwischenspeicher einen RD von seinem eigenen Kern auf eine gültige Zwischenspeicherzeile empfängt, stellt dieser Zwischenspeicher die gelesenen Daten bereit und bleibt im gleichen Zustand, egal, ob er sich im Zustand M, O, E oder S befindet.
  • Es ist ersichtlich, dass in Ausführungsformen des offenbaren Zwischenspeicherkohärenzprotokolls, wie in 12A illustriert, der O-Zustand als der F-Zustand für inkonsistente Zwischenspeicherleitungen dient. Alle Antworten auf entfernte Leseanforderungen für gemeinsam genutzte Daten (GetS) werden vom O-Zustand (inkonsistent) oder F-Zustand (fehlerfrei) gehandhabt.
  • STEUERN VON ZWISCHENSPEICHERZUSTANDSÜBERGÄNGEN UND DATENBEWEGUNGEN
  • In einigen Ausführungsformen werden die in 12A veranschaulichten Zwischenspeicherzustandsübergänge und die oben aufgeführten Datenbewegungen von einem Zwischenspeichersteuerschaltkreis implementiert und verwaltet. Der Zwischenspeichersteuerschaltkreis 215 in 2 ist ein Beispiel. 12B veranschaulicht jedoch eine ausführlichere Ausführungsform eines Zwischenspeichersteuerschaltkreises zum Implementieren eines Zwischenspeicherkohärenzprotokolls, wie in 12A illustriert und wie oben beschrieben.
  • 12B veranschaulicht eine Ausführungsform eines Zwischenspeichersteuerschaltkreises zum Implementieren eines Zwischenspeicherkohärenzprotokolls, wie hierin beschrieben. Wie gezeigt enthält das Mehrkernrechensystem 1250 ein Datenantwortnetzwerk 1252, Datenzwischenspeicher D$0 1254, D$1 1256, D$2 1258 und D$3 1260, die zusammen eine Kohärenzdomäne definieren. Jeder der Datenzwischenspeicher weist zwei Sätze von Tags auf: Tag 0 und Tag 1, auch als Ping- und Pong-Tags bezeichnet. Dadurch, dass sie zwei Sätze von Tags aufweisen, wird jedem Kern ermöglicht, einen Satz von Tags zu verwenden, während der andere Satz aktualisiert wird. Der Zwischenspeichersteuerschaltkreis 1262 ermittelt, welcher der Sätze der Zwischenspeichertags zu einem bestimmten Zeitpunkt gültig ist.
  • Wie gezeigt enthält der Zwischenspeichersteuerschaltkreis 1262 eine Schattentagsteuerung 1264 und eine Schattentaganordnung 1266. In einigen Ausführungsformen enthält die Schattentaganordnung Duplikate von beiden Sätzen, Ping und Pong, von Zwischenspeichertags im Inneren jedes Kerns. Die Schattentagsteuerung 1264 stellt deshalb einen zentralen Ort zum Modellieren und Nachverfolgen aller der Zwischenspeicherzeilen und deren Zustände bereit. Der Zwischenspeichersteuerschaltkreis verwendet über die Schattentagsteuerung 1264 die Schattentaganordnung 1266 um zum Beispiel in dem Fall, in dem eine Zwischenspeicherzeile im Weiterleitungszustand geleert wird, zu ermitteln, welcher Kern der neue Weiterleitende werden soll.
  • Im Betrieb fungiert der Schattentag in dem Sinn als ein Quasi-Orakel, in dem Sinn, dass er mehr als lokale Kerne weiß, wie zum Beispiel in einer Kombination von MESI und GOLS (Global O-im Besitz Lokal S-geteilt). Deduplizierung, Komprimierung und Verschlüsselung werden alle durch diesen Ansatz auf direkte Weise unter dem Schattentagsystem ermöglicht. Der Schattentag speichert zusätzliche Zustandsinformationen, die nicht in den Hauptarrays gehalten werden müssen, was Platz, Energie und Latenz spart. Da innerhalb des Schattentags Kenntnis über das DRAM-Rückschreiben besteht, können auch zusätzliche Schritte (Deduplizieren, Komprimieren, Verschlüsseln) angewandt werden, die durchgeführt werden müssen, wenn schließlich das Rückschreiben stattfindet. Lokale Kerne bearbeiten unkomprimierte/verschlüsselte/duplizierte Daten und sind in Unkenntnis über all dies. Dies könnte verwendet werden, um ein Voll-Leer-Bit oder eine Metadatenmarkierung zu unterstützen, was ein Nachverfolgen von transaktionalen Arbeitsspeichereigenschaften durch Zeiger und Poison-Bits enthält.
  • 13 ist ein Ablaufdiagramm, das einen von einer Zwischenspeichersteuerverschaltung durchgeführten Prozess nach einigen Ausführungsformen veranschaulicht. Die Zwischenspeichersteuerverschaltung ist in einigen Ausführungsformen ein Teil eines Prozessorkerns. In einigen Ausführungsformen sind ein oder mehrere Zwischenspeichersteuerschaltkreise in der Nähe eines oder mehrerer Zwischenspeicher angeordnet und steuern diese. Der Ablauf verfolgt nach, welcher Zwischenspeicher in die gemeinsam genutzte Domäne eingetreten ist. Dadurch, dass ein Zähler für jede Zwischenspeicherzeile unter Verwendung von n Bits gepflegt wird, wobei 2n die Gesamtanzahl der Zwischenspeicher in der Kohärenzdomäne ist, kann jeder Zwischenspeichersteuerschaltkreis überwachen, wann eine Zwischenspeicherzeile der gemeinsam genutzten Kohärenzgruppe für eine Zwischenspeicherzeilenadresse beigetreten ist.
  • Wie gezeigt beginnt die Zwischenspeichersteuerverschaltung den Ablauf durch Warten auf Zwischenspeicherzeilendaten. Bei 1302 empfängt ein vom Zwischenspeichersteuerschaltkreis gesteuerter Zwischenspeicher Zwischenspeicherzeilendaten, wonach die Zwischenspeichersteuerverschaltung den Kohärenzzustand dieser Zwischenspeicherzeile auf S setzt, einen Zähler von Anforderungen an diese Zwischenspeicherzeile auf 0 setzt und auf nachfolgende Anforderungen an die adressierte Zwischenspeicherzeile wartet. Bei 1304 erhöht die Zwischenspeichersteuerverschaltung den Zähler als Reaktion auf ein Empfangen einer GetS-Anforderung an die adressierte Zwischenspeicherzeile. Bei 1306 prüft die Zwischenspeichersteuerverschaltung als Reaktion auf ein Empfangen eines PutS (S evict) zusätzlich zum Reihenfolgezähler (C_Evict) des Senders, ob ihr Zähler größer als der Zähler des Senders (C_Evict) ist, und wenn ja, verringert sie ihren Zähler. Andernfalls tut sie nichts. Bei 1308 prüft die Zwischenspeichersteuerverschaltung als Reaktion auf ein Empfangen eines PutP (O evict) oder PutF (Fevict), ob ihr Zähler beim Empfangen der Anforderung null ist, und falls ja, ändert sie bei 1312 ihren Zustand auf O/F bei 1314 oder bei 1316E auf M/E, abhängig davon, ob andere S-Zwischenspeicher existieren. Und falls nein, verringert die Zwischenspeichersteuerverschaltung bei 1310 den Zähler.
  • Wenn ein PutS (S evict) gesendet wird, wird der Reihenfolgezähler (C_Evict) dieses Zwischenspeichers mit diesem gesendet. Alle gemeinsam genutzten Zwischenspeicher vergleichen ihre Zähler mit dem mit der Anforderung empfangenen Zähler, zum Beispiel bei 1306, und falls ihr Zähler höher ist, verringern sie ihn um 1, zum Beispiel bei 1310. Falls er niedriger ist, erfolgt keine Änderung.
  • Unterschiedliche Verfahren zum Überwachen der Gesamtanzahl an S-Zwischenspeichern sind möglich, abhängig von der Implementierungswahl. Für einen Snoop-Bus, wenn ein Zwischenspeicher eine PutO- oder PutF-Anforderung empfängt, kann er auf dem Bus (unabhängig von seinem Zähler) antworten und signalisieren, ob er sich im S-Zustand befindet oder nicht. Sobald der übergehende Zwischenspeicher Antworten von allen anderen Zwischenspeichern empfängt, weiß er, in welchen Zustand er überzugehen hat. Falls ein Verzeichnis verwendet wird, kann ein Zähler von allen S-Zwischenspeichern im Verzeichnis gespeichert werden, wobei dieser Zähler jedes Mal geprüft wird, wenn ein PutO/PutF empfangen wird.
  • GESCHALTETE BUS-FABRIC ZUM VERBINDEN MEHRERER KOMMUNIKATIONSEINHEITEN
  • Die offenbarte Befehlssatzarchitektur beschreibt eine geschaltete Bus-Fabric zum Verbinden von mehreren kommunizierenden Kernen im System. Ein Implementieren eines Systems nach der offenbarten Befehlssatzarchitektur wird mit einer offenbarten Fabric erleichtert, um mehrere Kerne miteinander zu verbinden.
  • 14 ist ein Diagramm eines Teils einer geschalteten Bus-Fabric zur Verwendung mit der offenbarten Befehlssatzarchitektur, nach einer Ausführungsform. Wie gezeigt sieht eine geschaltete Bus-Fabric 1400 vier parallele Routen vor, die acht Sendeports S0-S7 gemeinsam sind und von diesen verwendet wird. Die geschaltete Bus-Fabric 1400 sieht auch mehrere Spuren vor und ermöglicht dem Netzwerkverkehr, die Spuren zu wechseln, um die Leistung zu verbessern, zum Beispiel um stark verstopfte Routen zu vermeiden. Wie gezeigt enthält die geschaltete Bus-Fabric 1400 Pufferswitches 1401A-1401H6, die jeweils die Leistung des Switches zu überwachen oder zu messen haben. Dementsprechend bietet die geschaltete Bus-Fabric 1400 Mechanismen, um nicht nur den Fluss von Paketverkehr durch sie zu steuern, sondern auch eine Routenverstopfung zu überwachen und um Spuren zu wechseln, um verstopfte Routen zu vermeiden.
  • Wie gezeigt verbindet die geschaltete Bus-Fabric 1400 mehrere kommunizierende Sende- und Empfangsports, wobei vorgesehen ist, dass Hardwareeinheiten, Kerne, Schalkreise und Engines über die Ports angeschlossen werden. Die geschaltete Bus-Fabric 1400 enthält mehrere Busse - aus verstärkten Verbindungspufferswitches 1401A0-1401H3 aufgebaut - die verwendet werden, um alle kommunizierenden Einheiten zu umspannen. Hier wird zur Veranschaulichung ein verstärkter Bus mit 4 Spuren gezeigt, obwohl unterschiedliche Ausführungsformen unterschiedliche Anzahlen von Spuren enthalten können. In die geschaltete Bus-Fabric 1400 sind acht Sendeports S0-S7 und acht Empfangsports R0-R7 integriert. Die acht Sendeports sind als S0 1404, S1 1408, S2 1412, S3 1416, S4 1420, S5 1424, S6 1428 und S7 1432 gezeigt. Die acht Empfangsports sind als R0 1406, R1 1410, R2 1414, R3 1418, R4 1422, R5 1426, R6 1430 und R7 1434 gezeigt. In einigen Ausführungsformen können Ports Ausgaben von beliebigen der Zeilen konsumieren. In einigen Ausführungsformen befinden sich die mehreren kommunizierenden Ports auf einem gleichen Chip.
  • Takt und Zeitgebung
  • Alle Ports - hier durch (Si, Ri) enthalten - sind auf einen gemeinsamen Takt synchronisiert. In chipinternen Schaltkreisen ist dies der Fall. Im obigen Beispiel wird ohne Beschränkung der Allgemeinheit angenommen, dass eine Taktgrenze nicht länger als 5 Elemente überspannend ist. Anders ausgedrückt, darf j für ein kommunizierendes Paar Si zu Rj nicht größer als i+5 sein.
  • Alle Flop-Zeitgebungselemente sind unter der mit „Flop-Grenze“ bezeichneten Linie. Es ist anzumerken, dass die Länge des wiederholten Bus nicht länger als ein Taktzyklus ist.
  • Informierte Routingauswahl
  • Im Betrieb kann der Netzwerkverkehr Spuren auf Grundlage der Verstopfung wechseln oder im Versuch, die Anzahl der Hops zwischen der Quelle und dem Ziel zu minimieren, oder im Versuch, Netzwerksegmente einzusetzen, die eine höhere Datenwut bereitstellen. In einigen Ausführungsformen enthält jede Spur ein rückwärts propagierendes Signal (nicht gezeigt, das anzeigt, ob eine Spur mit einer gültigen Ausgabe verbunden werden könnte). Falls ermittelt wird, dass eine Route gesättigt ist, wechselt die Route die Spur. Oder falls der zurückzulegende Pfad verstopft ist oder zu viele Hops aufweist oder zu lang ist, wird beim Auswählen einer Route gleich ein anderer Pfad ausgewählt.
  • Im Betrieb, um zu entscheiden, welcher Pfad von A nach D zu verwenden ist, kann ein Pfad von A→B→D anstatt eines Pfads von A→B→C→D ausgewählt werden, was einen schnelleren Pfad mit weniger Hops ermöglicht. In einigen Ausführungsformen hängt der ausgewählte Pfad von der Länge der Wegstrecke, nicht von Konflikten ab.
  • Die geschaltete Bus-Fabric 1400 weist nach einigen Ausführungsformen vorteilhafte Netzwerkeigenschaften auf. In einigen Ausführungsformen unterstützt die geschaltete Bus-Fabric 1400 zum Beispiel eine asynchrone Nachrichtenübermittlung unter den mehreren Kernen im Netzwerk. Außerdem bietet die geschaltete Bus-Fabric 1400 zum Beispiel einen gemeinsamen Bus nicht nur zur Nutzung durch die Kerne eines Systems, sondern auch die CENG-, MENG- und QENG-Engines, von denen Instanzen an verschiedenen Positionen platziert werden können.
  • Chipinterne Pfade
  • Die wiederholten Spuren weisen keine Flip-Flip-Zustandselemente auf. Es wird nur der Vorwärtspfad gezeigt.
  • Mehrzykluspfade
  • Signale, die innerhalb eines einzigen Chips von einer Quelle zu einem Ziel laufen, benötigen einen Taktzyklus, um dies abzuschließen. Offenbarte geschaltete Fabrics implementieren ein geschaltetes Schaltkreisnetz. In derartigen Ausführungsformen können zwei beliebige Einheiten mit der vollen Datenraten (ein Datenelement pro Takt) kommunizieren, solange sie sich innerhalb einer Takttrennung voneinander befinden.
  • In einigen Ausführungsformen existieren Mehrzykluspfade für Signale, die von einem Chip zu einem anderen übertreten, wobei Signale länger als einen Taktzyklus benötigen, um ihr Ziel zu erreichen. In derartigen Ausführungsformen wird der Versatz zwischen den Takten auf den zwei Chips gemessen und Anpassungen werden durchgeführt, sodass mehrere Transaktionen gleichzeitig auf dem Draht existieren können. In derartigen Ausführungsformen sind Switches an der Ausgangsseite ausgelegt, immer dann herunterzuschalten, wenn eine Ausgabe verbraucht wird, was verhindert, dass weitere Eingaben den Ausgang erreichen. Ein kombinatorisches Abbruchsignal, das zusammen mit den Hauptdaten gesendet wird, stellt sicher, dass falsche Umschaltungen nicht über den Empfangspunkt hinaus propagieren.
  • Beispielhafte Pfade
  • 14 zeigt einen Satz von beispielhaften Pfaden, als Pfad 11451, Pfad 2 1452 und Pfad 3 1453 gekennzeichnet, um einen Betrieb der geschalteten Fabric zu veranschaulichen. Am Beginn des Takts (1), S0, S1, S2, bemerken alle, dass die obere Spur frei ist und beginnen zu senden. Die gezeigte Konfiguration bewirkt, dass für S0 (Pfad 11451) die Spuren ausgehen. Ein Rückwärtspropagieren eines Signals auf dem Pfad bewirkt, dass S0 beim nächsten Takt (Takt (2)) erkennt, dass der Sendevorgang ausgetauscht wurde, und fährt deshalb fort, vorangehende Daten zu senden, d. h., er ist blockiert. Ein Senden von einem Port bewirkt, dass alle Eingabeswitches SWI für einen Spurenwechsel konfiguriert werden. Pfad 2 1452 von S1 zu R4 ist erfolgreich und fährt mit Transfers fort, bis die Daten vollständig gesendet sind. Es ist anzumerken, dass S4 nur dann bei Takt(i) starten kann, wenn der Pfad S1 zu R4 anzeigt, dass es der letzte Sendevorgang bei Takt(i-1) ist, indem er ein Ende-Bit ausgibt. Pfad 3 1453 ist der längste Pfad und läuft von S2 zu R7. S3 und S5 versuchen beide, an R6 zu senden. Nur einer wird zu einem Zeitpunkt bedient (hier kann S3 als blockiert angenommen werden). Das Netzwerk blockiert nicht, falls die Anzahl der Spuren größer als die maximale einzelne Takttrennung der Anzahl der Einheiten ist. Mit einer Maximaltrennung von 3 Einheiten blockiert das Netzwerk nicht, falls es mindestens 3 Spuren gibt.
  • PAKETKAPERMECHANISMUS MIT LEITUNGSGESCHWINDIGKEIT FÜR LOKALE ANALYSE, MODIFIKATION, ABLEHNUNG
  • Die offenbare Befehlssatzarchitektur enthält eine Kapereinheit, die manchmal mit Leitungsgeschwindigkeit arbeitet, um eine live lokale Echtzeit-Analyse, Modifikation und Ablehnung von Pakten zu ermöglichen. Die grundlegende Voraussetzung ist eine Installation eines schnellen, kleinen Prioritätsadressbereichsprüfungs(PARC)-Schaltkreises, der Pakete überwacht, die eine Netzwerkschnittstelle durchlaufen, zum Beispiel einen Eintritts- oder Austrittsschaltkreis, und ermittelt, ob ein Paket oder eine Abfolge von Paketen zur Verarbeitung zu kapern ist oder nicht zu kapern ist und dem Paket den Durchtritt zu erlauben. In einigen Ausführungsformen erfolgt diese Ermittlung durch Vergleichen von Paketadressen mit einer Tabelle, die zu kapernde Adressbereiche auflistet. In einigen Ausführungsformen ist der PARC-Schaltkreis in der Nähe eines Netzwerk-Eintritts- oder Austrittspunkts platziert, um Pakete zu überwachen, die mit Leitungsgeschwindigkeit durchtreten. In einigen Ausführungsformen enthält der PARC-Schaltkreis einen Scratch-Zwischenspeicher, um zu verarbeitende gekaperte Pakete zu speichern. In einigen Ausführungsformen enthält der PARC-Schaltkreis eine Kaperausführungsverschaltung, um eine Kaperverarbeitung durchzuführen. In einigen Ausführungsformen generiert der PARC-Schaltkreis eine Unterbrechung, die von einer Kaper-Unterbrechungsdienstroutine zu bedienen ist. Das Ausmaß der vom Kaperausführungsschaltkreis durchgeführten Verarbeitung ist von der Zeilenrate, mit der der Schaltkreis arbeiten muss, durch Latenzanforderungen (d. h. des Ausmaßes der Kaperverarbeitungslatenz, die toleriert werden kann) und durch die Tiefe des Scratch-Zwischenspeichers (je tiefer der Scratch-Zwischenspeicher, desto mehr Pakete können gekapert und verarbeitet werden) begrenzt. Nach Abschluss der Kaperverarbeitung platziert die Kapereinheit das Paket zurück ins Netzwerk, manchmal mit einem modifizierten Paketkopf.
  • Im Betrieb, sobald die Kapereinheit ein Paket kapert, reiht sie das Paket in einen Arbeitsspeicher ein, der anstehende, zu aktualisierende Pakete beherbergt. In einigen Ausführungsformen stellt die Kapereinheit der Kaperausführungsverschaltung einen Auslöser bereit, um das Vorhandensein von gekaperten, zu verarbeitenden Paketen anzuzeigen. In einigen Ausführungsformen erhöht die Kapereinheit einen Zähler von zu verarbeitenden Paketen und die Kaperausführungsverschaltung verringert den Zähler nach Verarbeiten der Pakete.
  • In einigen Ausführungsformen versucht die Kapereinheit, mit Zeilengeschwindigkeit zu arbeiten, wobei sie ein oder mehrere Pakete kapert, das eine oder die mehreren Pakete an einen Arbeitsspeicher weiterleitet, zum Beispiel an einen kleinen Scratch-Zwischenspeicher in der Nähe, das eine oder die mehreren Pakete mit einem Ausführungsschaltkreis verarbeitet und die Pakete optional wieder in den Verkehrsfluss einführt, mit oder ohne Modifikation. In einigen Ausführungsformen ist der Arbeitsspeicher ein Mehrbank-Arbeitsspeicher mit einem separaten Ausführungsschaltkreis, um jede der Bänke parallel zu verarbeiten. In einigen Ausführungsformen überwacht ein Kaperschaltkreis Pakete, die durch eine Netzwerkschnittstelle treten, wie eine PCIe-Schnittstelle, und „kapert“ Pakete dynamisch, indem er sie aus der Eintritts-/Austrittsleitung zieht, an einen Arbeitsspeicher zur Verarbeitung leitet und dann optional die Pakete wieder - mit oder ohne Modifikation - in die ursprüngliche Leitung einführt.
  • BEISPIELHAFTE KAPERVERARBEITUNG
  • Das Ausmaß der Verarbeitung, die die Kaperausführungseinheit oder die Software erzielen kann, ist nur durch die Leitungsrate des gekaperten Datenstroms, durch erforderliche Latenzspezifikationen und die Menge des zum Halten von gekaperten Paketen zur Verarbeitung verfügbaren Scratch-Zwischenspeichers beschränkt. Einige Beispiele von Verarbeitung, die durch die Kapereinheit erreicht werden können, enthalten ohne Einschränkung eines oder mehrere von Folgendem:
  • Softwaredefiniertes Vernetzen (SDN): In einigen Ausführungsformen kann die Kapereinheit verwendet werden, ein softwaredefiniertes Netzwerk zu implementieren und zu unterstützen. Pakete, die mit einem bestimmten Netzwerk assoziiert sind, können zum Beispiel gekapert und an passende Netzwerkclients umgeleitet werden.
  • Umleitung von Paketen: In einigen Ausführungsformen, wenn Verschaltung auf einem ersten Chip ein Paket bzw. Pakete an einen zweiten Chip weiterleitet, kapert die Kapereinheit das Paket bzw. die Pakete und sendet sie an einen anderen Chip. In einigen Ausführungsformen, wenn Verschaltung ein Paket bzw. Pakete an einen Scratch-Speicher (Spad) weiterleitet, kapert die Kapereinheit das Paket bzw. die Pakete und sendet sie an einen anderen Spad, zum Beispiel als Reaktion darauf, dass der erste Spad defekt oder deaktiviert oder zu beschäftigt ist. Hierzu passt die Kapereinheit die Adresse bei der Übertragung an und ermöglicht, mit Zugriff auf den neuen Spad fortzufahren. In einigen Ausführungsformen generiert die Kapereinheit einen Fehler oder eine Ausnahme, wenn eine Sicherheitsfunktion ausgelöst wird. In einigen Ausführungsformen führt die Kapereinheit die Sicherheitszugriffssteuerung unabhängig von einem Betriebssystem durch.
  • Sicherheitszugriffssteuerung: In einigen Ausführungsformen führt die Kapereinheit Sicherheitsmerkmale durch, wie ein Verhindern, dass ein Paket einen verbotenen Arbeitsspeicherbereich erreicht. In einigen Ausführungsformen greift die Kapereinheit auf eine Tabelle oder andere Datenstruktur zu, die die gewünschte Sicherheitsfunktionalität für eine Adresse oder einen Bereich von Adressen auslöst. In einigen Ausführungsformen generiert die Kapereinheit einen Fehler oder eine Ausnahme, wenn eine Sicherheitsfunktion ausgelöst wird. In einigen Ausführungsformen führt die Kapereinheit die Sicherheitszugriffssteuerung unabhängig von einem Betriebssystem durch. In einigen Ausführungsformen kapert und verarbeitet die Kapereinheit ein Paket ohne Kenntnis durch den Sender des Pakets bzw. der Pakete.
  • Einspeisen von Informationen: In einigen Ausführungsformen speist die Kapereinheit Informationen in Pakete ein, mit oder ohne Kenntnis durch den Sender. In einigen Ausführungsformen speist die Kapereinheit Sicherheitsinformationen in einen Fluss von Paketen ein, wie eine Sender-ID, einen Zugriffsschlüssel und/oder ein verschlüsseltes Passwort.
  • Adressenmanipulation: In einigen Ausführungsformen steuert die Kapereinheit einen Zugriff, um den Anschein zu erwecken, dass mehrere, getrennte Arbeitsspeicher zusammenhängend sind. Mehrere, getrennte Scratch-Zwischenspeicher können beispielsweise auf einen zusammenhängenden Bereich logischer Adressen abgebildet werden.
  • 15 ist ein Blockdiagramm, das eine Kapereinheit nach einigen Ausführungsformen zeigt. Wie gezeigt beinhaltet Scratch-Zwischenspeicher 1500 acht Arbeitsspeicherbänke innerhalb des Scratch-Zwischenspeichers 1500: bank0 1520, bank1 1522, bank2 1524, bank3 1526, bank4 1528, bank5 1530, bank6 1532 und bank7 1534. Bank9 1536 ist ebenfalls enthalten und kommuniziert mit einer Kapereinheit-Eingabe-/Ausgabe-Schnittstelle 1536. In einigen Ausführungsformen befindet sich der Scratch-Zwischenspeicher 1500 in einem SRAM-Arbeitsspeicher. In einigen Ausführungsformen weist der Scratch-Zwischenspeicher 1500 seinen eigenen, dedizierten SRAM-Arbeitsspeicher auf. In einigen Ausführungsformen weist der Scratch-Zwischenspeicher 1500 eine unterschiedliche Anzahl von Bänken auf, ohne Einschränkung zum Beispiel 1, 2, 4, 16 oder mehr.
  • Es sind auch acht Ausführungsengines XE0 1502, XE1 1504, XE2 1506, XE3 1508, XE4 1510, XE5 1512, XE6 1514 und XE7 1516 enthalten. Jede der Ausführungsengines enthält eine arithmetisch-logische Einheit (ALU) oder eine ähnliche Verschaltung, um eine Operation an einem gekaperten Paket bzw. gekaperten Paketen auszuführen. Jede Ausführungsengine weist ferner Zugriff auf einen L1-Befehlszwischenspeicher (L1I ), einen L1-Datenzwischenspeicher (L1D ) und einen L1-Scratch-Zwischenspeicher (L1Spad) auf. In einigen Ausführungsformen verwendet eine Kaperausführungsengine Teile eines gemeinsam genutzten Arbeitsspeichers für ihre L1D$, L1I und L1Spad. Optionale Komponenten sind mit gestrichelten Rahmen angezeigt. Wie gezeigt verarbeitet jede der ach Ausführungsengines Pakete in einer anderen Bank des Scratch-Zwischenspeichers 1500.
  • Nach einigen Ausführungsformen ist ebenfalls eine Kapereinheit-Eingabe/Ausgabe(E/A)-Schnittstelle 1538 enthalten, die Pakete überwacht, die im Netzwerk 1540 laufen. In einigen Ausführungsformen analysiert die Kapereinheit-E/A-Schnittstelle 1538 jedes Netzwerkpaket unter Verwendung einer Ziel-Kaperadresse, einer Ziel-Adressmaske und einem gültigen Kaperbit, um zu ermitteln, ob ein überwachtes Paket zu kapern ist oder nicht. In einigen Ausführungsformen leitet die Kapereinheit-E/A-Schnittstelle 1538 nach Ermittlung, dass ein oder mehrere Pakete durch Kaperausführungsverschaltung zu verarbeiten sind, das eine oder die mehreren Pakete an eine der Kaperausführungsengines weiter, die der Arbeitsspeicherbank entspricht, in der sich das gekaperte Paket befindet.
  • In einigen Ausführungsformen verarbeitet jede der Ausführungsengines 1502-1516 Pakete, die in entsprechenden Bänken des Scratch-Zwischenspeichers 1500 gespeichert sind. In einigen Ausführungsformen ruft jede der Ausführungsengines 1502-1516 maschinenlesbare Befehle, die in einem Befehlsspeicher gespeichert sind, wie dem mit der Ausführungseinheit assoziierten L1I , ab, decodiert sie und führt sie aus.
  • In einigen Ausführungsformen ist eine der acht Ausführungseinheiten für das Überwachen des Verkehrs, das Ermitteln von zu kapernden Paketen, das Kapern der Pakete, das Speichern der Pakete im Arbeitsspeicher, nachfolgendes Anstoßen der Kaperausführungsschaltkreise, gekaperte Pakete gleichzeitig zu verarbeiten, verantwortlich. Durch die Verwendung von sieben der acht Kaperausführungseinheiten kann der Schaltkreis fähig sein, die notwendige Kaperverarbeitung an den gekaperten Paketen durchzuführen, und führt die Verarbeitung innerhalb eines vordefinierten Latenzmaximums durch.
  • Die offenbarte Kapereinheit, wie sie oben beschrieben ist, wählt Pakete in Echtzeit und mit Zeilengeschwindigkeit aus dem Verkehrsfluss aus und kapert diese, puffert diese Pakete in einen Puffer für gekaperte Pakete, führt eine Kaperverarbeitung an diesen Paketen durch, speist sie danach wieder in den Verkehrsfluss ein, möglicherweise mit einem aktualisierten Kopf oder aktualisierten Routinginformationen. Damit die Kapereinheit mit der Zeilenrate mithalten kann, muss sie die Verarbeitung innerhalb der von einem Latenzbudget des Verkehrsflusses erlaubten Zeit durchführen. Je größer die tolerierte Latenz, desto mehr kann verarbeitet werden. Die Menge der Pakete, die zur Verarbeitung gekapert werden können, ist auch durch die Tiefe des gekaperten Paketpuffers begrenzt. In einigen Ausführungsformen überwacht und misst die Kapereinheit die durch ihre Kaperverarbeitung eingeführte Latenz und passt dementsprechend die Rate an, mit der sie Pakete zur Verarbeitung kapert.
  • Es ist anzumerken, dass in einigen Ausführungsformen die Tatsache, dass ein oder mehrere Pakete aus einem Verkehrsfluss gekapert, verarbeitet und wieder in den Fluss eingespeist wurden, ohne Involvierung durch das Betriebssystem und ohne Einsicht durch einen Bediener des Rechensystems erfolgt. In einigen Ausführungsformen speist die Kapereinheit ein nominales Ausmaß von Latenz in ein oder mehrere oder alle Pakete ein, die nicht gekapert sind, um eine Erkennung der Kaperung durch Messen der leichten Latenz zu verhindern, die von der Kaperverarbeitung eingeführt wird. In einigen Ausführungsformen überwacht und misst die Kapereinheit das Ausmaß der durch die Kaperverarbeitung eingeführten Latenz und speist dieses Ausmaß von Latenz in Pakete ein, die nicht gekapert werden. In einigen Ausführungsformen versucht die Kapereinheit nicht, ihr Kapern zu verbergen, und aktualisiert einen oder mehrere Paketköpfe, um die Tatsache widerzuspiegeln, dass sie gekapert wurden, bevor sie sie wieder in den Verkehrsfluss einspeist.
  • 16 ist ein Blockdiagramm, das eine Kapereinheit nach einigen Ausführungsformen veranschaulicht. Wie gezeigt enthält Kapereinheit 1600 zwei Netzwerkschnittstellen, NIC0 1602 und NIC1 1604, um Pakete von einem vorgeschalteten Kanal zu empfangen, und zwei Netzwerkschnittstellen, NIC2 1612 und NIC3 1614, um Pakete an den vorgeschalteten Kanal zu senden. Die Kapereinheit 1600 enthält auch ein Routingwidget 1606, ein Durchgangswidget 1608 und ein Durchgangswidget 1610. Das Durchgangswidget 1608 ist ebenfalls gekoppelt, um Pakete an TM-Widget 1616 und TM-Widget 1618 zu senden und zu empfangen. In einigen Ausführungsformen sind die Netzwerkschnittstellen NIC0 1602, NIC1 1405, NIC2 1612 und NIC3 1413 innerhalb eines Prozessors eingebunden.
  • Im Betrieb überwachen die TM-Widgets 1616 und 1618 den Verkehr, der durch das Durchgangswidget 1608 läuft. In einigen Ausführungsformen sind der Eingang und der Ausgang die Schnittstelle zum Kern. In einigen Ausführungsformen nehmen die TM-Widgets 1616 und 1618 auf eine Kapertabelle Bezug, die zum Kapern interessierende Adressbereiche auflistet, und vergleichen die Quell- und Zieladressen von Paketen, die durchlaufen, mit der Tabelle. In einigen Ausführungsformen führen die TM-Widgets 1616 und 1618 eine tiefgehende Paketinspektion durch, um den Datenteil sowie die Kopfinformationen der durchlaufenden Pakete zu inspizieren, um zu ermitteln, ob ein Paket zu kapern ist, manchmal auf Grundlage eines Vergleichs mit der Kapertabelle. Wenn ein zu kaperndes Paket gefunden wird, wird es in einer Scratch-Zwischenspeicherstruktur mit Zeilengeschwindigkeit in eine Warteschlange eingereiht. Kaperausführungsverschaltung verarbeitet dann die in die Warteschlange eingereihten Befehle.
  • 17 ist ein Blockdiagramm, das einen einzigen Ausführungsblock einer Kapereinheit nach einigen Ausführungsformen veranschaulicht. Wie gezeigt enthält eine Kapereinheit 1700 eine Ausführungsengine (XE 1702) und ein Routingwidget 1704. Die Kapereinheit 1700 wird auch als an eine Eingangsnetzwerkschnittstelle, NIC 0 1706, über die Datenpakete empfangen werden, und zwei Austrittsnetzwerke, NIC 1 1708 und NIC 2 1710, gekoppelt gezeigt, über die Datenpakete gesendet werden.
  • Im Betrieb überwacht die Kapereinheit 1700 von NIC 0 1706 empfangene Pakete, wählt zu kapernde Pakete aus. Die Auswahl ergibt sich in einigen Ausführungsformen aus einer tiefgehenden Paketinspektion von Paketdaten und Köpfen und einem Vergleich mit einer Kapertabelle, die Kriterien zum Kapern eines Pakets angibt. Die Ausführungsengine XE 1702 verarbeitet dann die gepufferten, gekaperten Pakete. Schließlich platziert das Routingwidget 1704 unter Verwendung einer der Austrittsnetzwerkschnittstellen, NIC 1 1708 und NIC 2 1710, die gekaperten Pakete zurück in den Verkehrsfluss.
  • Befehlssätze
  • Ein Befehlssatz kann eine oder mehrere Befehlsformate enthalten. Ein bestimmtes Befehlsformat kann verschiedene Felder (z. B. Anzahl von Bits, Lage von Bits) definieren, um unter anderem die durchzuführende Operation (z. B. Opcode) und den bzw. die Operand(en), auf den bzw. die diese Operation durchzuführen ist, und/oder ein anderes Datenfeld bzw. andere Datenfelder (z. B. eine Maske) zu spezifizieren. Manche Befehlsformate sind ferner durch die Definition von Befehlsvorlagen (oder Teilformaten) aufgegliedert. Zum Beispiel können die Befehlsvorlagen eines bestimmten Befehlsformats definiert sein, verschiedene Teilsätze der Felder des Befehlsformats aufzuweisen (die enthaltenen Felder sind üblicherweise in der gleichen Reihenfolge, aber zumindest einige weisen verschiedene Bitpositionen auf, da weniger Felder enthalten sind), und/oder definiert sein, ein bestimmtes Feld unterschiedlich interpretiert aufzuweisen. Deshalb wird jeder Befehl einer ISA unter Verwendung eines bestimmten Befehlsformats ausgedrückt (und, falls definiert, in einer bestimmten der Befehlsvorlagen dieses Befehlsformats) und enthält Felder zum Spezifizieren der Operation und der Operanden. Zum Beispiel weist ein beispielhafter ADD-Befehl einen bestimmten Opcode und ein Befehlsformat auf, das ein Opcode-Feld, um diesen Opcode zu spezifizieren, und Operanden-Felder enthält, um Operanden auszuwählen (Quelle 1/Ziel und Quelle 2); und ein Auftreten dieses ADD-Befehls in einem Befehlsstrom wird spezifische Inhalte in den Operanden-Feldern aufweisen, die spezifische Operanden auswählen. Ein Satz von SIMD-Erweiterungen, die als Advanced Vector Extensions (AVX) (AVX1 und AVX2) bezeichnet werden und die das Vector-Extensions(VEX)-Codierschema verwenden, wurde freigegeben und/oder veröffentlicht (siehe z. B. Handbuch für Software-Entwickler zur Intel®-64- und IA-32-Architektur, September 2014; und siehe Programmierreferenz für Advanced Vector Extensions für die Intel®-Architektur, Oktober 2014).
  • Beispielhafte Befehlsformate
  • Ausführungsformen des hierin beschriebenen Befehls bzw. der hierin beschriebenen Befehle können in unterschiedlichen Formaten ausgeführt werden. Zusätzlich werden beispielhafte Systeme, Architekturen und Pipelines nachfolgend ausführlich beschrieben. Ausführungsformen des Befehls bzw. der Befehle können auf derartigen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf die besprochenen beschränkt.
  • Generisches vektorfreundliches Befehlsformat
  • Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das für Vektorbefehle geeignet ist (zum Beispiel gibt es bestimmte Felder, die für Vektorvorgänge spezifisch sind). Obwohl Ausführungsformen beschrieben werden, bei denen sowohl Vektor- als auch skalare Operationen durch das vektorfreundliche Befehlsformat unterstützt werden, verwenden alternative Ausführungsformen nur Vektoroperationen des vektorfreundlichen Befehlsformats.
  • 18A-18B sind Blockdiagramme, die ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen davon nach Ausführungsformen der Erfindung veranschaulichen. 18A ist ein Blockdiagramm, das ein generisches vektorfreundliches Befehlsformat und Befehlsvorlagen der Klasse A davon nach Ausführungsformen der Erfindung illustriert; während 18B ein Blockdiagramm ist, das das generische vektorfreundliche Befehlsformat und Befehlsvorlagen der Klasse B davon nach Ausführungsformen der Erfindung illustriert. Genauer ein generisches vektorfreundliches Befehlsformat 1800, für das Befehlsvorlagen der Klasse A und der Klasse B definiert sind, von denen beide Befehlsvorlagen ohne Arbeitsspeicherzugriff 1805 und Befehlsvorlagen mit Arbeitsspeicherzugriff 1820 enthalten. Der Begriff „generisch“ im Kontext des vektorfreundlichen Befehlsformats bezieht sich darauf, dass das Befehlsformat an keinen spezifischen Befehlssatz gebunden ist.
  • Während Ausführungsformen der Erfindung beschrieben werden, in denen das vektorfreundliche Befehlsformat Folgendes unterstützt: eine Vektoroperandenlänge (oder -größe) von 64 Bytes mit 32-Bit- (4-Byte-) oder 64-Bit- (8-Byte-)Datenelementbreiten (oder -größen) (und deshalb besteht ein 64-Byte-Vektor aus entweder 16 doppelwortgroßen Elementen oder alternativ 8 quadwortgroßen Elementen); eine Vektoroperandenlänge (oder -größe) von 64 Bytes mit 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-)Datenelementbreiten (oder -größen); eine Vektoroperandenlänge (oder -größe) von 32 Bytes mit 32-Bit- (4-Byte-), 64-Bit- (8-Byte-), 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-)Datenelementbreiten (oder -größen); und eine Vektoroperandenlänge (oder -größe) von 16 Bytes mit 32-Bit- (4-Byte-), 64-Bit- (8-Byte-), 16-Bit- (2-Byte-) oder 8-Bit- (1-Byte-)Datenelementbreiten (oder -größen); können alternative Ausführungsformen mehr, weniger und/oder unterschiedliche Vektoroperandengrößen (z. B. 256-Byte-Vektoroperanden) mit mehr, weniger oder unterschiedlichen Datenelementbreiten (z. B. 128-Bit- (16-Byte-)Datenelementbreiten) unterstützen.
  • Die Klasse-A-Befehlsvorlagen in 18A enthalten: 1) in den Befehlsvorlagen ohne Arbeitsspeicherzugriff 1805 wird eine Operationsbefehlsvorlage 1810 ohne Arbeitsspeicherzugriff vom vollständigen Rundungssteuerungstyp und eine Operationsbefehlsvorlage 1815 ohne Arbeitsspeicherzugriff vom Datentransformationstyp gezeigt; und 2) in den Befehlsvorlagen mit Arbeitsspeicherzugriff 1820 wird eine zeitliche Arbeitsspeicherzugriffsbefehlsvorlage 1825 und eine nicht zeitliche Arbeitsspeicherzugriffsbefehlsvorlage 1830 gezeigt. Die Klasse-B-Befehlsvorlagen in 18B enthalten: 1) in den Befehlsvorlagen ohne Arbeitsspeicherzugriff 1805 wird eine Operationsbefehlsvorlage 1812 ohne Arbeitsspeicherzugriff vom vollständigen Schreibmaskensteuerungs- und teilweisen Rundungssteuerungstyp und eine Operationsbefehlsvorlage 1817 ohne Arbeitsspeicherzugriff vom Schreibmaskensteuerungs-vsize-Typ gezeigt; und 2) in den Befehlsvorlagen mit Arbeitsspeicherzugriff 1820 wird eine Schreibmaskensteuerungsbefehlsvorlage 1827 mit Arbeitsspeicherzugriff gezeigt.
  • Das generische vektorfreundliche Befehlsformat 1800 enthält die unten aufgeführten folgenden Felder in der in den 18A-18B veranschaulichten Reihenfolge.
  • Formatfeld 1840 - Ein spezifischer Wert (ein Befehlsformatidentifikatorwert) in diesem Feld identifiziert das vektorfreundliche Befehlsformat eindeutig und somit Fälle des Auftretens von Befehlen im vektorfreundlichen Befehlsformat in Befehlsströmen. Als solches ist dieses Feld in dem Sinne optional, dass es für einen Befehlssatz, der nur das generische vektorfreundliche Befehlsformat aufweist, nicht erforderlich ist.
  • Basisoperationsfeld 1842 - Sein Inhalt unterscheidet verschiedene Basisoperationen.
  • Registerindexfeld 1844 - Sein Inhalt spezifiziert direkt oder durch Adressgenerierung die Orte der Quell- und Zieloperanden an, egal ob in Registern oder in Arbeitsspeicher. Diese enthalten eine ausreichende Anzahl von Bits, um N Register aus einer PxQ-Registerdatei (z. B. 32x512, 16x128, 32x1024, 64x1024) auszuwählen. Während in einer Ausführungsform N bis zu drei Quellen- und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quellen- und Zielregister unterstützen (z. B. können sie bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel fungiert, können sie bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als das Ziel fungiert, können sie bis zu zwei Quellen und ein Ziel unterstützen).
  • Modifikatorfeld 1846 - Sein Inhalt unterscheidet Auftreten von Befehlen im generischen Vektorbefehlsformat, die einen Arbeitsspeicherzugriff angeben, von denen, die dies nicht tun; das heißt zwischen Befehlsvorlagen ohne Arbeitsspeicherzugriff 1805 und Befehlsvorlagen mit Arbeitsspeicherzugriff 1820. Arbeitsspeicherzugriffsoperationen lesen aus der Arbeitsspeicherhierarchie und/oder schreiben in diese (in einigen Fällen unter Angabe der Quell- und/oder Zieladressen unter Verwendung von Werten in Registern), während Operationen ohne Arbeitsspeicherzugriff dies nicht tun (z. B. sind die Quelle und die Ziele Register). Während in einer Ausführungsform dieses Feld auch aus drei verschiedenen Wegen zum Durchführen von Arbeitsspeicheradressenberechnungen auswählt, können alternative Ausführungsformen mehr, weniger oder unterschiedliche Wege zum Durchführen von Arbeitsspeicheradressenberechnungen unterstützen.
  • Ergänzungsoperationsfeld 1850 - Sein Inhalt unterscheidet, welche von einer Vielzahl von unterschiedlichen Operationen zusätzlich zu der Basisoperation durchgeführt werden soll. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 1868, ein Alphafeld 1852 und ein Betafeld 1854 aufgeteilt. Das Ergänzungsoperationsfeld 1850 ermöglicht, dass gemeinsame Gruppen von Operationen in einem einzelnen Befehl statt in 2, 3 oder 4 Befehlen durchgeführt werden.
  • Skalierungsfeld 1860 - Sein Inhalt ermöglicht die Skalierung des Inhalts des Indexfelds zur Arbeitsspeicheradressgenerierung (z. B. zur Adressgenerierung, die 2Skalierung * Index + Basis verwendet).
  • Offsetfeld 1862A - Sein Inhalt wird als Teil der Arbeitsspeicheradressgenerierung verwendet (z. B. zur Adressgenerierung, die 2Skalierung * Index + Basis + Offset verwendet).
  • Offsetfaktorfeld 1862B (es ist anzumerken, dass die Nebeneinanderstellung des Offsetfelds 1862A direkt über dem Offsetfaktor 1862B anzeigt, dass das eine oder das andere verwendet wird) - Sein Inhalt wird als Teil der Adressengenerierung verwendet; es gibt einen Offsetfaktor an, der mit der Größe eines Arbeitsspeicherzugriffs (N) zu skalieren ist - wobei N die Anzahl der Bytes im Arbeitsspeicherzugriff ist (z. B. für eine Adressengenerierung, die 2Skalierung * Index + Basis + skalierter Offset verwendet). Redundante Bits niedriger Ordnung werden ignoriert und deshalb wird der Inhalt des Offsetfaktorfelds mit der Gesamtgröße des Arbeitsspeicheroperanden (N), um den endgültigen Offset zu generieren, der zum Berechnen einer effektiven Adresse zu verwenden ist. Der Wert von N ist durch die Prozessor-Hardware zur Laufzeit auf Basis des Feldes des vollständigen Opcodes 1874 (hierin weiter unten beschrieben) und dem Datenmanipulationsfeld 1854C bestimmt. Das Offsetfeld 1862A und das Offsetfaktorfeld 1862B sind in dem Sinn optional, dass sie für die Befehlsvorlagen ohne Arbeitsspeicherzugriff 1805 nicht verwendet werden und/oder andere Ausführungsformen nur eines oder keines der beiden implementieren können.
  • Datenelementbreitenfeld 1864 - Sein Inhalt unterscheidet, welche einer Reihe von Datenelementbreiten verwendet werden soll (in einigen Ausführungsformen für alle Befehle; in anderen Ausführungsformen nur für einige der Befehle). Dieses Feld ist in dem Sinne optional, dass es nicht erforderlich ist, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung einiger Aspekt der Opcodes unterstützt werden.
  • Schreibmaskenfeld 1870 - Sein Inhalt steuert für jede Datenelementposition einzeln, ob diese Datenelementposition im Zielvektoroperand das Ergebnis der Basisoperation und der Ergänzungsoperation widerspiegelt. Befehlsvorlagen der Klasse A unterstützen eine Schreimaskenanwendung mit Zusammenführen, während Befehlsvorlagen der Klasse B sowohl eine Schreibmaskenanwendung mit Zusammenführen als auch eine mit Nullsetzen unterstützen. Beim Zusammenführen ermöglichen Vektormasken, dass ein beliebiger Satz von Elementen im Ziel vor Aktualisierungen während der Ausführung einer beliebigen Operation (die durch die Basisoperation und die Zusatzoperation spezifiziert ist) geschützt ist; wobei in einer anderen Ausführungsform der alte Wert jedes Elements des Ziels geschützt wird, wo das entsprechende Maskenbit eine 0 aufweist. Im Gegensatz dazu ermöglichen Vektormasken beim Nullsetzen, dass ein beliebiger Satz von Elementen im Ziel während der Ausführung einer beliebigen Operation (die durch die Basisoperation und die Zusatzoperation spezifiziert ist) auf null gesetzt wird; in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Eine Teilmenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der Operation, die durchgeführt wird, zu steuern (das heißt den Umfang der Elemente, die modifiziert werden, vom ersten bis zum letzten); es ist jedoch nicht notwendig, dass die Elemente, die modifiziert werden, aufeinanderfolgend sind. Deshalb ermöglicht das Schreibmaskenfeld 1870 teilweise Vektoroperationen, einschließlich Lade-, Speicher-, arithmetische, logische Vorgänge usw. Während Ausführungsformen der Erfindung beschrieben werden, in denen der Inhalt des Schreibmaskenfelds 1870 eines von einer Anzahl von Schreibmaskenregistern auswählt, das die zu verwendende Schreibmaske beinhaltet (und deshalb identifiziert der Inhalt des Schreibmaskenfelds 1870 diese durchzuführende Maskierung indirekt), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Schreibmaskenfelds 1870 direkt die durchzuführende Maskierung angibt.
  • Direktfeld 1872 - Sein Inhalt ermöglicht die Angabe eines direkten Elements. Dieses Feld ist in dem Sinn optional, dass es in einer Implementierung des generischen vektorfreundlichen Formats nicht vorhanden ist, das keinen Direktoperanden unterstützt, und es in Befehlen nicht vorhanden ist, die keinen Direktoperanden verwenden.
  • Klassenfeld 1868 - Sein Inhalt unterscheidet zwischen unterschiedlichen Klassen von Befehlen. Unter Bezugnahme auf die 18A-B wählen die Inhalte dieser Felder zwischen Klasse-A- und Klasse-B-Befehlen aus. In den 18A-B werden Vierecke mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein bestimmter Wert in einem Feld vorhanden ist (z. B. Klasse A 1868A bzw. Klasse B 1868B für das Klassenfeld 1868 in den 18A-B).
  • BEFEHLSVORLAGEN DER KLASSE A
  • Im Falle der Befehlsvorlagen 1805 der Klasse A ohne Arbeitsspeicherzugriff wird das Alpha-Feld 1852 als ein RS-Feld 1852A interpretiert, dessen Inhalt unterscheidet, welche der unterschiedlichen Ergänzungsoperationstypen durchgeführt werden sollen (z. B. Runden 1852A.1 und Datentransformation 1852A.2 sind jeweils für die Befehlsvorlagen für Operation 1810 vom Rundungstyp ohne Arbeitsspeicherzugriff bzw. die Operation 1815 vom Datentransformationstyp ohne Arbeitsspeicherzugriff spezifiziert), während das Beta-Feld 1854 unterscheidet, welche der Operationen des angegebenen Typs durchzuführen sind. In den Befehlsvorlagen ohne Arbeitsspeicherzugriff 1805 sind das Skalierungsfeld 1860, das Offsetfeld 1862A und das Offsetskalierungsfeld 1862B nicht vorhanden.
  • BEFEHLSVORLAGEN OHNE ARBEITSSPEICHERZUGRIFF - OPERATION VOM VOLLEN RUNDUNGSSTEUERTYP
  • In der Befehlsvorlage für die Operation vom vollen Rundungssteuertyp ohne Arbeitsspeicherzugriff 1810 wird das Beta-Feld 1854 als Rundungssteuerungsfeld 1854A interpretiert, dessen Inhalt(e) statisches Runden bereitstellen. Während in den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerungsfeld 1854A ein Feld zum Unterdrücken aller Gleitkommaausnahmen (SAE) 1856 und ein Rundungsoperationssteuerungsfeld 1858 enthält, können alternative Ausführungsformen diese beiden Konzepte unterstützen und in das gleiche Feld codieren oder nur das eine oder das andere dieser Konzepte/Felder aufweisen (können z. B. nur das Rundungsoperationssteuerungsfeld 1858 aufweisen).
  • SAE-Feld 1856 - Sein Inhalt unterscheidet, ob die Ausnahmeereignismeldung zu deaktivieren ist oder nicht; wenn der Inhalt des SAE-Felds 1856 anzeigt, das die Unterdrückung aktiviert ist, meldet ein bestimmter Befehl keine Art von Gleitkommaausnahmeflag und startet keinen Gleitkommaausnahmehandler.
  • Rundungsoperationssteuerungsfeld 1858 - Sein Inhalt unterscheidet, welche aus einer Gruppe von Rundungsoperationen durchzuführen ist (z. B. Aufrunden, Abrunden, Runden Richtung null und Runden zur nächstgelegenen Rundungszahl). Somit ermöglicht der Rundenoperationssteuerbereich 1858 das Ändern des Rundungsmodus für jeden Befehl einzeln. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Angeben von Rundungsmodi enthält, ist der Inhalt des Rundungsoperationssteuerungsfelds 1850 diesem Registerwert übergeordnet.
  • Befehlsvorlagen ohne Arbeitsspeicherzugriff - Operationen vom Datentransformationstyp
  • In der Befehlsvorlage ohne Arbeitsspeicherzugriff mit Operation 1815 des Typs Datentransformation wird das Beta-Feld 1854 als ein Datentransformationsfeld 1854B interpretiert, dessen Inhalt unterscheidet, welche von einer Reihe von Datentransformationen durchgeführt werden sollen (z. B. ohne Datentransformation, Swizzeln, Broadcast).
  • Im Fall einer Befehlsvorlage mit Arbeitsspeicherzugriff 1820 der Klasse A wird das Alpha-Feld 1852 als ein Entfernungshinweisfeld 1852B interpretiert, dessen Inhalt unterscheidet, welcher der Entfernungshinweise zu verwenden ist (in 18A, wird zeitlich 1852B.1 bzw. nicht zeitlich 1852B.2 für die zeitliche Arbeitsspeicherzugriffsbefehlsvorlage 1825 bzw. die nicht zeitliche Arbeitsspeicherzugriffsbefehlsvorlage 1830 spezifiziert), während das Beta-Feld 1854 als ein Datenmanipulationsfeld 1854C interpretiert wird, dessen Inhalt unterscheidet, welche einer Anzahl von Datenmanipulationsoperationen (auch als Stammfunktionen bekannt) durchzuführen ist (z. B. keine Manipulation; Broadcast; Aufwärtskonversion einer Quelle; und Abwärtskonversion eines Ziels). Die Befehlsvorlagen mit Arbeitsspeicherzugriff 1820 enthalten das Skalierungsfeld 1860 und optional das Offsetfeld 1862A oder das Offsetskalierungsfeld 1862B.
  • Vektorspeicherbefehle führen ein Laden von Vektoren aus dem und ein Speichern von Vektoren in den Arbeitsspeicher mit Konvertierungsunterstützung durch. Wie bei normalen Vektorbefehlen übertragen Vektorspeicherbefehle Daten in einer datenelementweisen Art aus dem/in den Arbeitsspeicher, wobei die Elemente, die tatsächlich übertragen werden, durch den Inhalt der Vektormaske, die als die Schreibmaske ausgewählt ist, vorgegeben werden.
  • Befehlsvorlagen mit Arbeitsspeicherzugriff - zeitlich
  • Zeitliche Daten sind Daten, die wahrscheinlich bald genug wiederverwendet werden, um von einem Zwischenspeichern zu profitieren. Dies ist jedoch ein Hinweis, und unterschiedliche Prozessoren können ihn auf unterschiedliche Weise implementieren, einschließlich des vollständigen Ignorierens des Hinweises.
  • Befehlsvorlagen mit Arbeitsspeicherzugriff - nicht zeitlich
  • Nicht zeitliche Daten sind Daten, bei denen es unwahrscheinlich ist, dass sie bald genug wiederverwendet werden, um von einem Zwischenspeichern im Level-1-Zwischenspeicher zu profitieren, und denen Priorität für eine Entfernung gegeben werden sollte. Dies ist jedoch ein Hinweis, und unterschiedliche Prozessoren können ihn auf unterschiedliche Weise implementieren, einschließlich des vollständigen Ignorierens des Hinweises.
  • Befehlsvorlagen der Klasse B
  • Im Fall der Befehlsvorlagen der Klasse B wird das Alpha-Feld 1852 als ein Feld der Schreibmaskensteuerung (Z) 1852C interpretiert, dessen Inhalt unterscheidet, ob das durch das Schreibmaskenfeld 1870 gesteuerte Schreibmaskieren ein Zusammenführen oder ein Nullsetzen sein soll.
  • Im Fall der Befehlsvorlagen 1805 ohne Arbeitsspeicherzugriff der Klasse B wird ein Teil des Beta-Feldes 1854 als ein RL-Feld 1857A interpretiert, dessen Inhalt unterscheidet, welcher der unterschiedlichen Ergänzungsoperationstypen durchgeführt werden soll (z. B. sind Runden 1857A.1 und Vektorlänge (VSIZE) 1857A.2 für die Befehlsvorlage ohne Arbeitsspeicherzugriff, mit Schreibmaskensteuerung, mit Operation des Typs teilweise Rundungssteuerung 1812 bzw. die Befehlsvorlage ohne Arbeitsspeicherzugriff, mit Schreibmaskensteuerung, mit Operation des Typs VSIZE 1817 spezifiziert), während der Rest des Beta-Feldes 1854 unterscheidet, welche der Operationen des spezifizierten Typs durchgeführt werden soll. In den Befehlsvorlagen ohne Arbeitsspeicherzugriff 1805 sind das Skalierungsfeld 1860, das Offsetfeld 1862A und das Offsetskalierungsfeld 1862B nicht vorhanden.
  • In der Operationsbefehlsvorlage vom vollständigen Rundungssteuerungstyp ohne Arbeitsspeicherzugriff 1810 wird der Rest des Beta-Felds 1854 als ein Rundungsoperationsfeld 1859A interpretiert und die Ausnahmeereignismeldung ist deaktiviert (ein bestimmter Befehl meldet keine Art von Gleitkommaausnahmeflag und startet keinen Gleitkommaausnahmehandler).
  • Rundungsoperationssteuerungsfeld 1859A - Genau wie beim Rundungsoperationssteuerungsfeld 1858 unterscheidet dessen Inhalt, welche einer Gruppe von Rundungsoperationen durchgeführt werden soll (z. B. Aufrunden, Abrunden, Runden Richtung null und Runden zur nächstgelegenen Rundungszahl). Deshalb ermöglicht das Rundungsoperationssteuerungsfeld 1859A das Ändern des Rundungsmodus pro Befehl. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Angeben von Rundungsmodi enthält, ist der Inhalt des Rundungsoperationssteuerungsfelds 1850 diesem Registerwert übergeordnet.
  • In der Operationsbefehlsvorlage 1817 ohne Arbeitsspeicherzugriff vom Schreibmaskensteuerungs-VSIZE-Typ wird der Rest des Beta-Felds 1854 als ein Vektorlängenfeld 1859B interpretiert, dessen Inhalt unterscheidet, an welcher einer Anzahl von Datenvektorlängen die Operation durchzuführen ist (z. B. 128, 256 oder 512 Bytes).
  • Im Fall einer Befehlsvorlage 1820 mit Arbeitsspeicherzugriff der Klasse B wird ein Teil des Beta-Felds 1854 als ein Broadcastfeld 1857B interpretiert, dessen Inhalt unterscheidet, ob die Datenmanipulation vom Broadcasttyp durchzuführen ist oder nicht, während der Rest des Beta-Felds 1854 als das Vektorlängenfeld 1859B interpretiert wird. Die Befehlsvorlagen mit Arbeitsspeicherzugriff 1820 enthalten das Skalierungsfeld 1860 und optional das Offsetfeld 1862A oder das Offsetskalierungsfeld 1862B.
  • In Bezug auf das generische vektorfreundliche Befehlsformat 1800 ist ein Feld des vollständigen Opcodes 1874 einschließlich des Formatfeldes 1840, des Basisoperationsfeldes 1842 und des Datenelementbreitenfeldes 1864 gezeigt. Während eine Ausführungsform gezeigt ist, in der das vollständige Opcode-Feld 1874 alle dieser Felder enthält, enthält das vollständige Opcode-Feld 1874 weniger als alle dieser Felder in Ausführungsformen, die nicht alle davon unterstützen. Das Feld des vollständigen Opcodes 1874 stellt den Operationscode (Opcode) bereit.
  • Das Ergänzungsoperationsfeld 1850, das Datenelementbreitenfeld 1864 und das Schreibmaskenfeld 1870 ermöglichen, dass diese Merkmale für jeden Befehl einzeln in dem generischen vektorfreundlichen Befehlsformat spezifiziert werden.
  • Die Kombination aus Schreibmaskenfeld und Datenelementbreitenfeld erzeugt dahingehend typenbehaftete Befehle, dass sie ermöglichen, die Maske auf Grundlage unterschiedlicher Datenelementbreiten anzuwenden.
  • Die diversen Befehlsvorlagen, die in Klasse A und Klasse B zu finden sind, sind in unterschiedlichen Situationen vorteilhaft. In einigen Ausführungsformen der Erfindung können unterschiedliche Prozessoren oder unterschiedliche Kerne in einem Prozessor nur die Klasse A, nur die Klasse B oder beide Klassen unterstützen. Ein Hochleistungs-Out-of-Order-Universalkern für Universalrechenzwecke kann zum Beispiel nur Klasse B unterstützen, ein Kern, der hauptsächlich für Grafik und/oder wissenschaftliches (Durchsatz-)Rechnen gedacht ist, kann nur Klasse A unterstützen und ein Kern, der für beides gedacht ist, kann beides unterstützen (natürlich liegt ein Kern, der eine Mischung von Vorlagen und Befehlen von beiden Klassen, aber nicht alle Vorlagen und Befehlen von beiden Klassen aufweist, innerhalb des Geltungsbereichs der Erfindung). Außerdem kann ein Einzelprozessor mehrere Kerne enthalten, die alle die gleiche Klasse enthalten oder in denen unterschiedliche Kerne unterschiedliche Klassen unterstützen. Zum Beispiel kann in einem Prozessor mit separaten Grafik- und Universalkernen einer der Grafikkerne, die primär für Grafik und/oder wissenschaftliches Rechnen gedacht sind, nur Klasse A unterstützen, während einer oder mehrere der Universalkerne Universalhochleistungskerne mit Out-Of-Order-Ausführung und Registerumbenennung sein können, die für Universalrechenvorgänge gedacht sind, die nur Klasse B unterstützen. Ein anderer Prozessor, der keinen separaten Grafikkern aufweist, kann einen oder mehrere In-Order- oder Out-Of-Order-Kerne enthalten, die sowohl Klasse A als auch Klasse B unterstützen. Natürlich können in anderen Ausführungsformen der Erfindung Merkmale von einer Klasse auch in der anderen Klasse implementiert sein. In einer Hochsprache geschriebene Programme werden in eine Vielzahl unterschiedlicher ausführbarer Formen gebracht (z. B. Just-in-Time-kompiliert oder statisch kompiliert), einschließlich: 1) einer Form, die nur Befehle der Klasse(n) aufweisen, die vom Zielprozessor zur Ausführung unterstützt werden; oder 2) einer Form mit alternativen Routinen, die unter Verwendung verschiedener Kombinationen der Befehle aller Klassen geschrieben sind und Ablaufsteuerungscode aufweisen, der die auszuführenden Routinen auf Grundlage der vom Prozessor unterstützten Befehle auswählt, der den Code aktuell ausführt.
  • BEISPIELHAFTES SPEZIFISCHES VEKTORFREUNDLICHES BEFEHLSFORMAT
  • 19A ist ein Blockdiagramm, das ein beispielhaftes spezifisches vektorfreundliches Befehlsformat nach Ausführungsformen der Erfindung illustriert. 19A zeigt ein spezifisches vektorfreundliches Befehlsformat 1900, das in dem Sinn spezifisch ist, dass es die Position, Größe, Interpretation und Reihenfolge der Felder sowie Werte für einige dieser Felder angibt. Das spezifische vektorfreundliche Befehlsformat 1900 kann verwendet werden, um den x86-Befehlssatz zu erweitern und deshalb sind einige der Felder denen ähnlich oder die gleichen, wie sie im bestehenden x86-Befehlssatz und Erweiterungen (z. B. AVX) davon verwendet werden. Dieses Format bleibt mit dem Präfixcodierfeld, realen Opcodebytefeld, MOD-R/M-Feld, SIB-Feld, Offsetfeld und unmittelbaren Feldern des bestehenden x86-Befehlssatzes mit Erweiterungen vereinbar. Die Felder der 18A-B, in die die Felder von 19A abgebildet sind, sind veranschaulicht.
  • Es sollte klar sein, dass, obwohl Ausführungsformen der Erfindung unter Bezugnahme auf das spezifische vektorfreundliche Befehlsformat 1900 im Kontext des generischen vektorfreundlichen Befehlsformats 1800 für veranschaulichende Zwecke beschrieben sind, die Erfindung nicht auf das spezifische vektorfreundliche Befehlsformat 1900 eingeschränkt ist, ausgenommen dort, wo dies beansprucht wird. Das generische vektorfreundliche Befehlsformat 1800 erwägt zum Beispiel eine Vielfalt von möglichen Größen für die verschiedenen Felder, während das spezifische vektorfreundliche Befehlsformat 1900 als Felder mit spezifischen Größen aufweisend gezeigt wird. Als spezifisches Beispiel, während das Datenelement mit Feld 1864 als ein Ein-Bit-Feld im spezifischen vektorfreundlichen Befehlsformat 1900 veranschaulicht ist, ist die Erfindung nicht derart eingeschränkt (das heißt, das generische vektorfreundliche Befehlsformat 1800 erwägt andere Größen des Datenelementbreitenfelds 1864).
  • Das generische vektorfreundliche Befehlsformat 1800 enthält die unten aufgeführten folgenden Felder in der in der 19A veranschaulichten Reihenfolge.
  • EVEX-Präfix (Bytes 0-3) 1902 - ist in einer Vier-Byte-Form codiert.
  • Formatfeld 1840 (EVEX-Byte 0, Bits [7:0]) - Das erste Byte (EVEX Byte 0) ist das Formatfeld 1840 und es beinhaltet 0x62 (den eindeutigen Wert, der zum Unterscheiden des vektorfreundlichen Befehlsformats in einer Ausführungsform der Erfindung verwendet wird).
  • Die Bytes vom zweiten bis zum vierten (EVEX-Bytes 1-3) enthalten eine Anzahl von Bitfeldern, die eine spezifische Fähigkeit bereitstellen.
  • REX-Feld 1905 (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 1857BEX-Byte 1, Bit[5] - B). Die Bitfelder EVEX.R, EVEX.X und EVEX.B bieten die gleiche Funktionalität wie die entsprechenden VEX-Bitfelder und sind unter Verwendung einer 1er-Komplementform codiert, d. h. ZMM0 ist als 1111B codiert, ZMM15 ist als 0000B codiert. Andere Felder der Befehle codieren die unteren drei Bits der Registerindizes, wie auf dem Fachgebiet bekannt ist (rrr, xxx und bbb), sodass Rrrr, Xxxx und Bbbb durch Addieren von EVEX.R, EVEX.X und EVEX.B gebildet werden kann.
  • REX'-Feld 1810 - Dies ist der erste Teil des REX'-Felds 1810 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4] - R'), das verwendet wird, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Registersatzes zu codieren. In einer Ausführungsform der Erfindung wird dieses Bit zusammen mit anderen wie unten angezeigt in bitinvertiertem Format gespeichert, um es (im gut bekannten x86-32-Bitmodus) vom BOUND-Befehl zu unterscheiden, dessen reales Opcodebyte 62 ist, aber im MOD-R/M-Feld (unten beschrieben) den Wert von 11 im MOD-Feld nicht akzeptiert; alternative Ausführungsformen der Erfindung speichern dieses und die anderen angezeigten Bits unten nicht im invertierten Format. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Anders ausgedrückt wird R'Rrrr durch Kombinieren von EVEX.R', EVEX.R und den anderen RRR von anderen Feldern gebildet.
  • Das Opcode-Abbildungsfeld 1915 (EVEX-Byte 1, Bits [3:0] - mmmm) - Sein Inhalt codiert ein impliziertes führendes Opcode-Byte (0F, 0F 38 oder 0F 3).
  • Datenelementbreitenfeld 1864 (EVEX-Byte 2, Bit [7] - W) - wird durch die Notation EVEX.W repräsentiert. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente) zu definieren.
  • EVEX.vvvv 1920 (EVEX-Byte 2, Bits [6:3]-vvvv)- Die Rolle von EVEX.vvvv kann Folgendes enthalten: 1) EVEX.vvvv codiert den ersten Quellenregisteroperanden, der in invertierter (1er-Komplement-)Form angegeben ist und für Befehle mit 2 oder mehr Quellenoperationen gültig ist; 2) EVEX.vvvv codiert den Zielregisteroperanden, der in Form eines 1er-Komplements für bestimmte Vektorverschiebungen angegeben ist; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b beinhalten. Deshalb codiert das EVEX.vvvv-Feld 1920 die 4 Bits des ersten Quellenregisterspezifizierers niedriger Ordnung, die in invertierter (1er-Komplement-)Form gespeichert sind. Abhängig vom Befehl wird ein zusätzliches anderes EVEX-Bit-Feld verwendet, um die Spezifizierergröße auf 32 Register zu erweitern.
  • Klassenfeld EVEX.U 1868 (EVEX-Byte 2, Bit [2]-U) - Falls EVEX.U = 0, zeigt es Klasse A oder EVEX.U0 an; falls EVEX.U = 1, zeigt es Klasse B oder EVEX.U1 an.
  • Präfixcodierfeld 1925 (EVEX-Byte 2, Bits [1:0]-pp) - stellt zusätzliche Bits für das Basisoperationsfeld bereit. Zusätzlich zum Bereitstellen von Unterstützung für die Alt-SSE-Befehle im EVEX-Präfixformat weist dies auch den Vorteil des Verdichtens des SIMD-Präfix auf (anstatt ein Byte zu benötigen, um das SIMD-Präfix auszudrücken, benötigt das EVEX-Präfix nur 2 Bits). In einer Ausführungsform, um Alt-SSE-Befehle zu unterstützen, die ein SIMD-Präfix (66H, F2H, F3H) in sowohl dem Alt-Format als auch im EVEX-Präfix-Format verwenden, sind diese Alt-SIMD-Präfixe im SIMD-Präfix-Codierfeld codiert; und werden zur Laufzeit in das Alt-SIMD-Präfix vor Bereitstellung an das PLA des Decodierers erweitert (sodass das PLA sowohl das Alt- als auch das EVEX-Format dieser Alt-Befehle ohne Modifikation ausführen kann). Obwohl neuere Befehle den Inhalt des EVEX-Präfix-Codierfelds direkt als eine Opcode-Erweiterung verwenden könnten, erweitern bestimmte Ausführungsformen zur Kontinuität auf eine ähnliche Weise, ermöglichen jedoch, dass unterschiedliche Bedeutungen von diesen Alt-SIMD-Präfixen angegeben werden. Eine alternative Ausführungsform kann das PLA umkonstruieren, sodass es die 2-Bit-SIMD-Präfixcodierungen unterstützt und deshalb die Erweiterung nicht benötigt.
  • Alpha-Feld 1852 (EVEX-Byte 3, Bit [7] -EH; auch als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.-Schreibmaskensteuerung und EVEX.N bekannt; auch mit α veranschaulicht) - wie vorher beschrieben, ist dieses Feld kontextspezifisch.
  • Beta-Feld 1854 (EVEX-Byte 3, Bits [6:4]-SSS, auch als EVEX.S2-0, EVEX.r2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB bekannt; auch mit βββ veranschaulicht) - wie vorher beschrieben, ist dieses Feld kontextspezifisch.
  • REX'-Feld 1810 - Dies ist der Rest des REX'-Felds und ist das EVEX.V'-Bitfeld (EVEX-Byte 3, Bit [3] - V'), das verwendet werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Registersatzes zu codieren. Dieses Bit ist in bitinvertiertem Format gespeichert. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Anders ausgedrückt wird V'VVVV durch Kombinieren von EVEX.V', EVEX.vvvv gebildet.
  • Schreibmaskenfeld 1870 (EVEX-Byte 3, Bits [2:0]-kkk) - Sein Inhalt gibt den Index eines Registers im Schreibmaskenregister wie vorher beschrieben an. In einer Ausführungsform der Erfindung weist der spezifische Wert EVEX.kkk=000 ein besonderes Verhalten auf, der impliziert, dass keine Schreibmaske für den bestimmten Befehl verwendet wird; (Dies kann auf eine Vielfalt von Arten und Weisen einschließlich der Verwendung einer auf alles eins festverdrahteten Schreibmaske oder Hardware, die die Maskierungshardware umgeht, implementiert werden).
  • Das Real-Opcode-Feld 1930 (Byte 4) ist auch als das Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld angegeben.
  • MOD-R/M-Feld 1940 (Byte 5) enthält MOD-Feld 1942, Reg-Feld 1944 und R/M-Feld 1946. Wie bereits beschrieben, unterscheidet der Inhalt des MOD-Felds 1942 zwischen Operationen mit Arbeitsspeicherzugriff und solchen ohne Arbeitsspeicherzugriff. Die Rolle des Reg-Felds 1944 kann in zwei Situationen zusammengefasst werden: Codieren entweder des Zielregisteroperanden oder eines Quellenregisteroperanden oder Behandlung als eine Opcode-Erweiterung und keine Verwendung zum Codieren irgendeines Befehlsoperanden. Die Rolle des R/M-Felds 1946 kann Folgendes enthalten: Codieren des Befehlsoperanden, der eine Arbeitsspeicheradresse referenziert, oder Codieren von entweder dem Zielregisteroperanden oder einem Quellenregisteroperanden.
  • Skalierung-Index-Basis(SIB)-Byte (Byte 6) - Wie bereits beschrieben wird der Inhalt des Skalierungsfelds 1850 zur Arbeitsspeicheradressengenerierung verwendet. SIB.xxx 1954 und SIB.bbb 1956 - Auf den Inhalt dieser Felder wurde bereits in Bezug auf die Registerindizes Xxxx und Bbbb Bezug genommen.
  • Offsetfeld 1862A (Bytes 7-10) - Wenn das MOD-Feld 1942 10 beinhaltet, sind die Bytes 7-10 das Offsetfeld 1862A und es funktioniert auf die gleiche Weise wie der Alt-32-Bit-Offset (disp32) und arbeitet auf Byte-Granularitätsebene.
  • Offsetfaktorfeld 1862B (Byte 7) - Wenn das MOD-Feld 194201 beinhaltet, ist Byte 7 das Offsetfaktorfeld 1862B. Die Position dieses Felds ist die gleiche wie die des 8-Bit-Offsets (disp8) des Alt-x86-Befehlssatzes, der auf Byte-Granularitätsebene arbeitet. Da disp8 mit Vorzeichen erweitert ist, kann es nur Offsets zwischen -128 und 127 Bytes adressieren; in Form von 64-Byte-Zwischenspeicherzeilen verwendet disp8 8 Bits, die auf nur vier tatsächlich nützliche Werte -128, -64, 0 und 64 gesetzt werden können; da ein größerer Bereich oft benötigt wird, wird disp32 verwendet; disp32 benötigt jedoch 4 Bytes. Im Gegensatz zu disp8 und disp32 ist das Offsetfaktorfeld 1862B eine Neuinterpretation von disp8; wenn das Offsetfaktorfeld 1862B verwendet wird, wird der tatsächliche Offset durch den Inhalt des Offsetfaktorfelds multipliziert mit der Größe des Arbeitsspeicheroperandenzugriffs (N) ermittelt. Diese Art von Offset wird als disp8*N bezeichnet. Dies reduziert die mittlere Befehlslänge (ein einziges Byte wird für den Offset verwendet, aber mit einem viel größeren Bereich). Ein derartiger komprimierter Offset basiert auf der Annahme, dass der effektive Offset ein Mehrfaches der Granularität des Arbeitsspeicherzugriffs ist und daher müssen die redundanten, niederwertigen Bits des Adressenoffsets nicht codiert werden. Anders ausgedrückt substituiert das Offsetfaktorfeld 1862B den 8-Bit-Offset des Alt-x86-Befehlssatzes. Deshalb ist das Offsetfaktorfeld 1862B auf die gleiche Weise wie ein 8-Bit-Offset eines x86-Befehlssatzes codiert (deshalb gibt es keine Änderungen in den ModRM/SIB-Codierregeln), mit der einzigen Ausnahme, dass disp8 auf disp8*N überladen ist. Anders ausgedrückt gibt es keine Änderungen bei den Codierregeln oder Codierlängen, sondern nur bei der Interpretation des Offsetwerts durch die Hardware (die den Offset mit der Größe des Arbeitsspeicheroperanden skalieren muss, um einen byteweisen Adressenoffset zu erhalten). Das Direktfeld 1872 arbeitet wie vorher beschrieben.
  • Vollständiges Opcode-Feld
  • 19B ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats 1900 illustriert, die das vollständige Opcode-Feld 1874 nach einer Ausführungsform der Erfindung bilden. Genauer enthält das vollständige Opcode-Feld 1874 das Formatfeld 1840, das Basisoperationsfeld 1842 und das Datenelementbreiten(W)-Feld 1864. Das Basisoperationsfeld 1842 enthält das Präfixcodierfeld 1925, das Opcodeabbildungsfeld 1915 und das reale Opcodefeld 1930.
  • Registerindexfeld
  • 19C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats 1900 illustriert, die das Registerindexfeld 1844 nach einer Ausführungsform der Erfindung bilden. Genauer enthält das Registerindexfeld 1844 das REX-Feld 1905, das REX'-Feld 1910, das MODR/M.reg-Feld 1944, das MODR/M.r/m-Feld 1946, das VVVV-Feld 1920, xxx-Feld 1954 und das bbb-Feld 1956.
  • Operationszusatzfeld
  • 19D ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats illustriert, das das Operationszusatzfeld 1850 nach einer Ausführungsform der Erfindung bildet. Wenn das Klassenfeld (U) 1868 0 beinhaltet, bedeutet es EVEX.U0 (Klasse A 1868A); wenn es 1 beinhaltet, bedeutet es EVEX.U1 (Klasse B 1868B). Wenn U = 0 und das MOD-Feld 1942 beinhaltet 11 (was eine Operation ohne Arbeitsspeicherzugriff bedeutet), wird das Alpha-Feld 1852 (EVEX-Byte 3, Bit [7] - EH) als das rs-Feld 1852A interpretiert. Wenn das rs-Feld 1852A eine 1 beinhaltet (Rundung 1852A.1), wird das Beta-Feld 1854 (EVEX-Byte 3, Bits [6:4]- SSS) als das Rundungssteuerungsfeld 1854A interpretiert. Das Rundungssteuerungsfeld 1854A enthält ein Ein-Bit-SAE-Feld 1856 und ein Zwei-Bit-Rundungsoperationsfeld 1858. Wenn das rs-Feld 1852A eine 0 beinhaltet (Datentransformation 1852A.2), wird das Beta-Feld 1854 (EVEX-Byte 3, Bits [6:4]- SSS) als das ein Drei-Bit-Datentransformationsfeld 1854B interpretiert. Wenn U = 0 und das MOD-Feld 1942 beinhaltet 00, 01 oder 10 (was eine Arbeitsspeicherzugriffsoperation bedeutet), wird das Alpha-Feld 1852 (EVEX-Byte 3, Bit [7] - EH) als das Entfernungshinweis(EH)-Feld 1852B interpretiert und das Beta-Feld 1854 (EVEX-Byte 3, Bits [6:4]- SSS) wird als ein Drei-Bit-Datenmanipulationsfeld 1854C interpretiert.
  • Wenn U = 1, wird das Alpha-Feld 1852 (EVEX-Byte 3, Bit [7] - EH) als das Schreibmaskensteuerungsfeld (Z) 1852C interpretiert. Wenn U = 1 und das MOD-Feld 1942 beinhaltet 11 (was eine Operation ohne Arbeitsspeicherzugriff bedeutet), wird ein Teil des Beta-Felds 1854 (EVEX-Byte 3, Bit [4] - S0) als das RL-Feld 1857A interpretiert; wenn es eine 1 (Runden 1857A.1) enthält, wird der Rest des Beta-Felds 1854 (EVEX-Byte 3, Bit [6-5]- S2-1) als das Rundungsoperationsfeld 1859A interpretiert, wohingegen, wenn das RL-Feld 1857A eine 0 beinhaltet (VSIZE 1857.A2), wird der Rest des Beta-Felds 1854 (EVEX-Byte 3, Bit [6-5]- S2-1) als das Vektorlängenfeld 1859B interpretiert (EVEX-Byte 3, Bit [6-5]- L1-0). Wenn U = 1 und das MOD-Feld 1942 beinhaltet 00, 01 oder 10 (was eine Arbeitsspeicherzugriffsoperation bedeutet), wird das Beta-Feld 1854 (EVEX-Byte 3, Bits [6:4]- SSS) als das Vektorlängenfeld 1859B (EVEX-Byte 3, Bit [6-5]- L1-0) und das Broadcastfeld 1857B (EVEX-Byte 3, Bit [4]- B) interpretiert.
  • Beispielhafte Registerarchitektur
  • 20 ist ein Blockdiagramm einer Registerarchitektur 2000 nach einer Ausführungsform der Erfindung. In der illustrierten Ausführungsform gibt es 32 Vektorregister 2010, die 512 Bits breit sind; auf diese Register wird mit zmm0 bis zmmm31 verwiesen. Die 256 niederwertigen Bits der unteren 16 zmm-Register sind den Registern ymm0-16 überlagert. Die 128 niederwertigen Bits der unteren 16 zmm-Register (die 128 niederwertigen Bits der ymm Register) sind den Registern xmm0-15 überlagert. Das spezifische vektorfreundliche Befehlsformat 1900 operiert an dieser überlagerten Registerdatei, wie in den Tabellen unten veranschaulicht.
    Anpassbare Vektorlänge Klasse Operationen Register
    Befehlsvorlagen, die das Vektorlängenfeld 1859B nicht enthalten A ( 18A; U=0) 1810, 1815, 1825, 1830 zmm-Register (Die Vektorlänge beträgt 64 Bytes.)
    B ( 18B; U=1) 1812 zmm-Register (Die Vektorlänge beträgt 64 Bytes.)
    Befehlsvorlagen, die das Vektorlängenfeld 1859B enthalten B ( 18B; U=1) 1817, 1827 zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Bytes, 32 Bytes oder 16 Bytes), abhängig vom Vektorlängenfeld 1859B.
  • Anders ausgedrückt wählt das Vektorlängenfeld 1859B zwischen einer Maximallänge und einer oder mehreren anderen kürzeren Längen aus, wobei jede solche kürzere Länge die halbe Länge der vorangehenden Länge ist; und Befehlsvorlagen ohne das Vektorlängenfeld 1859B wirken auf die maximale Vektorlänge. Ferner wirken die Befehlsvorlagen der Klasse B des spezifischen vektorfreundlichen Befehlsformats 1900 in einer Ausführungsform auf gepackte oder skalare Gleitkommadaten mit einfacher/doppelter Genauigkeit und auf gepackte oder skalare ganzzahlige Daten. Skalare Operationen sind Operationen, die an der niederwertigsten Datenelementposition in einem zmm/ymm/xmm-Register durchgeführt werden; wobei die höherwertigen Datenelementpositionen abhängig von der Ausführungsform entweder gleich gelassen werden, wie sie vor dem Befehl waren, oder auf null gesetzt werden.
  • Schreibmaskenregister 2015 - In der veranschaulichten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), die jeweils eine Größe von 64 Bit aufweisen. In einer alternativen Ausführungsform weisen die Schreibmaskenregister 2015 eine Größe von 16 Bit auf. Wie vorher beschrieben, kann das Vektormaskenregister k0 in einer Ausführungsform der Erfindung nicht als eine Schreibmaske verwendet werden; wenn die Codierung, die normalerweise k0 anzeigen würde, für eine Schreibmaske verwendet wird, wählt sie eine festprogrammierte Schreibmaske von 0xFFFF aus, was effektiv eine Schreibmaskierung für diesen Befehl deaktiviert.
  • Register 2025 für Universalzwecke - In der veranschaulichten Ausführungsform gibt es sechzehn 64-Bit-Register für Universalzwecke, die zusammen mit den bestehenden x86-Adressiermodi verwendet werden, um Arbeitsspeicheroperanden zu adressieren. Auf diese Register wird mit den Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 Bezug genommen.
  • Skalare Gleitkomma-Stapelregisterdatei (x87-Stapel) 2045, auf der der MMX-gepackten ganzzahligen flachen Registerdatei 2050 ein Alias zugewiesen ist - In der veranschaulichten Ausführungsform ist der x87-Stapel ein Stapel mit acht Elementen, der verwendet wird, um unter Verwendung der x87-Befehlssatzerweiterung skalare Gleitkommaoperationen an 32/64/80-Bit-Gleitkommadaten durchzuführen; während die MMX-Register verwendet werden, um Operationen an 64-Bit-gepackten ganzzahligen Daten durchzuführen, sowie um Operanden für einige Operationen zu halten, die zwischen den MMX- und XMM-Registern durchgeführt werden.
  • Alternative Ausführungsformen der Erfindung können breitere oder schmälere Register verwenden. Zusätzlich können alternative Ausführungsformen der Erfindung mehr, weniger oder unterschiedliche Registerdateien und Register verwenden.
  • Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen
  • Prozessorkerne können auf verschiedene Arten, für verschiedene Zwecke und in verschiedenen Prozessoren implementiert werden. Zum Beispiel können Implementierungen solcher Kerne Folgendes beinhalten: 1) einen Universal-In-Order-Kern, der für allgemeine Rechenzwecke gedacht ist; 2) einen Hochleistungs-Universal-Out-of-Order-Kern, der für allgemeine Rechenzwecke gedacht ist; 3) einen Kern für Sonderzwecke, der primär für Grafik- und/oder wissenschaftliches Rechnen (Durchsatzrechnen) gedacht ist. Implementierungen von verschiedenen Prozessoren können Folgendes enthalten: 1) eine CPU, die einen oder mehrere Universal-In-Order-Kerne, die für allgemeine Rechenzwecke gedacht sind, und/oder einen oder mehrere Universal-Out-of-Order-Kerne enthält, die für allgemeine Rechenzwecke gedacht sind; und 2) einen Coprozessor, der einen oder mehrere Kerne für Sonderzwecke enthält, die primär für Grafik und/oder Wissenschaft (Durchsatz) gedacht sind. Solche verschiedenen Prozessoren führen zu verschiedenen Computersystemarchitekturen, die Folgendes umfassen können: 1) den Coprozessor auf einem separaten Chip von der CPU; 2) den Coprozessor auf einem separaten Chip im gleichen Gehäuse wie eine CPU; 3) den Coprozessor auf dem gleichen Chip wie eine CPU (in diesem Fall wird ein solcher Coprozessor manchmal als Logik für Sonderzwecke bezeichnet, wie integrierte Grafik- und/oder wissenschaftliche Logik (Durchsatzlogik, oder als Kerne für Sonderzwecke); und 4) ein Ein-Chip-System, das die beschriebene CPU (manchmal als der Anwendungskern bzw. die Anwendungskerne oder der Anwendungsprozessor bzw. die Anwendungsprozessoren bezeichnet), den oben beschriebenen Coprozessor und zusätzliche Funktionalität auf dem gleichen Chip enthalten kann. Als Nächstes werden beispielhafte Kernarchitekturen beschrieben, gefolgt von Beschreibungen von beispielhaften Prozessoren und Computerarchitekturen.
  • Beispielhafte Kernarchitekturen
  • Blockdiagramm für In-Order- und Out-of-Order-Kerne
  • 21A ist ein Blockdiagramm, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline nach Ausführungsformen der Erfindung illustriert. 21B ist ein Blockdiagramm, das sowohl ein Ausführungsbeispiel eines Kerns mit In-Order-Architektur als auch eines Kerns mit Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungsarchitektur illustriert, die in einem Prozessor nach Ausführungsformen der Erfindung enthalten sein sollen. Die durchgezogen umrandeten Kästchen in den 21A-B illustrieren die In-Order-Pipeline und den In-Order-Kern, während der optionale Zusatz der gestrichelt umrandeten Kästchen die Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Pipeline und den Registerumbenennungs-, Out-of-Order-Ausgabe-/Ausführungs-Kern illustrieren. Da der In-Order-Aspekt eine Teilmenge des Out-of-Order-Aspekts ist, wird der Out-of-Order-Aspekt beschrieben.
  • In 21A enthält eine Prozessor-Pipeline 2100 eine Abrufphase 2102, eine Längendecodierphase 2104, eine Decodierphase 2106, eine Zuordnungsphase 2108, eine Umbenennungsphase 2110, eine Zeitplanungsphase (auch als Versand- oder Ausgabephase bekannt) 2112, eine Registerlese-/Speicherlesephase 2114, eine Ausführungsphase 2116, eine Zurückschreib-/Speicherschreibphase 2118, eine Ausnahmebehandlungsphase 2122 und eine Festschreibphase 2124.
  • 21B zeigt einen Prozessorkern 2190, der eine Front-End-Einheit 2130 enthält, die an eine Ausführengineeinheit 2150 gekoppelt ist, und beide sind an eine Arbeitsspeichereinheit 2170 gekoppelt. Der Kern 2190 kann ein Reduced-Instruction-Set-Computing(RISC)-Kern, ein Complex-Instruction-Set-Computing(CISC)-Kern, ein Very-Long-Instruction-Word(VLIW)-Kern oder ein Hybrid- oder alternativer Kerntyp sein. Als noch eine weitere Option kann der Kern 2190 ein Kern für Sonderzwecke sein, wie zum Beispiel ein Netzwerk- oder Kommunikationskern, eine Komprimierungsengine, ein Coprozessorkern, einen Kern einer Grafikverarbeitungseinheit für allgemeine Rechenzwecke (GPGPU), ein Grafikkern oder Ähnliches.
  • Die Front-End-Einheit 2130 enthält eine Verzweigungsvorhersageeinheit 2132, die an eine Befehls-Zwischenspeicher-Einheit 2134 gekoppelt ist, die an einen Befehlsübersetzungspuffer (TLB) 2136 gekoppelt ist, der an eine Befehlsabrufeinheit 2138 gekoppelt ist, der an eine Decodiereinheit 2140 gekoppelt ist. Die Decodiereinheit 2140 (oder der Decoder) kann Befehle decodieren und als eine Ausgabe eine oder mehrere Mikro-Operationen, Mikrocode-Eintrittspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale generieren, die von den ursprünglichen Befehlen decodiert oder abgeleitet werden oder die diese auf andere Weise widerspiegeln. Die Decodiereinheit 2140 kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Zu Beispielen für geeignete Mechanismen zählen unter anderem Umsetzungstabellen, Hardware-Implementierungen, programmierbare logische Anordnungen (PLAs), Mikrocode-Festwertspeicher (ROMs) usw. ein. In einer Ausführungsform enthält der Kern 2190 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für bestimmte Makrobefehlen speichert (z. B. in der Decodiereinheit 2140 oder auf andere Weise in der Front-End-Einheit 2130). Die Decodiereinheit 2140 ist in der Ausführungsengineeinheit 2150 an eine Umbenennungs-/Zuordnungseinheit 2152 gekoppelt.
  • Die Ausführungsengineeinheit 2150 enthält die an eine Stilllegungseinheit 2154 gekoppelte Umbenennungs-/Zuordnungseinheit 2152 und einen Satz von einer oder mehreren Planungseinheiten 2156. Die Planungseinheit(en) 2156 stellt bzw. stellen irgendeine Anzahl von unterschiedlichen Planern dar, einschließlich Reservierungsstationen, zentrales Befehlsfenster usw. Die Planungseinheit(en) 2156 ist bzw. sind an die Einheit(en) der physischen Registerdatei(en) 2158 gekoppelt. Jede der physischen Registerdateieinheit(en) 2158 repräsentiert eine oder mehrere physische Registerdateien, von denen verschiedene einen oder mehrere verschiedene Datentypen speichern, wie skalare ganze Zahl, skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma, Status (z. B. einen Befehlszeiger, der die Adresse des nächsten auszuführenden Befehls ist) usw. In einer Ausführungsform umfasst die Einheit der physischen Registerdatei(en) 2158 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine skalare Registereinheit. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Universalregister bereitstellen. Die physische(n) Registerdateieinheit(en) 2158 wird bzw. werden von der Stilllegungseinheit 2154 überlappt, um verschiedene Arten zu veranschaulichen, auf die eine Registerumbenennung und Out-of-Order-Ausführung implementiert werden können (z. B. unter Verwendung eines Umordnungspuffers bzw. von Umordnungspuffern und (einer) Stilllegungsregisterdatei(en); unter Verwendung einer bzw. von zukünftigen Datei(en), eines Verlaufspuffers bzw. von Verlaufspuffern und einer Stilllegungsregisterdatei bzw. von Stilllegungsregisterdateien; unter Verwendung einer Registerabbildung und eines Pools von Registern; usw.). Die Stilllegungseinheit 2154 und die physische(n) Registerdateieinheit(en) 2158 sind an das bzw. die Ausführungscluster 2160 gekoppelt. Das/die Ausführungs-Cluster 2160 enthalten einen Satz von einer oder mehreren Ausführungseinheiten 2162 und einen Satz von einer oder mehreren Arbeitsspeicherzugriffseinheiten 2164. Die Ausführungseinheiten 2162 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und an verschiedenen Datentypen (z. B. skalares Gleitkomma, gepackte ganze Zahl, gepacktes Gleitkomma, vektorielle ganze Zahl, vektorielles Gleitkomma) durchführen. Während einige Ausführungsformen eine Reihe von Ausführungseinheiten enthalten können, die für spezifische Funktionen oder Funktionssätze vorgesehen sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten enthalten, die alle Funktionen durchführen. Die Planungseinheit(en) 2156, physische(n) Registerdateieinheit(en) 2158 und Ausführungscluster 2160 sind als möglicherweise mehrzahlig gezeigt, da bestimmte Ausführungsformen separate Pipelines für bestimmte Arten von Daten/Operationen erstellen (z. B. eine Pipeline für skalare ganze Zahlen, eine Pipeline für skalares Gleitkomma/gepackte ganze Zahlen/gepacktes Gleitkomma/vektorielle ganze Zahlen/vektorielles Gleitkomma und/oder eine Arbeitsspeicherzugriffs-Pipeline, die jeweils ihre eigene Planungseinheit, physische Registerdateieinheit und/oder ihr eigenes Ausführungscluster aufweisen - und im Fall einer separaten Arbeitsspeicherzugriffs-Pipeline sind bestimmte Ausführungsformen implementiert, in denen nur das Ausführungscluster dieser Pipeline die Arbeitsspeicherzugriffseinheit(en) 2164 aufweist). Es sollte auch klar sein, dass, wo separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines Out-of-Order-Ausgabe-/Ausführungs- und der Rest In-Order-Pipelines sein können.
  • Der Satz von Arbeitsspeicherzugriffseinheiten 2164 ist an die Arbeitsspeichereinheit 2170 gekoppelt, die eine Daten-TLB-Einheit 2172 enthält, die an eine Daten-Zwischenspeichereinheit 2174 gekoppelt ist, die an eine Level 2 (L2)-Zwischenspeichereinheit 2176 gekoppelt ist. In einer beispielhaften Ausführungsform können die Arbeitsspeicherzugriffseinheiten 2164 eine Ladeeinheit, eine Adressspeichereinheit und eine Datenspeichereinheit enthalten, die alle an die Daten-TLB-Einheit 2172 in der Arbeitsspeichereinheit 2170 gekoppelt sind. Die Befehlszwischenspeichereinheit 2134 ist ferner an eine Level-2(L2)-Zwischenspeichereinheit 2176 in der Arbeitsspeichereinheit 2170 gekoppelt. Die L2-Zwischenspeichereinheit 2176 ist an eine oder mehrere andere Zwischenspeicher-Levels und letztendlich an einen Hauptspeicher gekoppelt.
  • Beispielsweise kann die beispielhafte Kernarchitektur für Registerumbenennung, Out-Of-Order-Ausgabe/-Ausführung die Pipeline 2100 wie folgt implementieren: 1) Der Befehlsabruf 2138 führt den Abruf und die Längendecodierphasen 2102 und 2104 durch; 2) die Decodiereinheit 2140 führt die Decodierphase 2106 durch; 3) die Umbenennungs-/Zuordnungseinheit 2152 führt die Zuordnungsphase 2108 und die Umbenennungsphase 2110 durch; 4) die Zeitplangebereinheit(en) 2156 führt bzw. führen die Zeitplanungsphase 2112 durch; 5) die physische(n) Registerdateieinheit(en) 2158 und die Arbeitsspeichereinheit 2170 führen die Registerlese-/Speicherlesephase 2114 durch; das Ausführungscluster 2160 führt die Ausführungsphase 2116 durch; 6) die Arbeitsspeichereinheit 2170 und die physische(n) Registerdateieinheit(en) 2158 führen die Zurückschreib-/Speicherschreibphase 2118 durch; 7) verschiedene Einheiten können an der Ausnahmebehandlungsphase 2122 beteiligt sein; und 8) die Stilllegungseinheit 2154 und die physische(n) Registerdateieinheit(en) 2158 führen die Festschreibphase 2124 durch.
  • Der Kern 2190 kann eine oder mehrere Befehlssätze unterstützen (z. B. den x86-Befehlssatz (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden); den MIPS-Befehlssatz von MIPS Technologies in Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings in Sunnyvale, CA), die die hierin beschriebene(n) Befehl(en) enthalten. In einer Ausführungsform enthält der Kern 2190 Logik, um eine gepackte Datenbefehlssatzerweiterung (z. B. AVX1, AVX2) zu unterstützen, wodurch erlaubt wird, dass die von vielen Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten durchgeführt werden.
  • Es versteht sich, dass der Kern Multithreading (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützen kann und dies auf vielfältige Weisen vornehmen kann, was Zeitscheiben-Multithreading, simultanes Multithreading (wobei ein einzelner physischer Kern einen logischen Kern für jeden der Threads bereitstellt, welche der physische Kern simultan im Multithreading behandelt) oder eine Kombination davon (z. B. Zeitscheibenabruf und -Decodierung und simultanes Multithreading danach, wie etwa bei der Hyperthreading-Technologie von Intel®) umfasst.
  • Während Registerumbenennen im Kontext einer Out-of-Order-Ausführung beschrieben wird, sollte klar sein, dass das Registerumbenennen in einer In-Order-Architektur verwendet werden kann. Während die illustrierte Ausführungsform des Prozessors auch separate Befehls- und Datenzwischenspeichereinheiten 2134/2174 und eine gemeinsam genutzte L2-Zwischenspeichereinheit 2176 enthält, können alternative Ausführungsformen einen einzigen internen Zwischenspeicher für sowohl Befehle als auch Daten aufweisen, wie zum Beispiel einen internen Level-1(L1)-Zwischenspeicher oder mehrere Levels von internem Zwischenspeicher. In einigen Ausführungsformen kann das System eine Kombination von einem internen Zwischenspeicher und einem externen Zwischenspeicher, der sich außerhalb des Kerns und/oder des Prozessors befindet, enthalten. Alternativ kann der gesamte Zwischenspeicher extern zum Kern und/oder zum Prozessor sein.
  • Spezifische beispielhafte In-Order-Kernarchitektur
  • 22A-B illustrieren ein Blockdiagramm einer spezifischeren beispielhaften In-Order-Kernarchitektur, wobei der Kern einer von mehreren logischen Blöcken (die andere Kerne des gleichen Typs und/oder anderer Typen enthalten) in einem Chip wäre. Die logischen Blöcke kommunizieren über ein Verbindungsnetzwerk hoher Bandbreite (z. B. ein Ringnetzwerk) mit einiger Logik mit festen Funktionen, Arbeitsspeicher-E/A-Schnittstellen und anderer notwendiger E/A-Logik, abhängig von der Anwendung.
  • 22A ist ein Blockschaltbild eines Einzelprozessorkerns zusammen mit seiner Verbindung zum rohchipinternen Zwischenverbindungsnetzwerk 2202 und seinem lokalen Teilsatz des Level-2(L2)-Zwischenspeichers 2204, nach Ausführungsformen der Erfindung. In einer Ausführungsform unterstützt ein Befehlsdecoder 2200 den x86-Befehlssatz mit einer Erweiterung für gepackte Datenbefehlssätze. Ein L1-Zwischenspeicher 2206 ermöglicht Zugriffe mit geringer Latenz auf Zwischenspeicher in den Skalar- und Vektoreinheiten. Obwohl in einer Ausführungsform (um den Entwurf zu vereinfachen) eine skalare Einheit 2208 und eine Vektoreinheit 2210 separate Registersätze verwenden (skalares Register 2212 bzw. Vektorregister 2214) und zwischen ihnen übertragene Daten in Arbeitsspeicher geschrieben und dann von einem Level-1(L1)-Zwischenspeicher 2206 wieder eingelesen werden, können alternative Ausführungsformen der Erfindung einen anderen Ansatz verwenden (z. B. einen einzelnen Registersatz verwenden oder einen Kommunikationspfad enthalten, der gestattet, dass Daten zwischen den beiden Registerdateien übertragen werden, ohne dass sie geschrieben und zurückgelesen werden).
  • Der lokale Teilsatz des L2-Zwischenspeichers 2204 ist Teil eines globalen L2-Zwischenspeichers, der in separate lokale Teilsätze, einer je Prozessorkern, geteilt ist. Jeder Prozessorkern weist einen direkten Zugriffspfad zu seinem eigenen lokalen Teilsatz des L2-Zwischenspeichers 2204 auf. Von einem Prozessorkern gelesene Daten werden in seinem L2-Zwischenspeicher-Teilsatz 2204 gespeichert und auf sie kann schnell zugegriffen werden, parallel zu anderen Prozessorkernen, die auf ihre eigenen lokalen L2-Zwischenspeicher-Teilsätze zugreifen. Von einem Prozessorkern geschriebene Daten werden in seinem eigenen L2-Zwischenspeicher-Teilsatz 2204 gespeichert und aus anderen Teilsätzen wenn nötig geleert. Das Ringnetzwerk stellt Kohärenz für gemeinsame Daten sicher. Das Ringnetzwerk ist bidirektional, um Agenten wie Prozessorkernen, L2-Zwischenspeichern und anderen Logikblöcken zu erlauben, miteinander innerhalb des Chips zu kommunizieren. Jeder Ring-Datenpfad ist pro Richtung 1012 Bit breit.
  • 22B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 22A nach Ausführungsformen der Erfindung. 22B enthält einen L1-Datenzwischenspeicher 2206A, einen Teil des L1-Zwischenspeichers 2204 sowie mehr Details in Bezug auf die Vektoreinheit 2210 und die Vektorregister 2214. Insbesondere ist die Vektoreinheit 2210 eine 16-breite Vektorverarbeitungseinheit (VPU) (siehe die 16-breite ALU 2228), die eine oder mehrere von folgenden Befehlen ausführt: ganzzahlige, Gleitkommabefehle mit einfacher Genauigkeit und Gleitkommabefehle mit doppelter Genauigkeit. Die VPU unterstützt ein Swizzeln der Registereingänge mit Swizzleeinheit 2220, numerische Umwandlung mit numerischen Umwandlungseinheiten 2222A-B und Replizierung mit Replizierungseinheit 2224 am Arbeitsspeichereingang. Schreibmaskenregister 2226 erlauben ein Vergleichen von resultierenden Vektorschreibvorgängen.
  • 23 ist ein Blockdiagramm eines Prozessors 2300, der nach Ausführungsformen der Erfindung mehr als einen Kern aufweisen kann, eine integrierte Arbeitsspeichersteuerung aufweisen kann und integrierte Grafik aufweisen kann. Die durchgezogen umrandeten Kästchen in 23 illustrieren einen Prozessor 2300 mit einem einzigen Kern 2302A, einem Systemagenten 2310, einen Satz von einem oder mehreren Bussteuerungseinheiten 2316, während die optionale Hinzufügung der gestrichelt umrandeten Kästchen einen alternativen Prozessor 2300 mit mehreren Kernen 2302A-N, einem Satz von einem oder mehreren integrierten Arbeitsspeichersteuerungseinheiten 2314 in der Systemagenteinheit 2310 und Logik für Sonderzwecke 2308 illustriert.
  • Deshalb können verschiedene Implementierungen des Prozessors 2300 enthalten: 1) eine CPU, wobei die Logik für Sonderzwecke 2308 integrierte Grafik- und/oder wissenschaftliche Logik (Durchsatzlogik) ist (die einen oder mehrere Kerne enthalten kann) und die Kerne 2302A-N ein oder mehrere Universalkerne sind (z. B. Universal-In-Order-Kerne, Universal-Out-of-Order-Kerne, eine Kombination der zwei); 2) einen Coprozessor, wobei die Kerne 2302A-N eine große Anzahl von Kernen für Sonderzwecke sind, die primär für Grafik und/oder Wissenschaft (Durchsatz) gedacht sind; und 3) einen Coprozessor, wobei die Kerne 2302A-N eine große Anzahl von Universal-In-Order-Kernen sind. Deshalb kann der Prozessor 2300 ein Universal-Prozessor, Coprozessor oder Prozessor für Sonderzwecke sein, wie zum Beispiel ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine Grafikverarbeitungseinheit für allgemeine Rechenzwecke (GPGPU), ein Many-Integrated-Core(MIC)-Coprozessor mit hohem Durchsatz (der 30 oder mehr Kerne enthält), ein eingebetteter Prozessor oder Ähnliches. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 2300 kann ein Teil eines oder mehrerer Substrate sein und/oder kann auf einem oder mehreren Substraten unter Verwendung einer beliebigen Anzahl von Prozesstechniken wie zum Beispiel BiCMOS, CMOS oder NMOS implementiert sein.
  • Die Arbeitsspeicherhierarchie enthält einen oder mehrere Level von Zwischenspeichern innerhalb der Kerne, einen Satz von einer oder mehreren gemeinsam genutzten Zwischenspeichereinheiten 2306 und externen Arbeitsspeicher (nicht gezeigt), die an den Satz der integrierten Arbeitsspeichersteuerungseinheiten 2314 gekoppelt sind. Der Satz der gemeinsam genutzten Zwischenspeichereinheiten 2306 kann einen oder mehrere Zwischenspeicher mittlerer Levels enthalten, wie Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Zwischenspeicherlevel, einen Last-Level-Zwischenspeicher (LLC) und/oder Kombinationen davon. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 2312 die integrierte Grafiklogik 2308 (die integrierte Grafiklogik 2308 ist ein Beispiel für und wird hierin auch als Logik für Spezialzwecke bezeichnet), den Satz der gemeinsam genutzten Zwischenspeichereinheiten 2306 und die Systemagenteneinheit 2310/den bzw. die integrierten Arbeitsspeichersteuerungseinheit(en) 2314 verbindet, können alternative Ausführungsformen eine beliebige Anzahl von gut bekannten Techniken zum Verbinden derartiger Einheiten verwenden. In einer Ausführungsform wird Kohärenz zwischen einem oder mehreren Zwischenspeichereinheiten 2306 und den Kernen 2302-A-N beibehalten.
  • In manchen Ausführungsformen sind einer oder mehrere der Kerne 2302A-N multithreadingfähig. Der Systemagent 2310 umfasst diejenigen Komponenten, die Kerne 2302A-N koordinieren und betreiben. Die Systemagenteneinheit 2310 kann beispielsweise eine Leistungssteuerungseinheit (PCU, Power Control Unit) und eine Anzeigeeinheit umfassen. Die PCU kann Logik und Komponenten, die zum Regeln des Leistungszustands der Kerne 2302A-N und der integrierten Grafiklogik 2308 benötigt werden, sein oder umfassen. Die Anzeigeeinheit dient zum Ansteuern einer oder mehrerer extern verbundener Anzeigen.
  • Die Kerne 2302A-N können in Bezug auf einen Architekturbefehlssatz homogen oder heterogen sein; das heißt, zwei oder mehr der Kerne 2302A-N können fähig sein, den gleichen Befehlssatz auszuführen, während andere fähig sein können, nur einen Teilsatz dieses Befehlssatzes oder einen anderen Befehlssatz auszuführen.
  • Beispielhafte Computerarchitekturen
  • 24-27 sind Blockdiagramme von beispielhaften Computerarchitekturen. Andere Systemdesigns und -konfigurationen, die in der Technik für Laptops, Desktops, tragbare PCs, Organizer, Entwicklungs-Workstations, Server, Netzwerkeinrichtungen, Netzwerkhubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Grafikeinrichtungen, Videospieleinrichtungen, Set-Top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Mediaplayer, tragbare Geräte und verschiedene andere Elektronikgeräte bekannt sind, sind ebenfalls geeignet. Im Allgemeinen ist eine enorm große Vielfalt von Systemen oder Elektronikeinrichtungen geeignet, die einen Prozessor und/oder eine andere Ausführungslogik, wie hierin offenbart, einbinden können.
  • Nunmehr auf 24 Bezug nehmend, wird ein Blockdiagramm eines Systems 2400 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das System 2400 kann einen oder mehrere Prozessoren 2410, 2415 enthalten, die mit einem Steuerungshub 2420 gekoppelt sind. In einer Ausführungsform enthält der Steuerungshub 2420 einen Grafikspeicher-Steuerungshub (GMCH) 2490 und einen Eingabe-/Ausgabe-Hub (IOH) 2450 (die auf separaten Chips sein können); der GMCH 2490 enthält Arbeitsspeicher- und Grafiksteuerungen, an die Arbeitsspeicher 2440 und ein Coprozessor 2445 gekoppelt sind; der IOH 2450 koppelt Eingabe-/Ausgabe(E/A)-Einrichtungen 2460 an den GMCH 2490. Alternativ sind eine oder beide, die Arbeitsspeicher- und/oder die Grafiksteuerung, in den Prozessor integriert (wie hier beschrieben), der Arbeitsspeicher 2440 und der Coprozessor 2445 sind direkt mit dem Prozessor 2410 gekoppelt, und der Steuerungshub 2420 befindet sich in einem einzelnen Chip mit dem IOH 2450.
  • Der optionale Charakter der zusätzlichen Prozessoren 2415 wird in 24 durch unterbrochene Linien angezeigt. Jeder Prozessor 2410, 2415 kann einen oder mehrere der hierin beschriebenen Verarbeitungskerne enthalten und kann eine Version des Prozessors 2300 sein.
  • Der Arbeitsspeicher 2440 kann zum Beispiel ein dynamischer Arbeitsspeicher mit wahlfreiem Zugriff (DRAM), ein Phasenwechselspeicher (PCM) oder eine Kombination der zwei sein. Für mindestens eine Ausführungsform kommuniziert der Steuerungshub 2420 mit dem Prozessor bzw. den Prozessoren 2410, 2415 über einen Mehrpunktbus wie einem Frontside-Bus (FSB), einer Punkt-zu-Punkt-Schnittstelle wie QuickPath Interconnect (QPI) oder einer ähnlichen Verbindung 2495.
  • In einer Ausführungsform ist der Coprozessor 2445 ein Prozessor für Sonderzwecke, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder Ähnliches. In einer Ausführungsform kann der Steuerungshub 2420 einen integrierten Grafikbeschleuniger enthalten.
  • Es kann eine Vielzahl an Unterschieden hinsichtlich eines Spektrums von Leistungsmetriken, einschließlich Architektur-, Mikroarchitektur-, thermischen, Stromverbrauchseigenschaften und dergleichen, zwischen den physischen Ressourcen 2410, 2415 geben.
  • In einer Ausführungsform führt der Prozessor 2410 Befehle aus, die Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In den Befehlen können Coprozessorbefehle eingebettet sein. Der Prozessor 2410 erkennt, dass diese Coprozessorbefehle von einem Typ sind, der vom angebundenen Coprozessor 2445 ausgeführt werden soll. Dementsprechend gibt der Prozessor 2410 diese Coprozessorbefehle (oder Steuersignale, die die Coprozessorbefehle repräsentieren) auf einem Coprozessorbus oder einer anderen Verbindung an den Coprozessor 2445 aus. Der bzw. die Coprozessor(en) 2445 nimmt bzw. nehmen die empfangenen Coprozessorbefehle an und führt bzw. führen diese aus.
  • Nunmehr auf 25 Bezug nehmend, wird ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems 2500 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt. Wie in 25 gezeigt, ist das Multiprozessorsystem 2500 ein Punkt-zu-Punkt-Verbindungssystem und enthält einen ersten Prozessor 2570 und einen zweiten Prozessor 2580, die über eine Punkt-zu-Punkt-Verbindung 2550 gekoppelt sind. Jeder der Prozessoren 2570 und 2580 kann eine Version des Prozessors 2300 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 2570 und 2580 die Prozessoren 2410 bzw. 2415, während der Coprozessor 2538 der Coprozessor 2445 ist. In einer anderen Ausführungsform sind die Prozessoren 2570 und 2580 der Prozessor 2410 bzw. der Coprozessor 2445.
  • Die Prozessoren 2570 und 2580 sind einschließlich integrierter Arbeitsspeichersteuerungseinheiten (IMC) 2572 bzw. 2582 gezeigt. Der Prozessor 2570 enthält auch als Teil seiner Bussteuerungseinheiten Punkt-zu-Punkt(P-P)-Schnittstellen 2576 und 2578; gleichermaßen enthält der zweite Prozessor 2580 P-P-Schnittstellen 2586 und 2588. Die Prozessoren 2570, 2580 können Informationen über eine Punkt-zu-Punkt(P-P)-Schnittstelle 2550 unter Verwendung der P-P-Schnittstellenschaltkreise 2578, 2588 austauschen. Wie in 25 gezeigt, koppeln die IMCs 2572 und 2582 die Prozessoren an jeweilige Arbeitsspeicher, nämlich einen Arbeitsspeicher 2532 und einen Arbeitsspeicher 2534, die Teile von Hauptspeicher sein können, die lokal an die jeweiligen Prozessoren angebunden sind.
  • Die Prozessoren 2570, 2580 können jeweils Informationen mit einem Chipsatz 2590 über einzelne P-P-Schnittstellen 2552, 2554 unter Verwendung von Punkt-zu-Punkt-Schnittstellen-Schaltungen 2576, 2594, 2586, 2598 austauschen. Der Chipsatz 2590 kann optional Informationen mit dem Coprozessor 2538 über eine Hochleistungsschnittstelle 2592 austauschen. In einer Ausführungsform ist der Coprozessor 2538 ein Prozessor für Sonderzwecke, wie zum Beispiel ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder Ähnliches.
  • Ein gemeinsam genutzter Zwischenspeicher (nicht gezeigt) kann in einem der beiden Prozessoren oder außerhalb beider Prozessoren enthalten sein, jedoch mit den Prozessoren über eine P-P-Verbindung verbunden sein, sodass die lokalen Zwischenspeicher-Informationen von einem der beiden oder beiden Prozessoren im gemeinsam genutzten Zwischenspeicher gespeichert werden kann, wenn ein Prozessor in einen Niedrigenergiemodus versetzt wird.
  • Der Chipsatz 2590 kann über eine Schnittstelle 2596 an einen ersten Bus 2516 gekoppelt sein. In einer Ausführungsform ist der erste Bus 2516 ein Peripheral-Component-Interconnect(PCI)-Bus oder ein Bus wie ein PCI-Express-Bus oder ein anderer E/A-Verbindungsbus der dritten Generation sein, obwohl der Umfang der vorliegenden Erfindung dadurch nicht eingeschränkt ist.
  • Wie in 25 gezeigt, können verschiedene E/A-Einrichtungen 2514 zusammen mit einer Busbrücke 2518, die den ersten Bus 2516 an einen zweiten Bus 2520 koppelt, an den ersten Bus 2516 gekoppelt sein. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessoren 2515 wie Coprozessoren, Hochdurchsatz-MIC-Prozessoren, GPGPUs, Beschleuniger (wie z. B. Grafikbeschleuniger oder digitale Signalverarbeitungseinheiten (DSP)), feldprogrammierbare Gatearrays oder beliebige andere Prozessoren an den ersten Bus 2516 gekoppelt. In einer Ausführungsform kann der zweite Bus 2520 ein Low-Pin-Count(LPC)-Bus sein. Verschiedene Einrichtungen können in einer Ausführungsform mit einem zweiten Bus 2520 gekoppelt sein, einschließlich zum Beispiel eine Tastatur und/oder eine Maus 2522, Kommunikationseinrichtungen 2527 und eine Speichereinheit 2528, wie zum Beispiel ein Festplattenlaufwerk oder eine andere Massenspeichereinrichtung, die Befehle/Code und Daten 2530 enthalten kann. Ferner kann eine Audio-E/A 2524 an den zweiten Bus 2520 gekoppelt sein. Es sei darauf hingewiesen, dass andere Architekturen möglich sind. Zum Beispiel kann ein System statt der Punkt-zu-Punkt-Architektur von 25 einen Mehrpunktbus oder eine andere solche Architektur implementieren.
  • Nunmehr auf 26 Bezug nehmend, wird ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems 2600 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt. Gleiche Elemente in den 25 und 26 tragen gleiche Referenzziffern, und bestimmte Aspekte von 25 wurden von 26 weggelassen, um ein Verdecken anderer Aspekte von 26 zu vermeiden.
  • 26 veranschaulicht, dass die Prozessoren 2570, 2580 eine integrierte Arbeitsspeicher- und E/A-Steuerlogik („CL“) 2572 bzw. 2582 enthalten können. Daher enthält die CL 2572, 2582 integrierte Arbeitsspeichersteuerungseinheiten und E/A-Steuerlogik. 26 illustriert, dass nicht nur die Arbeitsspeicher 2532, 2534 an die CL 2572, 2582 gekoppelt sind, sondern auch, dass E/A-Einrichtungen 2614 ebenfalls an die Steuerlogik 2572, 2582 gekoppelt sind. Alt-E/A-Einrichtungen 2615 sind an den Chipsatz 2590 gekoppelt.
  • Nunmehr auf 27 Bezug nehmend, wird ein Blockdiagramm eines SoC 2700 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 23 tragen gleiche Referenzziffern. Gestrichelt umrandete Kästchen sind außerdem optionale Merkmale an hochentwickelteren SoCs. In 27 ist eine Verbindungseinheit bzw. sind Verbindungseinheiten 2702 gekoppelt an: einen Anwendungsprozessor 2710, der einen Satz von einem oder mehreren Kernen 2302A-N, die Zwischenspeichereinheiten 2304A-N enthalten, und (eine) gemeinsam genutzte Zwischenspeichereinheit(en) 2306 enthält; eine Systemagenteneinheit 2310; (eine) Bussteuerungseinheit(en) 2316; (eine) integrierte Arbeitsspeichersteuerungseinheit(en) 2314; einen Satz von einem oder mehreren Coprozessoren 2720, die integrierte Grafiklogik, einen Grafikprozessor, einen Audioprozessor und einen Videoprozessor enthalten können; eine statische Arbeitsspeichereinheit mit wahlfreiem Zugriff (SRAM-Einheit) 2730; eine direkte Arbeitsspeicherzugriffs(DMA)-Einheit 2732; und eine Anzeigeeinheit 2740 zum Koppeln an eine oder mehrere externe Anzeigen. In einer Ausführungsform enthält bzw. enthalten der bzw. die Coprozessor(en) 2720 einen Prozessor für Sonderzwecke, wie zum Beispiel einen Netzwerk- oder Kommunikationsprozessor, eine Komprimierungsengine, eine GPGPU, einen Hochdurchsatz-MIC-Prozessor, einen eingebetteten Prozessor oder Ähnliches.
  • Ausführungsformen der hier offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination solcher Implementierungsansätze implementiert werden. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert werden, die auf programmierbaren Systemen ausgeführt werden, die mindestens einen Prozess, ein Speichersystem (das flüchtigen und nichtflüchtigen Arbeitsspeicher und/oder Speicherelemente enthält), mindestens eine Eingabeeinrichtung und mindestens eine Ausgabeeinrichtung umfassen.
  • Programmcode, wie zum Beispiel der in 25 veranschaulichte Code 2530, kann auf Eingabebefehle angewendet werden, um die hier beschriebenen Funktionen durchzuführen und Ausgabeinformationen zu generieren. Die Ausgabeinformationen können auf eine oder mehrere Ausgabeeinrichtungen angewandt werden, auf bekannte Weise. Für Zwecke dieser Anmeldung enthält ein Verarbeitungssystem ein beliebiges System, das einen Prozessor aufweist, wie zum Beispiel: einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor.
  • Der Programmcode kann in einer höheren verfahrens- oder objektorientierten Programmiersprache implementiert werden, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann, falls gewünscht, auch in einer Assembler- oder Maschinensprache implementiert werden. Tatsächlich sind die hierin beschriebenen Mechanismen im Umfang nicht auf eine beliebige bestimmte Programmiersprache beschränkt. Auf jeden Fall kann die Sprache eine compilierte oder interpretierte Sprache sein.
  • Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentative Befehle implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logik innerhalb des Prozessors repräsentiert, die, wenn sie von einer Maschine gelesen wird, bewirkt, dass die Maschine Logik erzeugt, um die hierin beschriebenen Techniken durchzuführen. Solche Repräsentationen, als „IP-Kerne“ bekannt, können auf einem greifbaren, maschinenlesbaren Medium gespeichert und an verschiedene Kunden oder Fertigungsanlagen geliefert werden, um in die Fertigungsmaschinen geladen zu werden, die die Logik oder den Prozessor tatsächlich herstellen.
  • Solche maschinenlesbaren Speichermedien können nicht-transitorische, greifbare Anordnungen von einer Maschine oder Einrichtung gefertigte oder gebildete Artikel enthalten, die Speichermedien wie Festplatten, irgendeinen anderen Typ von Platte einschließlich Disketten, optische Platten, Compact Disc Read-Only Memories (CD-ROMs), wiederbeschreibbare Compact Discs (CD-RWs) und magneto-optische Platten, Halbleiterbauelemente wie schreibgeschützte Arbeitsspeicher (ROMs), Arbeitsspeicher mit wahlfreiem Zugriff (RAMs) wie dynamische Arbeitsspeicher mit wahlfreiem Zugriff (DRAMs), statische Arbeitsspeicher mit wahlfreiem Zugriff (SRAMs), löschbare programmierbare schreibgeschützte Arbeitsspeicher (EPROMs), Flashspeicher, elektrisch löschbare programmierbare schreibgeschützte Arbeitsspeicher (EEPROMs), Phasenwechselspeicher (PCM), magnetische oder optische Karten oder irgendeinen anderen, zur Speicherung von elektronischen Befehlen geeigneten Medientyp enthalten, sind jedoch nicht darauf beschränkt.
  • Dementsprechend enthalten Ausführungsformen der Erfindung auch nicht-transitorische, greifbare maschinenlesbare Medien, die Befehle enthalten oder die Designdaten enthalten, wie Hardwarebeschreibungssprache (HDL), die hierin beschriebene Strukturen, Schaltkreise, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
  • Emulation (einschließlich binärer Übersetzung, Code-Morphing usw.)
  • In einigen Fällen kann ein Befehlswandler verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. Zum Beispiel kann der Befehlswandler einen Befehl in einen oder mehrere andere Befehle, die vom Kern verarbeitet werden sollen, übersetzen (z. B. unter Verwendung statischer binärer Übersetzung, dynamischer binärer Übersetzung einschließlich dynamischer Kompilierung), morphen, emulieren oder auf andere Weise umwandeln. Der Befehlswandler kann in Software, Hardware, Firmware oder einer Kombination daraus implementiert sein. Der Befehlswandler kann sich auf dem Prozessor, außerhalb des Prozessors oder teilweise auf und teilweise außerhalb des Prozessors befinden.
  • 28 ist ein Blockdiagramm, das die Verwendung eines Softwarebefehlswandlers gegenüberstellt, um binäre Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz nach Ausführungsformen der Erfindung umzuwandeln. Bei der illustrierten Ausführungsform ist der Befehlswandler ein Softwarebefehlswandler, obwohl alternativ dazu der Befehlswandler in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 28 zeigt, dass ein Programm in einer höheren Sprache 2802 unter Verwendung eines x86-Compilers 2804 compiliert werden kann, um x86-Binärcode 2806 zu generieren, der nativ von einem Prozessor mit mindestens einem x86-Befehlssatzkern 2816 ausgeführt werden kann. Der Prozessor mit mindestens einem x86-Befehlssatzkern 2816 repräsentiert einen beliebigen Prozessor, der im Wesentlichen die gleichen Funktionen wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern durchführen kann, indem er Folgendes kompatibel ausführt oder anderweitig verarbeitet: (1) einen wesentlichen Teil des Befehlssatzes des Intel-x86-Befehlssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software, die auf einem Intel-Prozessor mit mindestens einem x86-Befehlssatzkern laufen sollen, um im Wesentlichen das gleiche Ergebnis wie ein Intel-Prozessor mit mindestens einem x86-Befehlssatzkern zu erreichen. Der x86-Compiler 2804 repräsentiert einen Compiler, der betrieben werden kann, um x86-Binärcode 2806 (z. B. Objektcode) zu generieren, der ohne oder mit zusätzlicher Verlinkungsverarbeitung auf dem Prozessor mit mindestens einem x86-Befehlssatzkern 2816 ausgeführt werden kann. Gleichermaßen zeigt 28, dass das Programm in der höheren Sprache 2802 unter Verwendung eines Compilers für einen alternativen Befehlssatz 2808 compiliert werden kann, um Binärcode eines alternativen Befehlssatzes 2810 zu generieren, der nativ von einem Prozessor ohne mindestens einen x86-Befehlssatzkern 2814 ausgeführt werden kann (z. B. einem Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies in Sunnyvale, CA und/oder die den ARM-Befehlssatz von ARM Holdings in Sunnyvale, CA ausführen). Der Befehlswandler 2812 wird verwendet, um den x86-Binärcode 2806 in Code umzuwandeln, der nativ vom Prozessor ohne einen x86-Befehlssatzkern 2814 ausgeführt werden kann. Es ist unwahrscheinlich, dass dieser umgewandelte Code der gleiche wie der Binärcode eines alternativen Befehlssatzes 2810 ist, da ein Befehlswandler, der dazu fähig ist, schwer herzustellen ist; dennoch wird der umgewandelte Code die allgemeine Operation erzielen und aus Befehlen aus dem alternativen Befehlssatz bestehen. Deshalb repräsentiert der Befehlswandler 2812 Software, Firmware, Hardware oder eine Kombination davon, die durch Emulation, Simulation oder einen beliebigen anderen Prozess einem Prozessor oder einer anderen Elektronikeinrichtung erlaubt, der bzw. die keinen x86-Befehlssatzprozessor oder -Kern aufweist, den x86-Binärcode 2806 auszuführen.
  • WEITERE BEISPIELE
  • Beispiel 1 sieht einen beispielhaften Prozessor vor, enthaltend: eine Vielzahl von Beschleunigerkernen, die jeweils eine entsprechende Befehlssatzarchitektur (ISA) aufweisen, einen Abrufschaltkreis zum Abrufen eines oder mehrerer Befehle, die einen der Beschleunigerkerne angeben, einen Decodierschaltkreis, um den einen oder die mehreren abgerufenen Befehle zu decodieren, und einen Erteilungsschaltkreis, um den einen oder die mehreren decodierten Befehle in die ISA zu übersetzen, die dem angegebenen Beschleunigerkern entspricht, den einen oder die mehreren übersetzten Befehle in ein Befehlspaket zu vereinigen und das Befehlspaket an den angegebenen Beschleunigerkern auszugeben, wobei die Vielzahl der Beschleunigerkerne eine Arbeitsspeicherengine (MENG), eine Kollektivengine (CENG), eine Warteschlangenengine (QENG) und eine Kettenverwaltungseinheit (CMU) enthält.
  • Beispiel 2 enthält den Gegenstand des beispielhaften Prozessors von Beispiel 1, wobei jeder der Vielzahl der Beschleunigerkerne im Arbeitsspeicher auf einen Adressbereich abgebildet ist und wobei der eine oder die mehreren Befehle im Arbeitsspeicher abgebildete Eingabe-/Ausgabe(MMIO)-Befehle mit einer Adresse zur Angabe des einen Beschleunigerkerns sind.
  • Beispiel 3 enthält den Gegenstand des beispielhaften Prozessors von Beispiel 1, der ferner einen Ausführungsschaltkreis enthält, wobei der Abrufschaltkreis ferner einen weiteren Befehl abruft, der keinen Beschleunigerkern angibt, wobei der eine oder die mehreren Befehle, die den einen Beschleunigerkern angeben, nicht blockierend sind, wobei der Decodierschaltkreis ferner den anderen abgerufenen Befehl zu decodieren hat und wobei der Ausführungsschaltkreis den decodierten anderen Befehl auszuführen hat, ohne auf einen Abschluss der Ausführung des Befehlspakets zu warten.
  • Beispiel 4 enthält den Gegenstand des beispielhaften Prozessors von einem der Beispiele 1-3, wobei die ISA, die der MENG entspricht, duale Arbeitsspeicherbefehle enthält, wobei jeder der dualen Arbeitsspeicherbefehle eines von Dual_read_read, Dual_read_write, Dual_write_write, Dual_xchg_read, Dual_xchg_write, Dual_cmpxchg_read, Dual_cmpxchg_write, Dual_compare&read_read und Dual_compare&read_write enthält.
  • Beispiel 5 enthält den Gegenstand des beispielhaften Prozessors von einem der Beispiele 1-3, wobei die ISA, die der MENG entspricht, einen Direktspeicherzugriffsbefehl (DMA-Befehl) enthält, die eine Quelle, ein Ziel, eine arithmetische Operation und eine Blockgröße angibt, wobei die MENG einen Datenblock in Übereinstimmung mit der Blockgröße von der angegebenen Quelle an das angegebene Ziel kopiert und wobei die MENG ferner die arithmetische Operation an jedem Datenelement des Datenblocks durchführt, bevor sie das resultierende Datenelement an das angegebene Ziel kopiert.
  • Beispiel 6 enthält den Gegenstand des beispielhaften Prozessors von einem der Beispiele 1-3, wobei die ISA, die der CENG entspricht, kollektive Operationen einschließlich Reduktionen, vollständiger Reduktionen (Reduktion-auf-alle), Broadcasts, Sammlungen, Streuungen, Barrieren und paralleler Präfixoperationen enthält.
  • Beispiel 7 enthält den Gegenstand des beispielhaften Prozessors von einem der Beispiele 1-3, wobei die QENG eine hardwareverwaltete Warteschlange mit einem beliebigen Warteschlangentyp enthält und wobei die ISA, die der QENG entspricht, Befehle zum Hinzufügen von Daten zur Warteschlange und Entfernen von Daten aus der Warteschlange enthält und wobei der beliebige Warteschlangentyp einer von Last-in-First-out (LIFO), First-in-Last-Out (FILO) und First-in-First-out (FIFO) ist.
  • Beispiel 8 enthält den Gegenstand des beispielhaften Prozessors von einem der Beispiele 1-3, wobei eine Teilmenge des einen oder der mehreren Befehle ein Teil einer Kette ist und wobei die CMU eine Ausführung jedes verketteten Befehls bis zum Abschluss eines vorangehenden verketteten Befehls anhält, und wobei andere Befehle des einen oder der mehreren Befehle parallel ausgeführt werden können.
  • Beispiel 9 enthält den Gegenstand des beispielhaften Prozessors von einem der Beispiele 1-3, das ferner eine geschaltete Bus-Fabric enthält, um den Erteilungsschaltkreis und die Vielzahl von Beschleunigerkernen zu koppeln, wobei die geschaltete Bus-Fabric Pfade mit mehreren parallelen Spuren enthält und ein Ausmaß an Überlastung auf diesen überwacht.
  • Beispiel 10 enthält den Gegenstand des beispielhaften Prozessors von Beispiel 9, der ferner Eingangs- und Ausgangsnetzwerkschnittstellen und einen Paketkaperschaltkreis enthält, um: zu ermitteln, ob jedes eingehende Befehlspaket an der Eingangsnetzwerkschnittstelle zu kapern ist, indem er eine im Befehlspaket enthaltene Adresse mit einer softwareprogrammierbaren Kaperzieladresse vergleicht, ein Befehlspaket, von dem ermittelt wird, dass es zu kapern ist, in einen Scratch-Zwischenspeicher des Kaperschaltkreises zu kopieren und ein gespeichertes Paket durch eine Ausführungseinheit des Kaperschaltkreises zu verarbeiten, um eine lokale Analyse, Modifikation und Ablehnung von Paketen mit Zeilengeschwindigkeit durchzuführen.
  • Beispiel 11 sieht ein beispielhaftes System vor, enthaltend: einen Arbeitsspeicher, eine Vielzahl von Beschleunigerkernen, die jeweils eine entsprechende Befehlssatzarchitektur (ISA) aufweisen, Mittel zum Abrufen eines oder mehrerer Befehle, die einen der Beschleunigerkerne angeben, Mittel zum Decodieren des einen oder der mehreren abgerufenen Befehlen, und Mittel zum Übersetzen des einen oder der mehreren decodierten Befehle in die ISA, die dem angegebenen Beschleunigerkern entspricht, Mittel zum Vereinigen des einen oder der mehreren übersetzten Befehle in ein Befehlspaket und Mittel zum Ausgeben des Befehlspakets an den angegebenen Beschleunigerkern, wobei die Vielzahl der Beschleunigerkerne eine Arbeitsspeicherengine (MENG), eine Kollektivengine (CENG), eine Warteschlangenengine (QENG) und eine Kettenverwaltungseinheit (CMU) enthält.
  • Beispiel 12 enthält den Gegenstand des beispielhaften Systems von Beispiel 12, wobei jeder der Vielzahl der Beschleunigerkerne im Arbeitsspeicher auf einen Adressbereich abgebildet ist und wobei der eine oder die mehreren Befehle im Arbeitsspeicher abgebildete Eingabe-/Ausgabe(MMIO)-Befehle mit einer Adresse zur Angabe des einen Beschleunigerkerns sind.
  • Beispiel 13 enthält den Gegenstand des beispielhaften Prozessors von Beispiel 12, der ferner einen Ausführungsschaltkreis enthält, wobei das Mittel zum Abrufen ferner einen weiteren Befehl abruft, die keinen Beschleunigerkern angibt, wobei der eine oder die mehreren Befehle, die den einen Beschleunigerkern angeben, nicht blockierend sind, wobei das Mittel zum Decodieren ferner den anderen abgerufenen Befehl zu decodieren hat und wobei der Ausführungsschaltkreis den decodierten anderen Befehl auszuführen hat, ohne auf einen Abschluss der Ausführung des Befehlspakets zu warten.
  • Beispiel 14 enthält den Gegenstand des beispielhaften Systems von einem der Beispiele 11-13, wobei die ISA, die der MENG entspricht, duale Arbeitsspeicherbefehle enthält, wobei jeder der dualen Arbeitsspeicherbefehle einen von Dual_read_read, Dual_read_write, Dual_write_write, Dual_xchg_read, Dual_xchg_write, Dual_cmpxchg_read, Dual_cmpxchg_write, Dual_compare&read_read und Dual_compare&read_write enthält.
  • Beispiel 15 enthält den Gegenstand des beispielhaften Systems von einem der Beispiele 11-13, wobei die ISA, die der MENG entspricht, einen Direktspeicherzugriffsbefehl (DMA-Befehl) enthält, die eine Quelle, ein Ziel, eine arithmetische Operation und eine Blockgröße angibt, wobei die MENG einen Datenblock in Übereinstimmung mit der Blockgröße von der angegebenen Quelle an das angegebene Ziel kopiert und wobei die MENG ferner die arithmetische Operation an jedem Datenelement des Datenblocks durchführt, bevor sie das resultierende Datenelement an das angegebene Ziel kopiert.
  • Beispiel 16 enthält den Gegenstand des beispielhaften Systems von einem der Beispiele 11-13, wobei die ISA, die der CENG entspricht, kollektive Operationen einschließlich Reduktionen, vollständiger Reduktionen (Reduktion-auf-alle), Broadcasts, Sammlungen, Streuungen, Barrieren und paralleler Präfixoperationen enthält.
  • Beispiel 17 enthält den Gegenstand des beispielhaften Systems von einem der Beispiele 11-13, wobei die QENG eine hardwareverwaltete Warteschlange mit einem beliebigen Warteschlangentyp enthält und wobei die ISA, die der QENG entspricht, Befehle zum Hinzufügen von Daten zur Warteschlange und Entfernen von Daten aus der Warteschlange enthält und wobei der beliebige Warteschlangentyp einer von Last-in-First-out (LIFO), First-in-Last-Out (FILO) und First-in-First-out (FIFO) ist.
  • Beispiel 18 enthält den Gegenstand des beispielhaften Systems von einem der Beispiele 11-13, wobei eine Teilmenge des einen oder der mehreren Befehle ein Teil einer Kette ist und wobei die CMU eine Ausführung jedes verketteten Befehls bis zum Abschluss eines vorangehenden verketteten Befehls anhält, und wobei andere Befehle des einen oder der mehreren Befehle parallel ausgeführt werden können.
  • Beispiel 19 enthält den Gegenstand des beispielhaften Systems von einem der Beispiele 11-13, das ferner eine geschaltete Bus-Fabric enthält, um den Erteilungsschaltkreis und die Vielzahl von Beschleunigerkernen zu koppeln, wobei die geschaltete Bus-Fabric Pfade mit mehreren parallelen Spuren enthält und ein Ausmaß an Überlastung auf diesen überwacht.
  • Beispiel 20 enthält den Gegenstand des beispielhaften Systems von Beispiel 19, der ferner Eingangs- und Ausgangsnetzwerkschnittstellen und einen Paketkaperschaltkreis enthält, um: zu ermitteln, ob jedes eingehende Befehlspaket an der Eingangsnetzwerkschnittstelle zu kapern ist, indem er eine im Befehlspaket enthaltene Adresse mit einer softwareprogrammierbaren Kaperzieladresse vergleicht, ein Befehlspaket, von dem ermittelt wird, dass es zu kapern ist, in einen Scratch-Zwischenspeicher des Kaperschaltkreises zu kopieren und ein gespeichertes Paket durch eine Ausführungseinheit des Kaperschaltkreises zu verarbeiten, um eine lokale Analyse, Modifikation und Ablehnung von Paketen mit Zeilengeschwindigkeit durchzuführen.
  • Beispiel 21 sieht ein beispielhaftes Verfahren zum Ausführen von Befehlen unter Verwendung eines Ausführungsschaltkreises und einer Vielzahl von Beschleunigerkernen vor, die jeweils eine entsprechende Befehlssatzarchitektur (ISA) aufweisen, wobei das Verfahren umfasst: Abrufen, durch einen Abrufschaltkreis, eines oder mehrerer Befehle, die einen der Beschleunigerkerne angeben, Decodieren, unter Verwendung eines Decodierschaltkreises, des einen oder der mehreren abgerufenen Befehle, Übersetzen, unter Verwendung eines Erteilungsschaltkreises, des einen oder der mehreren decodierten Befehle in die ISA, die dem angegebenen Beschleunigerkern entspricht, Vereinigen, durch den Erteilungsschaltkreis, des einen oder der mehreren übersetzten Befehle in ein Befehlspaket und Ausgeben des Befehlspakets an den angegebenen Beschleunigerkern, wobei die Vielzahl der Beschleunigerkerne eine Arbeitsspeicherengine (MENG), eine Kollektivengine (CENG), eine Warteschlangenengine (QENG) und eine Kettenverwaltungseinheit (CMU) enthält.
  • Beispiel 22 enthält den Gegenstand des beispielhaften Verfahrens von Beispiel 21, wobei jeder der Vielzahl der Beschleunigerkerne im Arbeitsspeicher auf einen Adressbereich abgebildet ist und wobei der eine oder die mehreren Befehle im Arbeitsspeicher abgebildete Eingabe-/Ausgabe(MMIO)-Befehle mit einer Adresse zur Angabe des einen Beschleunigerkerns sind.
  • Beispiel 23 enthält den Gegenstand des beispielhaften Verfahrens von Beispiel 21, wobei der eine oder die mehreren Befehle, die den einen Beschleunigerkern angeben, nicht blockierend sind, wobei das Verfahren ferner ein Abrufen, durch den Abrufschaltkreis, eines anderen Befehls, der keinen Beschleunigerkern angibt, Decodieren, durch den Decodierschaltkreis, des anderen abgerufenen Befehls, und Ausführen enthält, durch den Ausführungsschaltkreis, des decodierten anderen Befehls, ohne auf einen Abschluss der Ausführung des Befehlspakets zu warten.
  • Beispiel 24 enthält den Gegenstand des beispielhaften Verfahrens von einem der Beispiele 21-23, wobei die ISA, die der MENG entspricht, duale Arbeitsspeicherbefehle enthält, wobei jeder der dualen Arbeitsspeicherbefehle einen von Dual_read_read, Dual_read_write, Dual_write_write, Dual_xchg_read, Dual_xchg_write, Dual_cmpxchg_read, Dual_cmpxchg_write, Dual_compare&read_read und Dual_compare&read_write enthält.
  • Beispiel 25 enthält den Gegenstand des beispielhaften Verfahrens von einem der Beispiele 21-23, wobei die ISA, die der MENG entspricht, einen Direktspeicherzugriffsbefehl (DMA-Befehl) enthält, der eine Quelle, ein Ziel, eine arithmetische Operation und eine Blockgröße angibt, wobei die MENG einen Datenblock in Übereinstimmung mit der Blockgröße von der angegebenen Quelle an das angegebene Ziel kopiert und wobei die MENG ferner die arithmetische Operation an jedem Datenelement des Datenblocks durchführt, bevor sie das resultierende Datenelement an das angegebene Ziel kopiert.
  • Beispiel 26 enthält den Gegenstand des beispielhaften Verfahrens von einem der Beispiele 21-23, wobei die ISA, die der CENG entspricht, kollektive Operationen einschließlich Reduktionen, vollständiger Reduktionen (Reduktion-auf-alle), Broadcasts, Sammlungen, Streuungen, Barrieren und paralleler Präfixoperationen enthält.
  • Beispiel 27 enthält den Gegenstand des beispielhaften Verfahrens von einem der Beispiele 21-23, wobei die QENG eine hardwareverwaltete Warteschlange mit einem beliebigen Warteschlangentyp enthält und wobei die ISA, die der QENG entspricht, Befehle zum Hinzufügen von Daten zur Warteschlange und Entfernen von Daten aus der Warteschlange enthält und wobei der beliebige Warteschlangentyp einer von Last-in-First-out (LIFO), First-in-Last-Out (FILO) und First-in-First-out (FIFO) ist.
  • Beispiel 28 enthält den Gegenstand des beispielhaften Verfahrens von einem der Beispiele 21-23, wobei eine Teilmenge des einen oder der mehreren Befehle ein Teil einer Kette ist und wobei die CMU eine Ausführung jedes verketteten Befehls bis zum Abschluss eines vorangehenden verketteten Befehls anhält, und wobei andere Befehle des einen oder der mehreren Befehle parallel ausgeführt werden können.
  • Beispiel 29 enthält den Gegenstand des beispielhaften Verfahrens von einem der Beispiele 21-23, das ferner ein Verwenden einer geschalteten Bus-Fabric enthält, um den Erteilungsschaltkreis und die Vielzahl von Beschleunigerkernen zu koppeln, wobei die geschaltete Bus-Fabric Pfade mit mehreren parallelen Spuren enthält und ein Ausmaß an Überlastung auf diesen überwacht.
  • Beispiel 30 enthält den Gegenstand des beispielhaften Verfahrens von Beispiel 29, das ferner einen Paketkaperschaltkreis mit Eingangs- und Ausgangsnetzwerkschnittstellen enthält, die an die geschaltete Bus-Fabric gekoppelt sind, und wobei das Verfahren ferner enthält: Überwachen, durch den Paketkaperschaltkreis, von Paketen, die in die Eingangsschnittstelle strömen, Ermitteln, durch den Paketkaperschaltkreis, der auf eine Paketkapertabelle Bezug nimmt, dass ein Paket zu kapern ist, Speichern des gekaperten Pakets in einem Paketkaperpuffer, lokales Verarbeiten von gekaperten Paketen, die im Paketkaperpuffer gespeichert sind durch den Paketkaperschaltkreis mit Zeilengeschwindigkeit, wobei das Verarbeiten ein resultierendes Datenpaket zu generieren hat, Generieren eines resultierenden Datenpakets und Ausgeben des resultierenden Datenpakets zurück in einen Verkehrsstrom, der durch die Eingangsschnittstelle tritt.
  • Beispiel 31 sieht ein beispielhaftes nichtflüchtiges maschinenlesbares Medium vor, das Befehle enthält, die, wenn sie von einem Ausführungsschaltkreis ausgeführt werden, der an eine Vielzahl von Beschleunigerkernen gekoppelt ist, die jeweils eine entsprechende Befehlssatzarchitektur (ISA) aufweisen, bewirken, dass der Ausführungsschaltkreis: durch einen Abrufschaltkreis einen oder mehrere Befehle abruft, die einen der Beschleunigerkerne angeben, unter Verwendung eines Decodierschaltkreises den einen oder die mehreren abgerufenen Befehle decodiert, unter Verwendung eines Erteilungsschaltkreises den einen oder die mehreren decodierten Befehle in die ISA übersetzt, die dem angegebenen Beschleunigerkern entspricht, durch den Erteilungsschaltkreis den einen oder die mehreren übersetzten Befehle in ein Befehlspaket vereinigt und das Befehlspaket an den angegebenen Beschleunigerkern ausgibt, wobei die Vielzahl der Beschleunigerkerne eine Arbeitsspeicherengine (MENG), eine Kollektivengine (CENG), eine Warteschlangenengine (QENG) und eine Kettenverwaltungseinheit (CMU) enthält.
  • Beispiel 32 enthält den Gegenstand des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von Beispiel 31, wobei jeder der Vielzahl der Beschleunigerkerne im Arbeitsspeicher auf einen Adressbereich abgebildet ist und wobei der eine oder die mehreren Befehle im Arbeitsspeicher abgebildete Eingabe-/Ausgabe(MMIO)-Befehle mit einer Adresse zur Angabe des einen Beschleunigerkerns sind.
  • Beispiel 33 enthält den Gegenstand des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von Beispiel 31, wobei der eine oder die mehreren Befehle, die den einen Beschleunigerkern angeben, nicht blockierend sind, wobei das nichtflüchtige maschinenlesbare Medium ferner Befehle enthält, die bewirken, dass der Ausführungsschaltkreis: durch den Abrufschaltkreis einen weiteren Befehl abzurufen, der keinen Beschleunigerkern angibt, den anderen abgerufenen Befehl durch den Decodierschaltkreis zu decodieren und durch den Ausführungsschaltkreis den decodierten anderen Befehl auszuführen, ohne auf einen Abschluss der Ausführung des Befehlspakets zu warten.
  • Beispiel 34 enthält den Gegenstand des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von einem der Beispiele 31-33, wobei die ISA, die der MENG entspricht, duale Arbeitsspeicherbefehle enthält, wobei jeder der dualen Arbeitsspeicherbefehle einen von Dual_read_read, Dual_read_write, Dual_write_write, Dual_xchg_read, Dual_xchg_write, Dual cmpxchg_read, Dual_cmpxchg_write, Dual_compare&read_read und Dual_compare&read_write enthält.
  • Beispiel 35 enthält den Gegenstand des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von einem der Beispiele 31-33, wobei die ISA, die der MENG entspricht, einen Direktspeicherzugriffsbefehl (DMA-Befehl) enthält, der eine Quelle, ein Ziel, eine arithmetische Operation und eine Blockgröße angibt, wobei die MENG einen Datenblock in Übereinstimmung mit der Blockgröße von der angegebenen Quelle an das angegebene Ziel kopiert und wobei die MENG ferner die arithmetische Operation an jedem Datenelement des Datenblocks durchführt, bevor sie das resultierende Datenelement an das angegebene Ziel kopiert.
  • Beispiel 36 enthält den Gegenstand des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von einem der Beispiele 31-33, wobei die ISA, die der CENG entspricht, kollektive Operationen einschließlich Reduktionen, vollständiger Reduktionen (Reduktion-auf-alle), Broadcasts, Sammlungen, Streuungen, Barrieren und paralleler Präfixoperationen enthält.
  • Beispiel 37 enthält den Gegenstand des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von einem der Beispiele 31-33, wobei die QENG eine hardwareverwaltete Warteschlange mit einem beliebigen Warteschlangentyp enthält und wobei die ISA, die der QENG entspricht, Befehle zum Hinzufügen von Daten zur Warteschlange und Entfernen von Daten aus der Warteschlange enthält und wobei der beliebige Warteschlangentyp einer von Last-in-First-out (LIFO), First-in-Last-Out (FILO) und First-in-First-out (FIFO) ist.
  • Beispiel 38 enthält den Gegenstand des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von einem der Beispiele 31-33, wobei eine Teilmenge des einen oder der mehreren Befehle ein Teil einer Kette ist und wobei die CMU eine Ausführung jedes verketteten Befehls bis zum Abschluss eines vorangehenden verketteten Befehls anhält, und wobei andere Befehle des einen oder der mehreren Befehle parallel ausgeführt werden können.
  • Beispiel 39 enthält den Gegenstand des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von einem der Beispiele 31-33, wobei der maschinenlesbare Code ferner bewirkt, dass der Ausführungsschaltkreis eine geschaltete Bus-Fabric verwendet, um den Erteilungsschaltkreis und die Vielzahl von Beschleunigerkernen zu koppeln, wobei die geschaltete Bus-Fabric Pfade mit mehreren parallelen Spuren enthält und ein Ausmaß an Überlastung auf diesen überwacht.
  • Beispiel 40 enthält den Gegenstand des beispielhaften nichtflüchtigen maschinenlesbaren Mediums von Beispiel 39, wobei die maschinenlesbaren Befehle, wenn sie von einem Paketkaperschaltkreis mit Eingangs- und Ausgangsnetzwerkschnittstellen, die an die geschaltete Bus-Fabric gekoppelt sind, ausgeführt werden: durch den Paketkaperschaltkreis Pakete überwachen, die in die Eingangsschnittstelle strömen, durch den Paketkaperschaltkreis ermitteln, der auf eine Paketkapertabelle Bezug nimmt, dass ein Paket zu kapern ist, das gekaperte Pakets in einem Paketkaperpuffer speichern, gekaperte Pakete, die im Paketkaperpuffer gespeichert sind, durch den Paketkaperschaltkreis mit Zeilengeschwindigkeit verarbeiten, wobei das Verarbeiten ein resultierendes Datenpaket zu generieren hat, ein resultierendes Datenpaket generieren; und das resultierende Datenpaket zurück in einen Verkehrsstrom auszugeben, der durch die Eingangsschnittstelle tritt.
  • Beispiel 41 enthält den Gegenstand des beispielhaften Prozessors von Beispiel 1, wobei die Vielzahl von Beschleunigerkernen in einem oder mehreren einer Vielzahl von Prozessorkernen angeordnet sind, wobei jeder der Prozessorkerne enthält: einen Zwischenspeicher, der in Übereinstimmung mit einem Modified-Owned-Exclusive-Shared-Invalid-plus-Forward(MOESI+F)-Zwischenspeicherkohärenzprotokoll gesteuert wird, wobei Lesevorgänge in einen Arbeitsspeicher, wenn die Zwischenspeicherzeile in mindestens einem der Zwischenspeicher gültig ist, immer durch den mindestens einen der Zwischenspeicher bedient werden, anstatt von einem Arbeitsspeicherlesevorgang bedient zu werden, und wobei inkonsistente Zwischenspeicherzeilen nur dann in den Arbeitsspeicher zurückgeschrieben werden, wenn eine inkonsistente Zwischenspeicherzeile in einem modifizierten Zustand aufgrund einer Austauschrichtlinie geleert wird.
  • Beispiel 42 enthält den Gegenstand des beispielhaften Prozessors von Beispiel 41, wobei, wenn eine Zwischenspeicherzeile in einem Besitzzustand aufgrund einer Austauschrichtlinie geleert wird, die Zwischenspeicherzeile in den Besitzzustand in einem anderen Zwischenspeicher übergeht, wenn mehr als ein Zwischenspeicher eine Kopie der Zwischenspeicherzeile vor der Leerung aufgewiesen hat, oder in den modifizierten Zustand übergeht, wenn nur ein Zwischenspeicher eine Kopie der Zwischenspeicherzeile vor der Leerung aufgewiesen hat.
  • Beispiel 43 enthält den Gegenstand des beispielhaften Prozessors von Beispiel 41, wobei, wenn eine Zwischenspeicherzeile in einem Weiterleitungszustand aufgrund einer Austauschrichtlinie geleert wird, die Zwischenspeicherzeile in den Weiterleitungszustand in einem anderen Zwischenspeicher übergeht, wenn mehr als ein Zwischenspeicher eine Kopie der Zwischenspeicherzeile vor der Leerung aufgewiesen hat, oder in den exklusiven Zustand übergeht, wenn nur ein Zwischenspeicher eine Kopie der Zwischenspeicherzeile vor der Leerung aufgewiesen hat.
  • Beispiel 44 enthält den Gegenstand des beispielhaften Prozessors von Beispiel 41, ferner enthaltend einen Zwischenspeichersteuerschaltkreis, um Kohärenzdatenanforderungen unter der Vielzahl von Kernen zu überwachen und Leerungen und Übergänge in Zwischenspeicherzustände zu bewirken, wobei der Zwischenspeichersteuerschaltkreis eine Zwischenspeichertaganordnung umfasst, um Zwischenspeicherzustände von Zwischenspeicherzeilen in jedem der Zwischenspeicher der Vielzahl der Kerne zu speichern.

Claims (25)

  1. Prozessor, umfassend: eine Vielzahl von Beschleunigerkernen, die jeweils eine entsprechende Befehlssatzarchitektur (ISA) aufweisen; einen Abrufschaltkreis, um einen oder mehrere Befehle abzurufen, die einen der Beschleunigerkerne angeben; einen Decodierschaltkreis, um den einen oder die mehreren abgerufenen Befehle zu decodieren; und einen Erteilungsschaltkreis, um den einen oder die mehreren decodierten Befehle in die ISA zu übersetzen, die dem angegebenen Beschleunigerkern entspricht, den einen oder die mehreren übersetzten Befehle in ein Befehlspaket zu vereinigen und das Befehlspaket an den angegebenen Beschleunigerkern auszugeben; wobei die Vielzahl der Beschleunigerkerne eine Arbeitsspeicherengine (MENG), eine Kollektivengine (CENG), eine Warteschlangenengine (QENG) und eine Kettenverwaltungseinheit (CMU) enthält.
  2. Prozessor nach Anspruch 1, wobei jeder der Vielzahl der Beschleunigerkerne im Arbeitsspeicher auf einen Adressbereich abgebildet ist und wobei der eine oder die mehreren Befehle im Arbeitsspeicher abgebildete Eingabe-/Ausgabe(MMIO)-Befehle mit einer Adresse zur Angabe des einen Beschleunigerkerns sind.
  3. Prozessor nach Anspruch 1, ferner umfassend einen Ausführungsschaltkreis; wobei der Abrufschaltkreis ferner einen weiteren Befehl abruft, der keinen Beschleunigerkern angibt; wobei der eine oder die mehreren Befehle, die den einen Beschleunigerkern angeben, nicht blockierend sind; wobei der Decodierschaltkreis ferner den anderen abgerufenen Befehl zu decodieren hat; und wobei der Ausführungsschaltkreis den decodierten anderen Befehl auszuführen hat, ohne auf einen Abschluss der Ausführung des Befehlspakets zu warten.
  4. Prozessor nach einem der Ansprüche 1-3, wobei die ISA, die der MENG entspricht, duale Arbeitsspeicherbefehle enthält, wobei jeder der dualen Arbeitsspeicherbefehle einen von Dual_read_read, Dual_read_write, Dual_write_write, Dual_xchg_read, Dual_xchg_write, Dual_cmpxchg_read, Dual_cmpxchg_write, Dual_compare&read_read und Dual_compare&read_write umfasst.
  5. Prozessor nach einem der Ansprüche 1-3, wobei die ISA, die der MENG entspricht, einen Direktspeicherzugriffsbefehl (DMA-Befehl) enthält, der eine Quelle, ein Ziel, eine arithmetische Operation und eine Blockgröße angibt, wobei die MENG einen Datenblock in Übereinstimmung mit der Blockgröße von der angegebenen Quelle an das angegebene Ziel kopiert und wobei die MENG ferner die arithmetische Operation an jedem Datenelement des Datenblocks durchführt, bevor sie das resultierende Datenelement an das angegebene Ziel kopiert.
  6. Prozessor nach einem der Ansprüche 1-3, wobei die ISA, die der CENG entspricht, kollektive Operationen einschließlich Reduktionen, vollständiger Reduktionen (Reduktion-auf-alle), Broadcasts, Sammlungen, Streuungen, Barrieren und paralleler Präfixoperationen enthält.
  7. Prozessor nach einem der Ansprüche 1-3, wobei die QENG eine hardwareverwaltete Warteschlange mit einem beliebigen Warteschlangentyp umfasst und wobei die ISA, die der QENG entspricht, Befehle zum Hinzufügen von Daten zur Warteschlange und Entfernen von Daten aus der Warteschlange enthält und wobei der beliebige Warteschlangentyp einer von Last-in-First-out (LIFO), First-in-Last-Out (FILO) und First-in-First-out (FIFO) ist.
  8. Prozessor nach einem der Ansprüche 1-3, wobei eine Teilmenge des einen oder der mehreren Befehle ein Teil einer Kette ist und wobei die CMU eine Ausführung jedes verketteten Befehls bis zum Abschluss eines vorangehenden verketteten Befehls anhält, und wobei andere Befehle des einen oder der mehreren Befehle parallel ausgeführt werden können.
  9. Prozessor nach einem der Ansprüche 1-3, ferner umfassend eine geschaltete Bus-Fabric, um den Erteilungsschaltkreis und die Vielzahl von Beschleunigerkernen zu koppeln, wobei die geschaltete Bus-Fabric Pfade mit mehreren parallelen Spuren enthält und ein Ausmaß an Überlastung auf diesen überwacht.
  10. Prozessor nach Anspruch 9, der ferner Eingangs- und Ausgangsnetzwerkschnittstellen und einen Paketkaperschaltkreis enthält, um: zu ermitteln, ob jedes eingehende Paket an der Eingangsnetzwerkschnittstelle zu kapern ist, indem er eine im Befehlspaket enthaltene Adresse mit einer softwareprogrammierbaren Kaperzieladresse vergleicht; ein Befehlspaket, von dem ermittelt wird, dass es zu kapern ist, in einen Scratch-Zwischenspeicher des Kaperschaltkreises zu kopieren; und ein gespeichertes Paket durch eine Ausführungseinheit des Kaperschaltkreises zu verarbeiten, um eine lokale Analyse, Modifikation und Ablehnung von Paketen mit Zeilengeschwindigkeit durchzuführen.
  11. Prozessor nach einem der Ansprüche 1-3, wobei die Vielzahl von Beschleunigerkernen in einem oder mehreren einer Vielzahl von Prozessorkernen angeordnet sind, wobei jeder der Prozessorkerne umfasst: einen Zwischenspeicher, der in Übereinstimmung mit einem Modified-Owned-Exclusive-Shared-Invalid-plus-Forward(MOESI+F)-Zwischenspeicherkohärenzprotokoll gesteuert wird; wobei Lesevorgänge in einen Arbeitsspeicher, wenn die Zwischenspeicherzeile in mindestens einem der Zwischenspeicher gültig ist, immer von dem mindestens einen der Zwischenspeicher bedient werden, anstatt durch einen Arbeitsspeicherlesevorgang bedient zu werden; und wobei inkonsistente Zwischenspeicherzeilen nur dann in den Arbeitsspeicher zurückgeschrieben werden, wenn eine inkonsistente Zwischenspeicherzeile in einem modifizierten Zustand aufgrund einer Austauschrichtlinie geleert wird.
  12. Prozessor nach Anspruch 11, wobei, wenn eine Zwischenspeicherzeile in einem Besitzzustand aufgrund einer Austauschrichtlinie geleert wird, die Zwischenspeicherzeile in den Besitzzustand in einem anderen Zwischenspeicher übergeht, wenn mehr als ein Zwischenspeicher eine Kopie der Zwischenspeicherzeile vor der Leerung aufgewiesen hat, oder in den modifizierten Zustand übergeht, wenn nur ein Zwischenspeicher eine Kopie der Zwischenspeicherzeile vor der Leerung aufgewiesen hat.
  13. Prozessor nach Anspruch 11, wobei, wenn eine Zwischenspeicherzeile in einem Weiterleitungszustand aufgrund einer Austauschrichtlinie geleert wird, die Zwischenspeicherzeile in den Weiterleitungszustand in einem anderen Zwischenspeicher übergeht, wenn mehr als ein Zwischenspeicher eine Kopie der Zwischenspeicherzeile vor der Leerung aufgewiesen hat, oder in den exklusiven Zustand übergeht, wenn nur ein Zwischenspeicher eine Kopie der Zwischenspeicherzeile vor der Leerung aufgewiesen hat.
  14. Prozessor nach Anspruch 11, ferner umfassend einen Zwischenspeichersteuerschaltkreis, um Kohärenzdatenanforderungen unter der Vielzahl von Kernen zu überwachen und Leerungen und Übergänge in Zwischenspeicherzustände zu bewirken, wobei der Zwischenspeichersteuerschaltkreis eine Zwischenspeichertaganordnung umfasst, um Zwischenspeicherzustände von Zwischenspeicherzeilen in jedem der Zwischenspeicher der Vielzahl der Kerne zu speichern.
  15. System, umfassend: einen Arbeitsspeicher; eine Vielzahl von Beschleunigerkernen, die jeweils eine entsprechende Befehlssatzarchitektur (ISA) aufweisen; Mittel zum Abrufen eines oder mehrerer Befehle, die einen der Beschleunigerkerne angeben; Mittel zum Decodieren des einen oder der mehreren abgerufenen Befehle; Mittel zum Übersetzen des einen oder der mehreren decodierten Befehle in die ISA, die dem angegebenen Beschleunigerkern entspricht; Mittel zum Vereinigen des einen oder der mehreren übersetzten Befehle in ein Befehlspaket; und Mittel zum Ausgeben des Befehlspakets an den angegebenen Beschleunigerkern; wobei die Vielzahl der Beschleunigerkerne eine Arbeitsspeicherengine (MENG), eine Kollektivengine (CENG), eine Warteschlangenengine (QENG) und eine Kettenverwaltungseinheit (CMU) enthält.
  16. System nach Anspruch 15: wobei jeder der Vielzahl der Beschleunigerkerne im Arbeitsspeicher auf einen Adressbereich abgebildet ist und wobei der eine oder die mehreren Befehle im Arbeitsspeicher abgebildete Eingabe-/Ausgabe(MMIO)-Befehle mit einer Adresse zur Angabe des einen Beschleunigerkerns sind; wobei das Mittel zum Abrufen ferner einen weiteren Befehl abruft, der keinen Beschleunigerkern angibt; wobei der eine oder die mehreren Befehle, die den einen Beschleunigerkern angeben, nicht blockierend sind; wobei das Mittel zum Decodieren ferner den anderen abgerufenen Befehl zu decodieren hat; wobei der Ausführungsschaltkreis den decodierten anderen Befehl auszuführen hat, ohne auf einen Abschluss der Ausführung des Befehlspakets zu warten; wobei die ISA, die der MENG entspricht, duale Arbeitsspeicherbefehle enthält, wobei jeder der dualen Arbeitsspeicherbefehle einen von Dual_read_read, Dual_read_write, Dual_write_write, Dual_xchg_read, Dual_xchg_write, Dual_cmpxchg_read, Dual_cmpxchg_write, Dual compare&read_read und Dual_compare&read_write umfasst; wobei die ISA, die der MENG entspricht, einen Direktspeicherzugriffsbefehl (DMA-Befehl) enthält, der eine Quelle, ein Ziel, eine arithmetische Operation und eine Blockgröße angibt, wobei die MENG einen Datenblock in Übereinstimmung mit der Blockgröße von der angegebenen Quelle an das angegebene Ziel kopiert und wobei die MENG ferner die arithmetische Operation an jedem Datenelement des Datenblocks durchführt, bevor sie das resultierende Datenelement an das angegebene Ziel kopiert; wobei die ISA, die der CENG entspricht, kollektive Operationen einschließlich Reduktionen, vollständiger Reduktionen (Reduktion-auf-alle), Broadcasts, Sammlungen, Streuungen, Barrieren und paralleler Präfixoperationen enthält; wobei die QENG eine hardwareverwaltete Warteschlange mit einem beliebigen Warteschlangentyp umfasst und wobei die ISA, die der QENG entspricht, Befehle zum Hinzufügen von Daten zur Warteschlange und Entfernen von Daten aus der Warteschlange enthält und wobei der beliebige Warteschlangentyp einer von Last-in-First-out (LIFO), First-in-Last-Out (FILO) und First-in-First-out (FIFO) ist; und wobei eine Teilmenge des einen oder der mehreren Befehle ein Teil einer Kette ist und wobei die CMU eine Ausführung jedes verketteten Befehls bis zum Abschluss eines vorangehenden verketteten Befehls anhält, und wobei andere Befehle des einen oder der mehreren Befehle parallel ausgeführt werden können.
  17. System nach Anspruch 15, das ferner Folgendes umfasst: eine geschaltete Bus-Fabric, um den Erteilungsschaltkreis und die Vielzahl von Beschleunigerkernen zu koppeln, wobei die geschaltete Bus-Fabric Pfade mit mehreren parallelen Spuren enthält und ein Ausmaß an Überlastung auf diesen überwacht; Eingangs- und Ausgangsnetzwerkschnittstellen; und einen Paketkaperschaltkreis, um: zu ermitteln, ob jedes eingehende Befehlspaket an der Eingangsnetzwerkschnittstelle zu kapern ist, indem er eine im Befehlspaket enthaltene Adresse mit einer softwareprogrammierbaren Kaperzieladresse vergleicht; ein Befehlspaket, von dem ermittelt wird, dass es zu kapern ist, in einen Scratch-Zwischenspeicher des Kaperschaltkreises zu kopieren; und ein gespeichertes Paket durch eine Ausführungseinheit des Kaperschaltkreises zu verarbeiten, um eine lokale Analyse, Modifikation und Ablehnung von Paketen mit Zeilengeschwindigkeit durchzuführen.
  18. Verfahren zum Ausführen von Befehlen unter Verwendung eines Ausführungsschaltkreises und einer Vielzahl von Beschleunigerkernen, die jeweils eine entsprechende Befehlssatzarchitektur (ISA) aufweisen, wobei das Verfahren umfasst: Abrufen, durch einen Abrufschaltkreis, eines oder mehrerer Befehle, die einen der Beschleunigerkerne angeben; Decodieren, unter Verwendung eines Decodierschaltkreises, des einen oder der mehreren abgerufenen Befehle; Übersetzen, unter Verwendung eines Erteilungsschaltkreises, des einen oder der mehreren decodierten Befehle in die ISA, die dem angegebenen Beschleunigerkern entspricht; Vereinigen, durch den Erteilungsschaltkreis, des einen oder der mehreren übersetzten Befehle in ein Befehlspaket; und Ausgeben des Befehlspakets an den angegebenen Beschleunigerkern; wobei die Vielzahl der Beschleunigerkerne eine Arbeitsspeicherengine (MENG), eine Kollektivengine (CENG), eine Warteschlangenengine (QENG) und eine Kettenverwaltungseinheit (CMU) enthält.
  19. Verfahren nach Anspruch 18, wobei jeder der Vielzahl der Beschleunigerkerne im Arbeitsspeicher auf einen Adressbereich abgebildet ist und wobei der eine oder die mehreren Befehle im Arbeitsspeicher abgebildete Eingabe-/Ausgabe(MMIO)-Befehle mit einer Adresse zur Angabe des einen Beschleunigerkerns sind; wobei das Mittel zum Abrufen ferner einen weiteren Befehl abruft, der keinen Beschleunigerkern angibt; wobei der eine oder die mehreren Befehle, die den einen Beschleunigerkern angeben, nicht blockierend sind; wobei das Mittel zum Decodieren ferner den anderen abgerufenen Befehl zu decodieren hat; wobei der Ausführungsschaltkreis den decodierten anderen Befehl auszuführen hat, ohne auf einen Abschluss der Ausführung des Befehlspakets zu warten; wobei die ISA, die der MENG entspricht, duale Arbeitsspeicherbefehle enthält, wobei jeder der dualen Arbeitsspeicherbefehle einen von Dual_read_read, Dual_read_write, Dual_write_write, Dual_xchg_read, Dual_xchg_write, Dual_cmpxchg_read, Dual_cmpxchg_write, Dual compare&read_read und Dual_compare&read_write umfasst; wobei die ISA, die der MENG entspricht, einen Direktspeicherzugriffsbefehl (DMA-Befehl) enthält, der eine Quelle, ein Ziel, eine arithmetische Operation und eine Blockgröße angibt, wobei die MENG einen Datenblock in Übereinstimmung mit der Blockgröße von der angegebenen Quelle an das angegebene Ziel kopiert und wobei die MENG ferner die arithmetische Operation an jedem Datenelement des Datenblocks durchführt, bevor sie das resultierende Datenelement an das angegebene Ziel kopiert; wobei die ISA, die der CENG entspricht, kollektive Operationen einschließlich Reduktionen, vollständiger Reduktionen (Reduktion-auf-alle), Broadcasts, Sammlungen, Streuungen, Barrieren und paralleler Präfixoperationen enthält; wobei die QENG eine hardwareverwaltete Warteschlange mit einem beliebigen Warteschlangentyp umfasst und wobei die ISA, die der QENG entspricht, Befehle zum Hinzufügen von Daten zur Warteschlange und Entfernen von Daten aus der Warteschlange enthält und wobei der beliebige Warteschlangentyp einer von Last-in-First-out (LIFO), First-in-Last-Out (FILO) und First-in-First-out (FIFO) ist; und wobei eine Teilmenge des einen oder der mehreren Befehle ein Teil einer Kette ist und wobei die CMU eine Ausführung jedes verketteten Befehls bis zum Abschluss eines vorangehenden verketteten Befehls anhält, und wobei andere Befehle des einen oder der mehreren Befehle parallel ausgeführt werden können.
  20. Verfahren nach Anspruch 18, ferner umfassend ein Verwenden einer geschalteten Bus-Fabric, um den Erteilungsschaltkreis und die Vielzahl von Beschleunigerkernen zu koppeln, wobei die geschaltete Bus-Fabric Pfade mit mehreren parallelen Spuren enthält und ein Ausmaß an Überlastung auf diesen überwacht.
  21. Verfahren nach Anspruch 20, das ferner einen Paketkaperschaltkreis mit Eingangs- und Ausgangsnetzwerkschnittstellen enthält, die an die geschaltete Bus-Fabric gekoppelt sind, und wobei das Verfahren ferner enthält: Überwachen von Paketen, die in die Eingangsschnittstelle strömen, durch den Paketkaperschaltkreis; Ermitteln, durch einen Paketkaperschaltkreis, der auf eine Paketkapertabelle Bezug nimmt, dass ein Paket zu kapern ist; Speichern des gekaperten Pakets in einen Paketkaperpuffer; lokales Verarbeiten von gekaperten Paketen, die im Paketkaperpuffer gespeichert sind, durch den Paketkaperschaltkreis mit Zeilengeschwindigkeit, wobei die Verarbeitung ein resultierendes Datenpaket zu generieren hat; Generieren eines resultierenden Datenpakets; und Ausgeben des resultierenden Datenpakets zurück in einen Verkehrsstrom, der durch die Eingangsschnittstelle tritt.
  22. Nichtflüchtiges maschinenlesbares Medium, das Befehle enthält, die, wenn sie von einem Ausführungsschaltkreis ausgeführt werden, der an eine Vielzahl von Beschleunigerkernen gekoppelt ist, die jeweils eine entsprechende Befehlssatzarchitektur (ISA) aufweisen, bewirken, dass der Ausführungsschaltkreis: durch einen Abrufschaltkreis einen oder mehrere Befehle abruft, die einen der Beschleunigerkerne angeben; unter Verwendung eines Decodierschaltkreises den einen oder die mehreren abgerufenen Befehle decodiert; unter Verwendung eines Erteilungsschaltkreises den einen oder die mehreren decodierten Befehle in die ISA übersetzt, die dem angegebenen Beschleunigerkern entspricht; durch den Erteilungsschaltkreis den einen oder die mehreren übersetzten Befehle in ein Befehlspaket vereinigt; und das Befehlspaket an den angegebenen Beschleunigerkern ausgibt; wobei die Vielzahl der Beschleunigerkerne eine Arbeitsspeicherengine (MENG), eine Kollektivengine (CENG), eine Warteschlangenengine (QENG) und eine Kettenverwaltungseinheit (CMU) enthält.
  23. Nicht transitorisches maschinenlesbares Medium nach Anspruch 22, wobei jeder der Vielzahl der Beschleunigerkerne im Arbeitsspeicher auf einen Adressbereich abgebildet ist und wobei der eine oder die mehreren Befehle im Arbeitsspeicher abgebildete Eingabe-/Ausgabe(MMIO)-Befehle mit einer Adresse zur Angabe des einen Beschleunigerkerns sind; wobei das Mittel zum Abrufen ferner einen weiteren Befehl abruft, der keinen Beschleunigerkern angibt; wobei der eine oder die mehreren Befehle, die den einen Beschleunigerkern angeben, nicht blockierend sind; wobei das Mittel zum Decodieren ferner den anderen abgerufenen Befehl zu decodieren hat; wobei der Ausführungsschaltkreis den decodierten anderen Befehl auszuführen hat, ohne auf einen Abschluss der Ausführung des Befehlspakets zu warten; wobei die ISA, die der MENG entspricht, duale Arbeitsspeicherbefehle enthält, wobei jeder der dualen Arbeitsspeicherbefehle einen von Dual_read_read, Dual_read_write, Dual_write_write, Dual_xchg_read, Dual_xchg_write, Dual_cmpxchg_read, Dual_cmpxchg_write, Dual_compare&read_read und Dual_compare&read_write umfasst; wobei die ISA, die der MENG entspricht, einen Direktspeicherzugriffsbefehl (DMA-Befehl) enthält, der eine Quelle, ein Ziel, eine arithmetische Operation und eine Blockgröße angibt, wobei die MENG einen Datenblock in Übereinstimmung mit der Blockgröße von der angegebenen Quelle an das angegebene Ziel kopiert und wobei die MENG ferner die arithmetische Operation an jedem Datenelement des Datenblocks durchführt, bevor sie das resultierende Datenelement an das angegebene Ziel kopiert; wobei die ISA, die der CENG entspricht, kollektive Operationen einschließlich Reduktionen, vollständiger Reduktionen (Reduktion-auf-alle), Broadcasts, Sammlungen, Streuungen, Barrieren und paralleler Präfixoperationen enthält; wobei die QENG eine hardwareverwaltete Warteschlange mit einem beliebigen Warteschlangentyp umfasst und wobei die ISA, die der QENG entspricht, Befehle zum Hinzufügen von Daten zur Warteschlange und Entfernen von Daten aus der Warteschlange enthält und wobei der beliebige Warteschlangentyp einer von Last-in-First-out (LIFO), First-in-Last-Out (FILO) und First-in-First-out (FIFO) ist; und wobei eine Teilmenge des einen oder der mehreren Befehle ein Teil einer Kette ist und wobei die CMU eine Ausführung jedes verketteten Befehls bis zum Abschluss eines vorangehenden verketteten Befehls anhält, und wobei andere Befehle des einen oder der mehreren Befehle parallel ausgeführt werden können.
  24. Nichtflüchtiges maschinenlesbares Medium nach Anspruch 22, wobei der maschinenlesbare Code ferner bewirkt, dass der Ausführungsschaltkreis eine geschaltete Bus-Fabric verwendet, um den Erteilungsschaltkreis und die Vielzahl von Beschleunigerkernen zu koppeln, wobei die geschaltete Bus-Fabric Pfade mit mehreren parallelen Spuren umfasst und ein Ausmaß an Überlastung auf diesen überwacht.
  25. Nichtflüchtiges maschinenlesbares Medium nach Anspruch 24, wobei die maschinenlesbaren Befehle, wenn sie von einem Paketkaperschaltkreis mit Eingangs- und Ausgangsnetzwerkschnittstellen, die an die geschaltete Bus-Fabric gekoppelt sind, ausgeführt werden, bewirken, dass der Ausführungsschaltkreis: Pakete, die in die Eingangsschnittstelle strömen, durch den Paketkaperschaltkreis überwacht; ermittelt, durch den Paketkaperschaltkreis, der auf eine Paketkapertabelle Bezug nimmt, ein Paket zu kapern; das gekaperte Paket in einen Paketkaperpuffer speichert; gekaperte Pakete, die im Paketkaperpuffer gespeichert sind, lokal durch den Paketkaperschaltkreis mit Zeilengeschwindigkeit verarbeitet, wobei die Verarbeitung ein resultierendes Datenpaket zu generieren hat; ein resultierendes Datenpaket generiert; und das resultierende Datenpaket zurück in einen Verkehrsstrom ausgibt, der durch die Eingangsschnittstelle tritt.
DE102019104394.8A 2018-03-29 2019-02-21 Befehlssatzarchitektur zum ermöglichen von energieeffizientem rechnen für exascalearchitekturen Pending DE102019104394A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/940,768 US20190303159A1 (en) 2018-03-29 2018-03-29 Instruction set architecture to facilitate energy-efficient computing for exascale architectures
US15/940,768 2018-03-29

Publications (1)

Publication Number Publication Date
DE102019104394A1 true DE102019104394A1 (de) 2019-10-02

Family

ID=67910242

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019104394.8A Pending DE102019104394A1 (de) 2018-03-29 2019-02-21 Befehlssatzarchitektur zum ermöglichen von energieeffizientem rechnen für exascalearchitekturen

Country Status (3)

Country Link
US (1) US20190303159A1 (de)
CN (1) CN110321164A (de)
DE (1) DE102019104394A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113885945A (zh) * 2021-08-30 2022-01-04 山东云海国创云计算装备产业创新中心有限公司 一种计算加速方法、设备以及介质

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10802995B2 (en) * 2018-07-26 2020-10-13 Xilinx, Inc. Unified address space for multiple hardware accelerators using dedicated low latency links
CN111782385A (zh) * 2019-04-04 2020-10-16 伊姆西Ip控股有限责任公司 用于处理任务的方法、电子设备和计算机程序产品
US11106584B2 (en) * 2019-05-24 2021-08-31 Texas Instmments Incorporated Hardware coherence for memory controller
US20200401412A1 (en) * 2019-06-24 2020-12-24 Intel Corporation Hardware support for dual-memory atomic operations
US11038799B2 (en) * 2019-07-19 2021-06-15 Cisco Technology, Inc. Per-flow queue management in a deterministic network switch based on deterministically transmitting newest-received packet instead of queued packet
CN110806899B (zh) * 2019-11-01 2021-08-24 西安微电子技术研究所 一种基于指令扩展的流水线紧耦合加速器接口结构
CN111198828A (zh) * 2019-12-25 2020-05-26 晶晨半导体（深圳）有限公司 多存储介质并存的配置方法、装置和系统
US11386020B1 (en) 2020-03-03 2022-07-12 Xilinx, Inc. Programmable device having a data processing engine (DPE) array
JP7255548B2 (ja) * 2020-04-28 2023-04-11 トヨタ自動車株式会社 ファンカップリング装置の制御装置
US20220100575A1 (en) * 2020-09-25 2022-03-31 Huawei Technologies Co., Ltd. Method and apparatus for a configurable hardware accelerator
CN114428638A (zh) 2020-10-29 2022-05-03 平头哥(上海)半导体技术有限公司 指令发射单元、指令执行单元、相关装置和方法
US11144238B1 (en) * 2021-01-05 2021-10-12 Next Silicon Ltd Background processing during remote memory access
KR20220124551A (ko) * 2021-03-03 2022-09-14 삼성전자주식회사 이종 하드웨어 타입의 가속기들을 포함한 전자 장치
CN112988871B (zh) * 2021-03-23 2021-11-16 山东和同信息科技股份有限公司 针对大数据中mpi数据接口的信息压缩传输方法
US11531555B2 (en) 2021-03-26 2022-12-20 International Business Machines Corporation Selective pruning of a system configuration model for system reconfigurations
US11609878B2 (en) 2021-05-13 2023-03-21 Apple Inc. Programmed input/output message control circuit
US11765092B2 (en) * 2021-06-22 2023-09-19 Hewlett Packard Enterprise Development Lp System and method for scaling data path processing with offload engines in control plane
CN114968362B (zh) * 2022-06-10 2024-04-23 清华大学 异构融合计算指令集以及使用方法
CN116360798B (zh) * 2023-06-02 2023-08-18 太初(无锡)电子科技有限公司 一种针对异构芯片的异构可执行文件的反汇编方法
CN117931204A (zh) * 2024-03-19 2024-04-26 英特尔(中国)研究中心有限公司 用于跨isa实现内建函数api转换的方法和装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113885945A (zh) * 2021-08-30 2022-01-04 山东云海国创云计算装备产业创新中心有限公司 一种计算加速方法、设备以及介质
CN113885945B (zh) * 2021-08-30 2023-05-16 山东云海国创云计算装备产业创新中心有限公司 一种计算加速方法、设备以及介质

Also Published As

Publication number Publication date
CN110321164A (zh) 2019-10-11
US20190303159A1 (en) 2019-10-03

Similar Documents

Publication Publication Date Title
DE102019104394A1 (de) Befehlssatzarchitektur zum ermöglichen von energieeffizientem rechnen für exascalearchitekturen
DE112012007063B4 (de) Zusammenfügen von benachbarten Sammel-/Streuoperationen
DE102018130441A1 (de) Einrichtung, Verfahren und Systeme mit konfigurierbarem räumlichem Beschleuniger
DE102018005169A1 (de) Prozessoren und verfahren mit konfigurierbaren netzwerkbasierten datenflussoperatorschaltungen
DE102015007571B4 (de) Keine-lokalität-hinweis-vektor-speicherzugriff-prozessoren, -verfahren, -systeme und -befehle
DE102018126650A1 (de) Einrichtung, verfahren und systeme für datenspeicherkonsistenz in einem konfigurierbaren räumlichen beschleuniger
DE102018126150A1 (de) Einrichtung, verfahren und systeme für multicast in einem konfigurierbaren räumlichen beschleuniger
DE102018005172A1 (de) Prozessoren, verfahren und systeme mit einem konfigurierbaren räumlichen beschleuniger
DE102018005216A1 (de) Prozessoren, Verfahren und Systeme für einen konfigurierbaren, räumlichen Beschleuniger mit Transaktions- und Wiederholungsmerkmalen
DE102018006791A1 (de) Prozessoren, Verfahren und Systeme mit einem konfigurierbaren räumlichen Beschleuniger mit einem Sequenzer-Datenflussoperator
DE112016007566T5 (de) Systeme, Verfahren und Vorrichtungen zur heterogenen Berechnung
DE102018005181A1 (de) Prozessoren, Verfahren und Systeme für einen konfigurierbaren, räumlichen Beschleuniger mit Leistungs-, Richtigkeits- und Energiereduktionsmerkmalen
DE102018006735A1 (de) Prozessoren und Verfahren für konfigurierbares Clock-Gating in einem räumlichen Array
DE112013005188B4 (de) Prozessor und vefrahren zur vektorisierung von zusammengeführten, mehrfach geschachtelten schleifen
DE112017001804T5 (de) Vorrichtung und Verfahren für träge synchrone Seitentabellenaktualisierungen mit geringem Aufwand
DE112012007119T5 (de) Threadmigration-Unterstützung für Kerne unterschiedlicher Architektur
DE102018000886A1 (de) Virtuelle Maschinenkommunikation auf Hardware-Basis
DE102018005105A1 (de) Befehle für entfernte atomare operationen
DE102015006863A1 (de) Befehle und Logik zum Unterbrechen und Wiederaufnehmen von Paging in Secure Enclaves
DE102014003790A1 (de) Parallelvorrichtung für hochkomprimierte Hochgeschwindigkeits-LZ77-Tokenisierung und Huffman-Codierung für Deflate-Komprimierung
DE112013005338T5 (de) Vorrichtung und Verfahren für Beschleunigeraufruf mit geringer Latenz
DE112016007516T5 (de) Vorrichtungen und verfahren für eine prozessorarchitektur
DE112012007088B4 (de) Vorrichtung, verfahren und system mit einem befehl zum reduzieren von elementen in einem vektorregister mit einem schrittweisem zugriffsmuster
DE102014003706A1 (de) BEREICHSBEGRENZTE VEKTORSPEICHERZUGRIFFSINSTRUKTIONEN, PROZESSOREN, VERFAHREN und SYSTEME
DE102018006797A1 (de) Kohärente Speichereinrichtungen über PCIe