DE102019112352A1 - Registerdateien in einem multithread-prozessor - Google Patents

Registerdateien in einem multithread-prozessor Download PDF

Info

Publication number
DE102019112352A1
DE102019112352A1 DE102019112352.6A DE102019112352A DE102019112352A1 DE 102019112352 A1 DE102019112352 A1 DE 102019112352A1 DE 102019112352 A DE102019112352 A DE 102019112352A DE 102019112352 A1 DE102019112352 A1 DE 102019112352A1
Authority
DE
Germany
Prior art keywords
instruction
registers
arithmetic
processor
thread
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
DE102019112352.6A
Other languages
English (en)
Inventor
Alan Graham Alexander
Simon Christian Knowles
Mrudula Gore
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.)
Graphcore Ltd
Original Assignee
Graphcore Ltd
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 Graphcore Ltd filed Critical Graphcore Ltd
Publication of DE102019112352A1 publication Critical patent/DE102019112352A1/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/46—Multiprogramming arrangements
    • G06F9/461—Saving or restoring of program or task context
    • 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/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/3001—Arithmetic 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/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/3009—Thread 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/30098—Register arrangements
    • G06F9/3012—Organisation of register space, e.g. banked or distributed register file
    • G06F9/30123—Organisation of register space, e.g. banked or distributed register file according to context, e.g. thread buffers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/3012—Organisation of register space, e.g. banked or distributed register file
    • G06F9/3013—Organisation of register space, e.g. banked or distributed register file according to data content, e.g. floating-point registers, address registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/3016—Decoding the operand specifier, e.g. specifier format
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/34—Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes
    • G06F9/345—Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes of multiple operands or results
    • G06F9/3455—Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes of multiple operands or results using stride
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/461—Saving or restoring of program or task context
    • G06F9/462—Saving or restoring of program or task context with multiple register sets
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/06—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons
    • G06N3/063—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons using electronic means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/084—Backpropagation, e.g. using gradient descent

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biomedical Technology (AREA)
  • Biophysics (AREA)
  • Computing Systems (AREA)
  • Artificial Intelligence (AREA)
  • General Health & Medical Sciences (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Molecular Biology (AREA)
  • Multimedia (AREA)
  • Neurology (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Executing Machine-Instructions (AREA)
  • Advance Control (AREA)

Abstract

Ein Prozessor weist eine Barrelthread-Ausführungseinheit zum Ausführen von gleichzeitigen Threads und eine oder mehrere Registerdateien mit einem jeweiligen Satz von Kontextregistern für jeden gleichzeitigen Thread auf. Eine der Registerdateien weist ferner einen Satz von gemeinsam benutzten Gewichtungsregistern auf, die manchen oder allen der gleichzeitigen Threads gemeinsam sind. Die im Befehlssatz des Prozessors definierten Befehlstypen enthalten einen arithmetischen Befehl mit Operanden, die eine Quelle und ein Ziel aus einem jeweiligen Satz von arithmetischen Registern des Threads bestimmen, in dem der arithmetische Befehl ausgeführt wird. Die Ausführungseinheit ist ausgestaltet, um als Reaktion auf den Opcode des arithmetischen Befehls einen Vorgang mit einem Multiplizieren einer Eingabe von der Quelle mit wenigstens einer der Gewichtungen aus wenigstens einem der gemeinsam benutzten Gewichtungsregister durchzuführen und ein Ergebnis in das Ziel zu setzen.

Description

  • Technisches Gebiet
  • Die vorliegende Offenbarung betrifft eine Anordnung von Registerdateien zur Verwendung durch in einem Multithread-Prozessor ausgeführte Maschinencodebefehle.
  • Hintergrund
  • Es gab ein steigendes Interesse an der Entwicklung von Prozessoren für spezielle Anwendungen, wie beispielsweise Grafikprozessoren (GPUs) und digitalen Signalprozessoren (DSPs). Eine andere Art von anwendungsspezifischem Prozessor, der kürzlich Interesse geweckt hat, ist einer, der Maschinenintelligenzanwendungen gewidmet ist, vom Anmelder „IPU“ (Intelligenzprozessor) genannt. Diese können zum Beispiel eingesetzt werden als Beschleunigungsprozessoren zum Durchführen einer durch einen Host zugeteilten Arbeit, beispielsweise zum Trainieren oder Unterstützen beim Trainieren eines Wissensmodells, wie beispielsweise eines neuronalen Netzes, oder zum Durchführen oder Unterstützen beim Durchführen von Vorhersagen oder Schlussfolgerungen basierend auf einem solchen Modell.
  • Ein Maschinenintelligenzalgorithmus beruht auf dem Durchführen iterativer Updates zu einem „Wissensmodell“, das durch eine Grafik aus mehreren miteinander verbundenen Knoten dargestellt werden kann. Jeder Knoten stellt eine Funktion seiner Eingaben dar. Manche Knoten empfangen die Eingaben an die Grafik und manche empfangen Eingaben von einem oder mehreren anderen Knoten, während die Ausgabe mancher Knoten die Eingaben anderer Knoten bildet und die Ausgabe mancher Knoten die Ausgabe der Grafik bereitstellt (und in manchen Fällen ein bestimmter Knoten sogar alles davon haben kann: Eingaben in die Grafik, Ausgaben von der Grafik und Verbindungen mit anderen Knoten). Ferner wird die Funktion an jedem Knoten durch einen oder mehrere entsprechende Parameter, z.B. Gewichtungen, parametrisiert. Während einer Lernstufe ist es das Ziel, basierend auf einem Satz von empirischen Eingangsdaten Werte für die verschiedenen Parameter zu finden, sodass die Grafik insgesamt eine gewünschte Ausgabe für einen Bereich möglicher Eingaben erzeugt. In der Technik sind hierfür verschiedene Algorithmen bekannt, wie beispielsweise ein Back-Propagation-Algorithmus basierend auf einem stochastischen Gradientenabfall. Die Parameter werden über mehrere Iterationen basierend auf den Eingangsdaten allmählich abgestimmt, um ihre Fehler zu vermindern, und so konvergiert die Grafik zu einer Lösung. In einer anschließenden Stufe kann das gelernte Modell dann benutzt werden, um für einen gegebenen speziellen Satz von Eingaben Vorhersagen für Ausgaben zu machen oder für gegebenen speziellen Satz von Ausgaben Schlussfolgerungen bezüglich der Eingaben (Ursachen) zu machen.
  • Ein für Maschinenintelligenzanwendungen ausgebildeter Prozessor kann dedizierte Befehle in seinem Befehlssatz zum Durchführen von arithmetischen Vorgängen enthalten, die üblicherweise in Maschinenintelligenzanwendungen verwendet werden (der Befehlssatz ist der Fundamentalsatz von Maschinencodebefehlstypen, für welche die Ausführungseinheit des Prozessors ausgestaltet ist, sie zu erkennen, wobei jeder Typ durch einen entsprechenden Opcode und null oder mehr Operanden definiert ist). Zum Beispiel ist ein üblicher Vorgang, der in Maschinenintelligenzanwendungen wie beispielsweise neuronalen Netzen erforderlich ist, die Faltung eines Kernels über einen Satz von Eingangsdaten, wobei der Kernel die Gewichtungen eines Knotens im neuronalen Netz darstellt. Um die Faltung eines signifikant großen Kernels über den Daten durchzuführen, kann die Faltung in mehrere Vektor- oder Matrixprodukte untergliedert werden, die jeweils eine Teilsumme ausgeben, die mit der Ausgabe der folgenden Produkte zu akkumulieren ist. Es existieren bereits Prozessoren, die in ihrem Befehlssatz arithmetische Befehle enthalten, die dem Durchführen von Vorgängen des Vektor- und Matrixmultiplikationstyps zur Verwendung beim Durchführen von Faltungen gewidmet sind.
  • Zusammenfassung
  • Ein Prozessor kann auch eine Unterstützung für eine gleichzeitige Ausführung mehrerer Programm-Threads bereitstellen. Diese Unterstützung weist typischerweise einen jeweiligen Satz von Kontextregistern für jeden Thread auf, wobei jeder Satz verwendet wird, um den Programmstatus (den „Kontext“) eines jeweiligen von mehreren gleichzeitig auszuführenden Threads hält. Der in den Kontextregistern eines bestimmten Threads gehaltene Programmstatus weist typischerweise einen Programmzähler für diesen Thread, ein oder mehrere Steuerstatusregister, die einen Status des Threads (z.B. pausiert, laufend, etc.) protokollieren, und mehrere Operandenregister einschließlich Register arithmetischer Operanden zum vorübergehenden Halten von Werten, gemäß denen bearbeitet werden soll und die durch arithmetische Befehle des jeweiligen Threads ausgegeben werden, auf. Die verschiedenen gleichzeitigen Threads werden durch eine gemeinsame Ausführungspipeline vorübergehend in unterschiedlichen Ausführungszeitfenstern verschachtelt, wobei jedes Fenster nur von den Registern eines anderen der Sätze von Kontextregistern Gebrauch macht. Herkömmlicherweise weist jeder Thread seinen eigenen jeweiligen Satz von Registern arithmetischer Operanden in einer separaten arithmetischen Registerdatei für jeden Thread auf. Wenn ein Befehl als Teil eines bestimmten Threads ausgeführt wird, ist es selbstverständlich, dass er immer die Register arithmetischer Operanden in der arithmetischen Registerdatei dieses speziellen Threads benutzt.
  • Es ist hier erkannt, dass Anwendungen auftreten können, bei denen Threads tatsächlich gemäß manchen derselben Operandenwerte aber manchen anderen Operanden, die für den einzelnen Thread spezifisch sind, arbeiten. Ein Beispiel wäre eine Vektor- oder Matrixmultiplikation, die als Teil einer Faltung durchgeführt wird, wobei der Befehl in jedem Thread einen gemeinsamen Gewichtungssatz (von den Threads gemeinsam benutzt) mit Eingangsdaten multipliziert, die für den einzelnen Thread spezifisch sind. Ein besonderes Beispiel hiervon kann in einem neuronalen Faltungsnetz stattfinden, in dem viele Knoten tatsächlich die gleichen Gewichtungen aber mit verschiedenen Verbindungen aufweisen. Man betrachte zum Beispiel ein Szenario, in dem jeder Thread ausgestaltet ist, um die Verarbeitung eines anderen jeweiligen Knotens im neuronalen Netz durchzuführen, wie beispielsweise eine Faltung eines gemeinsamen Kernels von Gewichtungen mit jeweiligen Eingangsdaten, um ein bestimmtes Merkmal zu erfassen. In solchen Szenarien wäre es vorteilhaft, einen Mechanismus vorzusehen, der es einem bestimmten arithmetischen Befehl erlaubt, gemäß einer Kombination eines oder mehrerer gemeinsamer Gewichtungsoperanden, die von den Threads gemeinsam benutzt werden, und eines oder mehrerer Operanden, die für den einzelnen jeweiligen Thread spezifisch sind, zu arbeiten. Das Thema ist keineswegs für neuronale Netze spezifisch und kann in irgendeiner Anwendung auftreten, die schließlich manche gemeinsam benutzten Operandenwerte und manche thread-spezifischen Operanden verwendet.
  • Gemäß einem hier offenbarten Aspekt ist ein Prozessor vorgesehen, aufweisend: eine oder mehrere Registerdateien; und eine Ausführungseinheit, die ausgestaltet ist, um Instanzen von in einem Befehls-satz definierten Befehlstypen auszuführen, wobei jeder Befehl in dem Befehlssatz aus einem Opcode und einem oder mehreren Operanden besteht. Die Ausführungseinheit ist eine Barrelthread-Ausführungseinheit ist, die ausgestaltet ist, um mehrere gleichzeitige Threads jeweils in einem anderen einer Wiederholungssequenz von verschachtelten Zeitfenstern auszuführen, und die eine oder mehreren Registerdateien weisen für jeden der gleichzeitigen Threads einen entsprechenden Satz von Kontextregistern auf, die ausgebildet sind, um einen Programmstatus des jeweiligen Threads zu halten, wobei jeder Satz von Kontextregistern einen entsprechenden Satz von Registern arithmetischer Operanden zur Verwendung durch den jeweiligen Thread aufweist. Eine der einen oder mehreren Registerdateien weist ferner einen Satz von gemeinsam benutzten Gewichtungsregistern auf, die manchen oder allen der gleichzeitigen Threads gemeinsam sind. Die im Befehlssatz definierten Befehlstypen enthalten einen arithmetischen Befehl mit Operanden, die eine Quelle und ein Ziel aus dem jeweiligen Satz von arithmetischen Registern des Threads bestimmen, in dem der arithmetische Befehl ausgeführt wird. Die Ausführungseinheit ist ausgestaltet, um als Reaktion auf den Opcode des arithmetischen Befehls einen Vorgang mit einem Multiplizieren einer Eingabe von der Quelle mit wenigstens einer der Gewichtungen aus wenigstens einem der gemeinsam benutzten Gewichtungsregister durchzuführen und ein Ergebnis in das Ziel zu setzen.
  • In Ausführungsformen kann das wenigstens eine der gemeinsam benutzten Gewichtungsregister aus dem Opcode des arithmetischen Befehls impliziert sein und nicht durch irgendeinen Operanden des arithmetischen Befehls bestimmt werden.
  • In Ausführungsformen kann der arithmetische Befehl einen weiteren Operanden nehmen, der wenigstens eines der gemeinsamen benutzten Gewichtungsregister aus dem Satz von gemeinsam benutzten Gewichtungsregistern bestimmt.
  • In Ausführungsformen kann die Eingabe einen Vektor aufweisen und kann die Multiplikation ein Skalarprodukt der Eingabe mit einem Vektor von Gewichtungen aus den gemeinsam benutzten Gewichtungsregistern aufweisen.
  • In Ausführungsformen kann das wenigstens eine der gemeinsam benutzten Gewichtungsregister einen Teilsatz der gemeinsam benutzten Gewichtungsregister von mehreren Teilsätzen aufweisen, wobei jeder Teilsatz einen jeweiligen Gewichtungsvektor hält; und der weitere Operand kann auswählen, aus welchem Teilsatz der Gewichtungsvektor zur Verwendung in der Multiplikation zu nehmen ist.
  • In Ausführungsformen kann der arithmetische Befehl einen Vektor-Skalarprodukt-Befehl, einen akkumulierenden Vektor-Skalarprodukt-Befehl, einen Matrixprodukt-Befehl, einen akkumulierenden Matrix-produkt-Befehl oder einen Faltungsbefehl aufweisen.
  • In Ausführungsformen können die gleichzeitigen Threads mehrere Worker-Threads aufweisen und kann die Ausführungseinheit ferner ausgebildet sein, um zumindest manchmal ein Supervisor-Subprogramm mit wenigstens einem Supervisor-Thread zum Managen der Worker-Threads auszuführen.
  • In Ausführungsformen kann das Supervisor-Subprogramm ausgestaltet sein, um die Gewichtungen in die gemeinsam benutzte Gewichtungsregisterdatei zu schreiben.
  • In Ausführungsformen können die Gewichtungen in den gemeinsam benutzten Gewichtungsregistern nur durch das Supervisor-Subprogramm geschrieben werden und können die Worker-Threads die gemeinsam benutzten Gewichtungsregister nur lesen.
  • In Ausführungsformen können die Kontextregister einen jeweiligen Satz von Kontextregistern für jeden der Worker-Threads, die gleichzeitig ausgeführt werden können, aufweisen und kann ein zusätzlicher Satz von Kontextregistern ausgebildet sein, um einen Programmstatus des Supervisor-Subprogramms zu halten.
  • In Ausführungsformen kann das Supervisor-Subprogramm ausgebildet sein, um mit einem anfänglichen Laufen in allen Fenstern zu beginnen und die Gewichtungen vor einem Starten der Worker-Threads zu schreiben; wobei das Supervisor-Subprogramm jeden der Worker-Threads durch Abtreten jedes von manchen oder allen Fenstern, in denen das Supervisor-Subprogramm anfänglich läuft, an die jeweiligen Worker-Threads startet.
  • In Ausführungsformen kann der Befehlssatz einen Laufbefehl enthalten, der bei seiner Ausführung als Teil des Supervisor-Subprogramms das Fenster, in dem der Laufbefehl ausgeführt wird, an einen der Worker-Threads abtreten lässt, sodass der Worker-Thread in diesem Fenster anstelle des Supervisor-Subprogramms gestartet wird.
  • In Ausführungsformen kann der Befehlssatz einen Ausstiegsbefehl enthalten, der bei seiner Ausführung als Teil eines der Worker-Threads das Fenster, in dem der Ausstiegsbefehl ausgeführt wird, an das Supervisor-Subprogramm zurückgeben lässt, sodass das Supervisor-Subprogramm wieder in diesem Fenster anstelle des Worker-Threads weiterläuft.
  • In Ausführungsformen enthalten die Registerdateien eine separate arithmetische Registerdatei für jeden gleichzeitigen Worker-Thread, wobei die jeweilige arithmetische Registerdatei die entsprechenden Register arithmetischer Operanden aufweist.
  • In Ausführungsformen können die Registerdateien eine separate Gewichtungsregisterdatei mit den Gewichtungsregistern enthalten.
  • In Ausführungsformen kann die Gewichtungsregisterdatei so ausgebildet sein, dass sie nur durch das Supervisor-Subprogramm geschrieben werden kann und die Worker-Threads die Gewichtungsregisterdatei nur lesen können.
  • Gemäß einem anderen Aspekt der vorliegenden Erfindung ist ein Verfahren zum Betreiben eines Prozessors gemäß einer der obigen oder sonstigen Ausführungsformen vorgesehen, wobei das Verfahren ein Ausführen eines Programms mit einer oder mehreren Instanzen des arithmetischen Befehls auf dem Prozessor durch die Ausführungseinheit aufweist.
  • Figurenliste
  • Zum besseren Verständnis der Ausführungsformen der vorliegenden Offenbarung und um zu zeigen, wie solche Ausführungsformen in Kraft treten können, wird nur beispielhaft auf die beiliegenden Zeichnungen Bezug genommen, in denen
    • 1 ein schematisches Blockschaltbild eines beispielhaften Multithread-Prozessors ist,
    • 2 schematisch ein Schema von verschachtelten Zeitfenstern zeigt,
    • 3 schematisch einen Supervisor-Thread und mehrere Worker-Threads zeigt, die in mehreren verschachtelten Zeitfenstern ausgeführt werden,
    • 4 schematisch eine logische Blockstruktur eines beispielhaften Prozessors zeigt,
    • 5 ein schematisches Blockschaltbild eines Prozessors mit einer Anordnung von Teilprozessoren ist,
    • 6 eine schematische Darstellung einer Grafik ist, die in einem Maschinenintelligenzalgorithmus verwendet wird,
    • 7 schematisch ein Adressenpackungsschema zur Verwendung beim Umsetzen eines Typs eines Lade/Speicher-Befehls zeigt,
    • 8 schematisch eine Anordnung von vorbestimmten Abstandswerten in einem Satz von Stride-Registern zeigt,
    • 9 schematisch eine Faltung eines 3D-Kernels K mit einem Eingangsdatenvolumen zeigt,
    • 10 schematisch eine Matrixmultiplikation zeigt, die durch eine Sequenz von Phasen eines akkumulierenden Matrixprodukt-Befehls durchgeführt wird,
    • 11 weiter den Vorgang der akkumulierenden Matrixprodukt-Befehle zeigt,
    • 12 ein Beispiel einer Reihe von Schleifen einer Sequenz von akkumulierenden Matrixprodukt-Befehlen zum Durchführen einer Faltung gibt,
    • 13 schematisch den Vorgang eines Faltungsbefehls zeigt, und
    • 14 ein Beispiel einer Reihe von Faltungsbefehlen gibt.
  • Detaillierte Beschreibung von Ausführungsbeispielen
  • 1 zeigt ein Beispiel eines Prozessors 4 gemäß Ausführungsbeispielen der vorliegenden Offenbarung. Der Prozessor 4 weist eine Multithread-Verarbeitungseinheit 10 in Form einer Barrelthread-Verarbeitungseinheit und einen lokalen Speicher 11 auf (d.h. auf dem gleichen Tile im Fall einer Multitile-Anordnung oder dem gleichen Chip im Fall eines Ein-Prozessor-Chips). Eine Barrelthread-Verarbeitungseinheit ist eine Art Multithread-Verarbeitungseinheit, in welcher die Ausführungszeit der Pipeline in eine Wiederholungssequenz von verschachtelten Zeitfenstern unterteilt ist, von denen jedes durch einen gegebenen Thread belegt werden kann. Dies kann auch als simultane Ausführung bezeichnet werden, wie in Kürze in mehr Einzelheiten erläutert. Der Speicher 11 weist einen Befehlsspeicher 12 und einen Datenspeicher 22 auf (die in unterschiedlich adressierbaren Speichereinheiten oder unterschiedlichen Bereichen derselben adressierbaren Speichereinheit verwirklicht sein können). Der Befehlsspeicher 12 speichert einen durch die Verarbeitungseinheit 10 auszuführenden Maschinencode, während der Datenspeicher 22 sowohl Daten, gemäß denen durch den ausgeführten Code zu arbeiten ist, als auch durch den ausgeführten Code ausgegebene Daten (z.B. als ein Ergebnis solcher Verarbeitungen) speichert.
  • Der Speicher 12 speichert mehrere verschiedene Threads eines Programms, wobei jeder Thread eine jeweilige Sequenz von Befehlen zum Durchführen einer bestimmten Aufgabe oder bestimmter Aufgaben aufweist. Man beachte, dass ein hier bezeichneter Befehl einen Maschinencodebefehl bedeutet, d.h. eine Instanz eines der grundlegenden Befehle des Befehlssatzes des Prozessors, der aus einem einzelnen Opcode und null oder mehr Operanden besteht. In Ausführungsbeispielen weist das Programm mehrere Worker-Threads und ein Supervisor-Subprogramm, das als eines oder mehrere Supervisor-Threads aufgebaut sein kann, auf. Dies wird in Kürze in mehr Einzelheiten erläutert.
  • Ein Multithread-Prozessor ist ein Prozessor, der mehrere Programm-Threads nebeneinander, typischerweise in einer gleichzeitigen Weise ausführen kann. Eine gleichzeitige Ausführung bedeutet, dass die Threads eine gemeinsame Ausführungspipeline (oder wenigstens einen gemeinsamen Teil einer Pipeline) gemeinsamen nutzen und verschiedene Threads durch diese gemeinsam benutzte Ausführungspipeline in unterschiedlichen verschachtelten Zeitfenstern in einem Wiederholungszyklus verschachtelt sind. Dies erhöht die Leistungsfähigkeit wegen erhöhter Möglichkeiten zum Ausblenden einer Pipeline-Wartezeit. Der Prozessor weist eine Hardware auf, die den mehreren verschiedenen Threads gemeinsam ist (z.B. einen gemeinsamen Befehlsspeicher, Datenspeicher und/oder Ausführungseinheit), aber zum Unterstützen des Multithreadings weist der Prozessor auch eine dedizierte Hardware speziell für jeden Thread auf.
  • Die dedizierte Hardware weist einen separaten Satz von Kontextregistern 26 für wenigstens jeden der Threads auf, die gleichzeitig ausgeführt werden können, d.h. einen Satz je Fenster im Zyklus. Wenn über Multithread-Prozessoren gesprochen wird, bezieht sich ein „Kontext“ auf den Programmstatus eines jeweiligen der Threads, die nebeneinander ausgeführt werden (z.B. Programmzählerwert, Status- und aktuelle Operandenwerte). Die Kontextregister beziehen sich auf die jeweiligen Register zum Darstellen dieses Programmstatus des jeweiligen Threads. Die Register in einer Registerdatei sind von einem allgemeinen Speicher dahingehend verschieden, dass die Registeradressen als Bits in Befehlswörtern fixiert sind, während Speicheradressen durch die Ausführungsbefehle berechnet werden können.
  • In der Verarbeitungseinheit 10 können mehrere verschiedene der Threads aus dem Befehlsspeicher 12 durch eine einzelne Ausführungspipeline 13 verschachtelt werden (obwohl typischerweise nur ein Teilsatz der gesamten Threads, die im Befehlsspeicher gespeichert sind, an irgendeinem Punkt im gesamten Programm verschachtelt werden kann). Die Multithread-Verarbeitungseinheit 10 weist mehrere Sätze von Kontextregistern 26 auf, wobei jeder Satz 26 ausgebildet ist, um den Status (Kontext) eines jeweiligen anderen der Threads, der gleichzeitig ausgeführt werden kann, darzustellen. Die Multithread-Verarbeitungseinheit 10 weist auch eine gemeinsam benutzte Ausführungspipeline 13 auf, die den gleichzeitig ausgeführten Threads gemeinsam ist, und einen Scheduler 24 zum Planen der gleichzeitigen Threads zur Ausführung durch die gemeinsam benutzte Pipeline in einer verschachtelten Weise, z.B. in einer Ringverteilungsweise. Die Verarbeitungseinheit 10 ist mit einem gemeinsam benutzten Befehlsspeicher 12, der den mehreren Threads gemeinsam ist, und einem gemeinsam benutzten Datenspeicher 22, der ebenfalls den mehreren Threads gemeinsam ist, verbunden.
  • Die Ausführungspipeline 13 weist eine Abrufstufe 14, eine Decodierstufe 16 und eine Ausführungsstufe 18 mit einer Ausführungseinheit, die arithmetische und logische Vorgänge, Adressberechnungen, Lade- und Speichervorgänge und weitere Vorgänge durchführen kann, wie sie durch die Befehlssatzarchitektur definiert sind ,auf.
  • Jeder Satz der Kontextregister 26 weist ein entsprechendes oder mehrere entsprechende Steuerregister mit wenigstens einem Programmzähler (PC) für den jeweiligen Thread (zum Nachverfolgen der Befehlsadresse, bei welcher der Thread aktuell ausgeführt wird), und in Ausführungsbeispielen auch einen Satz von einem oder mehreren Steuerstatusregistern (CSRs), die einen aktuellen Status des jeweiligen Threads protokollieren (beispielsweise ob er aktuell ausgeführt wird oder pausiert) auf. Jeder Satz der Kontextregisterdateien 26 weist auch einen entsprechenden Satz von Operandenregistern zum vorübergehenden Halten der Operanden der durch den jeweiligen Thread ausgeführten Befehle auf, d.h. Werte, gemäß denen gearbeitet wird die aus durch die Opcodes der jeweiligen Thread-Befehle definierten Vorgängen bei ihrer Ausführung resultieren. Jeder Satz von Registern 26 kann in einer oder mehreren Registerdateien implementiert sein.
  • Die Abrufstufe 14 hat Zugriff auf den Programmzähler (PC) jedes der Kontexte. Für jeden jeweiligen Thread ruft die Abrufstufe 14 den nächsten Befehl dieses Threads von der nächsten Adresse im Programmspeicher 12 ab, wie sie durch den Programmzähler angegeben ist. Der Programmzähler wird automatisch nach jedem Ausführungszyklus erhöht, sofern er nicht durch einen Verzweigungsbefehl abzweigt. Die Abrufstufe 10 gibt den abgerufenen Befehl dann an die Decodierstufe 16 weiter, um decodiert zu werden, und die Decodierstufe 16 gibt dann eine Angabe des decodierten Befehls an die Ausführungseinheit 18 zusammen mit den decodierten Adressen der im Befehl bestimmten Operandenregister weiter, damit der Befehl ausgeführt wird. Die Ausführungseinheit 18 hat Zugriff auf die Operandenregister und die Steuerstatusregister, welche sie beim Ausführen des Befehls basierend auf den decodierten Registeradressen benutzen kann, wie beispielsweise im Fall eines arithmetischen Befehls (z.B. durch Addieren, Multiplizieren, Subtrahieren oder Dividieren der Werte in zwei Operandenregistern und Ausgeben des Ergebnisses an ein anderes Operandenregister des jeweiligen Threads). Oder falls der Befehl einen Speicherzugriff definiert (Laden oder Speichern), lädt die Lade/Speicher-Logik der Ausführungseinheit 18 einen Wert aus dem Datenspeicher in ein Operandenregister des jeweiligen Threads oder speichert einen Wert aus einem Operandenregister des jeweiligen Threads in den Datenspeicher 22, entsprechend dem Befehl.
  • Die Abrufstufe 14 ist so verbunden, dass sie auszuführende Befehle aus dem Befehlsspeicher 12 unter Kontrolle des Schedulers 24 abruft. Der Scheduler 24 ist ausgestaltet, um die Abrufstufe 14 zu steuern, um einen Befehl aus jedem eines Satzes von gleichzeitig ausgeführten Threads in einer Wiederholungssequenz von Zeitfenstern abzurufen, um so die Ressourcen der Pipeline 13 in mehrere zeitlich verschachtelte Zeitfenster zu unterteilen, wie in Kürze in mehr Einzelheiten erläutert. Zum Beispiel könnte das Planungsschema eine Ringverteilung oder eine gewichtete Ringverteilung sein. Ein anderer Begriff für einen in einer solchen Weise arbeitenden Prozessor ist ein Barrelthread-Prozessor.
  • Ein Beispiel des durch den Scheduler 24 verwirklichten Verschachtelungsschemas ist in 2 veranschaulicht. Hier sind die gleichzeitigen Threads gemäß einem Ringverteilungsschema verschachtelt, wodurch in jeder Runde des Schemas die Runde in eine Sequenz von Zeitfenstern S0, S1, S2...SJ-1 (z.B. J=4 oder J=6) unterteilt ist, wobei jedes Fenster dem Ausführen eines jeweiligen Threads dient. Typischerweise ist jedes Fenster einen Ausführungszyklus lang und sind die verschiedenen Fenster gleich groß, obwohl dies nicht notwendigerweise in allen Ausführungsbeispielen so ist, z.B. ist auch ein gewichtetes Ringverteilungsschema möglich, wodurch manche Threads mehr Zyklen als andere je Ausführungsrunde bekommen. Im Allgemeinen kann das Barrelthreading entweder eine gleichmäßige Ringverteilung oder einen gewichteten Ringverteilungsplan verwenden, wobei im letztgenannten Fall die Gewichtung fest oder anpassbar sein kann.
  • Was auch immer die Sequenz je Ausführungsrunde ist, dieses Muster wiederholt dann jede Runde mit einer entsprechenden Instanz jedes der Zeitfenster. Man beachte deshalb, dass ein Zeitfenster, wie es hier bezeichnet wird, den zugeordneten Wiederholungsplatz in der Sequenz bedeutet, nicht eine besondere Instanz des Zeitfensters in einer gegebenen Wiederholung der Sequenz. Oder anders gesagt teilt der Scheduler 24 die Ausführungszyklen der Pipeline 13 in mehrere zeitlich verschachtelte (Time-Division-Multiplex) Ausführungskanäle, wobei jeder eine Wiederholung eines jeweiligen Zeitfensters in einer Wiederholungssequenz der Zeitfenster aufweist. Im gezeigten Ausführungsbeispiel gibt es vier Zeitfenster, aber dies dient nur Veranschaulichungszwecken und es sind auch andere Anzahlen möglich. Z.B. gibt es in einem bevorzugten Ausführungsbeispiel tatsächlich sechs Zeitfenster.
  • In Ausführungsbeispielen weisen die Kontextregister 26 einen jeweiligen Satz von Worker-Kontextregistern CX0...CX(J-1) für jeden der Anzahl J von Threads auf, die gleichzeitig ausgeführt werden können (J=3 in dem gezeigten Beispiel, aber dies ist nicht einschränkend), und eine zusätzliche Supervisor-Kontextregisterdatei CXS. Die Worker-Kontextregisterdateien halten die Kontexte der Worker-Threads, und die Supervisor-Kontextregisterdatei hält den Kontext eines Supervisor-Threads. Man beachte, dass in Ausführungsbeispielen der Supervisor-Kontext eine andere Anzahl an Registern als jeder der Worker haben kann. Die Verarbeitungseinheit 10 weist so eine Kontextregisterdatei 26 mehr auf als es Zeitfenster gibt, d.h. sie unterstützt einen Kontext mehr als die Anzahl verschachtelter Zeitfenster ein Barrelthreading machen kann.
  • Jeder der Worker-Kontexte CX0...CXJ wird benutzt, um den Zustand eines jeweiligen von mehreren Worker-Threads darzustellen, die aktuell einem der vier Ausführungszeitfenster S0...SJ zum Durchführen von anwendungsspezifischen Berechnungsaufgaben, welche auch immer vom Programmierer gewünscht sind, zugeordnet ist (man beachte wieder, dass dies nur ein Teilsatz der Gesamtzahl der Worker-Threads des Programms sein kann, wie es im Befehlsspeicher 12 gespeichert ist). Der zusätzliche Kontext CXS wird benutzt, um den Status eines „Supervisor-Thread“ (SV) darzustellen, dessen Rolle es ist, die Ausführung der Worker-Threads zu koordinieren, zumindest im Sinne einer Zuordnung, welcher der Worker-Threads W in welchem der Zeitfenster S0, S1, S2... an irgendeinem Punkt im gesamten Programm ausgeführt werden soll. Optional kann der Supervisor-Thread einen weiteren „Aufpasser“ oder Koordinationszuständigkeiten wie beispielsweise ein Durchführen externer Wechsel oder Grenzsynchronisationen haben. Man beachte natürlich, dass der gezeigte Fall von J=4 nur eine beispielhafte Umsetzung zu Veranschaulichungszwecken ist. Z.B. ist in einer anderen Umsetzung J=6 (sechs Zeitfenster, sechs Worker-Kontexte und ein Supervisor-Kontext).
  • Bezugnehmend auf 3 hat der Supervisor-Thread SV in Ausführungsbeispielen kein eigenes Zeitfenster für sich im Schema der verschachtelten Ausführungszeitfenster. Auch nicht die Worker, da eine Zuordnung von Fenster zu Worker-Threads flexibel definiert ist. Vielmehr hat jedes Zeitfenster seinen eigenen Satz von Kontextregistern zum Speichern von Worker-Kontext, der vom Worker verwendet wird, wenn das Fenster dem Worker zugeordnet wird, aber nicht benutzt wird, wenn das Fenster dem Supervisor zugeordnet wird. Wenn ein gegebenes Fenster dem Supervisor zugeordnet wird, benutzt dieses Fenster stattdessen die Kontextregisterdatei CXS des Supervisors. Der Supervisor hat immer Zugriff auf seinen eigenen Kontext und keine Worker können die Supervisor-Kontextregisterdatei CXS besetzen.
  • Der Supervisor-Thread SV hat die Fähigkeit, in irgendeinem und allen der Zeitfenster S0...S3 (oder allgemeiner S0...SJ-1) zu laufen. Der Scheduler 24 ist ausgestaltet, um beim Starten des Programms als Ganzes durch Zuordnen des Supervisor-Threads zu allen Zeitfenstern zu beginnen, d.h. der Supervisor SV beginnt in allen von S0...SJ-1 zu laufen. Der Supervisor-Thread ist jedoch mit einem Mechanismus versehen, um an irgendeinem folgenden Punkt (entweder sofort oder nach dem Durchführen einer oder mehrerer Supervisor-Aufgaben) vorübergehend jedes der Fenster, in dem er läuft, an einen entsprechenden der Worker-Threads abzutreten, z.B. anfängliche Worker W0... W3 in dem in 3 gezeigten Beispiel (oder allgemeiner W0...WJ-1). Dies wird erreicht, indem der Supervisor-Thread einen Laufbefehl ausführt, der wenigstens eine Adresse eines Worker-Threads im Befehlsspeicher 22 als einen Operanden nimmt. Die Worker-Threads sind Teile des Codes, der gleichzeitig mit einem anderen laufen kann, wobei jeder eine oder mehrere entsprechende durchzuführende Berechnungsaufgaben darstellt.
  • Der Laufbefehl wirkt auf den Scheduler 24 so, dass er das aktuelle Zeitfenster, in dem dieser Befehl selbst ausgeführt wird, an den durch den Operanden bestimmten Worker-Thread abtritt. Man beachte, dass es im Laufbefehl impliziert ist, dass es das Zeitfenster ist, in dem dieser Befehl ausgeführt wird, welches abgetreten wird (impliziert im Kontext von Maschinencodebefehlen bedeutet, dass es keines Operanden bedarf, um dies zu bestimmen - es ist impliziert aus dem Opcode selbst zu verstehen). Somit ist das Zeitfenster, das weggegeben wird, das Zeitfenster, in dem der Supervisor den Laufbefehl ausführt.
  • Der Supervisor-Thread SV führt einen ähnlichen Vorgang in jedem des einen oder der mehreren anderen Zeitfenster durch, um einige oder alle seiner Zeitfenster an verschiedene entsprechende Worker-Threads W0...WJ-1 (ausgewählt aus einem größeren Satz von möglichen Worker-Threads im Befehlsspeicher 12) abzugeben. Wenn dies einmal für das letzte Fenster erfolgt ist, wird der Supervisor gesperrt (dann später wieder fortgesetzt, wo er aufhörte, wenn eines der Fenster durch einen Worker W zurückgegeben wird). Der Supervisor-Thread SV ist somit in der Lage, verschiedene Worker-Threads, die jeweils eine oder mehrere Aufgaben durchführen, verschiedenen der verschachtelten Ausführungszeitfenster S0...SJ-1 (z.B. J=4, wie dargestellt, oder J=6) zuzuordnen. Wenn der Supervisor-Thread bestimmt, dass es Zeit ist, einen Worker-Thread auszuführen, benutzt er den Laufbefehl, um diesen Worker dem Zeitfenster zuzuordnen, in dem der Laufbefehl ausgeführt wurde.
  • In manchen Ausführungsbeispielen weist der Befehlssatz auch eine Variante des Laufbefehls, „alle laufen“ auf. Dieser Befehl wird benutzt, um einen Satz von mehr als einem Worker zusammen zu starten, die alle den gleichen Code ausführen. In Ausführungsbeispielen startet dies einen Worker in jedem der Fenster S0...S3 (oder allgemeiner S0...S(J-1)) der Verarbeitungseinheit.
  • Einmal gestartet, schreitet jeder der aktuell zugeordneten Worker-Threads W0...WJ-1 fort, um die eine oder mehreren Berechnungsaufgaben durchzuführen, die in dem durch den jeweiligen Laufbefehl bestimmten Code definiert sind. Am Ende davon gibt der jeweilige Worker-Thread dann das Zeitfenster, in dem er gelaufen ist, zurück an den Supervisor-Thread. Dies wird durch Ausführen eines Ausstiegsbefehls im jeweiligen Worker-Thread erzielt. Der Ausstiegsbefehl wirkt auf den Scheduler 24 so, dass er das aktuelle Zeitfenster, in dem dieser Befehl selbst ausgeführt wird, an den Supervisor-Thread zurückleitet. Als Reaktion setzt der Scheduler 24 dann das Laufen des Supervisors in diesem Fenster fort.
  • 4 zeigt weitere beispielhafte Details des Prozessors 4 einschließlich Einzelheiten der Ausführungseinheit 18 und der Kontextregister 26. Der Prozessor weist einen jeweiligen Befehlspuffer 53 für jeden der M Threads auf, die gleichzeitig ausgeführt werden können.
  • Die Kontextregister 26 weisen eine jeweilige Hauptregisterdatei (MRF) 26M für jeden der M Worker-Kontexte und des Supervisor-Kontextes auf. Die Kontextregister weisen ferner eine jeweilige Zusatzregisterdatei (ARF) 26A für wenigstens jeden der Worker-Kontexte auf. Die Kontextregister 26 weisen ferner eine gemeinsame Gewichtungsregisterdatei (WRF) 26W auf, auf die alle aktuell ausführenden Worker-Threads zugreifen können, um daraus zu lesen. Die WRF kann mit dem Supervisor-Kontext dahingehend in Verbindung stehen, dass der Supervisor-Thread der einzige Thread ist, der in die WRF schreiben kann. Die Kontextregister 26 können auch eine jeweilige Gruppe von Steuerstatusregistern 26CSR für jeden der Supervisor- und Worker-Kontexte aufweisen. Die Ausführungseinheit 18 weist eine Hauptausführungseinheit 18M und eine Zusatzausführungseinheit 18A auf. Die Hauptausführungseinheit 18M weist eine Lade/Speicher-Einheit (LSU) 55 und eine arithmetische Ganzzahl-Logikeinheit (IALU) 56 auf. die Zusatzausführungseinheit 18A weist wenigstens eine arithmetische Gleitkommaeinheit (FPU) auf.
  • In jedem der J verschachtelten Zeitfenster S0...SJ-1 steuert der Scheduler 24 die Abrufstufe 14, um wenigstens einen Befehl eines jeweiligen Threads aus dem Befehlsspeicher 11 in den jeweiligen der J Befehlspuffer 53 entsprechend dem aktuellen Zeitfenster abzurufen. In Ausführungsbeispielen ist jedes Zeitfenster ein Ausführungszyklus des Prozessors, auch wenn andere Schemata nicht ausgeschlossen sind (z.B. gewichtete Ringverteilung). In jedem Ausführungszyklus des Prozessors 4 (d.h. jedem Zyklus des Prozessortakts, der den Programmzähler taktet) ruft die Abrufstufe 14 abhängig von der Anwendung entweder einen einzelnen Befehl oder ein kleines „Befehlsbündel“ (z.B. ein Zwei-Befehle-Bündel oder Vier-Befehle-Bündel) ab. Jeder Befehl wird dann über die Decodierstufe 16 in eine der LSU 55 oder IALU 56 der Hauptausführungseinheit 18M oder der FPU der Zusatzausführungseinheit 18A ausgegeben, abhängig davon, ob der Befehl (gemäß seinem Opcode) ein Speicherzugriffsbefehl, ein arithmetischer Ganzzahlbefehl oder ein arithmetischer Gleitkommabefehl ist. Die LSU 55 und die IALU 56 der Hauptausführungseinheit 18M führen ihre Befehle mittels Registern aus der MRF 26M aus, wobei die speziellen Register in der MRF 26M durch Operanden der Befehle bestimmt sind. Die FPU der Zusatzausführungseinheit 18A führt Vorgänge mittels Registern in der ARF 26A und der WRF 26W durch, wobei die speziellen Register in der ARF durch Operanden der Befehle bestimmt sind. In Ausführungsbeispielen können die Register in der WRF im Befehlstyp impliziert sein (d.h. vorbestimmt für diesen Befehlstyp). Die Zusatzausführungseinheit 18A kann auch ein Schaltschema in der Form von logischen Regeln innerhalb der Zusatzausführungseinheit 18A zum Halten manches internen Zustandes 57 zur Verwendung beim Durchführen der Vorgänge einer oder mehrerer Arten des arithmetischen Gleitkommabefehls enthalten.
  • In Ausführungsbeispielen, die Befehle in Bündeln abrufen und ausführen, werden die einzelnen Befehle in einem gegebenen Befehlsbündel gleichzeitig in parallelen unabhängigen Pipelines 18M, 18A (dargestellt in 4) ausgeführt. In Ausführungsbeispielen, die Bündel aus zwei Befehlen ausführen, können die zwei Befehle gleichzeitig in jeweiligen Zusatz- und Haupt-Pipelines ausgeführt werden. In diesem Fall ist die Haupt-Pipeline ausgebildet, um Befehlstypen auszuführen, die die MRF benutzen, und wird die Zusatz-Pipeline verwendet, um Befehlstypen auszuführen, die die ARF benutzen. Das Paaren von Befehlen in geeignete komplementäre Bündel kann durch den Compiler abgewickelt werden.
  • Jeder Worker-Thread-Kontext hat seine eigene Instanz der Hauptregisterdatei (MRF) 26M und der Zusatzregisterdatei (ARF) 26A (d.h. eine MRF und eine ARF für jedes der Barrelthread-Fenster). Die hier bezüglich der MRF oder ARF beschriebene Funktionalität soll so verstanden werden, dass sie auf einer Basis je Kontext arbeitet. Es gibt jedoch eine einzelne, gemeinsam benutzte Gewichtungsregisterdatei (WRF), die zwischen den Threads geteilt wird. Jeder Thread kann auf die MRF und die ARF nur von seinem eigenen Kontext 26 zugreifen. Alle aktuell laufenden Worker-Threads können aber auf die gemeinsame WRF zugreifen. Die WRF stellt so einen gemeinsamen Satz von Gewichtungen zur Verwendung durch alle Worker-Threads bereit. In Ausführungsbeispielen kann nur der Supervisor in die WRF schreiben und können die Worker nur aus der WRF lesen.
  • Der Befehlssatz des Prozessors 4 enthält wenigstens einen Typ von Ladebefehl, dessen Opcode bei Ausführung die LSU 55 veranlasst, Daten aus dem Datenspeicher 22 in die jeweilige ARF 26A des Threads zu laden, in dem der Ladebefehl ausgeführt wurde. Die Position des Ziels in der ARF wird durch einen Operanden des Ladebefehls bestimmt. Ein anderer Operand des Ladebefehls bestimmt ein Adressregister in der jeweiligen MRF 26M, die einen Pointer zu einer Adresse im Datenspeicher 22 hält, aus dem die Daten zu laden sind. Der Befehlssatz des Prozessors 4 enthält auch wenigstens einen Typ von Speicherbefehl, dessen Opcode bei Ausführung die LSU 55 veranlasst, Daten aus der jeweiligen ARF des Threads, in dem der Speicherbereich ausgeführt wurde, in den Datenspeicher 22 zu speichern. Die Position der Quelle des Speicherns in der ARF wird durch einen Operanden des Speicherbefehls bestimmt. Ein anderer Operand des Speicherbefehls bestimmt ein Adressregister in der MRF, der einen Pointer zu einer Adresse im Datenspeicher 22 hält, zu der die Daten zu speichern sind. Im Allgemeinen kann der Befehlssatz separate Lade- und Speicherbefehlstypen und/oder wenigstens einen Lade/Speicher-Befehlstyp, der die Lade- und Speichervorgänge in einem einzigen Befehl kombiniert, enthalten. Wie in Kürze in mehr Einzelheiten erläutert, kann der Befehlssatz einen speziellen Typ von Lade/Speicher-Befehl enthalten, der zwei Ladevorgänge und einen Speichervorgang alle in einem einzigen Befehl durchführt. Man beachte, dass der Befehlssatz eines gegebenen Prozessors 4 mehrere unterschiedliche Varianten von Lade-, Speicher- und/oder Lade/Speicher-Befehlstypen enthalten kann.
  • Der Befehlssatz des Prozessors enthält auch einen oder mehrere arithmetische Befehlstypen zum Durchführen von arithmetischen Vorgängen. Gemäß hier offenbarten Ausführungsbeispielen können diese wenigstens einen arithmetischen Befehlstyp enthalten, der von der gemeinsamen Gewichtungsregisterdatei WRF 26W Gebrauch macht. Dieser Befehlstyp nimmt wenigstens einen Operanden, der wenigstens eine Quelle des entsprechenden arithmetischen Vorgangs in der jeweiligen ARF 26A des Threads, in dem der arithmetische Befehl ausgeführt wurde, bestimmt. Wenigstens eine andere Quelle des arithmetischen Befehls ist jedoch in der gemeinsamen WRF gemeinsam für alle Worker-Threads. In Ausführungsbeispielen ist diese Quelle im fraglichen arithmetischen Befehl impliziert (d.h. impliziert für diesen arithmetischen Befehlstyp). Impliziert im Sinne eines Maschinencodebefehls bedeutet, dass nicht ein Operand bestimmen muss. D.h. in diesem Fall ist die Position der Quelle in der WRF aus dem Opcode inhärent (vorbestimmt für diesen speziellen Opcode). Alternativ kann der arithmetische Befehl in anderen Ausführungsbeispielen einen Operanden nehmen, der bestimmt, aus welchem Satz von Gewichtungsregistern aus einigen unterschiedlichen Sätzen in der WRF die Gewichtungen zu nehmen sind. Die Tatsache, dass die Quelle der Gewichtungen in der WRF gefunden wird (im Gegensatz zu der MRF oder ARF für allgemeine Zwecke), ist jedoch nach wie vor impliziert.
  • Als Reaktion auf den Opcode des relevanten arithmetischen Befehlstyps führt die arithmetische Einheit (z.B. FPU) in der Zusatzausführungseinheit 18A einen arithmetischen Vorgang durch, wie er durch den Opcode bestimmt wird, der ein Bearbeiten der Werte in dem/den bestimmten Quellenregister(n) in der jeweiligen ARF der Threads und dem/den Quellenregister(n) in der WRF aufweist. Sie gibt auch ein Ergebnis des arithmetischen Vorgangs an ein Zielregister in der jeweiligen ARF des Threads aus, wie er explizit durch einen Zieloperanden des arithmetischen Befehls bestimmt wird.
  • Beispiele von arithmetischen Befehlstypen, die eine Quelle in der gemeinsamen WRF 26W einsetzen können, können enthalten: eine oder mehrere Vektormultiplikations-Befehlstypen, eine oder mehrere Matrixmultiplikations-Befehlstypen, eine oder mehrere akkumulierende Vektormultiplikations-Befehlstypen und/oder akkumulierende Matrixmultiplikations-Befehlstypen (die ein Ergebnis der Multiplikation von einer Instanz des Befehls zur nächsten akkumulieren), und/oder eine oder mehrere Faltungs-Befehlstypen. Zum Beispiel kann ein Vektormultiplikations-Befehlstyp einen expliziten Eingangsvektor aus der ARF 26A mit einem vorbestimmten Gewichtungsvektor aus der WRF multiplizieren; oder ein Matrixmultiplikations-Befehlstyp kann einen expliziten Eingangsvektor aus der ARF mit einer vorbestimmten Gewichtungsmatrix aus der WRF multiplizieren. Als anderes Beispiel kann ein Faltungs-Befehlstyp eine Eingangsmatrix aus der ARF mit einer vorbestimmten Matrix aus der WRF falten. Bei einer gemeinsam benutzten Gewichtungsregisterdatei WRF, die mehreren Threads gemeinsam ist, ermöglicht sie jedem Thread, einen gemeinsamen Kernel mit seinen eigenen jeweiligen Daten zu multiplizieren oder zu falten. Dies ist nützlich, da dies ein Szenario ist, das häufig in Maschinenlernanwendungen auftritt, z.B. wenn jeder Thread einen anderen Knoten in einem neuronalen Netz darstellt und der gemeinsame Kernel eine gesuchte oder trainierte Funktion (zum Beispiel eine Kante oder eine besondere Form in einem Bereich oder Volumen von grafischen Daten) darstellt.
  • In Ausführungsbeispielen können die Werte durch den Supervisor-Thread in die WRF 26W geschrieben werden. Der Supervisor (der im Ausführungsbeispiel durch Laufen in allen Fenstern S0...SM beginnt) führt zuerst eine Reihe von Setzbefehlen aus, um die Werte mancher gemeinsamen Gewichtungen in die vorbestimmte Position in der WRF zu schreiben. Er führt dann Laufbefehle (oder einen Alle-Laufen-Befehl) aus, um einen entsprechenden Worker in manchen oder allen der Fenster S0...SJ-1 zu starten. Jeder Worker enthält dann eine oder mehrere Instanzen eines oder mehrerer arithmetischer Befehle des/der oben beschriebenen Typs/Typen, um so den/die entsprechenden arithmetischen Vorgang/Vorgänge an ihren eigenen jeweiligen Eingangsdaten, wie sie in ihre jeweilige ARF 26A geladen sind, aber unter Verwendung der durch den Supervisor in die WRF 26W geschriebenen gemeinsamen Gewichtungen durchzuführen. Wenn jeder Thread seine jeweilige Aufgabe beendet, führt er einen Ausstiegsbefehl aus, um sein Fenster dem Supervisor zurückzugeben. Wenn alle gestarteten Threads ihre jeweiligen Aufgaben beendet haben, kann der Supervisor neue Werte in die WRF schreiben und einen neuen Satz von Threads starten (oder einen neuen Satz starten, um die Verwendung der existierenden Werte in der WRF fortzusetzen).
  • Es sei darauf hingewiesen, dass die Begriffe „Haupt-“, „Zusatz-“ und „Gewichtungs-“ nicht notwendigerweise einschränkend sind. In Ausführungsbeispielen können sie irgendeine erste Registerdatei (je Worker-Kontext), zweite Registerdatei (je Worker-Kontext) und gemeinsam benutzte dritte Registerdatei (z.B. Teil des Supervisor-Kontextes, aber von allen Workern zugreifbar) sein. Die ARF 26A und die Zusatzausführungseinheit 18 können auch als arithmetische Registerdatei und arithmetische Ausführungsdatei bezeichnet werden, da sie für arithmetische Befehle (oder wenigstens die Gleitkomma-Arithmetik) benutzt werden. Die MRF 26M und die Zusatzausführungseinheit 18 können auch als Speicheradressen-Registerdatei und arithmetische Ausführungseinheit bezeichnet werden, da eine von ihnen zum Zugriff auf den Speicher benutzt wird. Die Gewichtungsregisterdatei WRF 26W wird so genannt, weil sie verwendet wird, um vielfache Gewichtungen zu halten, die in (einem) bestimmten arithmetischen Befehlstyp(en) benutzt werden, wie in Kürze in mehr Einzelheiten erläutert. Z.B. könnten diese benutzt werden, um die Gewichtungen von Knoten in einem neuronalen Netz darzustellen. Anders betrachtet könnte die MRF als Ganzzahl-Registerdatei bezeichnet werden, da sie benutzt wird, um Ganzzahl-Operanden zu halten, während die ARF als Gleitkomma-Registerdatei bezeichnet werden könnte, da sie benutzt wird, m Gleitkomma-Operanden zu halten. In Ausführungsbeispielen, die Befehle in Zweierbündeln ausführen, ist die MRF die von der Haupt-Pipeline benutzte Registerdatei und ist die ARF die von der Zusatz-Pipeline benutzte Registerdatei.
  • Man beachte aber, dass in alternativen Ausführungsbeispielen der Registerraum 26 nicht notwendigerweise in diese separaten Registerdateien für diese verschiedenen Zwecke unterteilt ist. Stattdessen können die durch die Haupt- und Zusatz-Ausführungseinheiten ausgeführten Befehle Register aus derselben gemeinsam benutzten Registerdatei (eine Registerdatei je Kontext im Fall eines Multithread-Prozessors) bestimmen. Auch muss die Pipeline 13 nicht unbedingt parallele Teil-Pipelines (z.B. Zusatz- und Haupt-Pipelines) zum gleichzeitigen Ausführen von Befehlsbündeln aufweisen.
  • Der Prozessor 4 kann auch eine Austausch-Schnittstelle 51 zum Datenaustausch zwischen dem Speicher 11 und einer oder mehreren anderen Ressourcen wie z.B. anderen Instanzen des Prozessors und/oder anderen externen Geräten wie beispielsweise ein Netzwerkschnittstellegerät oder ein am Netzwerk angebrachtes Speichergerät (NAS) aufweisen. Wie in 5 dargestellt, kann der Prozessor 4 in Ausführungsbeispielen einen einer Anordnung 6 von miteinander verbundenen Prozessor-Tiles bilden, wobei jeder Tile einen Teil eines größeren Programms ausführt. Die einzelnen Prozessoren 4 (Tiles) bilden so einen Teil eines größeren Prozessors oder Prozessorsystems 6. Die Tiles 4 können über ein Verbindungs-Subsystem 34 zusammen verbunden sein, mit dem sie über ihre jeweilige Austausch-Schnittstelle 51 verbunden sind. Die Tiles 4 können auf demselben Chip (d.h. Würfel) oder auf verschiedenen Chips oder einer Kombination (z.B. kann die Anordnung aus mehreren Chips mit jeweils mehreren Tiles 4 gebildet sein) realisiert sein. Das Verbindungssystem 34 und die Austausch-Schnittstelle 51 können deshalb demgemäß einen internen (On-Chip-) Verbindungsmechanismus und/oder einen externen (Inter-Chip-) Austauschmechanismus aufweisen.
  • In einer beispielhaften Anwendung eines Multithread- und/oder Multitile-Prozessors oder Systems weist der Programmablauf über die mehreren Threads und/oder Tiles 4 einen Maschinenintelligenzalgorithmus auf, wie beispielsweise einen Algorithmus zum Trainieren eines neuronalen Netzes und/oder Durchführen einer Schlussfolgerung basierend auf einem neuronalen Netz. In solchen Ausführungsbeispielen wird jeder Worker-Thread oder der Teil des Programmablaufs auf jedem Tile oder jeder Worker-Thread auf jedem Tile benutzt, um einen anderen Knoten 102 in einem neuronalen Netz (einem Grafiktyp) darzustellen; und Kommunikationen zwischen Threads und/oder Tiles stellen demgemäß Flanken 104 zwischen Knoten 102 in der Grafik dar. Dies ist in 6 veranschaulicht.
  • Maschinenintelligenz beginnt mit einer Lernstufe, in der der Maschinenintelligenzalgorithmus ein Wissensmodell lernt. Das Modell weist eine Grafik von miteinander verbunden Knoten (d.h. Scheitelpunkten) 102 und Flanken (d.h. Verbindungen) 104 auf. Jeder Knoten 102 in der Grafik hat eine oder mehrere Eingangsflanken und eine oder mehrere Ausgangsflanken. Manche Eingangsflanken von manchen Knoten 102 sind die Ausgangsflanken von manchen anderen Knoten, wodurch die Knoten miteinander verbunden werden, um die Grafik zu bilden. Ferner bilden ein oder mehrere Eingangsflanken eines oder mehrerer Knoten 102 die Eingänge zur Grafik in ihrer Gesamtheit und bilden eine oder mehrere Ausgangsflanken eines oder mehrerer Knoten 102 die Ausgänge der Grafik in ihrer Gesamtheit. Manchmal kann ein bestimmter Knoten auch alles haben von Eingängen in die Grafik, Ausgängen aus der Grafik und Verbindungen zu anderen Knoten. Jede Flanke 104 kommuniziert einen Wert oder häufiger einen Tensor (n-dimensionale Matrix), wobei diese die Eingaben und Ausgaben zu und von den Knoten 102 auf ihren Eingangs- bzw. Ausgangsflanken bilden.
  • Jeder Knoten 102 stellt eine Funktion seiner ein oder mehreren Eingaben dar, die von seiner/seinen Eingangsflanke(n) empfangen werden, wobei das Ergebnis dieser Funktion die an der/den Ausgangsflanke(n) bereitgestellten Ausgabe(n) ist. Jede Funktion ist durch einen oder mehrere entsprechende Parameter (manchmal als Gewichtungen bezeichnet, obwohl sie nicht unbedingt multiplikative Gewichtungen sein müssen) parametrisiert. Im Allgemeinen können die durch die verschiedenen Knoten 102 dargestellten Funktionen unterschiedliche Funktionsformen sein und/oder durch unterschiedliche Parameter parametrisiert sein.
  • Ferner ist jeder der einen oder mehreren Parameter jeder Knotenfunktion durch einen jeweiligen Fehlerwert charakterisiert. Außerdem kann dem/den Fehler(n) in dem/den Parametern) jedes Knotens 102 eine jeweilige Bedingung zugeordnet sein. Für einen Knoten 102, der eine durch einen einzelnen Parameter parametrisierte Funktion darstellt, kann die Bedingung ein einfacher Grenzwert sein, d.h. die Bedingung ist erfüllt, falls der Fehler unter dem bestimmten Grenzwert liegt, aber ist nicht erfüllt, falls der Fehler über dem Grenzwert liegt. Für einen durch mehr als einen jeweiligen Parameter parametrisierten Knoten 102 kann die Bedingung dafür, dass dieser Knoten 102 ein akzeptables Fehlerniveau erreicht hat, komplexer sein. Zum Beispiel kann die Bedingung nur erfüllt sein, falls jeder der Parameter dieses Knotens 102 unter dem jeweiligen Grenzwert liegt. Als weiteres Beispiel kann eine kombinierte Metrik definiert sein, die die Fehler in den verschiedenen Parametern für denselben Knoten 102 kombiniert, und die Bedingung kann unter der Voraussetzung erfüllt sein, dass der Wert der kombinierten Metrik unter einem bestimmten Grenzwert liegt, aber andernfalls ist die Bedingung nicht erfüllt, falls der Wert der kombinierten Metrik über dem Grenzwert liegt (oder umgekehrt, abhängig von der Definition der Metrik). Welche Bedingung auch immer, dies gibt ein Maß dafür, ob der Fehler in dem/den Parameter(n) des Knotens unter ein bestimmtes Niveau oder Maß an Akzeptanz fällt. Allgemein kann irgendeine geeignete Metrik verwendet werden. Die Bedingung oder die Metrik können für alle Knoten gleich sein oder für verschiedene einzelne Knoten unterschiedlich sein.
  • In der Lernstufe empfängt der Algorithmus Erfahrungsdaten, d.h. mehrfache Datenpunkte, die verschiedene mögliche Kombinationen von Eingaben zur Grafik darstellen. Wenn immer mehr Erfahrungsdaten empfangen werden, passt der Algorithmus die Parameter der verschiedenen Knoten 102 in der Grafik basierend auf den Erfahrungsdaten allmählich an, um zu versuchen, die Fehler in den Parameter zu minimieren. Es ist das Ziel, Werte der Parameter zu finden, sodass die Ausgabe der Grafik so nah wie möglich an einer gewünschten Ausgabe für eine gegebene Eingabe ist. Wenn die Grafik insgesamt zu einem solchen Zustand tendiert, konvergiert die Grafik sozusagen. Nach einem geeigneten Maß an Konvergenz kann die Grafik dann benutzt werden, um Vorhersagen oder Schlussfolgerungen durchzuführen, d.h. ein Ergebnis für eine gegebene Eingabe vorherzusagen oder eine Ursache für eine gegebene Ausgabe zu schlussfolgern.
  • Die Lernstufe kann eine Anzahl von verschiedenen möglichen Formen annehmen. Zum Beispiel nehmen in einem überwachten Konzept die eingegebenen Erfahrungsdaten die Form von Trainingsdaten an, d.h. Eingaben, die bekannten Ausgaben entsprechen. Mit jedem Datenpunkt kann der Algorithmus die Parameter so anpassen, dass die Ausgabe enger zur bekannten Ausgabe für die gegebene Eingabe passt. In der anschließenden Vorhersagestufe kann die Grafik dann benutzt werden, um eine Eingabefrage auf eine ungefähr vorhergesagte Ausgabe abzubilden (oder umgekehrt, falls eine Schlussfolgerung gemacht wird). Andere Konzepte sind auch möglich. Zum Beispiel gibt es in einem nicht-überwachten Konzept kein Konzept eines Bezugsergebnisses je Eingabedaten, und stattdessen wird es dem Maschinenintelligenzalgorithmus überlassen, seine eigene Struktur in den Ausgangsdaten zu identifizieren. Oder in einem Verstärkungskonzept testet der Algorithmus wenigstens eine mögliche Ausgabe für jeden Datenpunkt in den eingegebenen Erfahrungsdaten und erfährt, ob diese Ausgabe positiv oder negativ ist (und potenziell ein Maß, wie positiv oder negativ) z.B. gewinnen oder verlieren oder Vergütung oder Kosten oder dergleichen. Über viele Versuche kann der Algorithmus allmählich die Parameter der Grafik anpassen, damit sie Eingaben vorhersagen können, die in einem positiven Ausgang resultieren. Die verschiedenen Konzepte und Algorithmen zum Lernen einer Grafik sind einem Fachmann im Gebiet des Maschinenlernens bekannt.
  • Gemäß einer beispielhaften Anwendung der hier offenbarten Techniken ist jeder Worker-Thread programmiert, um die Berechnungen durchzuführen, die zu einem jeweiligen einzelnen der Knoten 102 in einer Maschinenintelligenzgrafik wie beispielsweise einem neuronalen Netz gehören. In diesem Fall entsprechen wenigstens manche der Flanken 104 zwischen den Knoten 102 dem Datenaustausch zwischen Threads, und manche können einen Austausch zwischen Tiles einbeziehen. Im Fall einer Multitile-Anordnung 6 mit mehrfachen Threads je Tile 4, führt jeder Tile 4 eine Teilgrafik der Grafik aus. Jede Teilgrafik weist ein Supervisor-Subprogramm mit einem oder mehreren Supervisor-Threads und einen Satz von Worker-Threads, die die Knoten 102 der jeweiligen Teilgrafik darstellen, auf.
  • In Anwendungen wie beispielsweise Maschinenintelligenz wäre es wünschenswert, Daten in und aus dem Datenspeicher 22 des Prozessors 4 (z.B. Tile) effizient zu streamen. Zum Beispiel würde dies insbesondere (aber nicht ausschließlich) nützlich sein, um eine Sequenz von komplexen arithmetischen Befehlen wie beispielsweise Vektor-Skalarprodukt-Befehlen, Matrixprodukt-Befehlen, akkumulierenden Vektor-Skalarprodukt-Befehlen, akkumulierenden Matrixprodukt-Befehlen oder dedizierten Faltungsbefehlen, die einen hohen Grad an arithmetischer Komplexität in einen einzelnen arithmetischen Befehl packen, zu begleiten.
  • Um solche Aufgaben zu lösen, sehen Ausführungsbeispiele einen Lade/Speicher-Befehlstyp im Befehlssatz des Prozessors 4 vor, der zwei Ladevorgänge und einen Speichervorgang durchführt und dann automatisch einen unabhängigen Stride an jeder der Lade- und Speicheradressen anwendet, alles als Reaktion auf einen einzelnen Befehl des Opcodes des Befehls. Ferner benutzt der Befehl ein effizientes Packen von Adressen in die entsprechende Registerdatei (z.B. die MRF 26M), wodurch die drei Adressen (die zwei Ladeadressen und die eine Speicheradresse) in den Raum von zwei Registern gepackt werden. Dies ermöglicht es, dass auf die drei Speicheradressen und das Stride-Register in einem einzigen Befehl mit nur drei Ports von der MRF 26M zur LSU zugegriffen werden kann (ein jeweiliger Port zum Zugreifen auf jedes der drei Register).
  • Der Befehl kann hier als „Id2xst64pace“ bezeichnet werden, Bezug nehmend auf die Tatsache, dass er zwei 64-Bit-Werte lädt und einen 64-Bit-Wert speichert, wobei „pace“ ein Synonym für Stride ist. Diese Benennung oder die speziellen Bitbreiten sollen jedoch nicht als unbedingt einschränkend angenommen werden. Der Befehl kann allgemeiner als nur der Lade/Speicher-Befehl (obwohl dies nicht bedeutet, dass er notwendigerweise die einzige Art Lade/Speicher-Befehl im Befehlssatz des Prozessors ist) oder „Idx2st“ (Laden zweimal und Speichern) bezeichnet werden. Seine Syntax ist wie folgt:
    • Id2xst $aDst, $aSrc, $mAddr, $mStride, Strimm
  • $aDst bezieht sich auf einen oder mehrere Operanden, die ein Ziel in der Zusatz- (oder arithmetischen) Registerdatei ARF 26A identifizieren, wobei das Ziel ein oder mehrere Register in der ARF aufweist. In Ausführungsbeispielen ist jedes der Register in der ARF 32 Bits breit, und das Ziel $aDst kann aus vier solchen 32-Bit-Registern bestehen: $aDst0:Dst0+3. Der Zieloperand von Id2xst64pace kann die Position von nur einem dieser Zielregister in der ARF bestimmen (z.B. die niedrigste $aDst0), und die Positionen des/der anderen können relativ zu dieser impliziert sein (z.B. die nächsten drei benachbarten Register in der ARF). Alternativ ist es in anderen Anwendungen nicht ausgeschlossen, dass die mehreren Zieloperanden jeweils eindeutig und unabhängig durch separate Operanden identifiziert werden können (obwohl dies eine vergrößerte Befehlsbreite erfordern würde).
  • $aSrc bezieht sich auf einen oder mehrere Operanden, die eine Quelle in der ARF 26A identifizieren, wobei die Quelle ein oder mehrere Register in der ARF aufweist. In Ausführungsbeispielen ist jedes der Register in der ARF 32 Bits breit, und die Quelle $aSrc kann aus zwei solchen 32-Bit-Registern bestehen: $aSrc0:Src+1. Der Quellenoperand von Id2xst64pace kann die Position von genau einer dieser Quellenregister in der ARF bestimmen (z.B. die niedrigste $aSrc0), und die Position des anderen kann relativ zu diesem impliziert sein (z.B. das nächste benachbarte Register in der ARF). Alternativ ist es in anderen Anwendungen nicht ausgeschlossen, dass die mehrfachen Quellenoperanden jeweils eindeutig und unabhängig durch separate Operanden identifiziert werden können (obwohl dies eine größere Befehlsbreite erfordern würde).
  • $mAddr bezeichnet einen oder mehrere Operanden, die die Position von zwei Registern $mAddr0:Addr0+1 in der Hauptregisterdatei MRF 26M bestimmen, welche zwischen diesen drei Adressen hält: zwei Ladeadressen und eine Speicheradresse. In Ausführungsbeispielen ist jedes der Register in der MRF 32 Bits breit. Der Speicheradressenoperand kann die Position von nur einem dieser Register in der MRF bestimmen (z.B. die niedrigste $mAddr0), wobei die Position des anderen relativ zu dieser impliziert ist (z.B. das nächste benachbarte Register in der MRF). Alternativ ist es in anderen Anwendungen nicht ausgeschlossen, dass die Speicheradressregister jeweils explizit und unabhängig durch separate Operanden identifiziert werden können (obwohl dies eine größere Befehlsbreite erfordern würde).
  • Strimm ist ein Satz von direkten Operanden, ein jeweiliger für jede der zwei Ladeadressen und die eine Speicheradresse. In der MRF 26M ist ein Stride-Register vorgesehen, das mehrere Felder aufweist. Jedes Feld hält einen jeweiligen anderen eines vorbestimmten Satzes von verschiedenen möglichen Abstandswerten. Ein Abstandswert ist ein Wert, um den eine Speicheradresse zu erhöhen ist, d.h. ein Speicheradressenschritt, typischerweise zur Verwendung in einer Reihe solcher Schritte. Für jede der zwei Ladeadressen und der einen Speicheradresse bestimmt der jeweilige direkte Stride-Operand, von welchem Feld im Stride-Register der Abstandswert zu nehmen ist, um ihn auf die jeweilige Lade- oder Speicheradresse anzuwenden, nachdem der jeweilige Lade- oder Speichervorgang der aktuellen Instanz des Befehls durchgeführt worden ist. Dies bewegt sich entlang der Adresse in der MRF 26M zum Nutzen einer folgenden Instanz des Lade/Speicher-Befehls.
  • In Ausführungsbeispielen unterstützt die Lade/Speicher-Einheit 55 eine Funktion, wobei ein spezieller Wert des direkten Stride-Operanden einen Abstandswert von 1 direkt bestimmen kann (d.h. ein Anstieg um eine Adresseneinheit im benutzten Adressenraum), anstatt auf ein Registerfeld hinzuweisen. D.h. aus dem Bereich der Werte, die der direkte Stride-Operand nehmen kann, bestimmt einer der Werte einen Abstand von 1, und manche oder alle anderen bestimmen verschiedene mögliche Felder im Stride-Register, das programmierbare Abstandswerte hält. Eine Einheit bedeutet hier die atomare Größe des Datenzugriffs. Falls zum Beispiel der Operand ein 4-Element-Vektor von 16-Bit-Gleitkommawerten ist, erfolgt der Anstieg um 1 Atom/Einheit, was äquivalent zu 8 Bytes (64 Bits) ist.
  • Das Stride-Register ist ein Register in der MRF 26M. In Ausführungsbeispielen ist der Worker selbst verantwortlich zum Schreiben der Abstandswerte in die Felder seines eigenen Stride-Registers (in seiner eigenen MRF). Alternativ ist es nicht ausgeschlossen, dass in anderen Anwendungen die Abstandswerte in den Feldern des Stride-Registers durch den Supervisor-Thread SV geschrieben werden, oder es kann auch eine Kombination von Konzepten benutzt werden.
  • Das Erfordernis für einen Operanden, der $mStride bestimmt, ist eine optionale Funktion des Prozessors 4 in Abhängigkeit von der Anwendung. In Ausführungsbeispielen nimmt der Lade/Speicher-Befehl einen Operanden, der die Position des Stride-Registers $mStride in der MRF 26M bestimmt. So ist das Programm in der Lage, das Stride-Register aus mehreren möglichen Stride-Registern auszuwählen, was noch mehr Flexibilität bei der Auswahl des Strides vorsieht. In alternativen Anwendungen ist es jedoch nicht ausgeschlossen, dass die Position von $mStride fest oder impliziert sein kann oder keinen Operanden im Lade/Speicher-Befehl benötigt.
  • 7 zeigt ein Beispiel des Packens von drei Adressen in zwei 32-Bit-Register in der MRF 26M, wobei jede Adresse 21 Bits hat. 7 zeigt auch ein Beispiel des Packens von drei Abstandswerten in ein 32-Bit-Register in der MRF, wobei jeder Abstandswert 10 Bits hat (in diesem Fall bleiben 2 Bits des Registers unbenutzt). So kann der Lade/Speicher-Befehl über nur zwei 32 Bits breite Ports der MRF in einem einzigen Befehl auf drei Speicheradressen zugreifen. Ein dritter 32 Bits breiter Port kann durch denselben Befehl verwendet werden, um auf das Stride-Register zuzugreifen, das zum Beispiel drei 10-Bit-Abstandswerte (Adressendeltas) in drei 10 Bits breiten Feldern enthält, die in 32 Bits breite Stride-Register in der MRF gepackt sind (wobei 2 Bits dieses Registers unbenutzt gelassen werden). Man beachte, dass das in 7 dargestellte spezielle Packen nur ein Beispiel ist. Zum Beispiel kann in einer anderen Anwendung addr2 die zwei Register überspannen, anstelle addr1.
  • 8 zeigt eine Anordnung mehrerer Stride-Register $mStrideA, $mStrideB, $mStrideC, ... in der MRF 26M. Jedes von diesen könnte als Stride-Register $mStride durch den entsprechenden Operanden des Lade/Speicher-Befehls bestimmt werden. Jedes mögliche Stride-Register weist mehrere Felder auf, z.B. in Ausführungsbeispielen drei (obwohl abhängig von der Anwendung nicht notwendigerweise die gleiche Anzahl von Feldern oder Stride-Registern existieren muss wie es Lade- und Speicheradressen gibt). Für jede der zwei Ladeadressen und der einen Speicheradresse kann der jeweilige direkte Operand im Satz von direkten Strimm eines der möglichen Felder im Stride-Register $mStride bestimmen, aus dem ein jeweiliger Abstandswert zu nehmen ist (ein Adressdelta, das auf die folgende der jeweiligen Lade- oder Speicheradresse anzuwenden ist). Falls zum Beispiel in Ausführungsbeispielen der Stride-Operand 2 Bits für jede der zwei Ladeadressen und der einen Speicheradresse ist, dann bestimmen drei der möglichen Werte verschiedene der drei Stride-Felder und der andere mögliche Wert bestimmt einfach einen Stride von einem, ohne auf einen in einem Register gehaltenen Wert Bezug zu nehmen. Z.B. würde 00 einen Stride von 1 (Atom) bestimmen, während 01 ein erstes Feld im Stride-Register bestimmen würde, 10 ein zweites Feld im Stride-Register bestimmen würde und 11 ein drittes Feld im Stride-Register bestimmen würde.
  • Man beachte, dass in Ausführungsbeispielen einer der möglichen Abstandswerte direkt einen Standardanstieg von 1 bestimmt anstatt ein Feld im Stride-Register $mStride.
  • Im Betrieb bei Ausführung durch die Ausführungseinheit triggert der Opcode des Lade/Speicher-Befehls (nach Decodierung durch die Decodierstufe 16) die LSU 55, um die folgenden Vorgänge durchzuführen. Sie lädt die Werte aus den zwei Ladeadressen im Speicher 22, wie sie durch die in $mAddr in der MRF 26M gehaltene Adresse bestimmt sind, in das durch $aDsc bestimmte Ziel in der ARF 26A. Ferner speichert sie den/die Wert(e) aus $aSrc in der ARF in die Speicheradresse im Speicher 22, wie sie durch die in $mAddr in der MRF gehaltenen Adresse bestimmt ist/sind. Die LSU 55 erhöht dann jede der zwei Lade- und der einen Speicheradresse um den jeweiligen Abstandswert aus dem Feld des jeweiligen Stride-Registers $mStride in der MRF, wie er durch den jeweiligen der drei direkten Operanden Strimm bestimmt ist, weiter.
  • Man beachte: Für jede der zwei Lade- und der einen Speicheradresse der aktuellen Instanz des Lade/Speicher-Befehls erhöht der Stride-Vorgang des aktuellen Befehls die jeweilige Adresse um den jeweiligen Stride nach jedem der Lade- bzw. Speichervorgänge des aktuellen Lade/Speicher-Vorgangs. Abhängig von der Anwendung kann dies bedeuten, dass alle Erhöhungen zusammen nach sowohl den Lade- und Speichervorgängen angewendet werden, z.B. Laden, Laden, Speichern, Erhöhen, Erhöhen, Erhöhen. Alternativ kann der Stride-Vorgang die jeweilige Adresse direkt nach jedem Lade- bzw. Speichervorgang erhöhen, z.B. Laden, Erhöhen, Laden, Erhöhen, Speichern, Erhöhen. Tatsächlich kann auch das Speichern vor einem oder beiden der Ladevorgänge kommen. Was von Bedeutung ist, ist nur, dass die Erhöhung jeder Ladeadresse nach dem jeweiligen Laden erfolgt und die Erhöhung der Speicheradresse nach dem Speichern erfolgt. Der springende Punkt ist, die Lade- und Speicheradressen in der MRF bereit für eine anschließende Instanz des Lade/Speicher-Befehls weiterzubewegen.
  • In Ausführungsbeispielen hat der Speicher 11 (oder wenigstens der Datenspeicher 22) nur zwei 64-Bit-Ports zum Laden von Daten aus dem Speicher und nur einen 64-Bit-Port zum Speichern von Daten in den Speicher. In Ausführungsbeispielen hat die MRF 26M (oder ein gegebener Kontext) nur drei 32-Bit-Ports zur Lade/Speicher-Einheit 55; und hat die ARF 26A (oder ein gegebener Kontext) nur einen 64-Bit-Port zur Lade/Speicher-Einheit 55. (Man beachte: im dargestellten Beispiel wird die IALU 56 verwendet, um die Pointer aus der MRF 26M abzurufen und die Adressen aus diesen zu berechnen, um sie zur LSU 55 zu leiten, so arbeitet die IALU 56 praktisch als Teil der LSU 55. Daher weisen in diesem Beispiel die drei Ports von der MRF 26M zur LSU 55 die drei Ports von der MRF 26M zur IALU 56 auf. Es ist auch nicht ausgeschlossen, dass in anderen Anwendungen die LSU 55 die Pointer aus der MRF 26M direkt abrufen und ihre eigenen Adressen basierend darauf berechnen kann.)
  • In Ausführungsbeispielen können die vier 32-Bit-Zielregister $aDst0:Dst0+3 in der ARF (128 Bits insgesamt) verwendet werden, um aus dem Speicher 22 z.B. einen 4-Element-Vektor von 16-Bit-Gleitkomma-(f16)-Werten und einen 2-Element-Vektor von 32-Bit-Gleitkomma-(f32)-Werten zu laden. Die zwei 32-Bit-Quellenregister $aSrc0:Src+1 in der ARF (64 Bits insgesamt) können verwendet werden, um zum Beispiel einen 2-Element-Vektor von 32 Bits von f32-Werten in den Speicher 22 zu speichern.
  • Zur Verwendung in einem Programm ist der Lade/Speicher-Befehl zwischen anderen Befehlstypen wie beispielsweise arithmetischen Befehlen eingestreut, die Eingaben von den Zielen der Ladebefehle nehmen, basierend darauf Vorgänge durchführen und Ergebnisse an die Quellen des Lade/Speicher-Befehls ausgeben. D.h. das Programm weist Instanzen des Lade/Speicher-Befehls und Instanzen von wenigstens einem arithmetischen Befehl, wie beispielsweise dem Vektor-Skalarprodukt-Befehl, dem Matrixprodukt-Befehl, dem akkumulierenden Vektor-Skalarprodukt-Befehl, dem akkumulierenden Matrixprodukt-Befehl oder dem Faltungsbefehl, wie sie zuvor erwähnt wurden, auf; wobei die Ziele von wenigstens manchen der Lade/Speicher-Befehle die Quellen von wenigstens manchen der arithmetischen Befehle sind und die Ziele von wenigstens manchen der arithmetischen Befehle die Quellen von wenigstens manchen der Lade/Speicher-Befehle sind. Aufgrund der hohen semantischen Dichte des Lade/Speicher-Befehls mit seiner zwei Lade- und einen Speicher-Funktionalität ermöglicht es dies dem Programm, durch die Daten mit einem kleinen auf den Lade- und Speichervorgänge verbrauchten Code-Overhead effizient zu arbeiten.
  • Zum Beispiel kann das Programm eine Reihe von Befehlspaaren aufweisen, wobei jedes Befehlspaar aus einer Instanz des Lade/Speicher-Befehls gefolgt von einer entsprechenden Instanz eines arithmetischen Befehls besteht. In jedem Befehlspaar ist die Quelle des Lade/Speicher-Befehls als das Ziel des arithmetischen Befehls von einem vorherigen Paar gesetzt und sind die Ziele des Lade/Speicher-Befehls als die Quellen des entsprechenden arithmetischen Befehls im aktuellen oder einem anschließenden Paar gesetzt. Man betrachte zum Beispiel einen arithmetischen Befehl „arith“ mit der Syntax:
    • arith $aDst, $aSrcA, $aSrcB
    wobei sich $aDst auf einen Operanden bezieht, der ein Ziel in der ARF 26A bestimmt; und sich $aSrcA, $aSrcB auf Operanden beziehen, die zwei Quellen in der ARF bestimmen (selbstverständlich ist „arith“ ein generischer Name, der hier für einen beliebigen arithmetischen Befehl mit wenigstens dieser Syntax benutzt wird). Das Programm kann dann mit einer Reihe von Befehlspaaren programmiert sein, zum Beispiel:
    ... ...
    Idx2st Xin-Pin, Pout, Tripacked, Strides; arith Pout, Xin, Pin;
    Idx2st Xin-Pin, Pout, Tripacked, Strides; arith Pout, Xin, Pin;
    Idx2st Xin-Pin, Pout, Tripacked, Strides; arith Pout, Xin, Pin;
    Idx2st Xin-Pin, Pout, Tripacked, Strides; arith Pout, Xin, Pin;
    ... ...
    oder:
    ... ...
    Idx2st Xin-Pin, Pout_A, Tripacked, Strides; arith Pout_A, Xin, Pin;
    Idx2st Xin-Pin, Pout_B, Tripacked, Strides; arith Pout_B, Xin, Pin;
    Idx2st Xin-Pin, Pout_A, Tripacked, Strides; arith Pout_A, Xin, Pin;
    Idx2st Xin-Pin, Pout_B, Tripacked, Strides; arith Pout_B, Xin, Pin;
    ... ...
    etc.
  • In Ausführungsbeispielen ist jedes Paar ein Befehlsbündel, d.h. es wird simultan ausgeführt durch jeweilige Pipelines. Z.B. wird in Ausführungsbeispielen der Lade/Speicher-Befehl durch die Haupt-Pipeline unter Verwendung der MRF 26M ausgeführt und wird der arithmetische Befehl durch die Zusatz-Pipeline unter Verwendung der ARF 26A parallel ausgeführt. In alternativen Realisierungen ist es jedoch nicht ausgeschlossen, dass der Lade/Speicher- und der arithmetische Befehl einer nach dem anderen durch eine Ein-Pipeline-Verarbeitungseinheit ausgeführt werden können.
  • In den Instanzen des Lade/Speicher-Befehls (Idx2st) bezieht sich Xin-Pin auf die Ziele $aDsc der zwei Ladevorgänge in der ARF 26A (z.B. ein 4xf16-Eingangsvektor Xin und ein 2xf32-Eingangsvektor Pin geladen in vier 32-Bit-Registern $aDsc0:Dsc0+3); und bezieht sich Pout_A oder Pout_B auf die Quelle des Speichervorgangs in der ARF (z.B. 2xf32-Werte gespeichert aus zwei 32-Bit-Registern $aSrc0:Scr0+1). „Tripacked“ bezieht sich auf das dreifach gepackte Adressenregisterpaar $mAddr0:Addr0+1 in der MRF 26M (z.B. drei 21-Bit-Adresspointer in zwei 32-Bit-Registern haltend). „Strides“ bezieht sich auf die Stride-Operanden $mStride und Strimm, welche den Stride für jeden der zwei Lade- und des einen Speichervorgangs bestimmen, durch Bezugnahme auf ein Feld im Stride-Register $mStride in der MRF, das durch drei direkte Werte Strimm bestimmt ist (siehe wieder 8). In den Instanzen des arithmetischen Befehls beziehen sich Xin, Pin auf die Quellenregister, aus denen Eingaben des arithmetischen Befehls genommen werden, die auf das Gleiche wie die Ziele des Ladevorgangs gesetzt werden, der durch den Lade/Speicher-Befehl im aktuellen oder einem vorherigen Befehlspaar durchgeführt wird. Pout bezieht sich auf das Ziel für die Ausgabe des arithmetischen Befehls in der ARF, welches auf den gleichen wie die Quelle des Speichervorgangs des Lade/Speicher-Befehls in einem anschließenden Befehlspaar gesetzt ist. In Ausführungsbeispielen, die jedes Paar als ein Bündel von zwei simultanen Befehlen ausführen, sind Xin, Pin auf das Gleiche wie die Ziele des Ladevorgangs gesetzt, der durch den Lade/Speicher-Befehl im vorherigen Bündel durchgeführt wird; und ist Pout auf das Gleiche wie die Quelle des Speichervorgangs des Idx2st im nächsten Bündel gesetzt. Dies benutzt die gleichen Register weiter, aber weil die zwei Befehle parallel ausgeführt werden, sind die Eingangsdaten für den aktuellen arithmetischen Befehl das, was von dem vorherigen Ladebefehl gelesen wurde. Der aktuelle Idx2st benutzt dann jene gleichen Register weiter, um die Eingangsdaten für den nächsten arithmetischen Befehl vorzubereiten.
  • So speichert in jedem Paar der Lade/Speicher-Befehl (Idx2st) die aktuell in einem Register Pout aus einem vorherigen arithmetischen Befehl in einem vorherigen Befehlspaar (z.B. Bündel) gefundene Ausgabe und lädt auch Werte aus dem Speicher in die Register Xin und Pin. Der folgende arithmetische Befehl im gleichen Paar (z.B. Bündel) führt einen arithmetischen Vorgang basierend auf zuvor geladenen Werten und Ausgaben an ein Register Pout zum Speichern durch den Speichervorgang eines anschließenden Lade/Speicher-Befehls in einem anschließenden Paar durch.
  • Man beachte, dass der arithmetische Befehl in Ausführungsbeispielen wenigstens eine dritte implizite Quelle in der gemeinsam benutzten WRF 26W hat. Diese können durch den Supervisor-Thread gesetzt sein, der in die WRF schreibt. So setzt der Supervisor gemeinsame Gewichtungen, die durch die arithmetischen Vorgänge aller ausführenden Worker-Threads implizit zu verwenden sind.
  • Die Werte der Speicheradressen „Tripacked“, die $mAddr0:Addr0+1 in der MRF 26M bestimmen, werden durch den jeweiligen Worker auch auf manche Anfangswerte gesetzt. Die Abstandswerte in den Feldern jedes möglichen Stride-Registers $mStride in der MRF werden ebenfalls durch den jeweiligen Worker gesetzt. Jedes Mal, wenn der Lade/ Speicher-Befehl ausgeführt wird, wird jede der drei Adressen (zwei Ladeadressen und eine Speicheradresse) in den Speicheradressregistern $mAddr0:Addr0+1 danach um den jeweiligen Abstandswert erhöht. Siehe wieder 7 und 8. Sage zum Beispiel, dass der Lade/Speicher-Befehl $mStride = $mStrideA und Strimm = 011000 (erster direkter Stride-Operand ist 01, zweiter = 10 und dritter = 00) bestimmt. Dies bedeutet, dass er nach dem Durchführen des ersten Ladevorgangs die erste Ladeadresse um den Abstandswert im Feld 0 von $mStrideA erhöht; nach dem Durchführen des zweiten Ladevorgangs die zweite Ladeadresse um den Abstandswert im Feld 1 von $mStrideA erhöht; und nach dem Speichervorgang die Speicheradresse um die atomare Erhöhung (Erhöhung um einen Speicheradressenschritt von 1 im benutzten Adressenraum) erhöht. Anschließende Instanzen des Lade/Speicher-Befehls können so gesetzt werden, dass sie den gleichen oder einen anderen Wert von $mStride und die gleichen oder andere Werte jedes der drei direkten Operanden bestimmen. So können mit jedem Lade/Speicher-Befehl in der Reihe die Positionen der Ladeadressen und der Speicheradresse in einer kontrollierbaren Weise weiterbewegt werden. So kann der Code durch den Eingangsdatenraum in einer flexiblen Weise effizient gescannt werden, ohne zusätzliche arithmetische Ganzzahl-Befehle zum Berechnen neuer Adressen zu benötigen.
  • 9 zeigt eine beispielhafte Anwendung, bei der dies nützlich sein kann, nämlich das Durchführen einer Faltung eines Kernels K mit einem mehrdimensionalen Teil von Eingangsdaten Xin. Zum Beispiel können die Eingangsdaten ein 3D-Volumen von Eingangsdaten sein und der Kernel K kann ein 3D-Kernel sein. Die Eingangsdaten können auch Eingangskanäle genannt werden, und die Ausgangsdaten können auch die Ausgabefunktionskanäle genannt werden. Wo gesagt wird, dass die Daten mehrdimensional sind, bedeutet dies, dass die Daten einen Wert an jeder von mehreren Kombinationen von Koordinaten in einem zwei- oder mehrdimensionalen Koordinatensystem nehmen, wobei jede Dimension (d.h. jede Achse) eine andere unabhängige Variable darstellt (und der Wert der Daten bei einer gegebenen Koordinatenkombination die abhängige Variable ist).
  • Ein Beispiel hierfür wäre in einer Bildverarbeitung, bei der jeder Datenwert ein Pixel darstellt. Zum Beispiel werden typischerweise 8 Bits für jedes von Rot, Grün und Blau benutzt; und jene 8-Bit-Ganzzahlwerte werden dann vor dem Faltungsvorgang in f16-Werte umgewandelt. Jeder R,G,B-Wert wird als separate Eingabeebene behandelt (d.h. separat eingegebener Kanal). So hat jedes 2D-Eingangsbild x,y,z-Dimensionen, wobei die R,G,B-Ebenen die z-Achse besiedeln. Das Datenvolumen kann zum Beispiel eine Sequenz von Frames aufweisen, wobei zwei Dimensionen des Volumens die räumliche x- und y-Achse des Frame-Bereichs darstellen und die dritte Dimension die Zeitachse entsprechend verschiedenen Frames in der Sequenz darstellt. In einem anderen Beispiel können die drei Dimensionen des Volumens drei räumliche x-, y- und z-Dimensionen eines 3D-Modells oder Bildes eines Raumes oder Gegenstandes darstellen. In einem anderen Beispiel können die Daten nur zweidimensional die räumliche x- und y-Achse eines Standbildes darstellen, wobei die z-Achse eine Anzahl von gleichzeitig zu verarbeitenden Eingangsbildern darstellt. Man beachte, dass die Anwendbarkeit der offenbarten Techniken nicht auf Bild- oder Grafikverarbeitung beschränkt ist und auch Daten mit höherer Dimensionalität nicht ausgeschlossen sind. Z.B. können die zwei, drei oder mehr Dimensionen verschiedene Aspekte von Benutzern oder ihren Bedingungen in einem eine Anwendung lernenden Benutzerverhalten, etc. darstellen.
  • Der Kernel K ist eine Matrix vorbestimmter Gewichtungen. Er kann eine bestimmte Funktion darstellen, für deren Erkennung das neuronale Netz trainiert wird, oder nach der in einer anschließenden Schlussfolgerung gesucht wird. Im Fall zum Beispiel von Bilddaten kann der Kernel eine Kante oder irgendeine andere Art von Form darstellen. In einer Maschinenlernanwendung kann jeder Knoten im neuronalen Netz einem jeweiligen Kernel entsprechen (obwohl es, wie später diskutiert, in vielen neuronalen Netzen mehrere Knoten 102 gibt, die dieselben Kernel-Werte benutzen, aber nur verschiedene Verbindungen 104 haben). In Ausführungsbeispielen wird jeder Knoten 102 durch einen jeweiligen Worker-Thread dargestellt, sodass jeder Thread eine jeweilige Faltung eines Kernels K mit den jeweiligen Eingangsdaten des Threads durchführt. Zumindest manche der Worker-Threads können den gleichen Kernel K benutzen, dessen Werte in der gemeinsam benutzten Gewichtungsregisterdatei WRF 26W gespeichert sind, aber jeder solche Thread faltet diesen Kernel mit seinen eigenen jeweiligen Eingangsdaten, die über seine eigene jeweilige Zusatz- (oder arithmetische) Registerdatei ARF 26A aus und in den Speicher 22 gestreamt werden.
  • Eine einzelne Faltung (*) in drei Dimensionen kann ausgedrückt werden als: Xin*K [ x ,y ,z ] = ∑ _x' ,y' ,z' ( K [ x' ,y' ,z' ] Xin [ x − x' , y − y' , z − ] )
    Figure DE102019112352A1_0001
  • Eine Faltung weist so ein systematisches Scannen des Kernels K über manche oder alle möglichen Positionen auf, an denen der Kernel mit den Eingangsdaten überzogen sein kann. An jeder solchen Position wird jedes Pixel (oder jeder Datenpunkt) in dem Teil der Eingangsdaten, der mit dem Kernel überlappt, mit dem Wert des Kernels am entsprechenden Überlagerungspunkt multipliziert, und die Ergebnisse jeder dieser einzelnen Multiplikationen werden summiert, um eine skalare Ausgabe zu geben, die die Faltung des Kernels mit den Eingangsdaten an dieser speziellen Überlagerungsposition darstellt. Dies wird dann an verschiedenen gescannten Positionen des Kernels relativ zu den Eingangsdaten Xin wiederholt, um ein entsprechendes Volumen von Ausgangsdaten zu geben (ein skalarer Wert je Kernel-Position). Zum Beispiel kann in dem in 9 dargestellten Beispiel der Kernel K in einer Ecke im Volumen der Eingangsdaten Xin platziert beginnen, und jeder Kernel-Wert wird mit dem Datenpunkt multipliziert, den er überlagert, wenn der Kernel an dieser Position ist. Der Kernel wird dann in einem Schritt entlang der Länge des Volumens bewegt und die Punktmultiplikationen und die Summe werden wieder durchgeführt, dieses Mal mit dem Kernel an der neuen Position, etc. Wenn der Kernel entlang der gesamten Länge des Volumens gescannt worden ist, wird er zu einer neuen Koordinatenposition verschoben und der Längs-Scan wird wieder durchgeführt, etc., bis das gesamte Volumen gescannt worden ist. Der Kernel erzeugt an jeder gegebenen Position ein Pixel (einen skalaren Wert) der Ausgangsdaten. Daher haben die Ausgangsdaten Xout die gleiche oder eine ähnliche Größe wie die Eingangsdaten, abhängig von der Schrittgröße des Faltungsscans.
  • In der Praxis muss dies in kleinere Vorgänge untergliedert werden. Dies kann durch Aufsplitten der Faltung der Daten mit dem Kernel an einer gegebenen Position in eine Anzahl von einzelnen Vektor-Skalarprodukten und Teilsummen erfolgen. Dies ist in der mittleren und der rechten Seite von 9 veranschaulicht. Der Kernel ist zum Beispiel 3x3x16 Pixel groß („Pixel“ bezeichnet im Sinne der vorliegenden Offenbarung nicht unbedingt Bilder). D.h. er besteht aus 3x3x16 vorbestimmten Gewichtungswerten. Dies kann in neun 16-Element-Vektoren CW untergliedert werden (hier auch als Teil-Kernel des Kernels K bezeichnet). Zuerst wird das Skalarprodukt zwischen einem dieser neun Vektoren und den Eingangsdaten an der entsprechenden Position genommen, um eine Teilsumme P (ein Skalar) zu geben. Dann wird das Skalarprodukt zwischen einem weiteren der neun Vektoren genommen und mit der ersten Teilsumme akkumuliert, um eine zweite Teilsumme (auch ein Skalar) zu geben. Dann wird das Skalarprodukt zwischen einem anderen der neun 16-Elelement-Vektoren genommen und das Ergebnis davon wird mit der zweiten Teilsumme akkumuliert, um eine dritte Teilsumme zu ergeben, etc. Wenn dies einmal erfolgt ist, um über alle neun Vektoren zu akkumulieren, ergibt das Akkumulationsgesamtergebnis den Wert eines einzelnen Punktes oder Pixels in den Ausgangsdaten Xout. Dies wird dann an jeder Kernel-Position wiederholt, wenn der Kernel K über verschiedene Positionen relativ zum Volumen der Eingangsdaten Xin gescannt wird, wodurch sich ein entsprechendes Volumen von Ausgangsdaten Xout ergibt (ein Ausgangsdatenpunkt je Kernel-Position).
  • In Ausführungsbeispielen enthält der Befehlssatz des Prozessors 4 zum Mitwirken beim Durchführen von Berechnungen wie beispielsweise Faltungen in einer effizienten Art und Weise einen arithmetischen Befehl in der Form eines akkumulierenden Produktbefehls („amp“). Dieser hat die Syntax:
    • amp $aDst, $aSrcA, $aSrcB, Phase
    wobei sich $aDst wieder auf einen Operanden bezieht, der ein Ziel in der ARF 26A bestimmt; und sich $aSrcA, $aSrcB auf Operanden beziehen, die zwei Quellen in der ARF bestimmen. „Phase“ ist ein direkter Operand, der eine Phase der Akkumulation bestimmt. Zum Beispiel wird in Ausführungsbeispielen der Phasenoperand aus zwei Bits gebildet, die eine von vier möglichen Phasen 0...3 bestimmen. In Ausführungsbeispielen kann der amp-Befehl auch als f16v4sisoamp bezeichnet werden, Bezug nehmend auf die Tatsache, dass er einen Vektor von vier Gleitkommawerten halber Genauigkeit (16 Bit) als eine erste Eingabe und einen Gleitkommawert mit einfacher Genauigkeit (32 Bit) als eine zweite Eingabe nimmt; und einen Gleitkommawert einer einfachen Genauigkeit (32 Bit) ausgibt („siso“ bezieht sich auf „Eingabe einfacher Genauigkeit, Ausgabe einfacher Genauigkeit“). Tatsächlich ist in Ausführungsbeispielen die zweite Eingabe ein Paar von zwei Gleitkommawerten einfacher Genauigkeit (2 x 32 Bits), ebenso wie die Ausgabe. Es ist jedoch selbstverständlich, dass diese besonderen Genauigkeitswerte und Anzahlen von Elementen nicht auf alle möglichen Ausführungsbeispiele einschränkend sind.
  • Für einen oder mehrere Befehlstypen wie beispielsweise amp ist in Ausführungsbeispielen die Position der Gewichtungen in der WRF vollständig impliziert. Alternativ oder zusätzlich können eine oder mehrere andere Befehlstypen einen zusätzlichen Operanden (nicht dargestellt) nehmen, der bestimmt, welcher Satz von Gewichtungen aus einigen unterschiedlichen Sätzen in der WRF zu benutzen ist. Z.B. kann ein Beispiel der später beschriebene schlanke Faltungsbefehl („slic“) sein.
  • Kombiniert mit den oben beschriebenen Lade/Speicher-Befehlen (Id2xst) kann ein Befehl wie beispielsweise der amp-Befehl benutzt werden, um effizient Daten aus dem Speicher zu streamen, die Skalarprodukte und die Teilsummen durchzuführen und die Teilsummen zurück in den Speicher zu streamen. Man betrachte zum Beispiel ein Programm mit einer Schleifensequenz von vier Befehlspaaren, wie folgt: 
       Loop {
       Idx2st Xin-Pin, Pout, Tripacked, Strides; amp Pout, Xin, Pin, Phase=0;
       Idx2st Xin-Pin, Pout, Tripacked, Strides; amp Pout, Xin, Pin, Phase=1;
       Idx2st Xin-Pin, Pout, Tripacked, Strides; amp Pout, Xin, Pin, Phase=2;
       Idx2st Xin-Pin, Pout, Tripacked, Strides; amp Pout, Xin, Pin, Phase=3;
       }
  • Eine weitere beispielhafte Version wäre: 
    •        Loop {
       Idx2st Xin-Pin, Pout_A, Tripacked, Strides; amp Pout_A, Xin, Pin, Phase=0;
       Idx2st Xin-Pin, Pout_B, Tripacked, Strides; amp Pout_B, Xin, Pin, Phase=1;
       Idx2st Xin-Pin, Pout_A, Tripacked, Strides; amp Pout_A, Xin, Pin, Phase=2;
       Idx2st Xin-Pin, Pout_B, Tripacked, Strides; amp Pout_B, Xin, Pin, Phase=3;
       }
    etc.
  • Wieder ist in Ausführungsbeispielen jedes Paar ein Befehlsbündel, d.h. simultan ausgeführt über jeweilige Pipelines, z.B. die Haupt- und Zusatz-Pipelines.
  • Jedes Befehlspaar weist eine Instanz des Lade/Speicher-Befehls gefolgt von einer Instanz des akkumulierenden Produktbefehls (amp) auf. Die Quellen des amp-Befehls sind die Ziele der zwei Ladevorgänge, die vom Lade/Speicher-Befehl im gleichen oder einem vorherigen Befehlspaar durchgeführt werden. In Ausführungsbeispielen, die jedes Paar als ein Bündel aus zwei simultanen Befehlen ausführen, werden die Quellen des amp (Xin, Pin) so gesetzt, dass sie die gleichen wie die Ziele des im vorherigen Bündel durchgeführten Ladevorgangs sind. Das Ziel des amp-Befehls ist die Quelle des einen durch den Lade/Speicher-Befehl in einem anschließenden Befehlspaar, z.B. nächsten Bündel, durchgeführten Speichervorgangs. Eine der Quellen $aSrcA, $aSrcB des amp-Befehls wird benutzt, um einen Eingangsvektor x aus den Eingangsdaten Xin zu nehmen. Die andere wird benutzt, um eine Teilsumme zu nehmen. Der amp-Befehl führt bei seiner Ausführung ein Skalarprodukt seines Eingangsvektors x mit einem entsprechenden Vektor von Gewichtungen CW aus der Gewichtungsregisterdatei WRF 26W durch (dieser Vektor CW ist ein Teil-Kernel des gesamten oder 3D-Kernels K). Der Phasenoperand bestimmt eine Phase für den Zweck des Akkumulierens der Ergebnisse der Skalarprodukte. In jedem Befehlspaar der Sequenz in einer gegebenen Instanz der Schleife wird der Phasenoperand auf einen anderen jeweiligen Wert gesetzt, der eine andere folgende Phase der Sequenz bestimmt. Über diese folgenden Phasen in der Sequenz, wie sie durch den Phasenoperanden bestimmt werden, ist der Effekt des amp-Befehls das Akkumulieren der Ergebnisse aller aufeinander folgenden Skalarprodukte. Die Akkumulation beginnt in der ersten Phase in der Sequenz mit einer Eingangsteilsumme.
  • Die Stride-Funktionalität des Lade/Speicher-Befehls ermöglicht es dem Programm, die Speicheradressen mit jedem Befehlspaar automatisch zum nächsten Datenstück weiterzuschieben, ohne separate arithmetische Ganzzahl-Befehle zu benötigen, um neue Speicheradressen zu berechnen, die in die MRF 26M einzugeben sind. Die Möglichkeit des beschriebenen Lade/Speicher-Befehls, irgendeine Anzahl von vorprogrammierten Strides aus dem Stride-Register $mStride auszuwählen, ist besonders nützlich beim Verarbeiten von mehrdimensionalen Daten, wie beispielhaft in 9 veranschaulicht. Der Speicherraum ist eindimensional, aber die Daten können zwei, drei oder noch mehr Dimensionen haben. Abhängig vom Mapping des 1D-Speicherraums zum mehrdimensionalen Datenraum kann es dann, wenn der Kernel K durch die Eingangsdaten Xin gescannt wird, manchmal notwendig sein, unterschiedlich große Schritte durch die entsprechenden Speicheradressen im Speicherraum zu machen. Wenn zum Beispiel der Kernel K längs entlang einer Dimension der Eingangsdaten Xin gescannt wird, dann kann die Speicheradresse der Daten an jeder Scanposition in atomaren Schritten erhöht werden, aber wenn der Scan in der senkrechten Ebene verschoben werden muss, dann kann ein anders großer Schritt in der Speicheradresse benötigt werden, um zum nächsten Stück oder Teilsatz der Eingangsdaten Xin zu gelangen (und unabhängig davon wird der gleiche Prozess für die zweiten Eingangs- und Ausgangsadressen durchgeführt). Die unterschiedlichen Felder im Stride-Register $mStride oder den Stride-Registern (z.B. $mStrideA, $mStrideB, ...) können vorteilhafterweise mit unterschiedlich großen Sprüngen im Speicherraum vorprogrammiert sein. Der Programmierer oder Compiler kann dann die direkten Operanden Strimm setzen, um auszuwählen, welche Sprunggröße auf einer Je-Lade/Speicher-Befehl-Basis ausgewählt werden soll (ohne Bedarf an separaten arithmetischen Ganzzahl-Befehlen, um die nächste Adresse oder die nächste Schrittgröße neu zu berechnen).
  • In Ausführungsbeispielen ist der amp-Befehl ein akkumulierender Matrixprodukt-Befehl. Der Vorgang hierzu wird bezugnehmend auf 10 bis 12 beschrieben. Wie in 10 dargestellt, führt der amp-Befehl bei seiner Ausführung durch die FPU eine Multiplikation einer MxN-Matrix von Gewichtungen (aus der WRF 26W) mit einem N-Element-Eingangsvektor aus den Eingangsdaten Xin durch. In Ausführungsbeispielen ist M=8 und N=16. Man beachte, dass jede der M Reihen der Matrix einem Teilvektor aus unterschiedlichen jeweiligen Kernels K0, K1...KM-1 entspricht. Daher wird der amp-Befehl benutzt, um eine Komponente der Faltung von M verschiedenen Kernels K mit den Eingangsdaten parallel durchzuführen. Zum Beispiel kann jeder dieser Kernels einer Faltung einer anderen jeweiligen Funktion (z.B. andere Kante oder Form) mit den Eingangsdaten entsprechen. Im Fall eines neuronalen Faltungsnetzes sind dies Funktionsfilter, wobei jeder der M Kernels versucht, das Vorhandensein einer anderen Funktion in den Eingangsschichten zu erfassen. Für einen gegebenen Kernel K führt der amp-Befehl nur ein Skalarprodukt und eine Akkumulation durch. Die Matrix erlaubt jedoch eine effiziente parallel Faltung mehrerer Kernels mit den Daten.
  • Der N-Element-Eingangsvektor ist in N1 Segmente unterteilt, die jeweils einen Subvektor von N2 Elementen aufweisen (somit N=N1xN2). In Ausführungsbeispielen ist N1=4 und N2=4. Der Phasenoperand des amp-Befehls nimmt einen von N1 verschiedenen möglichen Werten 0...N1-1 entsprechend den N1 verschiedenen Segmenten. In jeder Instanz der Schleifensequenz nimmt der amp-Befehl in jedem aufeinander folgenden Paar einen anderen Wert des Phasenoperanden, der eine andere folgende Phase 0...N1-1 bestimmt. Jede Phase führt das Skalarprodukt eines entsprechenden der N1 Subvektoren des N-Element-Eingangsvektors und jeder der M Reihen der Matrix durch (so ein Teil der Berechnung für jeden der M verschiedenen Kernels K). Die FPU in der Ausführungseinheit 18 (in Ausführungsbeispielen in der Zusatz- oder der arithmetischen Ausführungseinheit 18A) hat M Akkumulatorzustände $AACC (je Thread). In Ausführungsbeispielen sind diese als interner Zustand 57 der FPU umgesetzt. In alternativen Anwendungen ist es jedoch nicht ausgeschlossen, dass sie als Register in einer der Registerdateien 26 (z.B. der ARF 26A des jeweiligen Threads) implementiert sein können. Im veranschaulichten Beispiel sind dies geradzahlige Zustände $AACC[0], $[AACC[2] ... $AACC[14]; während die ungeradzahligen Zustände $AACC[1], $AACC[3]...$AACC[15] benutzt werden können, um Werte zwischen verschiedenen Schleifen der Sequenz zu verteilen, aber dies ist ein Anwendungsdetail und nicht einschränkend.
  • 11 zeigt schematisch die Verarbeitung des amp-Befehls. 12 gibt ein Beispiel einer Reihe von amp-Befehlen. Beide sind so zu verstehen, dass ihnen ein entsprechender Lade/Speicher-Befehl eines Befehlspaares vorangeht, wie oben gezeigt. In 12 ist Pn eine Eingangsteilsumme n einfacher Genauigkeit, ist xn ein f16v4-Eingangsvektor, ist Cwm,n der gemeinsame Gewichtungszustand $CWEI_m_n und ist Rn das Endergebnis einfacher Genauigkeit von aufeinander folgenden Skalarprodukt-Akkumulationen, die mit Pn begannen.
  • Bei der Verarbeitung führt die FPU der Ausführungseinheit 18 (in Ausführungsbeispielen die Zusatz-Ausführungseinheit 18A) als Reaktion auf den (decodierten) Opcode des amp-Befehls die folgenden Vorgänge durch.
    • - Aus dem/den Register(n) in der ARF 26A, die durch einen der Quellenoperanden des amp-Befehls bestimmt sind, nimmt sie eine Anzahl M/N1 von Teilsummen und platziert diese vorübergehend in einem Propagatorzustand für die nächste Schleife. Dieser Propagatorzustand kann im internen Zustand 57 der FPU umgesetzt werden, oder er kann in alternativen Anwendungen ein anderes Register in einer der Registerdateien 26 (z.B. der ARF) sein. Jede Phase nimmt einen anderen Teilsatz von M/N1 Teilsummen. Über die N1 Phasen werden M solche Teilsummen in den Propagatorzustand genommen. Falls M=8 und N1=4, nimmt so dann jeder amp-Befehl zwei Teilsummen (z.B. zwei f32-Werte) als eine Eingabe und hält diese im Propagatorzustand, und über alle vier Phasen werden dann acht Teilsummen empfangen.
    • - Aus dem/den Register(n) in der ARF 26A, die durch einen der Quellenoperanden des amp-Befehls bestimmt sind, nimmt sie ein N2-Element-Segment (Subvektor) des Eingangsvektors xin. Für jede der M Reihen in der Matrix (somit jeden der M Kernels K0...KM-1) führt sie ein Skalarprodukt davon mit einem entsprechenden Subvektor von Gewichtungen CW aus der WRF durch. Aus welcher Spalte der Subvektor von Gewichtungen genommen wird, hängt vom Wert des Phasenoperanden ab. Ferner wird, falls die Phase die erste (d.h. Anfangs-)Phase in der Sequenz ist, dann eine entsprechende der Teilsummen ebenfalls zu jedem der M Skalarprodukte addiert. Man beachte, dass, weil jeder amp-Befehl in der vorherigen Schleife eine jeweilige M/N1 Teilsumme nahm, wobei N1 die Anzahl der Phasen ist, dann die vorherige Schleife alle M Teilsummen im Propagatorzustand für die aktuelle Schleife bereitgestellt hat.
    • - Für jede der M Reihen wird das Ergebnis der obigen Berechnungen mit irgendeinem Wert, der bereits in einem entsprechenden der M Akkumulatorzustände $AACC ist, akkumuliert (aufsummiert), womit ein entsprechendes von M Ergebnissen R0...RM-1 erzeugt wird. Über die N1 Phasen wird der amp-Befehl so ein Skalarprodukt des gesamten N-Element-Eingangsvektors mit einem entsprechenden N-Element-Vektor von Gewichtungen aus der WRF durchführen.
    • - In der aktuellen Schleife wird eine Anzahl M/N1 von Ergebnissen R aus der vorherigen Schleife an das/die Zielregister in der ARF ausgegeben, die durch den Zieloperanden des amp-Befehls bestimmt sind. Jede Phase gibt einen anderen Teilsatz von M/N1 Teilsummen aus, und über die N1 Phasen werden M solche Teilsumme in den Propagatorzustand genommen. So werden in Ausführungsbeispielen mit M=8 und N=4 dann zwei Ergebnisse je amp-Befehl (z.B. zwei f32s) ausgegeben und werden alle acht Ergebnisse R0...R7 über alle vier Phasen ausgegeben.
    • - Nach der letzten Phase der aktuellen Schleife (oder zum Start der ersten Phase der nächsten Schleife bevor irgendwelche Ergebnisse überschrieben werden) werden die Ergebnisse R der aktuellen Schleife vorübergehend in einem Propagatorzustand bereit zur Ausgabe in der nächsten Schleife platziert. Dieser Propagatorzustand kann im internen Zustand 57 der FPU umgesetzt sein, oder in alternativen Anwendungen kann er ein anderes Register in einer der Registerdateien 26 sein (z.B. die ARF).
  • Zusammenfassend wird eine einzelne Teilsumme (1) zum ersten Skalarprodukt-Ergebnis hinzugefügt und im Akkumulatorstatus gespeichert (den zuvor gehaltenen Wert überschreibend), (2) mit drei weiteren Skalarprodukt-Ergebnissen akkumuliert und (3) in den vorübergehenden Propagatorstatus kopiert (in welchem Fall dieser Wert zum Zieloperanden eines künftigen amp-Befehls geschrieben wird). Eine Alternative zu Schritt (3) besteht darin, die resultierende Teilsumme direkt aus dem Akkumulator in den Zieloperanden des amp-Befehls zu schreiben. So oder so können die Schritte (1) und (3) in der Hardware überlappt werden, wodurch eine 4-Zyklen-Schleife bereitgestellt wird.
  • In Ausführungsbeispielen muss der Akkumulatorstatus nicht explizit zurückgesetzt werden. Da der Startpunkt für jede Matrixvektor-Multiplikation die aus dem Speicher gelesene Eingangs-Teilsumme ist, hat das Ausgangsvolumen jedes Element zu Beginn der Faltung auf null gesetzt, anstatt den Akkumulatorstatus zurückzusetzen. Das heißt, in Ausführungsbeispielen erlaubt es der Tile 4 einem tatsächlich, alle Akkumulatorstatuse auf null zu initialisieren.
  • Man beachte, dass der Eingangs-Propagatorstatus des aktuellen amp-Befehls zur Verwendung in der nächsten Schleife gehalten wird. Auch ist das durch den amp-Befehl zum Zielregister in der ARF ausgegebene Ergebnis der existierende Akkumulatorstatus bevor der Akkumulationsvorgang des aktuellen amp angewendet wird - es ist das Ergebnis einer vorherigen kurzen Sequenz von Akkumulationen, die die aktuelle Eingabe nicht enthalten.
  • Das Programm ist so ausgestaltet (durch den Programmierer oder Compiler), dass die Ergebnisse R die Teilsummeneingaben P für nachfolgende Schleifen werden. Die exakte Relation liegt am Programmierer oder Compiler und hängt von der Struktur der Daten und des Kernels ab. Typischerweise haben die Teilsummen einen Anfangswert (im Speicher) von 0.
  • Man beachte, dass die Sequenz wegen der Verzögerung zwischen Schleifen eine Aufwärmperiode benötigt. Es gibt eine Wartezeit zwischen einem vorhandenen speziellen Eingangsvektor und dem Ergebnis der 4-Phasen-Berechnung, der durch den amp-Befehl zurückkehrt. Diese Wartezeit ist fest und bedeutet, dass die ersten M Ergebnisse ungültig, uninteressant oder unbedeutend sind und in dem Aufwärm-Code gelöscht werden. Nach dieser Aufwärmperiode, in der kein brauchbares Ergebnis erzeugt wird, tritt der Code dann in die Wiederholungsschleife ein, die vorangeht und die brauchbaren Ergebnisse in die erforderliche Speicherstelle schreibt (im gezeigten Beispiel jeweils 64 Bits). Es gibt auch eine Abkühlperiode nach der inneren Schleife, in der keine neuen Eingaben vorgesehen werden, aber in der die finalen Ausgabewerte gespeichert werden. 12 zeigt die Aufwärmperiode und die „Ergebnis-Latenz“ für f16v4sisoamp.
  • In Ausführungsbeispielen ist die Anzahl der Kernels M=8, ist die Anzahl der Elemente im Eingangsvektor N=16 und ist die Anzahl der Phasen N1=4. In Ausführungsbeispielen ist jedes Element des Eingangsvektors ein f16-Wert und ist jede eingegebene Teilsumme und jedes Ergebnis ein f32-Wert. In solchen Ausführungsbeispielen kann der obige Prozess Daten mit einer Rate von zwei f32-Teilsummen und vier f16-Elementen des Eingangsvektors je Befehlspaar laden und verarbeiten und kann Daten mit einer Rate von zwei f32-Werten je Befehlspaar ausgeben und speichern. Das heißt 128 Bits Eingabe und 64 Bits Ausgabe je Befehlspaar. Dies entspricht den zwei 64 Bit breiten Ladeports und dem einen 64 Bit breiten Speicherport zwischen der LSU 55 und dem Datenspeicher 22 (siehe wieder 4). Auch wegen des Dreifachpackens der Adressen kann der Prozess über zwei 32 Bit breite Ports aus der MRF 26M zur LSU plus einer weiteren für die Strides ausgeführt werden. Zwei 64 Bit breite Ports werden von der ARF 26A zur FPU in der Zusatz-Ausführungseinheit 18A benutzt. 12 zeigt, dass die Schleife für jeden 16-Element-Eingangsvektor acht Ausgangswerte erzeugt (ein Ausgangswert je Kernel). In diesem speziellen Szenario betragen diese Ausgangswerte jeweils 32 Bits. Die obige Schleife arbeitet in jedem Ticket durch sechzehn Eingangswerte (4xf16-Eingangswerte je Befehl). Um diese Eingaberate zu stützen, muss der Prozessor 4 deshalb 8x32-Bit-Werte je 4-Ticket-Schleife erzeugen - was 4x64-Bit-Speicherungen je Schleife oder 1x64-Bit-Speicherung je Ticket ausmacht.
  • Die Gewichtungen CW werden aus der gemeinsam benutzten WRF 26W genommen und sind für jeden Thread die gleichen. Es stellt sich heraus, dass es in Anwendungen, wie beispielsweise neuronalen Netzen, eine Menge Szenarien gibt, in denen es erforderlich ist, den gleichen Satz von Gewichtungen mit unterschiedlichen Daten zu multiplizieren (beispielsweise als Teil einer Faltung). Zum Beispiel können manche Knoten in einem neuronalen Netz exakt die gleichen Gewichtungen, aber verschiedene Verbindungen aufweisen. Z.B. kann jeder Kernel K(m=0 ... M) eine Faltung einer Funktion (z.B. einer Kante oder einer Form) mit den Eingangsdaten (z.B. einer Fläche oder einem Volumen von Grafik-Pixeln) darstellen. Deshalb benötigen die diesen Kernels entsprechenden Worker-Threads keine separaten Gewichtungen. Stattdessen ist nur eine Kopie des dem Supervisor eigenen Gewichtungszustands vorgesehen. Die Verwendung von gemeinsam benutzten Thread-Operanden aus der gemeinsam benutzten Gewichtungsregisterdatei erfordert somit vorteilhafterweise weniger Registerraum für die Gewichtungen. 12 zeigt, dass für jeden 16-Element-Eingangsvektor die Schleife acht Ausgangswerte erzeugt (1 Ausgangswert je Kernel). In diesem speziellen Szenario sind diese Ausgangswerte jeweils 32 Bits. Die obige Schleife arbeitet durch 16 Eingangswerte je 4 Zyklen (4xf16 Eingangswerte je Befehl). Um diese Rate an Eingaben zu unterstützen, erzeugt der Prozessor 4 deshalb 8x32-Bit-Werte je 4-Zyklen-Schleife - was 4x64-Bit-Speicherungen je Schleife oder 1x64-Bit-Speicherungen je Zyklus ausmacht.
  • In Ausführungsbeispielen werden die ungeradzahligen Akkumulatoren $AACC[1], $AACC[3], ..., $AACC[15] verwendet, um die Ergebnisse (Rx) zu staffeln und das Gleiche mit den Teilsummeneingaben (Px) zu machen. Die Teileingaben werden zu zweit in die hinteren Maschinen gespeist - in Akkumulatorregister $AACC[13] und $AACC[15].
  • Jeder Zyklus solcher Werte bewegt sich vorwärts, so in diesem Fall in $AACC[11] und $AACC[9]. Wenn sie die Ziel-AMP-Einheit erreichen, bewegen sie sich in die geradzahligen Akkumulatoren anstatt in die ungeradzahligen für die Akkumulation. Somit {$AACC[15], §AACC[13]} -> {$AACC[11], §AACC[9]} ->{$AACC[7], §AACC[5]} -> {$AACC[2], §AACC[0]}.
  • 13 und 14 zeigen einen weiteren arithmetischen Befehlstyp, der von einem Lade/ Speicher-Befehl der hier beschriebenen Art profitieren kann, nämlich einen Faltungsbefehl, der die über die ARF 26A des jeweiligen Threads gestreamten Eingangsdaten mit einem 2D-Satz von Gewichtungen aus der gemeinsamen Gewichtungsregisterdatei WRF 26W faltet. In Ausführungsbeispielen kann dieser Befehl die Form einer schlanken Gleitkommavektorfaltung halber Genauigkeit (slic-Befehl) annehmen, z.B. bezieht sich „f16v4slic“ auf die Tatsache, dass sie 4-Element-Teilvektoren von f16-Werten bearbeitet. Es hat eine Eingabe halber Genauigkeit und eine Eingabe einfacher Genauigkeit und eine Ausgabe einfacher Genauigkeit. slic ist ähnlich und benutzt die gleiche Hardware wie amp. Dieser Befehl führt jedoch eine 1x4x4-Faltung (was eine wirkliche Faltung ist) für jeden der 2 Kernels durch, anstatt ein akkumulierendes 1x1x16-Skalarprodukt für jeden von 8 Kernels. Tatsächlich kann sie in Ausführungsbeispielen ausgestaltet sein, um eine 1xNx4-Faltung mit N=2, 3 oder 4 durchzuführen.
  • Die akkumulierenden Matrixprodukt („amp“) - und schlanken Faltungs- („slic“) Befehle vereinfachen Hochleistungs-Multiplikations-Akkumulationssequenzen für Szenarien, in denen eine Gewichtungsverteilung über Worker-Kontexte passend ist. In Ausführungsbeispielen können amp- und slic-Befehle für Zahlenformate sowohl einfacher Genauigkeit als auch halber Genauigkeit unterstützt werden und in der gleichen Grundweise arbeiten. Der gemeinsame Berechnungskonfigurationszustand (mit den gemeinsam benutzten Gewichtungen in der WRF 26W) wird durch den Supervisor-Kontext zunächst initialisiert. Zwei Streams von Eingangsdaten werden dann verarbeitet: die eingegebenen Aktivierungsdaten (Pixel) und die Teilsummenwerte, die einen Startwert für eine anschließende Multiplikations-Akkumulations-Sequenz bestimmen (für Faltungen sind diese die teilberechneten Ausgangspixel/aktivierungen). Ein einzelner Stream von Ausgangsdaten wird erzeugt: die resultierenden akkumulierten Teilsummenwerte. Jeder Teilsummen-Eingangswert wird einer Sequenz fester Länge von Multiplikations-Akkumulations-Vorgängen unterzogen, bevor das finale Teilsummenergebnis als eine Ausgabe präsentiert wird. Viele Skalarprodukt- und Akkumulations-Vorgänge finden parallel statt, durchgeführt durch Computergeräte. Der erste Multiplikand wird von dem Eingangsdatenstrom bereitgestellt und der zweite wird durch den gemeinsamen Computerkonfigurationszustand bereitgestellt.
  • Die folgende Tabelle listet manche Beispiele von amp- und slic-Befehlsvarianten auf, von denen irgendwelche oder alle in Ausführungsbeispielen in dem Befehlssatz des Prozessors enthalten sein können.
    Befehl Eingangsdatenformat Eingangsteilsummenformat Ausgangsteilsummenformat
    f16v4sisoamp halbe Genauigkeit (v4) einfache Genauigkeit (v2) einfache Genauigkeit (v2)
    f16v4hihoamp halbe Genauigkeit (v4) halbe Genauigkeit (v2) halbe Genauigkeit (v2)
    f16v4sihoamp halbe Genauigkeit (v4) einfache Genauigkeit (v2) halbe Genauigkeit (v2)
    f32sisoamp einfache Genauigkeit (skalar) einfache Genauigkeit (v2) einfache Genauigkeit (v2)
    f16v4sisoslic halbe Genauigkeit (v4) einfache Genauigkeit (v2) einfache Genauigkeit (v2)
    f16v4hihoslic halbe Genauigkeit (v4) halbe Genauigkeit (v2) halbe Genauigkeit (v2)
    f16v4sihoslic halbe Genauigkeit (v4) einfache Genauigkeit (v2) halbe Genauigkeit (v2)
    f32sisoslic einfache Genauigkeit (skalar) einfache Genauigkeit (v2) einfache Genauigkeit (v2)
  • Man beachte: Für manche Befehlstypen ist die Position der Gewichtungen komplett impliziert, aber für andere nehmen sie einen Operanden, der auswählt, welcher aus einer Anzahl von verschiedenen Sätzen in der WRF zu verwenden ist. Der f16v4sisoslic-Befehl benötigt zum Beispiel nur ein Viertel des Gewichtungszustands von f16v4sisoamp. Als Ergebnis darf die Software bis zu vier Sätze von Gewichtungen vorladen. Die Gewichtungssatz-Auswahl wird durch zwei Bits eines direkten Operanden bestimmt. Für f16v4sisoamp nimmt dies andererseits den vollen Gewichtungszustand und es gibt darin deshalb keine Auswahl.
  • Selbstverständlich sind die obigen Ausführungsbeispiele nur beispielhaft beschrieben worden.
  • Zum Beispiel ist der Schutzumfang der vorliegenden Offenbarung die oben beschriebene Architektur, in der ein separater Kontext für den Supervisor-Thread vorgesehen ist, oder in der der Supervisor-Thread in einem Fenster läuft und dann sein Fenster an einen Worker abtritt. Der Supervisor kann stattdessen auch einen Kontext zur allgemeinen Verwendung benutzen. Oder in einer anderen Ausgestaltung kann der Supervisor zum Beispiel in seinem eigenen dedizierten Fenster laufen. Ferner ist die Anwendung nicht auf einen speziellen der Threads auch mit einer Supervisor-Rolle beschränkt. Ferner ist der Schutzumfang der Offenbarung nicht auf den Prozessor 4 beschränkt, der ein Tile in einer Anordnung von Tiles ist. In alternativen Ausführungsbeispielen kann der Prozessor 4 zum Beispiel ein eigenständiger Prozessor oder ein Ein-Chip-Prozessor sein.
  • Die Implementierung der Ausführungseinheit 18 ist nicht auf separate Haupt-Ausführungseinheit 18M und Zusatz-Ausführungseinheit 18A beschränkt, auch nicht auf separate MRF und ARF. Im Allgemeinen können die Register irgendeine oder irgendwelche mehreren Registerdateien sein, die zwischen verschiedenen Speicherzugriffs- und arithmetischen Vorgängen geteilt oder separiert sein können.
  • Die arithmetischen Befehle, die die gemeinsam benutzte Gewichtungsregisterdatei benutzen, sind nicht auf Matrixprodukt- oder Faltungsbefehle beschränkt. Allgemeiner kann die gemeinsam benutzte Gewichtungsregisterdatei für irgendeinen arithmetischen Befehlstyp oder irgendeine Kombination von Befehlen benutzt werden, z.B. einen nicht-akkumulierenden Matrixproduktbefehl, bei dem die Akkumulation in separaten Befehlen oder einem Mehrzweck-Code erfolgt, oder anderen Sequenzen von Matrixmultiplikationen anders als Faltungen, wobei die Ergebnisse von vorherigen Produkten nicht notwendigerweise die Eingaben von anschließenden Produkten sind. Andere Beispiele können it Vektor-Skalarprodukt-Befehle oder akkumulierende Vektor-Skalarprodukt-Befehle enthalten - d.h. die arithmetischen Befehle müssen nicht M verschiedene Kernels parallel anwenden.
  • Ferner ist der Schutzumfang der vorliegenden Offenbarung nicht auf die speziellen Registergrößen, Bitbreiten der Ports, Anzahl der Ports, Wertegenauigkeiten, Vektorgrößen oder Matrixgrößen beschränkt, die oben beispielhaft offenbart sind. Andere Bitbreiten von Registern und Ports sind möglich, sowie andere Werte von Genauigkeiten und andere Größen von Vektoren oder Matrizen (z.B. in Einheiten der Anzahl von Elementen). Ferner sind in anderen Anwendungen andere Packungen der zwei Ladeadressen und der einen Speicheradresse in zwei Register möglich, z.B. drei 10-Bit-Adressen in zwei 16-Bit-Registern oder drei 42-Bit-Adressen in zwei 64-Bit-Registern. Auch müssen die Lade- und Speicheradressen nicht notwendigerweise die gleiche Länge haben. Ferner sind auch andere Packungen der Abstandswerte in die Stride-Register in alternativen Umsetzungen möglich, z.B. vier 8-Bit-Stride-Felder in einem 32-Bit-Register, etc.
  • In noch weiteren Varianten ist die Anwendbarkeit der Offenbarung nicht auf eine Bildverarbeitung beschränkt. Der hier benutzte Begriff „Kernel“ kann irgendeine Matrix von Gewichtungen bedeuten, die als Teil irgendeines Prozesses mit Vorgängen wie beispielsweise Vektormultiplikation, Matrixmultiplikation oder Faltung oder anderen (z.B. Korrelation) aufweist. Auch ist die Anwendungsmöglichkeit nicht auf 3D-Datenvolumen beschränkt. Die Eingangsdaten (und der Kernel) können linear oder 2D sein oder eine größere Mehrdimensionalität (>3 unabhängig von Variablen oder Freiheitsgraden) haben. Ferner ist der Schutzumfang der Offenbarung nicht auf Maschinenlernanwendungen beschränkt. Es gibt viele weitere Anwendungen, in denen es erwünscht sein kann, einen Vorgang gemäß einer Kombination von einem oder mehreren Operanden, die den gleichzeitigen Threads gemeinsam sind, und einem oder mehreren Operanden, die für jeden Thread spezifisch sind, durchzuführen.
  • Weitere Varianten oder Nutzungsfälle der offenbarten Techniken sind dem Fachmann anhand der hier gegebenen Offenbarung offensichtlich. Der Schutzumfang der Offenbarung ist nicht auf die beschriebenen Ausführungsbeispiele beschränkt, sondern nur durch die beigefügten Ansprüche.

    • Claims (17)

    1. Prozessor, aufweisend: eine oder mehrere Registerdateien; und eine Ausführungseinheit, die ausgestaltet ist, um Instanzen von in einem Befehlssatz definierten Befehlstypen auszuführen, wobei jeder Befehl in dem Befehlssatz aus einem Opcode und einem oder mehreren Operanden besteht, wobei die Ausführungseinheit eine Barrelthread-Ausführungseinheit ist, die ausgestaltet ist, um mehrere gleichzeitige Threads jeweils in einem anderen einer Wiederholungssequenz von verschachtelten Zeitfenstern auszuführen, und die eine oder mehreren Registerdateien für jeden der gleichzeitigen Threads einen entsprechenden Satz von Kontextregistern aufweisen, die ausgebildet sind, um einen Programmstatus des jeweiligen Threads zu halten, wobei jeder Satz von Kontextregistern einen entsprechenden Satz von Registern arithmetischer Operanden zur Verwendung durch den jeweiligen Thread aufweist; wobei eine der einen oder mehreren Registerdateien ferner einen Satz von gemeinsam benutzten Gewichtungsregistern aufweist, die manchen oder allen der gleichzeitigen Threads gemeinsam sind; wobei die im Befehlssatz definierten Befehlstypen einen arithmetischen Befehl mit Operanden enthalten, die eine Quelle und ein Ziel aus dem jeweiligen Satz von arithmetischen Registern des Threads bestimmen, in dem der arithmetische Befehl ausgeführt wird; und wobei die Ausführungseinheit ausgestaltet ist, um als Reaktion auf den Opcode des arithmetischen Befehls einen Vorgang mit einem Multiplizieren einer Eingabe von der Quelle mit wenigstens einer der Gewichtungen aus wenigstens einem der gemeinsam benutzten Gewichtungsregister durchzuführen und ein Ergebnis in das Ziel zu setzen.
    2. Prozessor nach Anspruch 1, bei welchem das wenigstens eine der gemeinsam benutzten Gewichtungsregister aus dem Opcode des arithmetischen Befehls impliziert ist und nicht durch irgendeinen Operanden des arithmetischen Befehls bestimmt wird.
    3. Prozessor nach Anspruch 1, bei welchem der arithmetische Befehl einen weiteren Operanden nimmt, der wenigstens eines der gemeinsamen benutzten Gewichtungsregister aus dem Satz von gemeinsam benutzten Gewichtungsregistern bestimmt.
    4. Prozessor nach einem der vorhergehenden Ansprüche, bei welchem die Eingabe einen Vektor aufweist und die Multiplikation ein Skalarprodukt der Eingabe mit einem Vektor von Gewichtungen aus den gemeinsam benutzten Gewichtungsregistern aufweist.
    5. Prozessor nach Anspruch 3 und 4, bei welchem das wenigstens eine der gemeinsam benutzten Gewichtungsregister einen Teilsatz der gemeinsam benutzten Gewichtungsregister von mehreren Teilsätzen aufweist, wobei jeder Teilsatz einen jeweiligen Gewichtungsvektor hält; und bei welchem der weitere Operand auswählt, aus welchem Teilsatz der Gewichtungsvektor zur Verwendung in der Multiplikation zu nehmen ist.
    6. Prozessor nach einem der vorhergehenden Ansprüche, bei welchem der arithmetische Befehl einen Vektor-Skalarprodukt-Befehl, einen akkumulierenden Vektor-Skalarprodukt-Befehl, einen Matrixprodukt-Befehl, einen akkumulierenden Matrix-produkt-Befehl oder einen Faltungsbefehl aufweist.
    7. Prozessor nach einem der vorhergehenden Ansprüche, bei welchem die gleichzeitigen Threads mehrere Worker-Threads aufweisen und die Ausführungseinheit ferner ausgebildet ist, um zumindest manchmal ein Supervisor-Subprogramm mit wenigstens einem Supervisor-Thread zum Managen der Worker-Threads auszuführen.
    8. Prozessor nach Anspruch 7, bei welchem das Supervisor-Subprogramm ausgestaltet ist, um die Gewichtungen in die gemeinsam benutzte Gewichtungsregisterdatei zu schreiben.
    9. Prozessor nach Anspruch 8, derart ausgestaltet, dass die Gewichtungen in den gemeinsam benutzten Gewichtungsregistern nur durch das Supervisor-Subprogramm geschrieben werden können und die Worker-Threads die gemeinsam benutzten Gewichtungsregister nur lesen können.
    10. Prozessor nach einem der Ansprüche 7 bis 9, bei welchem die Kontextregister einen jeweiligen Satz von Kontextregistern für jeden der Worker-Threads, die gleichzeitig ausgeführt werden können, und einen zusätzlichen Satz von Kontextregistern, die ausgebildet sind, um einen Programmstatus des Supervisor-Subprogramms zu halten, aufweisen.
    11. Prozessor nach Anspruch 10, bei welchem das Supervisor-Subprogramm ausgebildet ist, um mit einem anfänglichen Laufen in allen Fenstern zu beginnen und die Gewichtungen vor einem Starten der Worker-Threads zu schreiben; und bei welchem das Supervisor-Subprogramm jeden der Worker-Threads durch Abtreten jedes von manchen oder allen Fenstern, in denen das Supervisor-Subprogramm anfänglich läuft, an die jeweiligen Worker-Threads startet.
    12. Prozessor nach Anspruch 11, bei welchem der Befehlssatz einen Laufbefehl enthält, der bei seiner Ausführung als Teil des Supervisor-Subprogramms das Fenster, in dem der Laufbefehl ausgeführt wird, an einen der Worker-Threads abtreten lässt, sodass der Worker-Thread in diesem Fenster anstelle des Supervisor-Subprogramms gestartet wird.
    13. Prozessor nach Anspruch 12, bei welchem der Befehlssatz einen Ausstiegsbefehl enthält, der bei seiner Ausführung als Teil eines der Worker-Threads das Fenster, in dem der Ausstiegsbefehl ausgeführt wird, an das Supervisor-Subprogramm zurückgeben lässt, sodass das Supervisor-Subprogramm wieder in diesem Fenster anstelle des Worker-Threads weiterläuft.
    14. Prozessor nach einem der Ansprüche 7 bis 13, bei welchem die Registerdateien eine separate arithmetische Registerdatei für jeden gleichzeitigen Worker-Thread enthalten, wobei die jeweilige arithmetische Registerdatei die entsprechenden Register arithmetischer Operanden aufweist.
    15. Prozessor nach Anspruch 14, bei welchem die Registerdateien eine separate Gewichtungsregisterdatei mit den Gewichtungsregistern enthalten.
    16. Prozessor nach Anspruch 15, bei welchem die Gewichtungsregisterdatei so ausgebildet ist, dass sie nur durch das Supervisor-Subprogramm geschrieben werden kann und die Worker-Threads die Gewichtungsregisterdatei nur lesen können.
    17. Verfahren zum Betreiben eines Prozessors nach einem der Ansprüche 1 bis 16, wobei das Verfahren ein Ausführen eines Programms mit einer oder mehreren Instanzen des arithmetischen Befehls auf dem Prozessor durch die Ausführungseinheit aufweist.
    DE102019112352.6A 2018-12-31 2019-05-10 Registerdateien in einem multithread-prozessor Pending DE102019112352A1 (de)

    Applications Claiming Priority (2)

    Application Number Priority Date Filing Date Title
    GB1821301.7A GB2580327B (en) 2018-12-31 2018-12-31 Register files in a multi-threaded processor
    GB1821301.7 2018-12-31

    Publications (1)

    Publication Number Publication Date
    DE102019112352A1 true DE102019112352A1 (de) 2020-07-02

    Family

    ID=65364640

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    DE102019112352.6A Pending DE102019112352A1 (de) 2018-12-31 2019-05-10 Registerdateien in einem multithread-prozessor

    Country Status (7)

    Country Link
    US (1) US20200210175A1 (de)
    JP (1) JP6895484B2 (de)
    CN (1) CN111381939B (de)
    CA (1) CA3040896C (de)
    DE (1) DE102019112352A1 (de)
    FR (1) FR3091389B1 (de)
    GB (1) GB2580327B (de)

    Families Citing this family (8)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US11893393B2 (en) 2017-07-24 2024-02-06 Tesla, Inc. Computational array microprocessor system with hardware arbiter managing memory requests
    US10671349B2 (en) * 2017-07-24 2020-06-02 Tesla, Inc. Accelerated mathematical engine
    US11561791B2 (en) 2018-02-01 2023-01-24 Tesla, Inc. Vector computational unit receiving data elements in parallel from a last row of a computational array
    US12014505B2 (en) * 2019-01-31 2024-06-18 Samsung Electronics Co., Ltd. Method and apparatus with convolution neural network processing using shared operand
    JP6906118B1 (ja) 2020-03-03 2021-07-21 三ツ星ベルト株式会社 ベルト取付治具の補助具及びベルトの取付方法
    CN114968358A (zh) * 2020-10-21 2022-08-30 上海壁仞智能科技有限公司 配置向量运算系统中的协作线程束的装置和方法
    CN114579929B (zh) * 2022-03-14 2023-08-08 海飞科(南京)信息技术有限公司 加速器执行的方法和电子设备
    CN115658146B (zh) * 2022-12-14 2023-03-31 成都登临科技有限公司 一种ai芯片、张量处理方法及电子设备

    Family Cites Families (24)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US5655132A (en) * 1994-08-08 1997-08-05 Rockwell International Corporation Register file with multi-tasking support
    US6134653A (en) * 1998-04-22 2000-10-17 Transwitch Corp. RISC processor architecture with high performance context switching in which one context can be loaded by a co-processor while another context is being accessed by an arithmetic logic unit
    JP3209205B2 (ja) * 1998-04-28 2001-09-17 日本電気株式会社 プロセッサにおけるレジスタ内容の継承装置
    JP3604029B2 (ja) * 1999-01-12 2004-12-22 日本電気株式会社 マルチスレッドプロセッサ
    JP2001167066A (ja) * 1999-12-08 2001-06-22 Nec Corp プロセッサ間通信方法及びマルチプロセッサシステム
    US7120783B2 (en) * 1999-12-22 2006-10-10 Ubicom, Inc. System and method for reading and writing a thread state in a multithreaded central processing unit
    CN1842770A (zh) * 2003-08-28 2006-10-04 美普思科技有限公司 一种在处理器中挂起和释放执行过程中计算线程的整体机制
    US20050050305A1 (en) * 2003-08-28 2005-03-03 Kissell Kevin D. Integrated mechanism for suspension and deallocation of computational threads of execution in a processor
    US7610473B2 (en) * 2003-08-28 2009-10-27 Mips Technologies, Inc. Apparatus, method, and instruction for initiation of concurrent instruction streams in a multithreading microprocessor
    US9189230B2 (en) * 2004-03-31 2015-11-17 Intel Corporation Method and system to provide concurrent user-level, non-privileged shared resource thread creation and execution
    WO2006079940A2 (en) * 2005-01-25 2006-08-03 Nxp B.V. Multi-threaded processor
    US8230423B2 (en) * 2005-04-07 2012-07-24 International Business Machines Corporation Multithreaded processor architecture with operational latency hiding
    US8321849B2 (en) * 2007-01-26 2012-11-27 Nvidia Corporation Virtual architecture and instruction set for parallel thread computing
    JP5211511B2 (ja) * 2007-03-01 2013-06-12 日本電気株式会社 処理実行装置、処理実行方法及びプログラム
    GB2451845B (en) * 2007-08-14 2010-03-17 Imagination Tech Ltd Compound instructions in a multi-threaded processor
    US8312254B2 (en) * 2008-03-24 2012-11-13 Nvidia Corporation Indirect function call instructions in a synchronous parallel thread processor
    CN102023844B (zh) * 2009-09-18 2014-04-09 深圳中微电科技有限公司 并行处理器及其线程处理方法
    US10078515B2 (en) * 2011-10-03 2018-09-18 International Business Machines Corporation Tracking operand liveness information in a computer system and performing function based on the liveness information
    JP2013114538A (ja) * 2011-11-30 2013-06-10 Toshiba Corp 情報処理装置、情報処理方法及び制御プログラム
    US20130246761A1 (en) * 2012-03-13 2013-09-19 International Business Machines Corporation Register sharing in an extended processor architecture
    GB2499277B (en) * 2012-08-30 2014-04-02 Imagination Tech Ltd Global register protection in a multi-threaded processor
    US11080064B2 (en) * 2014-10-28 2021-08-03 International Business Machines Corporation Instructions controlling access to shared registers of a multi-threaded processor
    US10761849B2 (en) * 2016-09-22 2020-09-01 Intel Corporation Processors, methods, systems, and instruction conversion modules for instructions with compact instruction encodings due to use of context of a prior instruction
    US11347964B2 (en) * 2017-08-07 2022-05-31 Renesas Electronics Corporation Hardware circuit

    Also Published As

    Publication number Publication date
    CN111381939B (zh) 2023-09-01
    CN111381939A (zh) 2020-07-07
    FR3091389B1 (fr) 2023-01-20
    JP2020109605A (ja) 2020-07-16
    GB2580327A (en) 2020-07-22
    GB201821301D0 (en) 2019-02-13
    US20200210175A1 (en) 2020-07-02
    CA3040896C (en) 2021-06-01
    FR3091389A1 (fr) 2020-07-03
    JP6895484B2 (ja) 2021-06-30
    GB2580327B (en) 2021-04-28
    CA3040896A1 (en) 2020-06-30

    Similar Documents

    Publication Publication Date Title
    DE102019112352A1 (de) Registerdateien in einem multithread-prozessor
    DE102019112353A1 (de) Lade/speicher-befehl
    DE102017113733B4 (de) Faltendes neuronales Netzwerk auf programmierbarem zweidimensionalem Bildprozessor
    EP0689694B1 (de) Verfahren zur maschinellen erzeugung von nebenläufig bearbeitbaren befehlsgruppen aus einem programm für superskalare mikroprozessoren
    DE202017103727U1 (de) Kernprozesse für Blockoperationen an einem Bildprozessor mit einer zweidimensionalen Ausführungsbahnmatrix und einem zweidimensionalen Schieberegister
    DE3689915T2 (de) Verfahren zur Vektorisation und Objektkodekompilation.
    DE69933088T2 (de) Vliw-verarbeiter verarbeitet befehle von verschiedenen breiten
    DE60318494T2 (de) Verfahren, einrichtung und system zur durchführung von kalkulationsoperationen
    DE112016001837T5 (de) Architektur für leistungseffiziente und programmierbare hochleistungs-bildverarbeitung
    DE3587591T2 (de) Mikroprozessor für Forth-ähnliche Sprache.
    DE3587218T2 (de) Verfahren zur Ausführung von in einer hohen Programmiersprache geschriebenen Anwenderprogrammen.
    DE3875979T2 (de) Schaltung zur berechnung des quantisierten koeffizienten der diskreten cosinustransformation von digitalen signalabschnitten.
    DE112016001866T5 (de) Zeilenpuffereinheit für Bildprozessor
    DE102018119225A1 (de) System und Verfahren für einen optimierten Winograd-Faltungsbeschleuniger
    DE102017103764A1 (de) Compilerverwalteter speicher für bildprozessor
    DE112015004983T5 (de) Parallel-Slice-Prozessor mit einer Lade-Speicher-Umlaufwarteschlange für eine schnelle Freigabe von Einträgen in einer Ausgabewarteschlange
    DE202008017916U1 (de) Virtuelle Architektur und virtueller Befehlssatz für die Berechnung paralleler Befehlsfolgen
    DE112015005597T5 (de) Verknüpfungsfähige Parallelausführungs-Schicht einer Ausgabewarteschlange für einen Prozessor
    DE102017113735B4 (de) Statistische Operationen auf einem zweidimensionalen Bildprozessor
    DE19510879A1 (de) Verfahren zum Lösen simultaner, linearer Gleichungen in einem speicherverteilten Parallelcomputer
    DE112016001836T5 (de) Energieeffiziente Prozessorkernarchitektur für Bildprozessoren
    DE19527031A1 (de) Verbesserte Vorrichtung zum Reduzieren von Verzögerungen aufgrund von Verzweigungen
    DE102018125805A1 (de) Systeme, verfahren, und vorrichtungen für skalarproduktoperationen
    US11164032B2 (en) Method of performing data processing operation
    DE112011103211T5 (de) Auf einem Halbleiterchip implementierte vektorlogische Reduktionsoperation

    Legal Events

    Date Code Title Description
    R012 Request for examination validly filed