DE102019112353A1

DE102019112353A1 - Lade/speicher-befehl

Info

Publication number: DE102019112353A1
Application number: DE102019112353.4A
Authority: DE
Inventors: Alan Graham Alexander; Simon Christian Knowles; Mrudula Gore
Original assignee: Graphcore Ltd
Current assignee: Graphcore Ltd
Priority date: 2018-12-31
Filing date: 2019-05-10
Publication date: 2020-07-02
Also published as: JP2020109604A; GB2584268B; FR3091375A1; CN111381880A; US11467833B2; CA3040794A1; US20200210187A1; CN111381880B; CA3040794C; FR3091375B1; GB2584268A; KR102201935B1; KR20200083123A; GB201821300D0; JP6944974B2

Abstract

Ein Prozessor hat einen Befehlssatz, der einen Lade/Speicher-Befehl mit Operanden enthält, die aus den Registern in wenigstens einer Registerdatei ein jeweiliges Ziel von jedem von zwei Ladevorgängen, eine jeweilige Quelle eines Speichervorgangs und ein Paar von Adressregistern zum Halten von drei Speicheradressen bestimmen, wobei die drei Speicheradressen eine entsprechende Ladeadresse für jeden der zwei Ladevorgänge und eine entsprechende Speicheradresse für den Speichervorgang sind. Der Lade/Speicher-Befehl enthält ferner drei direkte Stride-Operanden, die jeweils einen entsprechenden Abstandswert für jede der zwei Ladeadressen und eine Speicheradresse bestimmen, wobei wenigstens manche möglichen Werte jedes direkten Stride-Operanden den jeweiligen Abstandswert durch Bestimmen eines von mehreren Feldern in einem Stride-Register in einer der einen oder mehreren Registerdateien bestimmen, wobei jedes Feld einen anderen Abstandswert hält.

Description

Technisches Gebiet
Die vorliegende Offenbarung betrifft eine Form eines Lade/Speicher-Befehls mit hoher semantischer Dichte.
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 Gradientenabstieg. 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
Diese Arten von arithmetischen Befehlen enthalten im Vergleich zu einfacheren, traditionelleren arithmetischen Befehlstypen wie beispielsweise Addieren, Multiplizieren, etc. ein hohes Maß an semantischem Inhalt in einem einzelnen Befehl (d.h. führen ein größeres Maß an Logik je Befehl durch). Um mit solchen komplexen Befehlen oder Vorgängen einherzugehen, wäre es jedoch auch wünschenswert, im Befehlssatz einen Lade/Speicher-Befehl vorzusehen, der auch eine hohe Konzentration an semantischen Informationen in einem einzelnen Befehl enthält.
Gemäß einem hier offenbarten Aspekt ist ein Prozessor vorgesehen, aufweisend eine Ausführungseinheit, einen Speicher und eine oder mehrere Registerdateien mit mehreren Registern, wobei die Ausführungseinheit ausgestaltet ist, um Befehlsinstanzen aus einem Maschinencodebefehlstypen definierenden Befehlssatz auszuführen, die jeweils aus einem Opcode und null oder mehr Operanden bestehen. Die Ausführungseinheit weist eine Lade/Speicher-Einheit auf und die in dem Befehlssatz definierten Befehlstypen enthalten einen Lade/Speicher-Befehl mit Operanden, die aus den Registern in wenigstens einer der einen oder mehreren Registerdateien ein jeweiliges Ziel von jedem von zwei Ladevorgängen, eine jeweilige Quelle eines Speichervorgangs und ein Paar Adressregister zum Halten von drei Speicheradressen bestimmen, wobei die drei Speicheradressen eine jeweilige Ladeadresse für jeden der zwei Ladevorgänge und eine jeweilige Speicheradresse für den Speichervorgang sind. Der Lade/Speicher-Befehl enthält ferner drei direkte Stride-Operanden, die jeweils einen entsprechenden Abstandswert für jede der zwei Ladeadressen und die eine Speicheradresse bestimmen, wobei wenigstens manche möglichen Werte jedes direkten Stride-Operanden den jeweiligen Abstandswert bestimmen, indem sie eines von mehreren Feldern in einem Stride-Register in einer der einen oder mehreren Registerdateien bestimmen, wobei jedes Feld einen anderen Abstandswert enthält. Die Lade/Speicher-Einheit ist ausgestaltet, um als Reaktion auf den Opcode des Lade/Speicher-Befehls einen entsprechenden Datenteil aus dem Speicher von jeder der zwei Ladeadressen in das entsprechende Ziel des jeweiligen Ladevorgangs zu laden, einen entsprechenden Datenteil von der Quelle des Speichervorgangs in die Speicheradresse in dem Speicher zu speichern und nach jedem der Lade- und Speichervorgänge die jeweilige Adresse um den jeweiligen Abstandswert zu erhöhen (d.h. die Lade/Speicher-Einheit ist ausgestaltet, um für wenigstens manche möglichen Werte jedes direkten Stride-Operanden den jeweiligen Abstandswert aus einem von mehreren Feldern in einem Stride-Register zu nehmen, wobei das Feld durch den Wert des direkten Stride-Operanden bestimmt wird).
Dieser Lade/Speicher-Befehl ermöglicht es vorteilhafterweise, mit einer hohen Rate mit niedrigem Code-Overhead (hoher Codedichte) Eingangsdaten aus einem Speicher zu streamen und Ergebnisse zurück in den Speicher zu streamen. Dies kann zum Beispiel benutzt werden, um die Eingaben und Ausgaben der arithmetischen Vorgänge mit der gleichen Rate, wie sie durch die arithmetischen Befehle verbraucht bzw. ausgegeben werden, zu und aus dem Speicher zu streamen, wobei zu diesem Zweck ein relativ geringer Overhead von Befehlen benötigt wird. Dies kann zum Beispiel nützlich sein in Maschinenlernanwendungen, um Matrixmultiplikations- oder akkumulierende Matrixmultiplikationsbefehle zu begleiten, die benutzt werden, um eine Faltung von Gewichtungen mit Eingangsdaten durchzuführen.
Man beachte jedoch, dass die Anwendbarkeit des offenbarten Lade/Speicher-Befehls nicht auf solche Anwendungen beschränkt ist. Ein Lade/Speicher-Befehl mit einem solchen semantischen Inhalt kann auch andere Anwendungen als nur Maschinenlernen, Durchführen von Faltungen oder Matrixmultiplikationen wie beispielsweise in anderen Sequenzen von komplexen arithmetischen Befehlen finden.
In Ausführungsformen kann der Lade/Speicher-Befehl ferner einen Stride-Register-Operanden zum Bestimmen des Stride-Registers aus mehreren möglichen Registern in einer der einen oder mehreren Registerdateien aufweisen.
In Ausführungsformen kann ein möglicher Wert des Stride-Operanden einen Abstandswert einer Einheit bestimmen und mehrere andere mögliche Werte des Stride-Operanden können andere der Felder im Stride-Register bestimmen.
D.h. die Lade/Speicher-Einheit ist ausgestaltet, um für wenigstens manche möglichen Werte jedes direkten Stride-Operanden den jeweiligen Abstandswert auf eine Einheit zu setzen, anstelle den Abstandswert aus einem Feld des Stride-Registers zu nehmen (wobei eine Einheit 1 Atom bedeutet, d.h. die Größe des Datenzugriffs, der nicht notwendigerweise ein Byte ist - falls z.B. der Operand ein 4-Element-Vektor von 16-Bit-Gleitkommawerten ist, wird er um 1 Atom/Einheit erhöht, was äquivalent zu 8 Bytes = 64 Bits ist). Für manche oder alle anderen nimmt er den jeweiligen Abstandswert aus einem der Felder im Stride-Register, wie es durch den Wert des direkten Stride-Operanden bestimmt wird.
In Ausführungsformen kann der Prozessor drei Ports zur Lade/Speicher-Einheit von der/den Registerdatei(en) der Adressregister und des Stride-Registers aufweisen und kann die Lade/Speicher-Einheit ausgestaltet sein, um einen entsprechenden der Ports für jedes des Paares von Adressregistern und einen der Ports zum Zugriff auf das Stride-Register zu benutzen.
In Ausführungsformen hat jeder der drei Ports eine Bitbreite gleich einer Bitbreite des jeweiligen Adressregisters oder Stride-Registers, die zum Zugreifen benutzt werden.
In Ausführungsformen weist der Prozessor nur diese drei Ports zur Lade/Speicher-Einheit von der/den fraglichen Registerdatei(en) auf (gemeinsam benutzt von den Kontexten im Fall eines Multithread-Prozessors). In Ausführungsformen kann das Paar von Adressregistern und Stride-Registern in der gleichen Registerdatei sein. In Ausführungsformen können die Adress- und Stride-Register alle die gleiche Bitbreite haben. In Ausführungsformen kann diese Breite 32 Bits betragen.
In Ausführungsformen kann jedes des Paares von Adressregistern 32 Bits breit sein und kann jede der Lade- und Speicheradressen 21 Bits breit sein.
In Ausführungsformen kann das Ziel jedes der Ladevorgänge ein Paar von 32 Bit breiten Registern sein und kann die Quelle des Speichervorgangs ein Paar von 32 Bit breiten Registern sein.
In Ausführungsformen kann der Prozessor zwei Ports zum Durchführen eines Ladens aus dem Speicher und einen Port zum Durchführen des Speicherns in den Speicher aufweisen. In Ausführungsformen kann der Prozessor nur diese zwei Ports zum Laden aus dem Speicher und nur diesen einen Port zum Speichern in den Speicher aufweisen (gemeinsam benutzt von den Kontexten im Fall eines Multithread-Prozessors). In Ausführungsformen ist jeder dieser Ports 64 Bits breit. In Ausführungsformen ist der durch jeden dieser Ladevorgänge geladenen Datenteile 64 Bits breit und ist der durch den Speichervorgang gespeicherte Datenteil 64 Bits breit.
In Ausführungsformen kann der durch jeden dieser Ladevorgänge geladene Datenteil aus einem Paar von 32-Bit-Gleitkommawerten oder einem 4-Element-Vektor von 16-Bit-Gleitkommawerten bestehen und kann der durch diesen Speichervorgang gespeicherte Datenteil aus einem Paar von 32-Bit-Gleitkommawerten bestehen.
In Ausführungsformen können die im Befehlssatz definierten Befehlstypen ferner einen arithmetischen Befehl enthalten, der Operanden nimmt, die aus den Registern in wenigstens einer der einen oder mehreren Registerdateien Quellen, von denen eine erste Eingabe und eine zweite Eingabe zu empfangen sind, und ein Ziel, dem ein Ergebnis auszugeben ist, bestimmen. Der Prozessor kann programmiert sein, um ein Programm auszuführen, das eine Reihe von Befehlen mit Instanzen des Lade/Speicher-Befehls und Instanzen des arithmetischen Befehls aufweist, wobei die Quellen von wenigstens manchen der Lade/Speicher-Befehle als die Ziele von wenigstens manchen der arithmetischen Befehle gesetzt werden können und die Ziele von wenigstens manchen der Lade/Speicher-Befehle als die Quellen von wenigstens manchen der arithmetischen Befehle gesetzt werden können.
In Ausführungsformen kann diese Reihe eine Reihe von Befehlspaaren aufweisen, wobei jedes Befehlspaar aus einer Instanz des Lade/Speicher-Befehls und einer entsprechenden Instanz eines arithmetischen Befehls besteht. In jedem Befehlspaar kann die Quelle des Lade/Speicher-Befehls als das Ziel des arithmetischen Befehls von einem vorhergehenden der Paare gesetzt werden, und können die Ziele des Lade/Speicher-Befehls als die Quellen des arithmetischen Befehls im aktuellen oder anschließenden der Paare gesetzt werden.
In Ausführungsformen können jede der Eingaben und des Ergebnisses wenigstens einen Gleitkommawert aufweisen, wobei die Ausführungseinheit eine arithmetische Gleitkommaeinheit aufweist, die ausgestaltet ist, um als Reaktion auf den Opcode des arithmetischen Befehls den arithmetischen Vorgang durchzuführen.
In Ausführungsformen kann der arithmetische Befehl einer sein von einem Vektor-Skalarprodukt-Befehl, akkumulierenden Vektor-Skalarprodukt-Befehl, Matrixprodukt-Befehl, akkumulierenden Matrixprodukt-Befehl oder Faltungsbefehl.
In Ausführungsformen kann jedes der Befehlspaare ein gleichzeitig auszuführendes Befehlsbündel sein, und kann der Prozessor in zwei parallele Pipelines unterteilt sein, von denen eine erste die Lade/Speicher-Einheit zum Ausführen der Instanz des Lade/Speicher-Befehls jedes Bündels aufweist und eine zweite die arithmetische Gleitkommaeinheit zum parallelen Ausführen der entsprechenden Instanz des arithmetischen Befehls aufweist.
In Ausführungsformen kann der arithmetische Befehl ein akkumulierender Matrixprodukt-Befehl zum Multiplizieren eines N-Element-Eingangsvektors mit einer MxN-Matrix aus M Kernels sein, wobei jeder der M Kernels auch ein N-Element-Vektor ist, wobei der akkumulierende Matrixprodukt-Befehl ferner einen direkten Operanden nimmt, der eine Phase aus einer Anzahl N1 von aufeinanderfolgenden Phasen bestimmt. In diesem Fall kann die Befehlsreihe eine sich in einer Schleife wiederholende Sequenz aufweisen, wobei die Sequenz in jeder Schleife eine Sequenz von N1 der Befehlspaare aufweist, wobei die Instanz des akkumulierenden Matrixprodukt-Befehls in jedem Folgepaar in der Sequenz einen anderen Wert des Phasenoperanden hat, der eine andere Folgephase der Sequenz von einer Anfangsphase zu einer N1-ten Phase bestimmt. In jeder Phase ist die erste Eingabe ein entsprechender Subvektor des Eingangsvektors und ist die zweite Eingabe ein entsprechender Satz von einer oder mehreren Teilsummen, wobei die Anzahl der Elemente in jedem Eingangssubvektor N2=N/N1 ist und die Anzahl der Teilsummen in jedem Satz Np=M/N1 ist. In solchen Ausführungsformen kann der arithmetische Vorgang in jeder Phase jeder Schleife aufweisen:

- Kopieren des jeweiligen Satzes von Np Teilsummen aus der zweiten Eingabe der jeweiligen Instanz des akkumulierenden Matrixprodukt-Befehls in einen temporären Propagatorzustand zur Verwendung in der nächsten Schleife;
- für jeden der M Kernels Durchführen eines Skalarprodukts des jeweiligen Eingangssubvektors der aktuellen Phase mit einem jeweiligen N2-Element-Subvektor des Kernels, wodurch ein entsprechendes Zwischenergebnis für jeden der M Kernels erzeugt wird;
- falls der Phasenoperand die Anfangsphase bestimmt, Hinzufügen des entsprechenden Teilprodukts aus der vorherigen Schleife zu jedem der M Zwischenergebnisse;
- Addieren des entsprechenden Zwischenergebnisses zu jedem der M Elemente eines Akkumulatorzustands;
- Ausgeben eines entsprechenden Teilsatzes von Np der Elemente des Akkumulatorzustands aus der aktuellen oder einer vorherigen Schleife als Ausgangsergebnisse an das Ziel der jeweiligen Instanz des akkumulierenden Matrixprodukt-Befehls.

Ausführungsformen ermöglichen so einmal je Schleife die Multiplikation eines N-Element-Eingangsvektors mit einer MxN-Matrix, wobei die Eingaben und Ausgaben zu bzw. aus dem Speicher mit der gleichen Rate gestreamt werden, mit nur M Befehlen je Schleife. Zum Beispiel ist in den Ausführungsformen M=8, N=16, N1=4, N2=4 und Np=2.
Der Propagatorzustand und die Akkumulatorzustände können interne Zustände der Logik der arithmetischen Einheit sein, oder sie könnten alternativ als Register in einer der Registerdateien implementiert oder eine Kombination sein.
In Ausführungsformen kann das Programm eine Aufwärmzeit von mindestens zwei der Schleifen vor einem Erzeugen brauchbarer Ausgangsergebnisse aufweisen.
In Ausführungsformen kann der Prozessor programmiert sein, um die Schleifensequenz zum Durchführen einer Faltung zu verwenden. In diesem Fall kann der Eingangsvektor in jeder Schleife eine andere Auswahl eines Teils der Eingangsdaten darstellen und können die Ergebnisse aus früheren Schleifen als die Teilsummen für spätere Schleifen verwendet werden.
In Ausführungsformen kann der Teil der Eingangsdaten ein 3D-Datenvolumen aufweisen und kann jeder der M Kernels einen 1D-Bestandteil eines entsprechenden der M größeren 3D-Kernels darstellen. In diesem Fall können die Ergebnisse aus früheren Schleifen als die Teilsummen für spätere Schleifen verwendet werden, um so eine Faltung jedes 3D-Kernels mit den Eingangsdaten aus den entsprechenden 1D-Teil-Kernels zu bilden.
In Ausführungsformen kann jeder der 3D-Kernels einen Satz von Gewichtungen eines Knotens in einem neuronalen Netz darstellen.
In Ausführungsformen kann jeder Wert von M die Faltung einer anderen Funktion mit den Eingangsdaten darstellen.
In Ausführungsformen kann jedes Element des Eingangsvektors ein 16-Bit-Gleitkommawert sein und ist jedes Element jedes Kernels ein 16-Bit-Gleitkommawert.
In alternativen Ausführungsformen könnte jedes Element des Eingangsvektors zum Beispiel ein 32-Bit-Gleitkommawert sein und könnte jedes Element jedes Kernels ein 32-Bit-Gleitkommawert sein.
In Ausführungsformen kann jedes der Np Ausgangsergebnisse ein 32-Bit-Gleitkommawert sein.
In alternativen Ausführungsformen könnte das Ausgangsergebnis stattdessen zum Beispiel ein 16-Bit-Gleitkommawert sein.
In Ausführungsformen können die Registerdateien eine erste Registerdatei und eine separate zweite Registerdatei aufweisen, wobei die Adressregister Register in der ersten Registerdatei sind und die Quelle und die Ziele des Lade/Speicher-Befehls Register in der zweiten Registerdatei sind.
In Ausführungsformen kann das Stride-Register ein Register in der ersten Datei sein.
In Ausführungsformen können die Quellen und das Ziel des arithmetischen Befehls Register in der zweiten Registerdatei sein.
In Ausführungsformen kann der Prozessor drei Ports von der ersten Registerdatei zur Lade/Speicher-Einheit und einen Port von der zweiten Registerdatei zur Lade/Speicher-Einheit aufweisen. In Ausführungsformen kann jeder dieser drei Ports von der ersten Registerdatei zur Lade/Speicher-Einheit 32 Bits breit sein. In Ausführungsformen kann der eine Port von der zweiten Registerdatei zur Lade/Speicher-Einheit 64 Bits breit sein. In Ausführungsformen kann der Prozessor nur diese drei Ports von der ersten Registerdatei zur Lade/Speicher-Einheit und nur diesen einen Port von der zweiten Registerdatei zur Lade/Speicher-Einheit aufweisen.
In Ausführungsformen kann der Prozessor zwei Ports von der zweiten Registerdatei zur arithmetischen Einheit aufweisen. In Ausführungsformen kann jeder dieser zwei Ports 64 Bits breit sein. In Ausführungsformen kann der Prozessor nur diese zwei Ports von der zweiten Registerdatei zur arithmetischen Einheit aufweisen (d.h. im Fall eines Multithread-Prozessors nur zwei Ports, die von allen Kontexten gemeinsam benutzt werden).
Mit den oben angegebenen Parametern kann jeder Lade/Speicher-Befehl zwei 32-Bit-Teilsummen und vier 16-Bit-Elemente des Eingangsvektors je Couplet und damit die acht 32-Bit-Teilsummen und sechzehn 16-Bit-Elemente des Eingangsvektors je Schleife der Sequenz aus 4 Couplets (vier Couplets je Schleife) laden. Jeder Lade/Speicher-Befehl kann auch zwei 32-Bit-Teilsummen je Couplet und damit die acht 32-Bit-Teilsummenausgaben je Schleife der Sequenz von 4 Couplets speichern. Dies ermöglicht die Durchführung des 16-Element-Eingangsvektors mit der 8x16-Matrix einmal je Schleife, wobei die Eingaben und Ausgaben zu bzw. aus dem Speicher mit der entsprechenden Rate gestreamt werden, mit einem Code-Overhead von nur vier Lade/Speicher- und vier arithmetischen Befehlsinstanzen je Schleife.
In Ausführungsformen können die Registerdateien ferner eine dritte Registerdatei separat von den ersten und zweiten Registerdateien aufweisen und können die Kernels in der dritten Datei gehalten werden.
Die erste Registerdatei kann eine Speicheradressen-Registerdatei zum Halten von Speicheradressen und Adressen-Offsets wie beispielsweise Strides sein. Die zweite Registerdatei kann eine arithmetische Registerdatei zum Halten von Eingangs- und Ausgangs-Operanden von arithmetischen Vorgängen sein. Die dritte Registerdatei kann eine Gewichtungs-Registerdatei zum Halten von Gewichtungen z.B. eines neuronalen Netzes sein.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist ein Computerprogramm auf einem computerlesbaren Speicher vorgesehen, aufweisend einen Code zum Ausführen auf dem Prozessor nach einer obigen Ausführungsform oder einer anderen Ausführungsform hierin, wobei der Code einen oder mehrere Instanzen des Lade/Speicher-Befehls aufweist.
In Ausführungsformen kann das Programm ferner ausgestaltet sein, um gemäß einer der hier offenbarten Ausgestaltungen zu arbeiten. Zum Beispiel kann das Programm in Ausführungsformen eine oder mehrere Instanzen des arithmetischen Befehls aufweisen. Das Programm kann Instanzen des arithmetischen Befehls aufweisen, die mit Instanzen des Lade/Speicher-Befehls durchsetzt sind. Das Programm kann die oben erwähnte Reihe von Befehlen, z.B. die Schleifensequenz aufweisen.
Gemäß einem weiteren hier offenbarten Aspekt ist ein Verfahren zum Betreiben eines Prozessors, der gemäß einer obigen Ausführungsform oder einer anderen Ausführungsform hierin ausgestaltet ist, vorgesehen, wobei das Verfahren ein Ausführen eines Programms mit einer oder mehreren Instanzen des Lade/Speicher-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 durch den ausgeführten Code zu bearbeitende Daten 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 simultanen Art und Weise ausführen kann. Eine simultane 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 simultan 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 Programmzustand 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 Programmzustands 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 Untersatz 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 Zustand (Kontext) eines jeweiligen anderen der Threads, der simultan ausgeführt werden kann, darzustellen. Die Multithread-Verarbeitungseinheit 10 weist auch eine gemeinsam benutzte Ausführungspipeline 13 auf, die den simultan ausgeführten Threads gemeinsam ist, und einen Scheduler 24 zum Planen der simultanen 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 aufzeichnen (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. bearbeitete Werte oder aus durch die Opcodes der jeweiligen Thread-Befehle definierten Vorgängen bei ihrer Ausführung resultierende Werte. Jeder Satz von Registern 26 kann in einer oder mehreren Registerdateien umgesetzt 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 verzweigt. 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 simultan 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 simultanen 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 simultan 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 Zustand 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 Lauf-Befehl ausführt, der wenigstens eine Adresse eines Worker-Threads im Befehlsspeicher 22 als einen Operanden nimmt. Die Worker-Threads sind Teile des Codes, der simultan mit einem anderen laufen kann, wobei jeder eine oder mehrere entsprechende durchzuführende Berechnungsaufgaben darstellt.
Der Lauf-Befehl 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 Lauf-Befehl 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 Lauf-Befehl 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, an verschiedene 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 Lauf-Befehl, um diesen Worker dem Zeitfenster zuzuordnen, in dem der Lauf-Befehl ausgeführt wurde.
In manchen Ausführungsbeispielen weist der Befehlssatz auch eine Variante des Lauf-Befehls, „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 Lauf-Befehl 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 simultan 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 Zusatz-ausfü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 (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 Model 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 des einen oder der mehreren Parameter jeder Knotenfunktion durch einen jeweiligen Fehlerwert charakterisiert. Außerdem kann dem/den Fehler(n) in dem/den Parameter(n) 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 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 schlusszufolgern.
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, sieht die vorliegende Offenbarung 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

26A

$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, wodurch 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. 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 oder von ihm simultan im gleichen Bündel begleitet wird. In jedem Befehlspaar ist die Quelle des Lade/Speicher-Befehls als das Ziel des arithmetischen Befehls aus einem vorherigen Paar gesetzt und sind die Ziele des Lade/Speicher-Befehls als die Quellen des 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

26A

...	...
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;
...	...

...	...
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;
...	...

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 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-Befehls 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 (Bündel) führt einen arithmetischen Vorgang basierend auf zuvor geladenen Werten und Ausgaben an ein Register Pout zum Speichern durch den Speichervorgang eines folgenden Lade/Speicher-Befehls in einem folgenden 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 die gerufenen Eingangskanäle genannt werden, und die Ausgangsdaten können auch 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 - z'])$
Eine Faltung weist so ein systematisches Scannen des Kernels K über manche oder alle möglichen Positionen, an denen der Kernel mit den Eingangsdaten überzogen sein kann, auf. 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

26A

0

3

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 gefalteten neuronalen Netzes sind dies unterschiedliche 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) umgesetzt 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 Akkumulatorzustand gespeichert (den zuvor gehaltenen Wert überschreibend), (2) mit drei weiteren Skalarprodukt-Ergebnissen akkumuliert und (3) in den vorübergehenden Propagatorzustand 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 Akkumulatorzustand 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 Akkumulatorzustand zurückzusetzen. Das heißt, in Ausführungsbeispielen erlaubt es der Tile 4 einem tatsächlich, alle Akkumulatorzustände auf null zu initialisieren.

Man beachte, dass der Eingangs-Propagatorzustand 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 Akkumulatorzustand 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 eine Wiederholungsschleife ein, die bedeutende Ergebnisse erzeugt, die in der erforderlichen Speicherstelle gespeichert werden. 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.

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 in zwei Akkumulatorregister $AACC[13] und $AACC[15] geführt. Jeder Zyklus solcher Werte bewegt sich vor in $AACC[11] und $AACC[9], während die Werte zuvor in $AACC[11] und $AACC[9] sich in $AACC[7] und $AACC[5] bewegen und so weiter. Wenn sie ihr Ziel erreichen, werden sie in die geradzahligen Akkumulatoren verteilt, bereit für den Akkumulationsvorgang.

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 Vor-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 darauf beschränkt, einen der Threads auch mit einer Supervisor-Rolle zu bestimmen oder stattdessen tatsächlich auf Multithreading überhaupt. Die hier offenbarten Techniken können auch auf einem Prozessor verwendet werden, der keine Multithread-Ausführung einsetzt. 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 Umsetzung 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. Auch ist sie nicht beschränkt auf die Verwendung einer separaten WRF. 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, mit denen der offenbarte Lade/Speicher-Zustand benutzt werden kann, sind nicht auf Matrixprodukt- oder Faltungsbefehle beschränkt. Allgemeiner können die Instanzen des Lade/Speicher-Befehls auch benutzt werden, um Daten aus dem Speicher zu streamen und Ergebnisse zurück zum Speicher zu streamen, für irgendeinen arithmetischen Befehlstyp oder irgendeine Kombination von Befehlen, die wenigstens zwei Eingabeoperanden nimmt und ein Ergebnis ausgibt. Z.B. kann der Lade/Speicher-Befehlstyp mit einem nicht-akkumulierenden Matrixprodukt-Befehl verwendet werden, in dem die Akkumulation in separaten Befehlen oder einem Mehrzweck-Code erfolgt, oder anderen Sequenzen von Matrixmultiplikationen anders als Faltungen, in denen die Ergebnisse von vorherigen Produkten nicht notwendigerweise die Eingaben von anschließenden Produkten sind. Auch kann der Lade/Speicher-Befehl mit Vektor-Skalarprodukt-Befehlen oder akkumulierenden Vektor-Skalarprodukt-Befehlen benutzt werden - 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, Prozesse wie beispielsweise jene durchzuführen, die Vektormultiplikationen, Matrixmultiplikationen und/oder Faltungen, etc. aufweisen.

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

Prozessor, aufweisend eine Ausführungseinheit, einen Speicher und eine oder mehrere Registerdateien mit mehreren Registern, wobei die Ausführungseinheit ausgestaltet ist, um Befehlsinstanzen aus einem Maschinencodebefehlstypen definierenden Befehlssatz auszuführen, die jeweils aus einem Opcode und Null oder mehr Operanden bestehen, wobei die Ausführungseinheit eine Lade/Speicher-Einheit aufweist und die in dem Befehlssatz definierten Befehlstypen einen Lade/Speicher-Befehl mit Operanden enthalten, die aus den Registern in wenigstens einer der einen oder mehreren Registerdateien ein jeweiliges Ziel von jedem von zwei Ladevorgängen, eine jeweilige Quelle eines Speichervorgangs und ein Paar Adressregister zum Halten von drei Speicheradressen bestimmen, wobei die drei Speicheradressen eine jeweilige Ladeadresse für jeden der zwei Ladevorgänge und eine jeweilige Speicheradresse für den Speichervorgang sind; der Lade/Speicher-Befehl ferner drei direkte Stride-Operanden enthält, die jeweils einen entsprechenden Abstandswert für jede der beiden Ladeadressen und eine Speicheradresse bestimmen, wobei wenigstens manche mögliche Werte jedes direkten Stride-Operanden den jeweiligen Abstandswert bestimmen, indem sie eines von mehreren Feldern in einem Stride-Register in einer der einen oder mehreren Registerdateien bestimmen, wobei jedes Feld einen anderen Abstandswert enthält; und die Lade/Speicher-Einheit ausgestaltet ist, um als Reaktion auf den Opcode des Lade/Speicher-Befehls einen entsprechenden Datenteil aus dem Speicher von jeder der beiden Ladeadressen in das entsprechende Ziel des jeweiligen Ladevorgangs zu laden, einen entsprechenden Datenteil von der Quelle des Speichervorgangs in die Speicheradresse im Speicher zu speichern und nach jedem der Lade- und Speichervorgänge die jeweilige Adresse um den jeweiligen Abstandswert zu erhöhen.
Prozessor nach Anspruch 1, bei welchem der Lade/Speicher-Befehl ferner einen Strideregister-Operanden zum Bestimmen des Stride-Registers aus mehreren möglichen Registern in einer der einen oder mehreren Registerdateien aufweist.
Prozessor nach Anspruch 1 oder 2, bei welchem ein möglicher Wert des Stride-Operanden einen Abstandswert einer Einheit bestimmt und mehrere andere mögliche Werte des Stride-Operanden verschiedene der Felder im Stride-Register bestimmen.
Prozessor nach einem der vorhergehenden Ansprüche, aufweisend drei Ports von der/den Registerdatei(en) der Adressregister und des Stride-Registers zur Lade/ Speicher-Einheit, wobei die Lade/Speicher-Einheit ausgestaltet ist, um einen entsprechenden der Ports für jedes des Paares von Adressregistern und einen der Ports zum Zugriff auf das Stride-Register zu benutzen.
Prozessor nach Anspruch 4, bei welchem jeder der drei Ports eine Bitbreite gleich einer Bitbreite des jeweiligen Adressregisters oder Stride-Registers hat, die zum Zugreifen benutzt werden.
Prozessor nach einem der vorhergehenden Ansprüche, bei welchem jedes des Paares von Adressregistern 32 Bit breit ist und jede der Lade- und Speicheradressen 21 Bit breit ist.
Prozessor nach einem der vorhergehenden Ansprüche, bei welchem die im Befehlssatz definierten Befehlstypen ferner einen arithmetischen Befehl enthalten, der Operanden nimmt, die aus den Registern in wenigstens einer der einen oder mehreren Registerdateien Quellen, von denen eine erster Eingabe und eine zweite Eingabe zu empfangen sind, und ein Ziel, dem ein Ergebnis auszugeben ist, bestimmen; und der Prozessor programmiert ist, um ein Programm auszuführen, das eine Reihe von Befehlen mit Instanzen des Lade/Speicher-Befehls und Instanzen des arithmetischen Befehls aufweist, wobei die Quellen von wenigstens manchen der Lade/ Speicherbefehle als die Ziele von wenigstens manchen der arithmetischen Befehle gesetzt sind und die Ziele von wenigstens manchen der Lade/Speicher-Befehle als die Quellen von wenigstens manchen der arithmetischen Befehle gesetzt sind.
Prozessor nach Anspruch 7, bei welchem die Reihe eine Reihe von Befehlspaaren aufweist, wobei jedes Befehlspaar aus einer Instanz des Lade/Speicher-Befehls und einer entsprechenden Instanz eines arithmetischen Befehls besteht; und in jedem Befehlspaar die Quelle des Lade/Speicher-Befehls als das Ziel des arithmetischen Befehls von einem vorhergehenden der Paare gesetzt ist und die Ziele des Lade/Speicher-Befehls als die Quellen des arithmetischen Befehls im aktuellen oder einem anschließenden der Paare gesetzt sind.
Prozessor nach Anspruch 8, bei welchem jede der Eingaben und des Ergebnisses wenigstens einen Gleitkommawert aufweist, wobei die Ausführungseinheit eine arithmetische Gleitkommaeinheit aufweist, die ausgestaltet ist, um als Reaktion auf den Opcode des arithmetischen Befehls den arithmetischen Vorgang durchzuführen.
Prozessor nach Anspruch 8 oder 9, bei welchem der arithmetische Befehl ein Vektor-Skalarprodukt-Befehl, ein akkumulierender Vektor-Skalarprodukt-Befehl, ein Matrixprodukt-Befehl, ein akkumulierender Matrixprodukt-Befehl oder ein Faltungsbefehl ist.
Prozessor nach Anspruch 9 oder 10, bei welchem jedes der Befehlspaare ein gleichzeitig auszuführendes Befehlsbündel ist; und der Prozessor in zwei parallele Pipelines unterteilt ist, von denen eine erste die Lade/Speicher-Einheit zum Ausführen der Instanz des Lade/Speicher-Befehls jedes Bündels aufweist und eine zweite die arithmetische Gleitkommaeinheit zum parallelen Ausführen der entsprechenden Instanz des arithmetischen Befehls aufweist.
Prozessor nach einem der Ansprüche 8 bis 11, bei welchem der arithmetische Befehl ein akkumulierender Matrixprodukt-Befehl zum Multiplizieren eines N-Element-Eingangsvektors mit einer MxN-Matrix aus M Kernels ist, wobei jeder der M Kernels auch ein N-Element-Vektor ist, wobei der akkumulierende Matrixprodukt-Befehl ferner einen direkten Operanden nimmt, der eine Phase aus einer Anzahl N1 von aufeinanderfolgenden Phasen bestimmt; die Befehlsreihe eine sich in einer Schleife wiederholende Sequenz aufweist, wobei die Sequenz in jeder Schleife eine Sequenz von N1 der Befehlspaare aufweist, wobei die Instanz des akkumulierenden Matrixprodukt-Befehls in jedem Folgepaar in der Sequenz einen anderen Wert des Phasenoperanden hat, der eine andere Folgephase der Sequenz von einer Anfangsphase bis zu einer N1-ten Phase bestimmt; in jeder Phase die erste Eingabe ein entsprechender Subvektor des Eingangsvektors ist und die zweite Eingabe ein entsprechender Satz von einer oder mehreren Teilsummen ist, wobei die Anzahl der Elemente in jedem Eingangssubvektor N2=N/N1 ist und die Anzahl der Teilsummen in jedem Satz Np=M/N1 ist; der arithmetische Vorgang in jeder Phase jeder Schleife aufweist: - Kopieren des jeweiligen Satzes von Np Teilsummen aus der zweiten Eingabe der jeweiligen Instanz des akkumulierenden Matrixprodukt-Befehls in einen temporären Propagatorzustand zur Verwendung in der nächsten Schleife; - für jeden der M Kernels Durchführen eines Skalarprodukts des jeweiligen Eingangssubvektors der aktuellen Phase mit einem jeweiligen N2-Element-Subvektor des Kernels, wodurch ein entsprechendes Zwischenergebnis für jeden der M Kernels erzeugt wird; - falls der Phasenoperand die Anfangsphase bestimmt, Hinzufügen des entsprechenden Teilprodukts aus der vorherigen Schleife zu jedem der M Zwischenergebnisse; - Addieren des entsprechenden Zwischenergebnisses zu jedem der M Elemente eines Akkumulatorzustands; - Ausgeben eines entsprechenden Teilsatzes von Np der Elemente des Akkumulatorzustands aus der aktuellen oder einer vorherigen Schleife als Ausgangsergebnisse an das Ziel der jeweiligen Instanz des akkumulierenden Matrixprodukt-Befehls.
Prozessor nach Anspruch 12, bei welchem das Programm eine Aufwärmzeit von mindestens zwei der Schleifen vor einem Erzeugen brauchbarer Ausgangsergebnisse aufweist.
Prozessor nach Anspruch 12 oder 13, bei welchem M=8, N=16, N1=4, N2=4 und Np=2.
Prozessor nach einem der Ansprüche 12 bis 14, programmiert zur Verwendung der Schleifensequenz zum Durchführen einer Faltung, wobei der Eingangsvektor in jeder Schleife eine andere Auswahl eines Teils von Eingangsdaten darstellt und die Ergebnisse aus früheren Schleifen als die Teilsummen für spätere Schleifen verwendet werden.
Prozessor nach Anspruch 15, bei welchem der Teil der Eingangsdaten ein 3D-Datenvolumen aufweist und jeder der M Kernels einen 1D-Bestandteil eines entsprechenden der M größeren 3D-Kernels darstellt, wobei die Ergebnisse aus früheren Schleifen als die Teilsummen für spätere Schleifen verwendet werden, um eine Faltung jedes 3D-Kernels mit den Eingangsdaten aus den entsprechenden 1D-Teil-Kernels zu bilden.
Prozessor nach Anspruch 16, bei welchem jeder der 3D-Kernels einen Satz von Gewichtungen eines Knotens in einem neuronalen Netz darstellt.
Prozessor nach einem der Ansprüche 15 bis 17, bei welchem jeder Wert von M die Faltung einer anderen Funktion mit den Eingangsdaten darstellt.
Prozessor nach einem der Ansprüche 12 bis 18, bei welchem jedes Element des Eingangsvektors ein 16-Bit-Gleitkommawert ist und jedes Element jedes Kernels ein 16-Bit-Gleitkommawert ist.
Prozessor nach einem der Ansprüche 12 bis 19, bei welchem jedes der Np Ausgangsergebnisse ein 32-Bit-Gleitkommawert ist.
Prozessor nach einem der vorhergehenden Ansprüche, bei welchem die Registerdateien eine erste Registerdatei und eine separate zweite Registerdatei aufweisen, wobei die Adressregister Register in der ersten Registerdatei sind und die Quelle und die Ziele des Lade/Speicher-Befehls Register in der zweiten Registerdatei sind.
Prozessor nach Anspruch 21, bei welchem das Stride-Register ein Register in der ersten Datei ist.
Prozessor nach Anspruch 8 und Anspruch 21 oder 22, bei welchem die Quellen und das Ziel des arithmetischen Befehls Register in der zweiten Registerdatei sind.
Prozessor nach Anspruch 12 und einem der Ansprüche 21 bis 23, bei welchem die Registerdateien ferner eine dritte Registerdatei separat zu den ersten und zweiten Registerdateien aufweisen und die Kernels in der dritten Datei gehalten werden.
Computerprogramm auf einem computerlesbaren Speicher, aufweisend einen Code zum Ausführen auf dem Prozessor nach einem der vorhergehenden Ansprüche, wobei der Code eine oder mehrere Instanzen des Lade/Speicher-Befehls aufweist.
Verfahren zum Betreiben eines Prozessors nach einem der Ansprüche 1 bis 24, wobei das Verfahren ein Ausführen eines Programms mit einer oder mehreren Instanzen des Lade/Speicher-Befehls auf dem Prozessor durch die Ausführungseinheit aufweist.