-
VERWANDTE ANMELDUNGEN
-
Diese Patentanmeldung beansprucht die Priorität der anhängigen US-Anmeldung mit der Seriennummer
63/180,634 , eingereicht am 27.04.2021 von dem gleichen Erfinder mit dem Titel „Method and Apparatus for Programmable Machine Learning and Inference“ (Verfahren und Einrichtung für programmierbares maschinelles Lernen und Inferenz), die hiermit durch Bezugnahme aufgenommen wird. Diese Patentanmeldung beansprucht die Priorität der anhängigen US-Anmeldung mit der Seriennummer
63/180,562 , eingereicht am 27.04.2021 von dem gleichen Erfinder mit dem Titel „Method and Apparatus for Gather/Scatter Operations in a Vector Processor“ (Verfahren und Einrichtung für Sammel-/Streuungsoperationen in einem Vektorprozessor), die hiermit durch Bezugnahme hierin aufgenommen wird. Diese Patentanmeldung beansprucht die Priorität der anhängigen US-Anmeldung mit der Seriennummer
17/669,995 , eingereicht am 11.02.2022 von dem gleichen Erfinder mit dem Titel „Method and Apparatus for Gather/Scatter Operations in a Vector Processor“ (Verfahren und Einrichtung für Sammel-/Streuungsoperationen in einem Vektorprozessor), die hiermit durch Bezugnahme hierin aufgenommen wird. Diese Patentanmeldung beansprucht die Priorität der anhängigen US-Anmeldung mit der Seriennummer
63/180,601 , eingereicht am 27.04.2021 von dem gleichen Erfinder mit dem Titel „System of Multiple Stacks in a Processor Devoid of an Effective Address Generator“ (System von mehreren Stapeln in einem Prozessor ohne effektiven Adressgenerator), die hiermit durch Bezugnahme hierin aufgenommen wird. Diese Patentanmeldung beansprucht die Priorität der anhängigen US-Anmeldung mit der Seriennummer
17/468,574 , eingereicht am 07.09.2021 von dem gleichen Erfinder mit dem Titel „System of Multiple Stacks in a Processor Devoid of an Effective Address Generator“ (System von mehreren Stapeln in einem Prozessor ohne effektiven Adressgenerator), die hiermit durch Bezugnahme hierin aufgenommen wird. Diese Patentanmeldung beansprucht die Priorität der anhängigen US-Anmeldung mit der Seriennummer
17/701,582 , eingereicht am 22.03.2022 von dem gleichen Erfinder mit dem Titel „Method and Apparatus for Desynchronizing Execution in a Vector Processor“ (Verfahren und Einrichtung zur Desynchronisation der Ausführung in einem Vektorprozessor), die hiermit durch Bezugnahme hierin aufgenommen wird.
-
GEBIET
-
Das vorliegende Verfahren und die Einrichtung beziehen sich auf einen Vektorprozessor. Insbesondere beziehen sich das vorliegende Verfahren und die Einrichtung auf ein Verfahren und eine Einrichtung zum Desynchronisieren der Ausführung in einem Vektorprozessor.
-
HINTERGRUND
-
Zur Verbesserung des Durchsatzes greift eine Vektorverarbeitungseinheit (VPU) auf Vektoren im Speicher zu und führt Vektoroperationen mit hoher Geschwindigkeit kontinuierlich durch. Somit hat die Unterbrechung der Vektorpipeline aus irgendeinem Grund, wie z. B. zum Handhaben von seriellen oder skalaren Operationen oder Housekeeping-Anweisungen, einen hohen Preis in Form von Leistungseinbußen, da Vektorprozessoren auf brachiale Geschwindigkeit ausgelegt sind.
-
Hier liegt ein technisches Problem vor, für das eine technische Lösung unter Verwendung eines technischen Mittels erforderlich ist.
-
KURZDARS TELLUNG
-
Eine Vektorprozessoreinheit ist mit Vorladeregistern für Vektorlänge, Vektorkonstante, Vektoradresse und Vektorschritt bereitgestellt, wobei jedes Vorladeregister einen Eingang und einen Ausgang aufweist. Alle Vorladeregistereingänge sind gekoppelt, um neue Vektorparameter zu empfangen. Jeder der Vorladeregisterausgänge ist mit einem ersten Eingang eines jeweiligen Multiplexers gekoppelt, und ein zweiter Eingang aller jeweiligen Multiplexer ist gekoppelt, um die neuen Vektorparameter zu empfangen.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Die offenbarten Techniken sind in den Figuren der beigefügten Zeichnungen beispielhaft und ohne Einschränkungen veranschaulicht. Gleiche nummerierte Elemente sind nicht notwendigerweise identisch.
-
Die beigefügten Figuren veranschaulichen verschiedene nicht ausschließliche Beispiele für die offenbarten Techniken.
- 1 veranschaulicht im Allgemeinen bei 100 eine Blockdiagrammübersicht einer Decodiereinheit gemäß einem Beispiel.
- 2 veranschaulicht im Allgemeinen bei 200 eine Blockdiagrammübersicht der Vektorregister zum Adressieren einer Speicherzugriffssteuerung.
- 3 veranschaulicht im Allgemeinen bei 300 eine Blockdiagrammübersicht eines Abschnitts einer Vektorprozessoreinheit, die Speicherzugriffssteuerungsvorladeregister umfasst.
- 4 veranschaulicht im Allgemeinen bei 400 ein Flussdiagramm, das die desynchrone Ausführung einer Anweisung und die synchrone Ausführung einer Anweisung zeigt.
- 5 veranschaulicht im Allgemeinen bei 500 ein Flussdiagramm, das die asynchrone, desynchrone und synchrone Ausführung einer Anweisung veranschaulicht.
- 6 veranschaulicht im Allgemeinen bei 600 ein Flussdiagramm, das die Ausführung von Vektoranweisungen zeigt.
- 7 veranschaulicht im Allgemeinen bei 700 ein Flussdiagramm, das die Ausführung von desynchronisierten Vektoranweisungen zusätzlich zu nicht-desynchronisierten Anweisungen veranschaulicht.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Ein Verfahren und eine Einrichtung zum Desynchronisieren der Ausführung in einem Vektorprozessor werden offenbart.
-
DEFINITIONEN UND ANMERKUNGEN
-
Zum Beschreiben der hierin offenbaren Techniken werden verschiedene Begriffe verwendet. Der Anmelder ist der Lexikograph und definiert diese Begriffe wie folgt. Die Begriffe werden nachstehend bei ihrer ersten Verwendung zitiert.
-
„Gleichzeitig" ist das gleiche wie „parallel“ und wird definiert als zwei Dinge, die mindestens teilweise gleichzeitig ablaufen. Es sagt nichts darüber aus, wie sie sich zueinander beziehen - sie könnten „synchronisiert“ oder „desynchronisiert“ sein.
-
„Synchronisierte“ Ausführung - bedeutet, dass die Steuerung der Pipeline jeden Aspekt der Operation der Anweisung steuert.
-
„Desynchronisierte“ Ausführung - bedeutet, dass eine Anweisung einen wesentlichen Teil ihrer Operation unabhängig von der Steuerung der Pipeline durchführt. Daher kann die Pipelinesteuerung die Ausführung und den Abschluss einer oder mehrerer Anweisungen im Anschluss an die Anweisung, die desynchronisiert ausgeführt wird, vor Abschluss der desynchronisierten Ausführung steuern.
-
Es ist zu beachten, dass die Ausführung von Anweisungen im Anschluss an eine desynchronisierte Anweisung als modifizierend für einen kritischen Zustand des Prozessors betrachtet wird, wenn sie die Ergebnisse des auf dem Prozessor ausgeführten Programms in inakzeptabler Weise ändert. Eine inakzeptable Änderung ist ein Endergebnis der gesamten Verarbeitung für ein bestimmtes Programm, das anders ist, als wenn alle Anweisungen seriell ausgeführt würden, d. h., jede Anweisung wird bis zum Ende ausgeführt, bevor die nächste Anweisung beginnt. Ein kritischer Prozessorzustand ist ein Zustand, der aufrechterhalten werden muss, um eine unannehmbare Änderung zu vermeiden. Zulässige Änderungen können die Reihenfolge des Auftretens von Fehlern oder Unterbrechungen sowie Aktualisierungen der für das Programm sichtbaren Register, die in Bezug auf die desynchronisierte Anweisung außerhalb der Reihenfolge erfolgen (aber nicht in Bezug auf nicht-desynchronisierte Anweisungen außerhalb der Reihenfolge), einschließen, sind jedoch nicht darauf beschränkt. Es ist zu beachten, dass Änderungen, die als inakzeptabel betrachtet werden würden, durch einen Prozess der resynchronisierten Ausführung unzulässig sind.
-
„Desynchronisierte Anweisung“ - ist eine Anweisung, deren Ausführung nicht zu 100 % unter der Kontrolle der Pipelinesteuerung steht, d. h., eine wesentliche Komponente ihrer Operation ist nicht unter der Kontrolle der Pipelinesteuerung, allerdings kann die Pipelinesteuerung ihren Verlauf überwachen.
-
„Nicht desynchronisierte Anweisung“ - ist eine Anweisung, die nicht desynchron ausgeführt wird.
-
„Resynchronisierte" Ausführung verhindert, dass eine Anweisung, die auf eine desynchronisierte Anweisung folgt, ausgeführt wird, bis die desynchronisierte Anweisung abgeschlossen ist. Dies ist der Fall, wenn die nachfolgende Anweisung einen kritischen Prozessorzustand modifizieren würde, insbesondere wenn dieser Prozessorzustand die Ergebnisse der desynchronisierten Anweisung beeinflussen würde.
-
„Asynchrone" Anweisung/Ausführung - eine Anweisung ruft als Teil ihrer Ausführung eine Aktivität außerhalb des Prozessors auf, die zu einem vom Prozessor völlig unkontrollierten und unvorhersehbaren Zeitpunkt abgeschlossen wird. Die Pipelinesteuerung kann den Verlauf nicht überwachen. Gleichzeitig kann der Prozessor weiterhin Anweisungen ausführen.
-
„Asynchrone Reserialisierung“ wartet auf den Abschluss einer asynchronen Ausführung, bevor sie eine nachfolgende Anweisung ausführen lässt. Im Allgemeinen geht es darum, die Integrität der Programmergebnisse aufrechtzuerhalten.
-
Es ist zu beachten, dass der Unterschied zwischen desynchronisiert und asynchron nicht sehr groß ist. Bei der desynchronisierten Ausführung hat der Prozessor die vollständige Kontrolle über die beiden auszuführenden Anweisungen, auch wenn er zulässt, dass die zweite Anweisung den Prozessorzustand modifiziert, bevor die erste (desynchronisierte) Anweisung abgeschlossen ist. Bei der asynchronen Ausführung hat die Steuerung Null (keine) Kontrolle über den Zeitpunkt, zu dem die durch die asynchrone Anweisung ausgelöste Aktivität außerhalb des Prozessors abgeschlossen sein wird.
-
Es ist zu beachten, dass der Begriff desynchronisierte Ausführung verwendet wird, wenn Nicht-Vektoranweisungen ausgeführt werden können, nachdem eine Vektoranweisung begonnen hat, aber nicht abgeschlossen wurde. Die Ausführung der Vektoranweisung gilt als desynchronisiert gegenüber den nachfolgenden Nicht-Vektoranweisungen, die ausgeführt werden dürfen.
-
Das offenbare Desynchronisationsverfahren ist jedoch diesbezüglich nicht eingeschränkt. Das heißt, während im Allgemeinen Nicht-Vektoranweisungen erläutert werden, die ausgeführt werden, wenn eine desynchronisierte Vektoranweisung ausgeführt wird, ist das offenbarte Desynchronisationsverfahren diesbezüglich nicht eingeschränkt. In alternativen Implementierungen kann eine zweite Vektoranweisung desynchronisiert ausgeführt werden, während eine erste desynchronisierte Vektoranweisung ausgeführt wird. Darüber hinaus kommen neben den Vektoranweisungen auch andere langlaufende Anweisungen (d. h. sie benötigen mehr Zeit als andere Anweisungen, um ihre Ausführung abzuschließen) für eine desynchronisierte Ausführung in Frage.
-
Es ist zu beachten, dass der Begriff „asynchrone“ zum Beispiel für die Anweisungen zum externen Laden des Speichers (xload) und zum externen Speichern des Speichers (xsave) verwendet wird, die Verarbeitungsmaschinen außerhalb der Vektorverarbeitungseinheit (VPU) anweisen, die Bewegung von Daten zwischen dem Speicher der VPU und dem externen Speicher zu koordinieren.
-
„Modifizieren/Ändern/Kopieren/Übertragen von Registern“ bezieht sich auf das Modifizieren/Ändem/Kopieren/Übertragen von Werten oder Parametern, die innerhalb von Registern gespeichert werden. Das heißt zum Beispiel, dass das Kopieren eines ersten Registers in ein zweites Register so zu verstehen ist, dass der Inhalt oder die Parameter, die in dem ersten Register enthalten sind oder gehalten werden, in das zweite Register kopiert wird, sodass das zweite Register nun den Wert oder Parameter des ersten Registers enthält.
-
„Konflikt“ bezieht sich auf zwei oder mehrere Prozesse, wie, jedoch ohne Einschränkung, die Ausführung von Anweisungen, die versuchen, dieselbe Einheit zu ändern oder auf sie zuzugreifen, wie, jedoch ohne Einschränkung, einen Speicher oder ein Register, bei denen die Änderung eine Ungewissheit in Bezug auf das Ergebnis der Verarbeitung einführen würde. Wenn zum Beispiel zwei ausführende Anweisungen versuchen, beide einen bestimmten Speicherort zu ändern, handelt es sich um einen Konflikt um die Ressource, d. h. einen Konflikt um dieselbe spezifische Position im Speicher. Je nachdem, welche Anweisung zuerst ausgeführt wird, kann der Konflikt zu einem anderen Ergebnis bei der Verarbeitung führen. Zum Beispiel ist ein Desynchronisationskonflikt ein Konflikt zwischen einer ausgeführten desynchronisierten Anweisung und einer anderen Anweisung, der sich auf die Prozessorausgabe auswirkt und zu einer unterschiedlichen Ausgabe führt, je nachdem, welche Anweisung zuerst ausgeführt wird. Zum Beispiel ist ein asynchroner Konflikt ein Konflikt zwischen einer ausgeführten asynchronen Anweisung und einer anderen Anweisung, der sich auf die Prozessorausgabe auswirkt und zu einer unterschiedlichen Ausgabe führt, je nachdem, welche Anweisung zuerst ausgeführt wird.
-
„Vektorparameter/neue Vektorparameter" beziehen sich auf Informationen über einen Vektor. In einem Beispiel kann es eine Vielzahl von Signalen sein. Insbesondere handelt es sich um Informationen, die der Prozessor für den Zugriff auf den Speicher benötigt (z. B. Lesen und Schreiben eines Vektors). „Neu“ bezieht sich auf die Situation, in der der Prozessor bereits Vektorparameter verwendet und eine neue Vektoroperation in die Warteschlange gestellt oder in die Pipeline zur künftigen Ausführung eingefügt wird, wobei die Vektorparameter für diese Vektoroperation als „neue Vektorparameter“ bezeichnet werden, um sie von den Vektorparametern zu unterscheiden, die gegenwärtig in einer gerade ausgeführten Vektoranweisung verwendet werden.
-
BESCHREIBUNG
-
In einem Beispiel wird eine Vektorprozessoreinheit bereitgestellt, die Vorladeregister für Vektorlänge, Vektorkonstante, Vektoradresse und Vektorschritt aufweist. Jedes Vorladeregister weist einen jeweiligen Eingang und einen jeweiligen Ausgang auf. Alle Vorladeregistereingänge sind gekoppelt, um einen neuen Vektorparameter zu empfangen. Jeder der Vorladeregisterausgänge ist mit einem ersten Eingang eines jeweiligen Multiplexers gekoppelt, und ein zweiter Eingang aller jeweiligen Multiplexer ist gekoppelt, um die neuen Vektorparameter zu empfangen.
-
In einem Beispiel werden Mechanismen offenbart, die bestimmen, wann eine desynchronisierte und asynchrone Ausführung erfolgen kann, und Mechanismen, die die Ausführung von Anweisungen stoppen, wenn die desynchronisierte und/oder asynchrone Ausführung abgeschlossen sein muss (Resynchronisation bzw. asynchrone Reserialisierung genannt), im Allgemeinen, um die Integrität der Programmergebnisse aufrechtzuerhalten. Die offenbarten Verfahren erlauben nicht nur eine desynchrone und asynchrone Ausführung, sondern schränken auch die Fälle ein, in denen eine Resynchronisation oder asynchrone Reserialisierung durchgeführt werden soll, da Resynchronisation und asynchrone Reserialisierung die Programmleistung reduzieren.
-
1 veranschaulicht im Allgemeinen bei 100 eine Blockdiagrammübersicht einer Decodiereinheit. Bei 102 befindet sich eine Steuerung zum Abrufen von Anweisungen aus einem Speichersystem. Das Speichersystem kann zum Beispiel ein Direktzugriffsspeicher (RAM) sein, auch wenn dies für das Verständnis der Decodiereinheit 100 nicht von Belang ist. Die Anweisungsabrufsteuerung 102 gibt über 103 Informationen an die Anweisungsdecodierung 104 und über 105 Ausführungs-/Blockierinformationen an die Betriebszustandssteuerung 106 und an die Pipelinesteuerung 108 aus. Die Anweisungsdecodierung 104 gibt über 107 Informationen zur Blockierungserkennung 112, Ergebnisbypasserkennung 114 und Ressourcenzuweisungsverfolgung 116 aus. Die Pipelinesteuerung 108 gibt über 117 Informationen an die Ressourcenzuweisungsverfolgung 116 aus. Die Ressourcenzuweisungsverfolgung 116 gibt über 119 Informationen zur Ergebnisbypasserkennung 114 und zur Blockierungserkennung 112 aus. Die Ergebnisbypasserkennung 114 gibt über 115 Informationen an die Pipelinesteuerung 108 aus. Die Blockierungserkennung 112 gibt über 113 Informationen an die Pipelinesteuerung 108 aus. Die Pipelinesteuerung 108 gibt über 121 Informationen an/von der Registereinheit 118, der Steuereinheit 120 für den Speicherzugriff, den skalaren arithmetischen Logikeinheiten (ALUs) 122, den vektoriellen arithmetischen Logikeinheiten (ALUs) 124 und der Verzweigungseinheit 126 aus und empfängt sie. Die Verzweigungseinheit 126 gibt über 125 Informationen an die Anweisungsabrufsteuerung 102 aus. Die Verzweigungseinheit 126 gibt über 123 Informationen an die Fehlersteuerung 110 aus. Die Vektor-ALUs 124 geben über 123 Informationen an die Fehlersteuerung 110 aus. Skalare ALUs 122 geben über 123 Informationen an die Fehlersteuerung 110 aus. Die Speicherzugriffssteuereinheit 120 gibt über 123 Informationen an die Fehlersteuerung 110 aus. Die Registereinheit 118 gibt über 123 Informationen an die Fehlersteuerung 110 aus. Die Fehlersteuerung 110 gibt über 109 an die Pipelinesteuerung 108 und über 111 an die Betriebszustandssteuerung 106 aus. Die Verzweigungseinheit 126 empfängt über 127 Informationen, die von den skalaren ALUs 122 ausgegeben werden, und Informationen von den Vektor-ALUs 124.
-
Der Einfachheit halber ist in 1 zu sehen, dass die Pipelinesteuerung 108 unter anderem mit der Registereinheit 118, der Speicherzugriffssteuereinheit 120, den skalaren ALUs 122 und den Vektor-ALUs 124 kommuniziert. Die Pipelinesteuerung 108 versucht, den Prozessor, in dem sich die Decodiereinheit 100 befindet, so schnell wie möglich laufen zu lassen, indem sie versucht zu vermeiden, dass skalare oder Vektor-ALUs von der seriellen Verarbeitung dessen abgehalten werden, was parallel erfolgen kann. Sie ist im Grunde genommen ein Verkehrspolizist, der den Verkehr in eine bestimmte Richtung lenkt, sodass der Durchsatz verbessert wird.
-
In einem Prozessor, der sowohl Skalar- als auch Vektoroperationen durchführen kann, ist es vorzugsweise sinnvoll, die Vektor-ALUs mit der höchstmöglichen Geschwindigkeit zu betreiben, da Vektoroperationen einen höheren Verarbeitungsaufwand erfordern als Skalaroperationen und somit im Wesentlichen die Gesamtverarbeitungsgeschwindigkeit bestimmen.
-
2 veranschaulicht im Allgemeinen bei 200 eine Blockdiagrammübersicht der Vektorregister zum Adressieren einer Speicherzugriffssteuerung. Bei 201 handelt es sich um neue Vektorparameter, d. h. 201 stellt den Empfang neuer zu ladender Vektorparameter 201 dar. Neue Vektorparameter 201 sind mit dem Eingang des Vektorlängenregisters 202 gekoppelt und der Ausgang des Vektorlängenregisters 202 ist über 203 mit der Speicherzugriffssteuerung 220 gekoppelt. Neue Vektorparameter 201 sind auch mit dem Eingang des Vektorkonstantenregisters 204 gekoppelt und der Ausgang des Vektorlängenregisters 202 ist über 205 mit der Speicherzugriffssteuerung 220 gekoppelt. Neue Vektorparameter 201 sind auch mit dem Eingang des Vektoradressenregisters 206 gekoppelt und der Ausgang des Vektorlängenregisters 206 ist über 207 mit der Speicherzugriffssteuerung 220 gekoppelt. Neue Vektorparameter 201 sind mit dem Eingang des Vektorschrittregisters 208 gekoppelt und der Ausgang des Vektorschrittregisters 208 ist über 209 mit der Speicherzugriffssteuerung 220 gekoppelt. Während das Vektorlängenregister 202, das Vektorkonstantenregister 204, das Vektoradressenregister 206 und das Vektorschrittregister 208 veranschaulicht sind, sind in einigen Beispielen eine oder mehrere der Vektorlängenregister 202 und Vektorkonstantenregister 204 nicht bereitgestellt.
-
Die Speicherzugriffssteuerung 220 ist ein Funktionsblock, kein Register. Als Eingänge werden die Vektorlänge, die über 203 aus dem Vektorlängenregister 202 bereitgestellt wird, die Vektorkonstante, die über 205 aus dem Vektorkonstantenregister 204 bereitgestellt wird, die Vektoradresse, die über 207 aus dem Vektoradressregister 206 bereitgestellt wird, und der Vektorschritt, der über 209 aus dem Vektorschrittregister 208 bereitgestellt wird, eingegeben. Die Kombination von Vektorlängenregister 202, Vektorkonstantenregister 204, Vektoradressenregister 206 und Vektorschrittregister 208 kann als Vektorsteuerung und Speicherzugriffssteuerung 220 als Speichersubsystem bezeichnet werden. Das heißt, die Vektorsteuerung steuert die Adressierung an ein Speichersubsystem. Das Speichersubsystem kann einen (nicht gezeigten) RAM einschließen.
-
Mit dem Verständnis der nachstehend beschriebenen 3 wird der Leser erkennen, dass 2, wie veranschaulicht, ein Beispiel für eine Einrichtung ist, die keine Vektordesynchronisation in der Vektorspeichersteuerung unterstützt, während 3, wie veranschaulicht, ein Beispiel für eine Einrichtung ist, die Vektordesynchronisation in der Vektorspeichersteuerung unterstützt.
-
3 veranschaulicht im Allgemeinen bei 300 eine Blockdiagrammübersicht eines Abschnitts einer Vektorprozessoreinheit, die Speicherzugriffssteuerungsvorladeregister umfasst.
-
Bei 301 handelt es sich um neue Vektorparameter. Neue Vektorparameter 301 sind mit dem Eingang des Vektorlängenvorladeregisters 302 gekoppelt und der Ausgang des Vektorlängenvorladeregisters 302 ist über 303 mit einem ersten Eingang eines jeweiligen Multiplexers 310 gekoppelt. Der zweite Eingang des Multiplexers 310 ist mit neuen Vektorparametern 301 gekoppelt, d. h., er umgeht das Vektorlängenvorladeregister 302. Der Ausgang des Multiplexers 310 ist über 311 mit einem Vektorlängenregister 322 gekoppelt. Der Ausgang des Vektorlängenregisters 322 ist über 323 mit der Speicherzugriffssteuerung 320 gekoppelt.
-
Neue Vektorparameter 301 sind mit dem Eingang des Vektorkonstantenvorladeregisters 304 gekoppelt und der Ausgang des Vektorkonstantenvorladeregisters 304 ist über 305 mit einem ersten Eingang eines jeweiligen Multiplexers 312 gekoppelt. Der zweite Eingang des Multiplexers 312 ist mit neuen Vektorparametern 301 gekoppelt, d. h. er umgeht das Vektorkonstantenvorladeregister 304. Der Ausgang des Multiplexers 312 ist über 313 mit einem Vektorkonstantenvorladeregister 324 gekoppelt. Der Ausgang des Vektorkonstantenvorladeregisters 324 ist über 325 mit der Speicherzugriffssteuerung 320 gekoppelt.
-
Neue Vektorparameter 301 sind mit dem Eingang des Vektoradressenvorladeregisters 306 gekoppelt und der Ausgang des Vektoradressenvorladeregisters 306 ist über 307 mit einem ersten Eingang eines jeweiligen Multiplexers 314 gekoppelt. Der zweite Eingang des Multiplexers 314 ist mit neuen Vektorparametern 301 gekoppelt, d. h., er umgeht das Vektoradressenvorladeregister 306. Der Ausgang des Multiplexers 314 ist über 315 mit einem Vektoradressenvorladeregister 326 gekoppelt. Der Ausgang des Vektorkonstantenvorladeregisters 326 ist über 327 mit der Speicherzugriffssteuerung 320 gekoppelt.
-
Neue Vektorparameter 301 sind mit dem Eingang des Vektorschrittvorladeregisters 308 gekoppelt und der Ausgang des Vektorschrittvorladeregisters 308 ist über 309 mit einem ersten Eingang eines jeweiligen Multiplexers 316 gekoppelt. Der zweite Eingang des Multiplexers 316 ist mit neuen Vektorparametern 301 gekoppelt, d. h. er umgeht das Vektorschrittvorladeregister 308. Der Ausgang des Multiplexers 316 ist über 317 mit einem Vektorschrittvorladeregister 328 gekoppelt. Der Ausgang des Vektorschrittvorladeregisters 328 ist über 329 mit der Speicherzugriffssteuerung 320 gekoppelt.
-
Während das Vektorlängenvorladeregister 302, das Vektorkonstantenvorladeregister 304, das Vektoradressenvorladeregister 306, das Vektorschrittvorladeregister 208, das Vektorlängenregister 322, das Vektorkonstantenregister 324, das Vektoradressenregister 326 und das Vektorschrittregister 328 mit den jeweiligen Multiplexern 310, 312, 314, 316 veranschaulicht sind, sind in einigen Beispielen eine oder mehrere von Vektorlängenvorladeregister 302, Vektorlängenregister 322, Vektorkonstantenregister 304 und Vektorkonstantenregister 324 sowie die jeweiligen Multiplexer nicht bereitgestellt.
-
Bei 330 handelt es sich um eine Multiplexersteuerung. Ein Ausgang der Multiplexersteuerung 330 ist über 331 mit den jeweiligen Steuereingängen des Multiplexers 316, des Multiplexers 314, des Multiplexers 312 und des Multiplexers 310 gekoppelt. Das heißt, die Steuereingänge des Multiplexers 316, des Multiplexers 314, des Multiplexers 312 und des Multiplexers 310 werden alle über die Verbindung 331 gesteuert, die von der Multiplexersteuerung 330 ausgegeben wird. In einem Beispiel führt die Verbindung 331 ein einziges Signal zu allen Steuereingängen des Multiplexers 316, des Multiplexers 314, des Multiplexers 312 und des Multiplexers 310, und in einem anderen Beispiel führt die Verbindung 331 ein jeweiliges Signal zu jedem der Steuereingänge des Multiplexers 316, des Multiplexers 314, des Multiplexers 312 und des Multiplexers 310, sodass diese einzeln steuerbar sind.
-
Die Multiplexersteuerung 330 identifiziert, ob die Speicherzugriffssteuerungsregister 350 mit neuen Vektorparametereinstellungen 301 oder von den jeweiligen Ausgängen der Speicherzugriffssteuerungsvorladeregister 340, wie nachstehend beschrieben, geladen werden sollen, und steuert daher die Verbindung 331, um die Speicherzugriffssteuerungsregister 350 an den richtigen Punkten zwischen 2 desynchronisierten Vektorarithmetikoperationen zu aktualisieren. Das Aktualisieren erfolgt von den Vorladeregistern (302, 304, 306, 308) zu den Registern (322, 324, 326, 328) oder von neuen Vektorparametern 301 zu den Registern (322, 324, 326, 328). Wie nachstehend beschrieben, steuert die Multiplexersteuerung 330 ferner das Schreiben in jedes der Vorladeregister (302, 304, 306, 308) und die Register (322, 324, 326, 328).
-
Das Vektorlängenvorladeregister 302, das Vektorkonstantenvorladeregister 304, das Vektoradressenvorladeregister 306 und das Vektorschrittvorladeregister 308 umfassen zusammen die Speicherzugriffssteuerungsvorladeregister 340. Das Vektorlängenvorladeregister 302, das Vektoradressenvorladeregister 304, das Vektoradressenvorladeregister 306 und das Vektorschrittvorladeregister 308 werden unabhängig voneinander als Speicherzugriffssteuerungsvorladeregister betrachtet.
-
Vektorlängenregister 322, Vektorkonstantenregister 324, Vektorkonstantenregister 326 und Vektorschrittregister 328. Individuell umfassen jedes Vektorlängenregister 322, Vektorkonstantenregister 324, Vektorkonstantenregister 326 und Vektorschrittregister 328 zusammen Speicherzugriffssteuerungsregister 350. Individuell werden jedes Vektorlängenregister 322, das Vektorkonstantenregister 324, das Vektorkonstantenregister 326 und das Vektorschrittregister 328 als Speicherzugriffssteuerungsregister betrachtet.
-
Bei der Speicherzugriffssteuerung 320 handelt es sich um einen Funktionsblock und nicht um ein Register. Als Eingänge dienen die Werte von Vektorlänge, Vektorkonstante, Vektoradresse und Vektorschrittregister (bereitgestellt durch die jeweiligen Speicherzugriffssteuerungsregister 322, 324, 326, 328 über die jeweiligen Verbindungen 323, 325, 327, 329). Die Register 322, 324, 326, 328 und ihre jeweiligen Parameter, die über die Verbindungen 323, 325, 327, 329 kommuniziert werden, können als Vektorsteuerung und die Speicherzugriffssteuerung 320 als Speichersubsystem bezeichnet werden. Das heißt, die Vektorsteuerung steuert die Adressierung an ein Speichersubsystem. Das Speichersubsystem kann einen (nicht gezeigten) RAM einschließen.
-
Die Multiplexersteuerung 330 wird als in einer Nicht-Vorladeposition betrachtet, wenn neue Vektorparameter 301 durch die Multiplexer 310, 312, 314 bzw. 316 und dann über 311, 313, 315 bzw. 317 in das Vektorlängenregister 322, das Vektorkonstantenregister 324, das Vektorkonstantenregister 326 und das Vektorschrittregister 328 gelangen.
-
Die Multiplexersteuerung 330 wird als in einer Vorladeposition befindlich betrachtet, wenn die Multiplexer 310, 312, 314 und 316 jeweils Eingänge von Vektorlängenvorladeregister 302, Vektorkonstantenvorladeregister 304, Vektoradressenvorladeregister 306 und Vektorschrittvorladeregister 308 über 303, 305, 307 bzw. 309 empfangen.
-
Das heißt, in der Nicht-Vorladeposition empfangen die Speicherzugriffssteuerungsregister 350 Parameter von den neuen Vektorparametern 301. In der Vorladeposition empfangen die Speicherzugriffssteuerungsregister 350 Parameter von den Speicherzugriffssteuerungsvorladeregistern 340.
-
Damit das Beispiel nicht unübersichtlich wird, ist nicht gezeigt, dass die Multiplexersteuerung 330 Schreibsignale in die Zugriffssteuerungsregister 350 und die Speicherzugriffssteuerungsvorladeregister 340 steuert. Auf diese Weise steuert die Multiplexersteuerung 330, welche Register die neuen Vektorparameter 301 empfangen.
-
In 3 wird der Multiplexer 310 als erster Multiplexer betrachtet.
-
In 3 wird der Multiplexer 312 als zweiter Multiplexer betrachtet.
-
In 3 wird der Multiplexer 314 als dritter Multiplexer betrachtet.
-
In 3 wird der Multiplexer 316 als vierter Multiplexer betrachtet.
-
4 veranschaulicht im Allgemeinen bei 400 ein Flussdiagramm, das die desynchrone Ausführung einer Anweisung und die synchrone Ausführung einer Anweisung zeigt. Bei 402 wird die nächste auszuführende Anweisung abgerufen. Die Vorgehensweise über 403 bis 404. Bei 404 wird bestimmt, ob die nächste auszuführende Anweisung die Ergebnisse einer laufenden desynchronisierten Anweisung beeinflusst oder von diesen abhängig ist. Wenn die nächste auszuführende Anweisung die Ergebnisse einer laufenden desynchronisierten Anweisung beeinflusst oder von diesen abhängig ist, was als Desynchronisationskonflikt (Ja) bezeichnet wird, dann wird über 419 zu 420 übergegangen. Wenn die nächste auszuführende Anweisung die Ergebnisse einer laufenden desynchronisierten Anweisung nicht beeinflusst oder nicht von diesen abhängig ist (Nein), dann wird über 405 zu 430 zur optionalen asynchronen Ausführung übergegangen. Bei 420 wird die Ausführung erneut synchronisiert, indem gewartet wird, bis alle desynchronisierten Vorgänge abgeschlossen sind, bevor über 405 zu 430 zur optionalen asynchronen Ausführung übergegangen wird. Wenn keine optionale asynchrone Ausführung 430 vorhanden ist, dann wird über 409 zu 410 übergegangen.
-
Bei 410 wird bestimmt, ob die abgerufene nächste Anweisung desynchron ausgeführt werden kann. Wenn die nächste Anweisung desynchron ausgeführt werden kann (Ja), dann wird über 411 zu 412 übergegangen. Bei 412 wird die desynchrone Ausführung eingeleitet, indem dem Prozessor gestattet wird, die abgerufene nächste Anweisung desynchron auszuführen, d. h., der Abschluss der abgerufenen nächsten Anweisung erfolgt desynchron in Bezug auf die Steuerung des Prozessors, aber der Prozessor läuft, wenn ein internes Signal gegeben wird, das den Abschluss der Operation angibt. Der Prozessor wartet nicht auf dieses Abschlusssignal, bevor er über 415 zu 402 übergeht.
-
Wenn die nächste Anweisung nicht desynchron ausgeführt werden kann (Nein), dann über 413 zu 414 übergehen. Bei 414 wird die desynchrone Ausführung eingeleitet, indem dem Prozessor gestattet wird, die abgerufene nächste Anweisung synchron auszuführen, d. h., die Anweisung hat den Anschein für das Programm, dass sie vollständig abgeschlossen ist, bevor sie über 415 mit 402 fortgesetzt wird. Der Prozessor kann in einer Pipeline arbeiten oder andere überlappende Ausführungstechniken einsetzen, sodass es für ein Programm den Anschein hat, dass er die Anweisung abschließt, bevor er mit 402 fortfährt.
-
Einige Operationen können auch außerhalb der Reihenfolge durchgeführt werden, andere nicht. Nicht alles kann außerhalb der Reihenfolge sein, andernfalls wird die allgemeine Integrität eines Programms (und daher seine Nützlichkeit) untergraben. Um Anweisungen zu vermeiden, die den Zustand des Prozessors korrumpieren können, ist ein Prozess mit der Bezeichnung Resynchronisation, d. h. 420, bereitgestellt, der die weitere Ausführung anhält, bis eine desynchronisierte Operation abgeschlossen ist. Dies wirkt sich auf die Leistung aus, und diese Offenbarung beschreibt ausführlich die Beseitigung einiger der Ursachen für die Resynchronisation, wodurch die Programmausführung beschleunigt wird.
-
Wenn bekannt ist, dass es eine desynchronisierte Ausführung von einer oder mehreren Anweisungen gibt, z. B. eine Vektoranweisung in 4 bei 412, dann kann die Multiplexersteuerung 330 in 3 das Aktualisieren der Speicherzugriffssteuerungsregister 350 an den richtigen Punkten zwischen den beiden desynchronisierten Vektorarithmetikoperationen durchführen.
-
Eine Vektoranweisung kann sich von den ausführenden Anweisungen in der Pipeline abkoppeln, wodurch eine andere Anweisung ausgeführt werden kann. Wenn eine nachfolgende Anweisung einen Ressourcenkonflikt mit der desynchronisierten Anweisung aufweist, muss die nachfolgende Anweisung warten, bis der Konflikt beseitigt ist - dies ist ein Beispiel für einen Desynchronisationskonflikt, wie in Bezug auf 404 beschrieben. Wenn Sie jedoch eine zweite Vektoranweisung ausführen können, ohne einen Ressourcenkonflikt zu verursachen, kann die zweite Vektoranweisung desynchronisiert ausgeführt werden.
-
Anweisungen, die für eine desynchronisierte Ausführung in Frage kommen, sind alle langlaufenden Anweisungen, da dies den nachfolgenden Anweisungen ermöglicht, ihre Ausführung abzuschließen, während die desynchronisierte Anweisung ausgeführt wird. Somit wird die Ausführungszeit für nachfolgende Anweisungen, die ausgeführt werden, während die desynchronisierte Anweisung ausgeführt wird, effektiv reduziert, da sie nicht auf den Abschluss der Ausführung der desynchronisierten Anweisung warten müssen.
-
Eine andere Möglichkeit, die hierin offenbarten Beispiele zu betrachten, ist zu sehen, welche Anweisungen ausgeführt werden können, wenn eine desynchronisierte Anweisung ausgeführt wird.
-
Da Vektoranweisungen Langläufer sind und den Großteil der Arbeit in einem Vektorprozessor darstellen, sollten idealerweise alle Nicht-Vektoranweisungen ausgeführt werden dürfen, während eine desynchronisierte Vektoranweisung ausgeführt wird. Wenn dies erreicht werden kann, dann wird die Verarbeitungszeit durch die Ausführung der Vektoranweisungen begrenzt, da alle anderen Anweisungen ausgeführt werden, während die desynchronisierten Vektoranweisungen ausgeführt werden.
-
Vektoranweisungen lesen Operanden aus dem Speicher und schreiben Ergebnisse in den Speicher. Daher sind Anweisungen, die keinen Zugriff auf den Speicher haben, Kandidaten zur Ausführung, wenn eine desynchronisierte Vektoranweisung ausgeführt wird. Diese Anweisungen schließen alle skalaren arithmetischen Anweisungen ein, deren Operanden aus einem Registersatz stammen und deren Ergebnis in einen Registersatz einfließt. Sie schließen auch Anweisungen ein, die auf einen Speicher zugreifen, der entweder einen anderen Speicher oder einen anderen Speicherbereich verwendet als eine desynchronisierte Vektoranweisung. Dies kann ohne Einschränkung Unterprogrammaufrufe und -rückgaben sowie das Einschieben und Herausnehmen von Parametern aus einem Stapel einschließen.
-
Es gibt eine Klasse von Anweisungen, die zu Konflikten mit einer desynchronisierten Vektoranweisung führen können. Zum Beispiel Anweisungen, die eine nachfolgende Vektoroperation einrichten (Vektoradressen im Speicher, Vektorlängen, ohne Einschränkung) und Ressourcen modifizieren, die sich negativ auf die gerade ausgeführte desynchronisierte Vektoranweisung auswirken können.
-
Aus Leistungsgründen wäre es wünschenswert, wenn diese konfliktverursachenden Anweisungen auch parallel zu einer desynchronisierten Vektoranweisung ausgeführt werden könnten.
-
Wenn die Verarbeitung von Vektoren den Hauptteil der Arbeit in einem Vektorprozessor darstellt, dann sind Anweisungen, die diese Vektoren einstellen, ebenfalls sehr häufig, und die Ausführung jedes Mal neu synchronisieren zu müssen, wenn ein neuer Vektor eingestellt wird, stellt eine erhebliche Leistungsverschlechterung dar.
-
Daher besteht ein Bedarf an Anweisungen, die Speicherzugriffssteuerungsvorladeregister einstellen (z. B. 3 bei 340), die Vektoradressen, Vektorschritte, Vektorlängen und Vektorkonstantenwerte spezifizieren, sodass die aktuell ausgeführte desynchronisierte Vektoranweisung nicht beeinträchtigt wird.
-
Vektorlänge, Vektorkonstante, Vektoradresse und Vektorschritt sind Entitäten, die sich in Registern befinden können, z. B. in den Speicherzugriffssteuerungsregistern 350 (z. B. 322, 324, 326 bzw. 328) in 3, und über 323, 325, 327 bzw. 329 mit der Speicherzugriffssteuerung 320 kommunizieren. Vektorlängenvorladung, Vektorkonstantenvorladung, Vektoradressenvorladung und Vektorschrittvorladung sind Entitäten, die sich in Speicherzugriffssteuerungsvorladeregistern 340 (z. B. 302, 304, 306 bzw. 308 in 3) befinden können und über 303, 305, 307 bzw. 309 in Kommunikation mit Multiplexer 310, 312, 314 bzw. 316 stehen. Die Vektorlänge, Vektorkonstante, Vektoradresse und der Vektorschritt, die der Einfachheit halber gemeinsam als Vektorport bezeichnet werden, ermöglichen die Adressierung eines Vektors in der Speicherzugriffssteuerung 320, die der Einfachheit halber als Speicher bezeichnet wird. Somit adressiert der Vektorport den Speicher, um auf einen Vektor zu zeigen.
-
Zum Beispiel ist eine Vektorlänge eine Länge eines Vektors in dem Speicher.
-
Zum Beispiel ist eine Vektorkonstante eine Konstante, die beim Betrieb auf einem Vektor verwendet wird. Wenn es zum Beispiel erforderlich ist, jedes Element eines Vektors A mit 2 zu multiplizieren, dann ist Vektor B, der Multiplikator, ein Vektor, dessen Elemente alle den Wert 2 aufweisen. Anstatt den Vektor B im Speicher zu speichern, kann die Vektorkonstante in einem Register gespeichert werden, das den Wert jedes Elements von Vektor B spezifiziert.
-
Eine Vektoradresse ist eine Adresse, an der ein Vektor zu finden ist. Ein Vektorschritt ist ein Schrittwert, der bei jedem Zugriff auf ein Vektorelement im Speicher zur Vektoradresse hinzugefügt wird. Zum Beispiel kann der Vektorschritt gleich 1 sein, wenn der Vektor eine Zeile einer Matrix ist, aber er kann auf N eingestellt werden, wenn er eine Spalte einer Matrix ist, die N Elemente in jeder Zeile aufweist. Vektoradresse und Vektorschritt werden zum Adressieren von Speicherpositionen verwendet, an denen ein Vektor gelesen oder geschrieben werden kann.
-
DETAILLIERTE BEISPIELE FÜR DIE AUSFÜHRUNG VON ANWEISUNGEN
-
Da die offenbarten Techniken zum Verbessern der Ausführung eines Vektorprozessors verwendet werden, sind diese detaillierten Beispiele veranschaulichend für die Techniken.
-
Zunächst wird ein Beispiel für eine desynchronisierte Ausführung gezeigt. Dann ein Beispiel für eine asynchrone Ausführung. Und schließlich ein Beispiel, das die Relevanz in Bezug auf die gemeinsam eingereichte Anmeldung Nr. 17/468,574 vom 07.09.2021 aufzeigt, in der ein Parameterstapel, ein Registerstapel und ein Unterprogrammaufrufstapel beschrieben werden, die vom lokalen Speicher getrennt sind, der in großem Umfang von den Vektor-ALUs 124 verwendet wird.
-
In den folgenden Beispielen bedeuten diese Mnemonics Folgendes:
-
Um den Leser nicht zu verwirren, wird in den nachstehenden Beispielen der Fall betrachtet, in dem Feld 124 eine einzelne Vektor-ALU (Mehrzahl) angibt, während in 1 das Feld 124 eine einzelne Vektor-ALU ist, und es wird als Vektor-ALU 124 bezeichnet. Die offenbarten Techniken sind diesbezüglich nicht eingeschränkt, wobei mehrere ALUs möglich sind.
-
Desynchronisierte Ausführung
-
-
Es gibt keinen Grund, warum die vorstehend veranschaulichten Anweisungen, die auf die Anweisung sqrt folgen, nicht ausgeführt werden können, während die Anweisung sqrt ausgeführt wird. Das heißt, die Pipelinesteuerung 108 (auch Pipe Control genannt) muss zulassen, dass die Anweisung sqrt desynchronisiert ausgeführt wird, sodass die Pipelinesteuerung 108 die Ausführung der nachfolgenden Anweisungen (in diesem Beispiel add r7 r8 und div r7 r9) ermöglichen kann.
-
Es kann jedoch sein, dass die Pipelinesteuerung 108 zu einem bestimmten Zeitpunkt eine desynchronisierte Operation erneut synchronisieren muss, wenn diese noch im Gange ist. Zum Beispiel, wenn die Vektor-ALU, 124, jeweils nur eine Vektoroperation unterstützt, dann demonstriert das Folgende eine Resynchronisation:
-
Im unmittelbar obigen Beispiel wird der ursprüngliche Vektor quadratisch verwurzelt, wobei das Ergebnis dieser Quadratwurzel dann von der Logarithmusfunktion betrieben wird, da keine Vektoradressen geändert wurden. Wenn aber die Vektor-ALU 124 jeweils nur eine Vektoroperation durchführen kann, muss die Quadratwurzel abgeschlossen sein, bevor der Logarithmus beginnen kann. Wenn die Quadratwurzel nicht abgeschlossen ist (überwacht durch die Ressourcenzuweisungsverfolgung 116), muss das desynchronisierte sqrt mit der Ausführung der Pipelinesteuerung 108 neu synchronisiert werden, da die Anweisung sqrt nicht neu synchronisiert wurde. Dies erfolgt durch die Ressourcenzuweisungsverfolgung 116, die der Blockierungserkennung 112 angibt, dass eine Resynchronisation erforderlich ist, und die Blockierungserkennung 112 hält die Pipelinesteuerung 108 von der Ausführung der Protokollanweisung ab, bis die Resynchronisation abgeschlossen und die Vektor-ALU 124 verfügbar ist.
-
Eine Resynchronisation stellt einen Leistungsverlust dar und ist, obwohl manchmal notwendig, unerwünscht. Idealerweise sollte die Vektor-ALU 124 so gut wie möglich ausgelastet sein, mit einer Auslastung, die so nahe wie möglich bei 100 % liegt, da der Großteil des Prozesses in einem Vektorprozessor in der Verarbeitung von Vektoren besteht.
-
Das folgende Beispiel wird in Betracht gezogen, das stellvertretend für viele gängige Szenarien ist:
-
In diesem Fall ändert das zweite Auftreten der Anweisungen sas0, sas1 und slen die Speicherpositionen, die definieren, wo sich die Operanden- und Ergebnisvektoren befinden. Wenn aber die sqrt-Anweisung, die noch ausgeführt wird, desynchronisiert wird, wenn diese Anweisungen ausgeführt werden, wirken sie sich negativ auf den sqrt aus, da die Vektoren für den sqrt unerwartet eine geänderte Adresse, Schritte und Längen aufweisen. Somit muss das zweite Auftreten von sas0 eine Resynchronisation verursachen, was nicht erwünscht ist.
-
3 zeigt ein Beispiel, wie eine Resynchronisation vermieden werden kann.
-
Das zweite Auftreten der Anweisungen sas0, sas1 und slen kann ausgeführt werden, während der desynchronisierte sqrt ausgeführt wird, indem in die Speicherzugriffsvorladeregister 302, 306 und 308 die Operanden- und Ergebnisports geschrieben werden, anstatt in die Speicherzugriffssteuerungsvorladeregister 322, 326 und 328 zu schreiben.
-
Die Multiplexersteuerung 330, die durch die Pipelinesteuerung 108 gesteuert wird, erkennt den Versuch, eines der Speicherzugriffssteuerungsregister 350 zu modifizieren, während eine desynchronisierte Operation im Gange ist, und veranlasst stattdessen, dass die Speicherzugriffssteuerungsvorladeregister 340 geschrieben werden, d. h. die Multiplexersteuerung 330 entscheidet, ob die Speicherzugriffssteuerungsregister 350 oder die Speicherzugriffssteuerungsvorladeregister 340 geschrieben werden. Daher werden die Register der Speicherzugriffssteuerung 350 durch eine nachfolgende Anweisung nicht beeinträchtigt, während eine desynchronisierte Operation im Gange ist, und die desynchronisierte Operation wird daher nicht nachteilig beeinflusst.
-
Die Pipelinesteuerung 108 erkennt ferner, wenn der desynchronisierte Vorgang abgeschlossen ist, und wenn eines der Speicherzugriffssteuerungsvorladeregister 340 eine Änderung aufweist, wird ihr Inhalt durch die Multiplexersteuerung 330 der Pipelinesteuerung 108 in das jeweilige Speicherzugriffssteuerungsregister 350 verschoben. Somit wird die vollständige Funktionalität, die für die zweite Ausführung der Anweisungen sas0, sas 1 und slen erforderlich ist, bereitgestellt, ohne dass diese neu synchronisiert werden müssen und daher an Leistung verlieren. Die Vektorprotokollanweisung kann nun ausgeführt werden, und da es sich um eine Vektoranweisung handelt, kann sie desynchronisiert ausgeführt werden. Wenn mehrere Vektoranweisungen nicht parallel ausgeführt werden können, wird das Vektorprotokoll als Reaktion auf die Pipelinesteuerung 108 zuerst resynchronisiert, sodass jeweils nur eine desynchronisierte Vektoranweisung ausgeführt wird.
-
Auf diese Weise kann die Vektoreinheit nahezu 100 % ausgelastet bleiben (ohne Berücksichtigung etwaiger Ineffizienzen beim Hochfahren in einer bestimmten Implementierung). Die Vektor-ALU 124 wurde von der Durchführung von Quadratwurzeln an jedem Element eines Vektors zur sofortigen Durchführung von Logarithmen an einem anderen Vektor übergegangen und erfüllte damit das Ziel, die Vektor-ALU 124 zu fast 100 % auszulasten.
-
Wäre sqrt vor dem zweiten Auftreten der Anweisungen sas0, sas 1 und slen abgeschlossen worden, so wäre keine desynchronisierte Operation im Gange gewesen. Die Pipelinesteuerung 108 erkennt dies und ermöglicht über die Multiplexersteuerung 330, dass die Speicherzugriffssteuerungsregister 350 sofort durch die neuen Vektorparameter 301 aktualisiert werden, ohne Speicherzugriffssteuerungsvorladeregister 340 verwenden zu müssen.
-
Es ist möglich, dass die zweite sas0 die Register 306 und 308 und nicht 326 und 328 aufgrund der desynchronisierten Ausführung des sqrt aktualisiert hat, aber als die slen-Anweisung ausgeführt wurde, war die desynchronisierte Ausführung abgeschlossen. In diesem Fall werden die Register 326 und 328 durch die Multiplexersteuerung 330 aus den Registern 306 und 308 aktualisiert, wenn die desynchronisierte Ausführung abgeschlossen ist, und Slen kann direkt in das Register 322 schreiben.
-
3 stellt ein Verfahren dar, bei dem die desynchronisierte Ausführung fortgesetzt werden kann und zusätzliche Anweisungen ausgeführt werden können, selbst wenn diese Anweisungen einen Ressourcenkonflikt aufweisen, weil die Anordnung von 3 den Ressourcenkonflikt auflöst. Das in 3 gezeigte Beispiel dient zur Veranschaulichung und stellt keine Einschränkung des Schutzumfangs dar.
-
Asynchrone Ausführung
-
======================
-
Asynchrone Ausführung ist eine Form der desynchronisierten Ausführung, wenn bestimmte Aktionen nicht vorhergesagt oder antizipiert werden können, da sie außerhalb der Steuerung des Prozessors liegen.
-
Ein Beispiel dafür ist das programmatische Laden oder Speichern von lokalem Speicher mit einem externen Speicher oder einer Vorrichtung. Wenn eine Programmanweisung die Prozedur einleitet, dass ein externer Prozess den lokalen RAM ausliest und etwas mit den Daten macht, wie z. B. sie in einem ewigen Speicher zu speichern, dann weiß die Pipelinesteuerung 108 (auch Pipe Control genannt) (in 1) nicht, wann dieser externe Prozess tatsächlich den lokalen Speicher auslesen wird. In ähnlicher Weise weiß die Pipe Control 108 nicht, wann diese Daten tatsächlich geschrieben und vom Prozessor verwendet werden können, wenn eine Anweisung des Programms die Prozedur für einen externen Prozess zum Laden neuer Daten in den lokalen RAM einleitet.
-
Dieses Beispiel kann durch zwei Anweisungen weiter verdeutlicht werden:
- xload r1 r2 r3 -- lädt r2 Bytes von Daten beginnend mit der externen Speicheradresse r3 in den lokalen Speicher beginnend mit Adresse r1. Das heißt, der Inhalt der externen Speicherplätze r3, r3+1,...,r3+r2-1 wird in die jeweiligen lokalen Speicherplätze r1, r1+1,...,r1+r2-1 geladen.
- xsave r1 r2 r3 -- speichert r2 Bytes von Daten ab der lokalen Speicheradresse r3 in den externen Speicher ab Adresse r1. Das heißt, der Inhalt der lokalen Speicherplätze r3, r3+1,...,r3+r2-1 wird in den jeweiligen externen Speicherplätzen r1, r1+1,...,r1+r2-1 gespeichert.
- wobei r1, r2 und r3 Register sind, die die gewünschten Werte für die Operation enthalten.
-
Da die Ausführung von xload und xsave eine beträchtliche Zeit in Anspruch nehmen kann, wäre es vorteilhaft, wenn die Pipelinesteuerung 108 die Ausführung der Anweisungen fortsetzt, die auf xload oder xsave folgen, so wie sie es auch bei der desynchronisierten Ausführung tut. Diese Variation der desynchronisierten Ausführung wird als asynchrone Ausführung bezeichnet, da bestimmte Aktivitäten der Anweisungen xload und xsave asynchron in Bezug auf die Steuerung der Pipe 108 ausgeführt werden.
-
Eine asynchrone Ausführung ermöglicht eine schnellere Programmausführungsleistung. Jedoch muss die gleiche Art von Problem wie die Resynchronisation berücksichtigt werden, wenn ein Ressourcenkonflikt oder eine Datenabhängigkeit besteht. Die Ressourcenzuweisungsverfolgung 116 überwacht diese Probleme, solange die asynchronen Operationen noch keine externe Angabe zu ihrem Abschluss erhalten haben, und weist die Blockierungserkennung 112 bei Bedarf an, die Ausführung von Anweisungen durch die Steuerung 108 anzuhalten, wenn ein Problem auftritt, das die Unterbrechung der Ausführung von Anweisungen erforderlich macht, bis das Problem behoben oder die asynchrone Operation abgeschlossen ist. Dies ist nicht gleichbedeutend mit einer Resynchronisation, da die asynchrone Operation abgeschlossen werden kann, während eine desynchronisierte Vektoroperation noch läuft. Die Anweisung, die auf den Abschluss der asynchronen Operation warten musste, kann nun jedoch ausgeführt werden, obwohl eine Resynchronisation der desynchronisierten Vektoroperation nicht durchgeführt wurde.
-
Die xload-Anweisung wird nun in Betracht gezogen. Nach der Ausgabe durch die Pipelinesteuerung 108 schreibt ein externer Prozess zu einem nicht vorhersehbaren Zeitpunkt die Daten, die aus einem externen Speicher oder einer externen Vorrichtung abgerufen werden, in den lokalen Speicher. Wenn der lokale Speicher keine separaten Schreibports für externe und interne (durch einen Prozessor erzeugte) Schreibvorgänge aufweist, handelt es sich um einen Ressourcenkonflikt. Selbst wenn mehrere Schreibports vorhanden sind, kann es sein, dass eine zukünftige Anweisung die neuen Daten verwenden muss, die durch xload geladen werden. Auch hier handelt es sich um einen Ressourcenkonflikt, wobei die Ressource die Daten sind und der Konflikt in der richtigen Reihenfolge des Ladens der Daten aus der externen Quelle und der Verwendung der Daten durch eine Anweisung besteht, die auf den xload folgt.
-
Nun wird die xsave-Anweisung in Betracht gezogen. Nach der Ausgabe durch die Pipelinesteuerung 108 (d. h. die Pipeline-Steuerung 108) liest ein externer Prozess zu einem nicht vorhersehbaren Zeitpunkt die Daten aus dem lokalen Speicher aus und speichert sie in einem externen Speicher oder in einer externen Vorrichtung. Wenn der lokale Speicher keine getrennten Leseports für externe und interne (durch einen Prozessor erzeugte) Lesevorgänge aufweist, handelt es sich um einen Ressourcenkonflikt. Selbst wenn mehrere Leseports vorhanden sind, kann eine zukünftige Anweisung die Daten überschreiben, die noch im Prozess der Speicherung durch die xsave-Anweisung sind. Auch hier handelt es sich um einen Ressourcenkonflikt, wobei die Ressource die Daten sind und der Konflikt in der richtigen Reihenfolge des Lesens der Daten besteht, bevor sie durch neue Daten überschrieben werden.
-
Es folgt ein Beispiel für einen Anweisungsstrom:
-
In diesem Beispiel wird der xload ausgeführt, aber das Laden neuer Daten in den lokalen Speicher wird asynchron durchgeführt. Daher können die Anweisungen add und mul ausgeführt werden. Die Speicheranweisung muss jedoch Daten in den lokalen Speicher schreiben. Da es nicht vorhersehbar ist, wann xload auch in den lokalen Speicher schreibt, ist es möglich, dass store und xload versuchen, gleichzeitig Schreibvorgänge durchzuführen, was in einem Design mit nur einem Schreibport nicht unterstützt wird. Daher muss die Speicheranweisung zurückgestellt werden, bis xload das Schreiben in den lokalen Speicher beendet hat. Die Ressourcenzuweisungsverfolgung 116 überwacht den asynchronen xload, erkennt diesen Konflikt und weist die Blockierungserkennung 112 an, die Ausführung der Speicheranweisung durch die Pipelinesteuerung 108 anzuhalten, bis die Ressourcenzuweisungsverfolgung 116 bestimmt, dass der Konflikt gelöst ist.
-
In diesem Beispiel brachte die Möglichkeit, xload asynchron auszuführen, eine gewisse Leistungsverbesserung, und zwar bis hin zur Speicheranweisung. Zusätzliche Verbesserungen sind jedoch möglich, da die Speicheranweisung an eine andere Position im Speicher schreibt als der xload. Es wäre wünschenswert, dass die Speicheranweisung und die darauf folgenden Anweisungen ausgeführt werden können, während der asynchrone xload noch läuft.
-
Ein Mechanismus für eine solche Verbesserung besteht darin, dass der externe Prozess von dem Prozessor die Erlaubnis anfordert, in den lokalen Speicher zu schreiben und die Schreibdaten zu puffern, bis diese Erlaubnis von der Pipelinesteuerung 108 erteilt wird. Dies kann vollkommen zufriedenstellend sein, wenn nur kleine Datenmengen aus dem externen Speicher geladen werden sollen, aber wenn viele Daten aus dem externen Speicher zurückgegeben werden und die Erlaubnis der Pipelinesteuerung 108, in den lokalen Speicher zu schreiben, verzögert wird, kann der Puffer unannehmbar groß werden. (Wenn eine sehr lange laufende Vektoranweisung desynchronisiert ausgeführt wird, kann die Pipelinesteuerung 108 sie nicht unterbrechen, da sie desynchronisiert ist. Es kann sehr lange dauern, bis der Schreibport nicht mehr verwendet wird).
-
Ein anderer Mechanismus, der dieses Problem löst und den Puffer überflüssig macht, besteht darin, dass der externe Prozess die Taktgeber des Prozessors abschaltet, die Schreibvorgänge durchführt und dann die Taktgeber des Vektors wieder einschaltet. Dies ist vergleichbar mit einer kurzzeitigen Untätigkeit des Vektors, während der der lokale RAM beschrieben wurde, wobei der Prozessor erst danach wieder aktiv wurde. Aus der Perspektive des Prozessors ist es so, als ob die neuen Daten plötzlich im lokalen Speicher erscheinen würden. Dies setzt voraus, dass der lokale Speicher an einem vom restlichen Vektorprozessor getrennten Taktgeber hängt, der während dieser „unbewussten“ Operation nicht abgeschaltet wird.
-
Diese „unbewusste“ Operation löst nicht alle Probleme. Der folgende Anweisungsstrom wird in Betracht gezogen:
-
In diesem Beispiel ruft die Abrufanweisung Daten aus dem lokalen Speicher ab, die durch den vorherigen xload geladen werden. Der Abruf kann erst dann ausgeführt werden, wenn xload diese Daten in den lokalen Speicher geschrieben hat.
-
Die Ressourcenzuweisungsverfolgung 116 überwacht die diesen zugeordneten lokalen Speicheradressen und leitet den Prozess zum Blockieren jeder Anweisung ein, die eine Speicheradresse in diesem Bereich liest oder schreibt. Dabei handelt es sich um ein automatisches Mittel zur Konfliktlösung. Programmierbare Mittel können auch oder alternativ bereitgestellt werden. Ein Programmierer weiß im Allgemeinen, ob er Daten im Voraus abruft und wann diese Daten später im Programm verwendet werden. Daher kann der Programmierer eine Anweisung wie xlwait (xload wait) verwenden, um die Pipelinesteuerung 108 darauf hinzuweisen, dass sie warten muss, bis ein ausstehender asynchroner xload abgeschlossen ist, bevor sie mit der Anweisungsausführung fortfährt. Dies kann zu einer Vereinfachung des Entwurfs führen, da es den Programmierer dazu bewegt, sicherzustellen, dass die Gefahr eines Wettlaufs vermieden wird.
-
Ähnliche Überlegungen gelten für die Anweisung xsave:
- - Die Pipelinesteuerung 108 kann eine asynchrone Ausführung von xsave veranlassen und mit der Ausführung nachfolgender Anweisungen fortfahren, bis eine Anweisung angetroffen wird, die einen Konflikt mit einem Speicherleseport aufweist.
- - Konflikte beim Lesen von Speicherports können beseitigt werden, indem externe Logik die Vektortakte des Prozessors abschalten kann.
- - Die Ressourcenzuweisungsverfolgung 116 überwacht die lokalen Speicheradressen, die xsave zugeordnet sind, und leitet den Prozess zum Blockieren jeder Anweisung ein, die eine Speicheradresse in diesem Bereich modifiziert.
- - Eine xswait-Anweisung kann den Programmierer dazu bewegen, Angaben darüber zu machen, wann die Anweisungsausführung angehalten werden soll, bis die asynchrone Operation abgeschlossen ist.
- xsave weist eine zusätzliche Überlegung, was zum Abschluss seiner Operation erforderlich ist. Im Falle von xload gilt die Operation erst dann als abgeschlossen, wenn alle Daten in den lokalen Speicher geladen wurden. Für xsave gibt es jedoch zwei Punkte, die als vollständig betrachtet werden können:
- - alle zu speichernden Daten wurden aus dem lokalen Speicher ausgelesen
- - alle zu speichernden Daten wurden aus dem lokalen Speicher ausgelesen und der externe Speicher/die externe Vorrichtung hat den Empfang dieser Daten bestätigt.
-
Die letztgenannte Definition des Begriffs „vollständig“ ermöglicht dem externen Speicher/Prozess, nicht nur anzugeben, dass die Daten empfangen wurden (wie in: der xsave hat sie an einem legalen Platz gespeichert), sondern auch die Integrität der empfangenen Daten anzugeben (wie zum Beispiel in: sie sind mit guter Parität angekommen).
-
Ein Programm berücksichtigt häufig nur die erstgenannte Definition, d. h., dass die Daten aus dem internen Speicher gelesen wurden, obwohl sie möglicherweise noch nicht vom externen Speicher/von der externen Vorrichtung empfangen und bestätigt wurden. Der Grund dafür ist, dass das Programm lediglich die Ausführung fortsetzen und die gespeicherten Daten modifizieren kann, da der ursprüngliche Zustand der Daten gespeichert wird.
-
Manchmal muss ein Programm jedoch wissen, dass der xsave in jeder Hinsicht zu 100 % abgeschlossen ist und dass der externe Schreibvorgang bestätigt wurde. Zum Beispiel können die Daten so kritisch sein, dass das Programm, wenn die Daten mit einem Paritätsfehler auf der Empfangsseite eintreffen, die Daten erneut einem xsave unterziehen möchte, bis die Bestätigung, dass gute Daten empfangen wurden, bestätigt wurde.
-
Aus diesem Grund gibt es möglicherweise zwei Varianten von xswait, die beide Variationen von xsave-complete bereitstellen.
-
5 veranschaulicht im Allgemeinen bei 500 ein Flussdiagramm, das die asynchrone, desynchrone und synchrone Ausführung einer Anweisung veranschaulicht. Bei 502 wird die nächste auszuführende Anweisung abgerufen. Über 503 wird zu 504 übergegangen. Bei 504 wird bestimmt, ob die als nächstes auszuführende Anweisung die Ergebnisse einer laufenden desynchronisierten Anweisung beeinflusst oder von diesen abhängig ist, d. h., ob es einen Desynchronisationskonflikt gibt. Wenn die abgerufene nächste auszuführende Anweisung die Ergebnisse einer laufenden desynchronisierten Anweisung beeinflusst oder von diesen abhängig ist (Ja), wird über 519 mit 520 fortgefahren. Bei 520 wird die Ausführung erneut synchronisiert, indem gewartet wird, bis alle desynchronisierten Operationen abgeschlossen sind, bevor über 505 mit 506 fortgefahren wird. Wenn die abgerufene nächste auszuführende Anweisung keine Auswirkungen auf die Ergebnisse einer laufenden desynchronisierten Anweisung hat oder von diesen nicht abhängig ist (Nein), wird über 505 mit 506 fortgefahren.
-
Bei 506 wird bestimmt, ob die abgerufene, als nächstes auszuführende Anweisung die Ergebnisse einer laufenden asynchronen Operation, d. h. eines asynchronen Konflikts, beeinflusst oder davon abhängig ist. Wenn die nächste auszuführende Anweisung sich auf die Ergebnisse einer laufenden asynchronen Operation auswirkt oder davon abhängig ist (Ja), wird über 521 mit 522 fortgefahren, ansonsten wird, wenn die nächste auszuführende Anweisung sich nicht auf die Ergebnisse einer laufenden asynchronen Operation auswirkt oder davon nicht abhängig ist (Nein), über 507 mit 508 fortgefahren. Bei 522 wird die Ausführung synchronisiert, indem gewartet wird, bis alle synchronisierten Operationen abgeschlossen sind, bevor über 507 mit 508 fortgefahren wird. Bei 508 wird bestimmt, ob die nächste auszuführende Anweisung asynchron ausgeführt werden kann. Wenn die nächste auszuführende Anweisung asynchron ausgeführt werden kann (Ja), wird über 517 mit 518 fortgefahren, ansonsten wird, wenn die nächste auszuführende Anweisung nicht asynchron ausgeführt werden kann (Nein), über 509 mit 510 fortgefahren. Bei 518 wird die asynchrone Ausführung eingeleitet, indem dem Prozessor gestattet wird, die nächste Anweisung asynchron auszuführen.
-
Bei 510 wird bestimmt, ob die abgerufene nächste Anweisung desynchron ausgeführt werden kann. Wenn die nächste Anweisung desynchron ausgeführt werden kann (Ja), dann wird über 511 mit 512 fortgefahren. Bei 512 wird die desynchrone Ausführung eingeleitet, indem dem Prozessor gestattet wird, die abgerufene nächste Anweisung desynchron auszuführen, d. h., der Abschluss der abgerufenen nächsten Anweisung erfolgt desynchron in Bezug auf die Steuerung des Prozessors, aber der Prozessor läuft, wenn ein internes Signal gegeben wird, das den Abschluss der Operation angibt. Der Prozessor wartet nicht auf dieses Abschlusssignal, bevor er über 515 zu 502 übergeht.
-
Wenn die nächste Anweisung nicht desynchron ausgeführt werden kann (Nein), dann wird über 513 mit 514 fortgefahren. Bei 514 wird die desynchrone Ausführung eingeleitet, indem dem Prozessor gestattet wird, die abgerufene nächste Anweisung synchron auszuführen, d. h. die Anweisung hat den Anschein für das Programm, dass sie vollständig abgeschlossen ist, bevor sie über 515 mit 502 fortgesetzt wird. Der Prozessor kann in einer Pipeline arbeiten oder andere überlappende Ausführungstechniken einsetzen, sodass es für ein Programm den Anschein hat, dass er die Anweisung abschließt, bevor er mit 502 fortfährt.
-
6 veranschaulicht im Allgemeinen bei 600 ein Flussdiagramm, das die Ausführung von Vektoranweisungen zeigt. Bei 602 wird bestimmt, ob derzeit eine erste Vektoranweisung ausgeführt wird. Wenn die erste Vektoranweisung nicht ausgeführt wird (Nein), wird über 601 zu 602 zurückgegangen. Wenn die erste Vektoranweisung derzeit ausgeführt wird (Ja), wird über 603 mit 604 fortgefahren und es werden Parameter verwendet, die in Registern gespeichert sind, um auf eine Speicherzugriffssteuerung für die erste Vektoranweisung zuzugreifen, dann wird über 605 mit 606 fortgefahren.
-
Bei 606 wird bestimmt, ob die erste Vektoranweisung die Ausführung beendet hat. Wenn die erste Vektoranweisung die Ausführung beendet hat (Ja), dann wird über 601 mit 602 fortgefahren. Wenn die erste Vektoranweisung die Ausführung nicht beendet hat (Nein), wird über 607 mit 608 fortgefahren.
-
Bei 608 wird bestimmt, ob eine zweite Vektoranweisung darauf wartet, ausgeführt zu werden. Wenn eine zweite Vektoranweisung nicht darauf wartet, ausgeführt zu werden (Nein), dann wird über 601 zu 602 zurückgegangen. Wenn eine zweite Vektoranweisung darauf wartet, ausgeführt zu werden (Ja), wird über 609 mit 610 fortgefahren und es werden neue Vektorparameter in Speicherzugriffssteuerungsvorladeregister geladen, um sie mit der zweiten Vektoranweisung zu verwenden, dann wird über 611 mit 612 fortgefahren. Bei 612 wird bestimmt, ob die erste Vektoranweisung die Ausführung beendet hat. Wenn die erste Vektoranweisung die Ausführung nicht beendet hat (Nein), dann wird über 611 mit 612 fortgefahren. Wenn die erste Vektoranweisung die Ausführung beendet hat (Ja), wird über 613 mit 614 fortgefahren. Bei 614 wird ein Multiplexer in eine Vorladeposition geschaltet, wodurch der Inhalt der Speicherzugriffssteuerungsvorladeregister in die Speicherzugriffssteuerungsregister kopiert wird; anschließend wird über 615 mit 616 fortgefahren. Bei 616 wird der Multiplexer in eine Nicht-Vorladeposition geschaltet und dann wird über 617 mit 618 fortgefahren. Bei 618 wird die zweite Vektoranweisung ausgeführt, wobei die zweite Vektoranweisung als erste Vektoranweisung bezeichnet wird, und es wird über 601 zu 602 zurückgegangen.
-
Wenn sich der Multiplexer in der Vorladeposition befindet, können neue Vektorparameter eingestellt werden. Unter Bezugnahme auf 3 ermöglicht die Multiplexersteuerung 330 beispielsweise, dass in der Vorladeposition neue Vektorparameter 301 in die Multiplexer 310, 312, 314 und 316 eintreten und sich über 311, 313, 315 bzw. 317 in das Vektorlängenvorladeregister 322, das Vektorkonstantenregister 324, das Vektoradressenregister 326 bzw. das Vektorschrittregister 328 ausbreiten.
-
Wenn sich der Multiplexer in der Vorladeposition befindet, können neue Vektorparameter über die Speicherzugriffssteuerungsvorladeregister 340 eingestellt werden. Unter Bezugnahme auf 3 ermöglicht beispielsweise die Multiplexersteuerung 330 in der Vorladeposition, dass neue Vektorparameter 301, die in das Vektorlängenvorladeregister 320, das Vektorkonstantenvorladeregister 304, das Vektoradressenvorladeregister 306 und Vektorlängenvorladeregister 308 geladen wurden, um über 303, 305, 307 bzw. 309 in die Multiplexer 310, 312, 314 und 316 einzutreten und sich über 311, 313, 315 bzw. 317 in das Vektorlängenregister 322, das Vektorkonstantenregister 324, das Vektoradressenregister 326 bzw. das Vektorschrittregister 328 auszubreiten.
-
7 veranschaulicht im Allgemeinen bei 700 ein Flussdiagramm, das die Ausführung von desynchronisierten Vektoranweisungen zusätzlich zu nicht-desynchronisierten Anweisungen veranschaulicht. Bei 702 wird bestimmt, ob eine desynchronisierte Vektoranweisung derzeit ausgeführt wird. Wenn derzeit eine desynchronisierte Vektoranweisung nicht ausgeführt wird (Nein), dann wird über 703 mit 714 fortgefahren. Bei 714 wird eine neue desynchronisierte Vektoranweisung zusätzlich zu den nicht-desynchronisierten Anweisungen ausgeführt, und es wird über 701 zu 702 übergegangen.
-
Wenn derzeit eine desynchronisierte Vektoranweisung ausgeführt wird (Ja), dann wird über 705 mit 704 fortgefahren. Bei 704 werden die in den Speicherzugriffssteuerungsregistern gespeicherten Parameter (z. B. 3 bei 350) für den Zugriff auf eine Speicherzugriffssteuerungsvektoranweisung verwendet, um dann über 707 mit 706 fortzufahren. Bei 706 wird bestimmt, ob eine Anweisung besteht, die versucht, ein oder mehrere Speicherzugriffssteuerungsregister (Register) zu modifizieren (z. B. 3 bei 350). Wenn keine Anweisung vorliegt, die versucht, ein oder mehrere Speicherzugriffssteuerungsregister zu modifizieren (z. B. 3 bei 350) (Nein), wird über 703 mit 714 fortgefahren.
-
Wenn eine Anweisung vorliegt, die versucht, ein oder mehrere Speicherzugriffssteuerungsregister zu modifizieren (Ja), wird über 709 mit 708 fortgefahren. Bei 708 werden das oder die entsprechende(n) Speicherzugriffssteuerungsvorladeregister (das oder die Register) (z. B. 3 bei 340) anstelle des oder der Speicherzugriffssteuerungsregister (z. B. 3 bei 350) modifiziert, dann wird über 711 mit 710 fortgefahren. Anhand von 3 ist zum Beispiel zu erkennen, dass das Vektorlängenregister 322 ein entsprechendes Vektorlängenvorladeregister 302 aufweist. Das Beispiel gilt für das Vektorkonstantenregister 324 und das entsprechende Vektorkonstantenvorladeregister 304. Das Beispiel gilt für das Vektoradressenregister 326 und das entsprechende Vektoradressenvorladeregister 306. Das Beispiel gilt für das Vektorschrittregister 328 und das entsprechende Vektorschrittvorladeregister 308.
-
Bei 710 wird die Ausführung neuer desynchronisierter Vektoranweisungen untersagt, die Ausführung nicht-desynchronisierter Anweisungen wird jedoch weiterhin zugelassen, dann wird über 713 mit 712 fortgefahren.
-
Bei 712 wird bestimmt, ob alle desynchronisierten Vektoranweisungen abgeschlossen sind. Wenn alle desynchronisierten Vektoranweisungen noch nicht abgeschlossen sind (Nein), wird über 715 mit 704 fortgefahren. Wenn alle desynchronisierten Vektoranweisungen abgeschlossen sind (Ja), dann wird über 717 mit 716 fortgefahren.
-
Bei 716 werden alle modifizierten Speicherzugriffssteuerungsvorladeregisterparameter in das/die Speicherzugriffssteuerungsregister bewegt, und dann wird über 719 mit 718 fortgefahren. Optional werden bei 720 alle Speicherzugriffssteuerungsvorladeregisterparameter in die Speicherzugriffssteuerungsregister bewegt, ohne dass berücksichtigt wird, ob sie modifiziert wurden. Unter Verwendung der Multiplexersteuerung 330 werden zum Beispiel in 3 alle Parameter der Speicherzugriffssteuerungsvorladeregister 340 in die Speicherzugriffssteuerungsregister 350 bewegt.
-
Bei 718 modifizieren Anweisungen, die das/die Speicherzugriffssteuerungsregister modifizieren, das/die Speicherzugriffssteuerungsvorladeregister nicht mehr, dann wird über 703 mit 714 fortgefahren. Das heißt, dass zum Beispiel Anweisungen, die Speicherzugriffssteuerungsregister modifizieren würden (z. B. 3 bei 350), dies nun tun können, anstatt die Speicherzugriffssteuerungsvorladeregister zu modifizieren (z. B. 3 bei 340). Nach 718 wird mit 714 fortgefahren, damit neue desynchronisierte Vektoranweisungen zusätzlich zu den nicht-desynchronisierten Anweisungen ausgeführt werden können.
-
Relevanz in Bezug auf die gemeinsam eingereichte Anmeldung Nr. 17/468,574, eingereicht am 07.09.2021.
-
================================
-
Diese Verfahren können mit der ebenfalls anhängigen Anmeldung Nr. 17/468,574 verwendet werden, die am 07.09.2021 eingereicht wurde. Die gemeinsam anhängige Anmeldung Nr. 17/468,574, eingereicht am 07.09.2021, beschreibt einen Parameterstapel, einen Registerstapel und einen Unterprogrammaufrufstapel, die vom lokalen Speicher getrennt sind; diese Stapel werden von der Vektor-ALU 124 ausgiebig verwendet.
-
Betrachtet wird die folgende Anweisungssequenz, die mit einem zuvor angeführten Beispiel zur desynchronisierten Ausführung vergleichbar ist:
-
Somit sind ein Verfahren und eine Einrichtung zum Desynchronisieren der Ausführung in einem Vektorprozessor beschrieben.
-
Um die Beispiele zu erläutern und zu verstehen, sei darauf hingewiesen, dass ein Fachmann verschiedene Begriffe verwendet, um Techniken und Ansätze zu beschreiben. Des Weiteren werden in der Beschreibung zu Erklärungszwecken zahlreiche spezifische Details dargelegt, um ein umfassendes Verständnis der Beispiele bereitzustellen. Es ist jedoch für den Durchschnittsfachmann offensichtlich, dass die Beispiele ohne diese spezifischen Details umgesetzt werden kann. In einigen Fällen sind hinlänglich bekannte Strukturen und Vorrichtungen in Form eines Blockdiagramms und nicht im Detail gezeigt, um die Beispiele nicht zu verunklaren. Diese Beispiele sind hinreichend detailliert beschrieben, um dem Durchschnittsfachmann zu ermöglichen, die Beispiele umzusetzen, und es versteht sich, dass andere Beispiele genutzt werden können und dass logische, mechanische und andere Änderungen vorgenommen werden können, ohne vom Schutzumfang der Beispiele abzuweichen.
-
Wie in dieser Beschreibung verwendet, bedeutet „ein Beispiel“ oder ähnliche Formulierungen, dass das/die beschriebene(n) Merkmal(e) in mindestens einem Beispiel eingeschlossen ist/sind. Bezugnahmen auf „ein Beispiel“ in dieser Beschreibung beziehen sich nicht notwendigerweise auf das gleiche Beispiel; jedoch sind solche Beispiele nicht gegenseitig ausschließend. Auch bedeutet „ein Beispiel“ nicht, dass es nur ein einziges Beispiel gibt. Zum Beispiel kann ein Merkmal, eine Struktur, eine Handlung, die in „einem Beispiel“ beschrieben ist, ohne Einschränkung auch in anderen Beispielen eingeschlossen sein. Somit kann die Erfindung eine Vielzahl von Kombinationen und/oder Integrationen der hierin beschriebenen Beispiele einschließen.
-
Wie in dieser Beschreibung verwendet, werden die Begriffe „im Wesentlichen“ oder „im Wesentlichen gleich“ oder ähnliche Formulierungen verwendet, um anzugeben, dass die Elemente sehr nahe beieinander liegen oder vergleichbar sind. Da zwei physische Einheiten niemals exakt gleich sein können, wird eine Formulierung wie „im Wesentlichen gleich“ verwendet, um anzugeben, dass sie in allen praktischen Belangen gleich sind.
-
Es versteht sich, dass in einem oder mehreren Beispielen, in denen alternative Ansätze oder Techniken erläutert werden, alle möglichen Kombinationen hiermit offenbart werden. Werden zum Beispiel fünf Techniken erläutert, die alle möglich sind, so wird jede Technik wie folgt bezeichnet: A, B, C, D, E, jede Technik kann mit jeder anderen Technik entweder vorhanden oder nicht vorhanden sein, sodass sich 2^5 oder 32 Kombinationen ergeben, die in binärer Reihenfolge von nicht A und nicht B und nicht C und nicht D und nicht E bis zu A und B und C und D und E reichen. Der/die Anmelder beansprucht/beanspruchen hiermit alle derartigen möglichen Kombinationen. Der/die Anmelder reicht/reichen hiermit ein, dass die vorstehenden Kombinationen den geltenden EP-Normen (Europäisches Patent) entsprechen. Es wird keine Kombination bevorzugt.
-
Somit sind ein Verfahren und eine Einrichtung zum Desynchronisieren der Ausführung in einem Vektorprozessor beschrieben.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 63/180634 [0001]
- US 63/180562 [0001]
- US 17/669995 [0001]
- US 63/180601 [0001]
- US 17/468574 [0001]
- US 17/701582 [0001]
