-
Technisches Anwendungsgebiet/Stand der
Technik
-
Die
vorliegende Erfindung betrifft einen Prozessor für die Abarbeitung sequentieller
Programme. Derartige Prozessoren arbeiten mit einer Folge von Befehlen,
die sequentiell abgearbeitet werden. Die Befehle werden einzeln
dekodiert und anschließend
in sog. Ausführungseinheiten
zur Ausführung
gebracht. Die Ausführungseinheiten
sind bei herkömmlichen
Prozessoren, bspw. bei Superskalar- oder VLIW-Prozessoren, eindimensional
angeordnet. Diesen Ausführungseinheiten
können
daher in einem Takt nur Befehle zugeordnet werden, die vollkommen
unabhängig
voneinander sind. Erst nach deren Ausführung können abhängige Befehle im nächsten Takt
zugeordnet und demnach erst dann ausgeführt werden.
-
Sog. "Tiled Architectures" verbinden den Ansatz
eines herkömmlichen
Prozessors mit Array-Strukturen von rekonfigurierbaren Systemen.
Die Array-Strukturen umfassen hierbei in der Regel eine zweidimensionale
Anordnung aus kleinen Prozessoren zur Abarbeitung der Befehle. In
vielen Fällen
ist zur zentralen Steuerung der kleinen Prozessoren noch ein weiterer
Steuerprozessor außerhalb
des Arrays vorhanden. Die Datenpfade zwischen den kleinen Prozessoren
können
von diesen meist selbständig
gesteuert werden, so dass ein Datenaustausch zwischen den Prozessoren
stattfinden kann. Die Programmierung dieser "Tiled Architectures" erfolgt in Form mehrerer sequentieller
Befehlsströme,
die den einzelnen Prozessoren zugeordnet werden können.
-
Der
Steuerprozessor arbeitet hierbei generell mit einem eigenen Befehlsstrom,
ggf. sogar mit einem von den Array-Prozessoren verschiedenen Befehlssatz.
-
Neben
den genannten Prozessoren bzw. Prozessorarchitekturen sind auch
sog. rekonfigurierbare Systeme bekannt, die aus einer zentralen,
in der Regel zweidimensionalen, mehr oder weniger homogenen Anordnung
von Arbeitselementen bestehen. Bei diesen Systemen handelt es sich
jedoch nicht um Prozessoren, sondern um Systeme, die zusätzlich zu
Prozessoren eingesetzt werden. Den Arbeitselementen, die mehr oder
weniger spezialisiert sind, wird während einer Konfigurationsphase
eine Aufgabe zugeteilt. Über
Datenpfade sind die Arbeitselemente miteinander verbunden und können Daten
austauschen. Diese Datenpfade werden in der Regel auch während der
Konfigurationsphase bereits gestellt bzw. programmiert. Die Konfigurationsdaten
werden bei rekonfigurierbaren Systemen vorab, d.h. bereits bei der
Programmierung des Gesamtsystems, explizit erstellt. Dies erfolgt
in der Praxis manuell mit Hilfe von geeigneten Synthese-Werkzeugen.
Durch einen speziellen Mechanismus werden die Konfigurationsdaten
zur Laufzeit auf einmal aus einem Speicher in das rekonfigurierbare
System geladen und verbleiben dort, solange diese Konfiguration
benötigt wird.
Die rekonfigurierbaren Systeme arbeiten in der Regel parallel zu
einem herkömmlichen
Prozessor, dessen Programm separat neben den Konfigurationsdaten
gehalten wird.
-
Die
Aufgabe der vorliegenden Erfindung besteht darin, einen Prozessor
bereitzustellen, der sich sowohl effizient in Kontrollfluss- als
auch in Datenflussorientierten Anwendungen einsetzen lässt und
gegenüber bekannten
Prozessoren Leistungsvorteile bei der Abarbeitung von Kontrollfluss-orientierten
Programmen bietet.
-
Darstellung der Erfindung
-
Die
Aufgabe wird mit dem Prozessor gemäß Patentanspruch 1 gelöst. Vorteilhafte
Ausgestaltungen des Prozessors sind Gegenstand der Unteransprüche oder
lassen sich der nachfolgenden Beschreibung sowie den Ausführungsbeispielen
entnehmen.
-
Der
vorliegende Prozessor umfasst eine zweidimensionale Anordnung aus
mehreren Zeilen konfigurierbarer Ausführungseinheiten, die in Spalten
angeordnet sein können
und durch konfigurierbare Datenverbindungen von Zeile zu Zeile zu
mehreren Ketten von Ausführungseinheiten
verbunden werden können.
Die Anordnung weist ein Rückführungsnetzwerk
auf, über
das ein am Datenausgang der untersten Ausführungseinheit jeder Kette ausgegebener
Datenwert an ein Top-Register der Kette überführt werden kann. Die Ausführungseinheiten
sind dabei so ausgebildet, dass sie während ein oder mehrerer Ausführungsphasen
an ihrem Dateneingang anliegende Daten entsprechend ihrer momentanen
Konfiguration behandeln, d.h. verarbeiten oder durchleiten, und
die behandelten Daten an ihrem Datenausgang für die in der Kette nachfolgende Ausführungseinheit
bereitstellen. Eine als Frontend vorgesehene Dekodier- und Konfigurationseinheit
wählt während mehrerer
durch ein oder mehrere Ausführungsphasen
getrennte Dekodierphasen aus einem einzelnen eingehenden sequentiellen
Befehlsstrom zur Laufzeit eigenständig Ausführungseinheiten aus, erzeugt Konfigurationsdaten
für die
ausgewählten
Ausführungseinheiten
und konfiguriert die ausgewählten
Ausführungseinheiten über ein
Konfigurationsnetzwerk zur Ausführung
der Befehle. Die Dekodier- und Konfigurationseinheit kann sich dabei
auch aus einer Dekodiereinheit und einer davon getrennten Konfigurationseinheit zusammensetzen.
Der Prozessor weist weiterhin zumindest eine mit den Ausführungseinheiten über Datenleitungen
verbundene Sprung-Kontrolleinheit für die Behandlung von Sprungbefehlen
sowie ein oder mehrere mit den Ausführungseinheiten über Datenleitungen
verbundene Speicherzugriffseinheiten zur Ausführung von Speicherzugriffen
auf.
-
Zentraler
Teil der Prozessorarchitektur, die dem vorgeschlagenen Prozessor
zugrunde liegt, ist eine zweidimensionale Struktur aus einfachen
Arbeitselementen, den Ausführungseinheiten,
die keine eigenen Prozessoren aufweisen. Die Ausführungseinheiten
sind in der Regel als arithmetisch logische Einheiten (ALU) ausgebildet,
die in einer Ausgestaltung des Prozessors ein Raster aus Zeilen
und Spalten bilden, im Folgenden auch als ALU-Grid bezeichnet. Die
Ausführungseinheiten
werden im Folgenden aufgrund ihrer bevorzugten Ausgestaltung stellvertretend
nur noch als ALUs bezeichnet, ohne diese Ausführungseinheiten jedoch damit auf
ALUs einzuschränken.
In der genannten Ausgestaltung mit dem internen Raster von ALUs
repräsentiert jede
Spalte ein Architekturregister. Somit ist die Anzahl der Spalten
in diesem Fall genauso hoch wie die Anzahl der Architekturregister
der zugrunde liegenden Prozessor architektur, d.h. sie ist abhängig vom
gewählten Assembler-Befehlssatz.
Dies ist jedoch nicht in jedem Falle erforderlich, wie weiter unten
näher erläutert wird. Die
Anzahl an Zeilen ist abhängig
von der zur Verfügung
stehenden Chip-Fläche.
Je höher
die Zeilenanzahl, desto höher
ist die zu erwartende Leistung. Für die Anwendung in einem Desktop-PC
kann bspw. ein Bereich zwischen fünf und zehn Zeilen sinnvoll
sein.
-
Die
ALUs werden von der Dekodier- und Konfigurationseinheit dynamisch über ein
Konfigurationsnetzwerk einzeln mit einer bestimmten Funktion belegt.
Diese Programmierung der ALUs geschieht Takt-synchron. Einmal programmiert,
arbeiten die ALUs dann asynchron mit den jeweils an ihren Dateneingängen anliegenden
Werten, d.h. sie besitzen keinerlei Speicherelemente für die Arbeitsdaten.
Die Arbeitsdaten oder ein Teil davon können bei der Konfiguration
auch mit einem festgelegten Festwert belegt werden.
-
Zwischen
den ALUs kann ein Datenaustausch stattfinden, der aber immer aus
Sicht der Spalte bzw. Kette von oben nach unten gerichtet ist und
die ALUs mit Arbeitsdaten versorgt. Oberhalb der obersten Zeile ist
eine Reihe von Registern angeordnet, in der vorliegenden Patentanmeldung
als Top-Register bezeichnet. Zusätzlich
können
optional weitere Registerreihen zwischen anderen Zeilen angeordnet
sein. Diese Zwischenregister müssen
allerdings mit einer Bypass-Technik
ausgestattet sein, so dass ankommende Daten gespeichert oder direkt
durchgeschleift werden können.
-
Im
Folgenden wird bei der Beschreibung des Prozessors sowie bevorzugter
Ausgestaltungen des Prozessors zur Vereinfachung nur der Begriff
der Spalte benutzt. Selbstverständlich
gelten jedoch sämtliche
Ausführungen
in gleicher Weise auch bei einer Verbindung der ALUs zu nicht geradlinig
verlaufenden Ketten.
-
Zusätzlich zu
den Datenpfaden, die (vorwärts)
durch die ALUs führen
und ein sog. Vorwärtsnetzwerk bilden,
sind separate Datenrückführungen
vorhanden, die die am Ende einer Spalte anliegenden Daten an den Anfang
derselben Spalte, also in die Top-Register, zurückführen. Diese Datenrückführungen
bilden ein sog. Rückführungsnetzwerk.
Ebenso können
die Datenrückführungen
Daten optional an einer anderen Stelle innerhalb einer Spalte, z.B.
den Zwischenregistern, abgreifen und an weiter oben liegender Stelle
der Spalte, z.B. in eine andere Zwischenregisterreihe, wieder einspeisen.
-
Neben
dem zentralen ALU-Grid sind ein oder mehrere Speicherzugriffseinheiten
und eine Sprung-Kontrolleinheit vorgesehen. Die Sprung-Kontrolleinheit
stößt unter
bestimmten Bedingungen die Rückführung von
Daten über
die Datenrückführungen
von unten nach oben an. Die Speicherzugriffseinheiten erlauben die
Ausführung
von Speicherzugriffen, um Daten aus dem ALU-Grid in den Speicher
bzw. Daten aus dem Speicher in das ALU-Grid zu transportieren. Dabei
ist vorzugsweise jeder Zeile des ALU-Grid eine bestimmte Anzahl
von Speicherzugriffseinheiten beigeordnet.
-
Vorzugsweise
verfügt
jede ALU über
einen speziellen Predication-Eingang, über den sie während der Arbeit
deaktiviert werden kann. Ist eine ALU deaktiviert, so leitet sie
den oberhalb, d.h. an ihrem Dateneingang anliegenden Wert, unverändert an
ihren Datenausgang weiter. Die Predication-Eingänge werden von der Sprung-Kontrolleinheit
bedient. Dadurch können
sog. "predicated
instructions" des
Assembler-Befehlssatzes im
ALU-Grid abgebildet werden, d.h. es besteht die Möglichkeit,
einzelne Befehle nur unter bestimmten Bedingungen auszuführen.
-
Die
dem Prozessor zugrunde liegende neuartige Prozessorarchitektur besitzt
somit als Hauptmerkmal eine interne zweidimensionale Anordnung bzw.
ein Raster von Ausführungseinheiten
oder ALUs, mit dessen Hilfe sequentielle Programme abgearbeitet
werden. Die Verbindungen zwischen den ALUs werden automatisch dynamisch
zur Laufzeit über
Multiplexer hergestellt. Verantwortlich für das Herstellen der Verbindungen ist
eine zentrale Dekodier- und Konfigurationseinheit (Frontend), die
aus einem Strom herkömmlicher
bzw. leicht modifizierter Befehle Konfigurationsdaten für das ALU-Grid
zur Laufzeit erzeugt. Diese neuartige Architektur bzw. der vorgeschlagene
Prozessor stellt einen Mittelweg zwischen herkömmlichen Prozessoren und rekonfigurierbarer
Hardware dar. Erstere eignen sich besser für Kontrollfluss-orientierte
Aufgaben, z.B. Steuerungsaufgaben, während rekonfigurierbare Hardware
ihre Stärke
bei der Lösung
von Datenfluss-orientierten Problemen, z.B. bei der Video- und Audioverarbeitung,
aufweist. Eine einheitliche Architektur, die für beide Arten der Problemstellung
gleichermaßen
geeignet ist, war bisher nicht bekannt. Mit der hier vorgeschlagenen Architektur
können
sowohl Daten- als auch Kontrollfluss-orientierte Aufgaben mittels
einer herkömmlichen
Programmiersprache, z.B. C/C++, behandelt werden. Bei der Ausführung des
Programmcodes ergeben sich dann je nach Bedarf die Vorteile von
Prozessoren bzw. von rekonfigurierbarer Hardware.
-
Als
Einsatzgebiete des neuen Prozessors kommen je nach Ausbaustufe alle
Arten von Datenverarbeitungssystemen in Betracht. In einer mächtigen
Variante kann der Prozessor bzw. die zugrunde liegende Architektur
in Datenbank- oder Compute-Servern Anwendung finden. In einer reduzierten
Ausbaustufe besteht auch die Möglichkeit
des Einsatzes in mobilen Geräten.
Da die Architektur in einer Richtung vollständig skalierbar ist, kann Software,
die für
eine Ausbaustufe entwickelt wurde, auch auf einer anderen Ausbaustufe
ausgeführt werden.
Es besteht also Kompatibilität
in beiden Richtungen (aufwärts
und abwärts).
-
Die
grundsätzliche
Idee bei der vorliegenden Prozessorarchitektur bzw. dem vorliegenden
Prozessor besteht darin, die einzelnen Maschinenbefehle eines sequentiellen
Befehlsstroms dynamisch auf ein rekonfigurierbares, mehrzeiliges
Raster aus ALUs abzubilden und dadurch ein herkömmliches Programm abzuarbeiten.
Diese Technik bietet neben der Möglichkeit
des effizienten Einsatzes sowohl in Kontrollfluss- als auch Datenfluss-orientierten
Anwendungsfeldern ebenfalls Leistungsvorteile gegenüber herkömmlichen
Prozessoren bei der Abarbeitung reiner Kontrollfluss-orientierter
Programme.
-
Im
Gegensatz zu bekannten Prozessorarchitekturen ist es damit möglich, abhängige Befehle
im selben Takt den Ausführungseinheiten
zuzuordnen und ggf. auch in einem Takt auszuführen. Durch die vorerst nicht
vorgesehene Sprungvorhersage entsteht kein "Miss-Prediction-Penalty" bei falsch vorhergesagten Sprüngen. Dennoch
erlaubt die vorgestellte Architektur die effiziente Behandlung von
Sprüngen,
die bei der Ausführung
von Schleifen ihre volle Leistungsfähigkeit entfaltet. Dabei entfällt die
Dekodierung und Zuordnung neuer Befehle ins ALU-Grid und es erfolgt
nur noch die Ausführung
der bereits im ALU-Grid vorhandenen Befehle. Im ALU-Grid wird eine
Schleife, nachdem diese als solche erkannt wurde, einmalig zugeordnet
und verbleibt so lange im ALU-Grid, bis sie wieder verlassen wird.
Die Dekodier- und Zuordnungseinheit kann somit in dieser Zeit deaktiviert
werden. Demgegenüber
muss jeder Befehl bei herkömmlichen
Prozessoren pro Schleifendurchlauf bei der Abarbeitung von Schleifen
einmal einer Ausführungseinheit
zugeordnet werden. Somit ist die Zuordnungseinheit und bei Fehlen
eines "Trace-Cache" auch die Dekodiereinheit
in derartigen Prozessoren durchgehend aktiv. Im Gegensatz zu ähnlich aufgebauten "Tiled Architectures" sind für die hier vorgestellte
Architektur keine speziellen Compiler oder sonstigen Software-Entwicklungswerkzeuge
erforderlich. Anders als bei einfachen rekonfigurierbaren Systemen
erfolgt die Programmierung des ALU-Grid mit einem sequentiellen
Befehlsstrom, der direkt vom Compiler stammt und die Form herkömmlicher
Assembler-Befehle besitzt. Die Ausführungseinheiten des ALU-Grid
werden mittels dieser Befehle konfiguriert und behalten diese Konfiguration
meist nur sehr kurze Zeit, es sei denn, es wird gerade eine Schleife
abgearbeitet. Die Konfiguration des gesamten ALU-Grid ergibt sich
somit dynamisch aus der Reihenfolge der abgearbeiteten Befehle und
nicht aus statisch generierten Konfigurationsdaten.
-
Kurze Beschreibung der Zeichnungen
-
Der
vorliegende Prozessor bzw. die zugrunde liegende Prozessorarchitektur
wird nachfolgend anhand von Ausführungsbeispielen
in Verbindung mit den Zeichnungen nochmals näher erläutert. Hierbei zeigen:
-
1 ein
Blockschaltbild einer Ausgestaltungsmöglichkeit des vorgeschlagenen
Prozessors;
-
2 ein
Beispiel für
die Ausgestaltung einer ALU;
-
3 ein
Beispiel einer Ausgestaltung beim Einsatz synchroner Datenfluss-Token;
-
4 ein
Beispiel für
eine erste Belegung der ALUs mit einem Beispielprogramm;
-
5 ein
Beispiel für
eine zweite Belegung der ALUs mit dem Beispielprogramm;
-
6 ein
Beispiel für
die Integration komplexer Ausführungseinheiten
in das ALU-Grid; und
-
7 ein
weiteres Beispiel für
eine Belegung der ALUs mit dem Beispielprogramm bei einer Pipeline-Ausführung.
-
Wege zur Ausführung der Erfindung
-
1 zeigt
ein Beispiel für
eine mögliche
Ausgestaltung des Prozessors als Blockschaltbild. In diesem Blockschaltbild
ist das ALU-Grid als zentraler Bestandteil des Prozessors zu erkennen.
Das Frontend bilden eine Befehlshole-Einheit, eine Dekodiereinheit
sowie eine Konfigurationseinheit. Der ebenfalls eingezeichnete Befehls-Cache,
der Daten-Cache sowie die virtuelle Speicherverwaltung sind Standard-Baugruppen.
-
Die
ALUs sind bei diesem Beispiel zeilen- und spaltenweise angeordnet,
wobei am Eingang jeder Spalte ein entsprechendes Top-Register vorgesehen
ist. Auch Zwischenregister mit Bypass sind zwischen einzelnen Zeilen
der ALUs in der Figur angedeutet. Über ein Zeilen-Routing-Netzwerk
sind die ALUs mit einer Sprung-Kontrolleinheit
sowie mit mehreren Speicherzugriffseinheiten (Laden/Speichern) verbunden.
Das Konfigurationsnetzwerk und das Predication-Netzwerk sind in
diesem Blockschaltbild nicht eingezeichnet.
-
2 zeigt
ein Beispiel für
die Ausgestaltung einer ALU, wie sie im vorliegenden Prozessor zum
Einsatz kommen kann. Über
die synchronen Eingänge
werden die Konfigurationsdaten von der Konfigurationseinheit in
ein Konfigurationsregister der ALU geschrieben und der Konfigurationstakt übertragen.
Die ALU erhält
die Arbeitsdaten über
die asynchronen Dateneingänge
A und B vom Top-Register oder der in der Spalte vorangehenden ALU.
Anstelle der Arbeitsdaten am Dateneingang B kann die ALU auch mit
einem bei der Konfiguration festgelegten Festwert arbeiten. Über die
Konfiguration eines der dargestellten Multiplexer (MUX) lässt sich
bei Bedarf erreichen, dass die ALU die Daten nur durchschleift. 2 zeigt
auch den Predication-Eingang, über den
jede ALU während
der Arbeit von der Sprung-Kontrolleinheit deaktiviert werden kann.
-
Grundlage
für die
Programmausführung
auf dem vorgeschlagenen Prozessor ist ein sequentieller Strom von
Assembler-Befehlen, bspw. von RISC-Assembler-Befehlen. Diese werden paketweise (ein
oder mehrere Befehle) von einer Befehlshole-Einheit aus dem Speicher
in den Prozessor geladen und der Dekodiereinheit übergeben.
Diese prüft
Abhängigkeiten
zu vorangegangenen Befehlen und gibt die aktuellen Befehle zusammen
mit den Abhängigkeitsinformationen
an die Konfigurationseinheit weiter. Aufgabe der Konfigurationseinheit
ist es, für
jeden Befehl eine ALU auszuwählen,
dieser die entsprechende Funktionalität zuzuweisen und die Multiplexer
für die
Arbeitsdaten richtig zu konfigurieren. Handelt es sich um einen
Sprung- oder Speicherzugriffsbefehl, so werden spezielle Maßnahmen
ergriffen, die später
genauer erläutert
werden.
-
Die
Arbeitsweise des Prozessors zerfällt
in zwei Teile, nämlich
die Befehlsanordnung der einzelnen Assembler-Befehle im ALU-Grid
(Dekodierphase) und die eigentliche Abarbeitung der Befehle innerhalb
der Grid sowie der Sprung-Kontroll- und den Speicherzugriffs einheiten
(Ausführungsphase).
Im Folgenden werden die beiden Teile separat erläutert, wohingegen diese Vorgänge im Prozessor
teilweise zeitlich überlappt
ausgeführt
werden können.
-
Prinzipiell
werden bei der Befehlsanordnung immer Teile des sequentiellen Programms
in das ALU-Grid übertragen.
Dabei muss zwischen folgenden drei Befehlsgruppen unterschieden
werden:
- – Speicherzugriffsbefehle:
Darunter fallen alle Befehle, die einen Datenzugriff auf den externen
Speicher verlangen, z.B. Load, Store, Push, Pop. Bei diesen Befehlen
wird ggf. eine Adressberechnung im ALU-Grid angeordnet; der eigentliche Speicherzugriff
erfolgt ausgehend von einer der Speicherzugriffseinheiten.
- – Sprungbefehle:
Hier muss wiederum zwischen bedingten und unbedingten Sprüngen unterschieden
werden. Unbedingte Sprünge
werden, sofern sie nicht eine indirekte Adressierung verwenden,
unmittelbar in der Dekodiereinheit behandelt und sind für das ALU-Grid
nicht relevant. Bedingte und indirekte Sprünge werden an die Sprung-Kontrolleinheit
weitergeleitet. Diese verarbeitet die aus dem ALU-Grid erhaltenen Werte
und löst
ggf. einen tatsächlichen
Sprung im Programmcode aus, d.h. es werden neue Befehle des Programms
im ALU-Grid angeordnet.
Werden keine neuen Befehle geladen, so werden Steuersignale für das ALU-Grid
erzeugt, so dass diese entsprechend des gewünschten Programmverlaufs weiter
arbeitet (z.B. beim Rücksprung
innerhalb einer Schleife). Hierzu werden innerhalb des ALU-Grid
die Datenrückführungen
verwendet, um die berechneten Ergebnisse vom Ende des Grid an die
Top-Register bzw. die entsprechenden Zwischenregister innerhalb
des Grid zu senden.
- – Arithmetisch-logische
Befehle: Hierunter fallen alle übrigen
Befehle. Diese werden jeweils einer ALU im Grid zugeordnet, d.h.
eine ausgewählte
ALU wird so konfiguriert, dass sie die Funktion des entsprechenden Befehls
ausführt.
-
Für die Anordnung
der arithmetisch-logischen Befehle im ALU-Grid muss für jede Operation
einzeln sowohl die Spalte als auch die Zeile im Grid bestimmt werden.
Dies erfolgt nach folgendem Schema:
- – Auswahl
der Spalte: Die Spalte, in der der Befehl zur Ausführung kommen
soll, wird durch das Zielregister des Befehls bestimmt. Der Ausgang
der ausgewählten
ALU nimmt nach der Operation den berechneten Wert an und leitet
diesen für
weitere Operationen über
ein Vorwärts-Netzwerk,
d.h. die Datenverbindungen zwischen den ALUs in Spaltenrichtung,
nach unten weiter. Das Vorwärts-Netzwerk
der ausgewählten
Spalte trägt
somit abschnittsweise die Werte, die das entsprechende Architekturregister
zwischen den Berechnungen annehmen würde.
- – Auswahl
der Zeile: die Zeile, in der die Operation ausgeführt werden
muss, bestimmt sich aus dem tiefsten Punkt, also der am weitesten
fortgeschrittenen Berechnungen, aller an der Operation beteiligten
Register. Dies bedeutet, dass die neue Operation unterhalb der letzten
Operation der Zielregister-Spalte angeordnet sein muss. Desweiteren
müssen
auch alle bereits zugeordneten Operationen des oder der Quellregister oberhalb
der neu auszuwählenden
ALU liegen.
-
Nach
Auswahl der neu zu konfigurierenden ALU müssen die Multiplexer des horizontalen
Netzwerks (Zeilen-Routing-Netzwerk) so geschalten werden, dass die
Daten der Quellregister an der neuen ALU anliegen. Ebenso muss dafür Sorge
getragen werden, dass die Werte der Quellregister unverändert bis
zur gewünschten
Zeile geleitet werden. Dazu müssen
ggf. ALUs in den Spalten der Quellregister deaktiviert werden, sofern
neben den ALUs keine Datenpfade in Vorwärts-Richtung vorgesehen sind.
Die ausgewählte
ALU wird derart konfiguriert, dass sie die Operation des aktuellen
Befehls ausführt.
Durch dieses Schema wird innerhalb des ALU-Grid der Datenflussgraph
der angeordneten arithmetisch-logischen Assembler-Befehle aufgebaut.
-
Im
Gegensatz zu den arithmetisch-logischen Befehlen werden die Speicherzugriffsbefehle
neben dem ALU-Grid in einer der Speicherzugriffseinheiten untergebracht.
Hierzu ist lediglich die Auswahl der Zeile von Interesse. Diese
wird äquivalent
zu den arithmetisch-logischen Befehlen, also abhängig von den verwendeten Quellregistern
(für die
Speicheradresse und ggf. für
die Schreibdaten) ausgewählt.
Eine ggf. auszuführende Adressberechnung
(z.B. Addition zweier Register oder Addition eines Offset) wird äquivalent
zu den arithmetisch-logischen Befehlen in dem ALU-Grid angeordnet.
-
Sprungbefehle
erfüllen
ihre Funktion ausgehend von der Sprung-Kontrolleinheit. Ebenfalls
zeilenweise führen
Datenleitungen aus dem ALU-Grid in die Sprung-Kontrolleinheit. Diese überprüft je nach
auszuführendem
Sprungbefehl die Datenleitungen und erzeugt ggf. entsprechende Steuersignale
sowohl für
das Prozessor-Frontend
als auch das ALU-Grid. Werden von der Dekodier- bzw. der Konfigurationseinheit
Vorwärtssprünge über eine
kurze Distanz (wenige Befehle) erkannt, so können die übersprungenen Befehle grundsätzlich im
ALU-Grid angeordnet werden. Die Sprung-Kontrolleinheit steuert über das
Predication-Netzwerk
während
der Ausführungsphase,
ob die entsprechenden Befehle tatsächlich ausgeführt werden.
-
Nachdem
ausreichend viele Befehle im ALU-Grid und den seitlich angrenzenden
Einheiten angeordnet wurden, wird das Dekodieren neuer Befehle gestoppt
und es beginnt die Befehlsausführungsphase.
-
Die
Initialwerte aller Architektur-Register sind in den Top-Registern
gespeichert. Die Werte wandern unverzüglich durch das Vorwärtsnetzwerk
in die vorher bestimmten ALUs. Dort erfolgen die gewünschten
Operationen. Steht ein Speicherzugriffsbefehl an, so werden die
benötigte
Adresse und ggf. die Schreibdaten eingefangen und ein synchroner
Speicherzugriff ausgeführt.
Nach einem Lesezugriff werden die gelesenen Daten in das ALU-Grid
geleitet und weiterverarbeitet.
-
Steht
ein Sprungbefehl an, so werden die für den Sprungbefehl relevanten
Datenworte in der Sprung- Kontrolleinheit
ausgewertet (d.h. Daten ggf. verglichen und das Sprungziel berechnet)
und eine der folgenden Aktionen ausgeführt:
- – Das Sprungziel
wurde noch nicht in das ALU-Grid integriert: Es werden alle Daten,
die unterhalb des Sprungbefehls im Vorwärts-Netzwerk anliegen in das
Top-Register der
jeweiligen Spalte kopiert. Anschließend wird ein Reset des ALU-Grid
durchgeführt,
d.h. alle Funktionen der ALUs werden gelöscht und die Verbindungen aufgelöst. Ebenso
werden sowohl alle Speicherzugriffseinheiten als auch die Sprung-Kontrolleinheit
zurückgesetzt.
Danach wird das Frontend des Prozessors reaktiviert und neue Befehle
von der gewünschten
Stelle des Programmcodes im ALU-Grid angeordnet.
- – Das
Sprungziel ist bereits im ALU-Grid vorhanden: in diesem Fall werden
lediglich die Daten unterhalb des Sprungbefehls in die Register
(Top- oder Zwischenregister) oberhalb der Stelle im Grid kopiert,
an der das Sprungziel im Grid angeordnet ist. Danach erfolgt eine
weitere Befehlsausführungsphase.
-
Stand
während
der Ausführungsphase
kein Sprungbefehl an, so werden nach Ende der Ausführung alle
Daten vom unteren Ende des ALU-Grid in die Top-Register kopiert; sie stellen jetzt
die neuen Initialwerte für
die später
folgende nächste
Ausführungsphase
dar. Anschließend
startet eine neue Dekodierphase.
-
Da
die Ausführung
der einzelnen Operationen in den ALUs asynchron erfolgt, kann ohne
weitere Hilfsmittel das Ende einer Ausführungsphase bzw. der Zeitpunkt,
an dem ein Speicherzugriff oder ein Sprung stattfinden kann, nicht
bestimmt werden. Hierzu stehen drei verschiedene Techniken zur Auswahl:
- – Tokens
unter Verwendung von Verzögerungselementen:
Jeder ALU wird ein Verzögerungselement
beigeordnet, das während
der Konfiguration der ALU einen entsprechenden Verzögerungswert
erhält.
Dieser muss der maximalen Signallaufzeit der gewünschten Operation der ALU entsprechen.
Ebenso erhalten die Datenleitungen ein weiteres Bit (Token), das
durch die Verzögerungselemente
geschleift wird. Treffen die Tokens aller benötigten Operanden in einer ALU
ein, so wird am Ausgang der ALU, um die entsprechende maximale Signallaufzeit
verzögert,
ein Token erzeugt.
- – Laufzeitzähler: Während der
Zuordnung der Funktionen an die ALUs werden die Signallaufzeiten
aller Spalten (in Form sog. Pico-Takte, also in Bruchteilen eines
Maschinen-Takts) mitgezählt.
Die für
synchrone Operationen relevanten Zeitpunkte werden in den jeweiligen
Einheiten gespeichert. Zu den gegebenen Zeitpunkten werden dann
die gewünschten
Operationen angestoßen,
d.h. jede synchrone Einheit wartet so lange ab, bis die benötigten Daten
laut Laufzeitzähler
bereit stehen.
- – Synchrone
Tokens: Hierzu werden ebenfalls Token verwendet. Das Weiterreichen
der Token erfolgt allerdings nicht durch asynchrone Verzögerungselemente
an jeder ALU, sondern durch Register mit Bypass an jeder ALU. Standardmäßig ist
das Register deaktiviert, also der Bypass aktiv. Wie bei der vorangehenden Variante
wird die Signallaufzeit der Daten bei der Konfiguration der ALUs
mitgezählt.
Wird die gezählte
Signallaufzeit größer als
ein Takt, so wird das Token-Register
der aktuell konfigurierten ALU aktiviert und der Laufzeitzähler um
einen Takt dekrementiert. Das Token läuft bei dieser Technik nicht
synchron zu den Daten durch den Datenflussgraph sondern eilt maximal
einen Takt voraus. Dies muss bei der Ausführung synchroner Operationen
berücksichtigt
werden. 3 zeigt ein Beispiel, bei dem
alle drei ALUs Operationen ausführen,
die eine Signallaufzeit von einem halben Maschinentakt besitzen.
Die Token-Register der beiden oberen ALUs werden auf Bypass geschalten,
während
das Token-Register der unteren ALU das Token so lange aufhält, bis
die Daten tatsächlich
verfügbar
sind.
-
Für die Funktion
des ALU-Grid Prozessors muss lediglich eine der drei genannten Möglichkeiten
zur Synchronisation realisiert werden. Die letzte Variante wird
dabei aufgrund ihrer Flexibilität
bevorzugt.
-
Im
Folgenden wird als Beispiel ein Programm in einem Assembler-Code
vorgegeben und in einen ALU-Grid Prozessor ohne Zwischenregister
abgebildet. Aufgabe des Programms ist es, die Summe über die Beträge eines
15 Elemente langen Zahlenvektors zu bilden. Der Vektor muss dabei
bereits in dem an den ALU-Grid Prozessor angeschlossenen Hauptspeicher
vorhanden sein. Das Programm wird in mehreren Dekodier- und Ausführungsphasen
abgearbeitet. Ebenso sind für
jede Dekodierphase mehrere Befehlshole-Zyklen erforderlich, die
hier aber zusammengefasst werden.
| move
R1,#15 | ;15
Datenwerte |
| move
R2,#adresse | ;Startadresse
des Vektors |
| move
R0,#0 | ;Register
für die
Summe auf 0 ;setzen |
| | |
| loop: | |
| load
R3,[R2] | ;ein
Element aus dem ;Speicher lesen |
| jmpnl
R3,not_negativ | ;ist
dieser nicht negativ? |
| neg
R3 | ;wenn
negativ: negieren |
| | |
| not_negativ: | |
| add
R0,R3 | ;absoluten
Wert zum ;Summenregister (R0) addieren |
| add
R2,#4 | ;Adresse
für nächstes Element
;erhöhen |
| sub
R1,#1 | ;ein
Datenelement wurde ;abgearbeitet |
| jmpnz
R1,loop | ;noch
mehr Datenwerte? |
-
Die
Abarbeitung dieses Programmstücks
erfolgt in zwei Dekodierphasen und in insgesamt 15 Ausführungsphasen.
In der ersten Dekodierphase werden alle Befehle des Programms im
ALU-Grid angeordnet. Die Dekodiereinheit bemerkt dabei, dass der
erste Sprungbefehl lediglich einen einzigen arithmetisch-logischen Befehl überspringt.
Dieser eine Befehl wird wie jeder andere arithmetisch-logische Befehl
im ALU-Grid angeordnet, mit dem Unterschied, dass die Predication-Leitung
der entsprechenden ALU mit der Sprung-Kontrolleinheit verbunden
wird. Diese wird derart konfiguriert, dass sie zu gegebener Zeit
den Wert von R3 auf ein negatives Vorzeichen hin überprüft. 4,
in der nur die Register bzw. Spalten R0 bis R3 skizziert sind, zeigt die
Belegung der ALUs, der Sprung-Kontrolleinheit und der Speicherzugriffseinheiten.
Dabei wurde angenommen, dass die Befehle add, sub und neg jeweils
einen vollen Maschinentakt und die move-Befehle einen halben Maschinentakt
zur Ausführung
benötigen.
Für einen
Cache-Zugriff werden hier zwei Takte veranschlagt, jeder der beiden
Vergleichsoperationen in der Sprung-Kontrolleinheit benötigt einen halben Takt. Diese
Zeiten sind hier nur beispielhaft gewählt und müssen bei der tatsächlichen
Implementierung genau bestimmt werden.
-
Die
in der 4 erkennbaren Zahlenwerte geben den Zeitpunkt
in Maschinentakten an, zu dem der entsprechende Wert Gültigkeit
erhält.
Je nachdem, welches Verfahren zur Synchronisation verwendet wird, muss
ein zentraler Zeitzähler
vorhanden sein, der die verstrichene Zeit seit Berechnungsbeginn
mitzählt.
Erzeugt ein Speicherzugriff einen Cache-Miss, so wird dieser Zähler so
lange angehalten, bis das gewünschte Datum
aus dem Speicher geladen wurde. Werden Token verwendet, so ist kein
Zeitzähler
erforderlich. Dies führt
zu einem deutlich flexibleren Laufzeitverhalten.
-
Zum
Zeitpunkt 2,5 Maschinentakte ist der erste Wert des Vektors aus
dem Speicher gelesen und die Sprung-Kontrolle überprüft diesen auf ein negatives
Vorzeichen. Ist der gelesene Wert in Register R3 negativ, so wird
der neg-Befehl ausgeführt,
anderenfalls wird die entsprechende ALU über das Predication-Signal deaktiviert
und der Eingangswert unverändert
an den Ausgang weitergegeben.
-
Zum
Zeitpunkt 5 Maschinentakte ist die Abarbeitung aller abgebildeten
Befehle beendet und das Ergebnis der letzten Vergleichsoperation
kann betrachtet werden. In diesem Fall ist der in Spalte R1 abgegriffene Wert
14, d.h. nicht 0, und es erfolgt ein Sprung. Die Sprung-Kontrolleinheit registriert,
dass das Sprungziel nicht auf eine Zeile mit Registern (Top- oder
Zwischenregister) abgebildet wurde. Dies hat zur Folge, dass alle
Werte am unteren Ende des ALU-Grid abgegriffen und in die Top-Register
kopiert werden. Danach erfolgt das Zurücksetzen aller ALU-Konfigurationen
und es wird eine erneute Dekodierungsphase an der Stelle des Sprungziels
im Programmcode gestartet. Nach Abschluss dieser Dekodierungsphase
befindet sich der erste Befehl des Schleifenkörpers in der ersten Zeile,
also direkt unter den Top-Registern. Das ALU-Grid besitzt jetzt
die in 5 gezeigte Konfiguration.
-
Nach
der zweiten Ausführungsphase
(4,5 Takte nach ihrem Beginn) erfolgt wieder die Überprüfung des
Registers R1, das diesmal den Wert 13 besitzt, auf den Wert 0. Somit
wird der Sprung als „auszuführen" erkannt und es wird
wieder geprüft,
ob sich das Sprungziel bereits im ALU-Grid an passender Stelle befindet. Diesmal
korrespondiert das Sprungziel mit dem ersten Befehl im ALU-Grid,
d.h. es wird keine neue Dekodierungsphase gestartet, sondern es
werden lediglich die Werte am unteren Ende des ALU-Grid in die Top-Register
kopiert. Anschließend
wird eine weitere Ausführungsphase
gestartet.
-
Erreicht
das Register R1 den Wert 0, so wird der Sprung am Ende der Schleife
als „nicht
auszuführen" ausgewertet. Dies
hat zur Folge, dass eine neue Dekodierungsphase angestoßen wird.
Dabei wird das ALU-Grid
mit weiteren Befehlen (nicht im Beispiel angegeben) bestückt, bis
die Kapazität
des ALU-Grid erreicht ist oder ein weiterer Sprungbefehl im Programmcode
auftaucht.
-
Die
erste der oben gezeigten Ausführungsphasen
erreicht einen IPC (Instructions Per Cycle) von 2 (10 Befehle in
5 Takten) und die zweite Ausführungsphase
einen IPC von 1,4 (7 Befehle in 5 Takten). Dabei entfallen jeweils
2 Takte alleine auf den Speicherzugriff. Ein konventioneller (Superskalar-)Prozessor
würde hier voraussichtlich
deutlich schlechtere Ergebnisse liefern. Ebenso kommt hinzu, dass
der ALU-Grid Prozessor ohne
Sprungvorhersage arbeitet. Diese Sprungvorhersage kann in Superskalar-Prozessoren
bei falschen Voraussagen weitere deutliche Leistungseinbußen verursachen.
Außerdem
führt das
Fehlen der Sprungvorhersage zu vorhersagbarem Laufzeitverhalten
des ALU-Grid Prozessors.
-
In
dem vorherigen Beispiel ist zu erkennen, dass das ALU-Grid nur zu
einem sehr geringen Prozentsatz ausgelastet ist. Werden die Architekturregister
nicht direkt auf die Spalten des Grid abgebildet, sondern lediglich
wenige ALUs pro Zeile integriert die von allen Registerspalten genutzt
werden können,
so lässt
sich die Anzahl an ALUs reduzieren. Ebenso ist dadurch auch eine
Spezialisierung der ALUs möglich,
so dass nicht alle ALUs als komplexe Multi-Funktions-ALUs realisiert
werden müssen.
Evtl. kann hierbei eine Art Register-Renaming angewandt werden,
d.h. eine Spalte ist nicht fest einem Register zugeordnet, sondern
die Zuordnung wechselt von Zeile zu Zeile.
-
Weiterhin
ist im vorherigen Beispiel zu sehen, dass die Dekodier- und Konfigurationseinheit
sehr lange Zeit (13 von 15 Schleifendurchläufen) nicht benötigt wurde.
Die Integration eines geeigneten Energiesparmechanismus, z.B. durch
dynamische Abschaltung der Einheit(en), ist hier möglich. Gleiches
gilt für
nicht benötigte
ALU-Zeilen unterhalb der zuletzt benötigten ALU. Da die beschriebene
Architektur in Bezug auf die Anzahl an Zeilen frei skalierbar ist,
besteht die Möglichkeit
einer Minimal-Implementierung mit zwei Zeilen für den Einsatz in mobilen (Kleinst-)Systemen
oder durch Kontext-gesteuerte Abschaltung von Zeilen (z.B. wenige
aktive Zeilen bei Batteriebetrieb und viele aktive Zeilen bei Netzbetrieb
von Notebooks).
-
Da
jede der Speicherzugriffseinheiten nur einem Lade/Speicherbefehl
zugeordnet werden kann, ist die Implementierung effizienter Streaming-Buffer
direkt in jeder Speicherzugriffseinheit von Vorteil. Bereits das
einfache Laden einer kompletten Cache-Line direkt in eine Speicherzugriffseinheit
kann hier enorme Leistungsvorteile bringen. Die Speicherzugriffseinheiten
können
bei vorhandenen Daten ebenfalls asynchron arbeiten, was bei dem
vorherigen Beispiel eine Verkürzung
der Laufzeit eines Schleifendurchlaufs von 1–1,5 Takten bewirken würde.
-
Auch
die Nachteile des Zeitzähler-Verfahrens
zur Synchronisation werden hier sichtbar: Erstens muss bei einem
Cache-Miss die „Zeit" vollständig angehalten
werden, d.h. Berechnungen, die gleichzeitig zum Hauptspeicher-Zugriff
erfolgen könnten,
können
ihren Vorteil nicht ausspielen. Zweitens muss beim Zeitzähler-Verfahren
immer mit dem schlechtesten Fall gerechnet werden, d.h. es muss
immer damit gerechnet werden, dass alle zugeordneten Befehle auch
ausgeführt
werden müssen.
Im Beispiel benötigten
alle Schleifendurchläufe
dieselbe Zeit, egal ob die Negation ausgeführt werden muss oder nicht.
Beide Probleme tauchen bei den beiden Token-Verfahren nicht auf.
-
Es
ist nicht sinnvoll (und auch teilweise nicht möglich), aufwendige Funktionen
wie Divisionen oder Gleitkommaberechnungen direkt in den asynchronen
ALUs zu integrieren. Wird eine Technik verwendet, bei der, wie weiter
oben beschrieben, wenige ALUs pro Zeile von allen Spalten genutzt
werden können,
so können auch
Spezial-Ausführungseinheiten
eingesetzt werden, die lediglich eine Aufgabe erfüllen können (z.B.
Division). Hier ist es allerdings nicht sinnvoll, pro Zeile eine
eigenständige
Divisionseinheit zu realisieren. Vielmehr besteht die Möglichkeit,
in jeder Zeile so genannte virtuelle Einheiten zu implementieren
(siehe 6). Durch virtuelle Einheiten werden in jeder
Zeile lediglich alle benötigten
Anschlüsse
(Ein- und Ausgänge) realisiert. Sind
in einer Zeile alle Token vorhanden, d.h. die Arbeitsdaten stehen
zur Verfügung,
so kann die entsprechende Berechnung von einer mit der virtuellen
Einheit verbundenen, zentralen (nunmehr getakteten) Spezial-Ausführungseinheit ausgeführt werden.
Dabei kann die Berechnung auch gepipelined durchgeführt werden,
so dass mehrere dieser Berechnungen zeitüberlappt stattfinden können. Diese
Erweiterung kann nur sinnvoll integriert werden, wenn eines der
beiden Token-basierten Synchronisationsverfahren zum Einsatz kommt.
-
Aus
der Compiler-Technik ist ein Verfahren zur optimierten Verarbeitung
von Schleifen bekannt, das sog. Software-Pipelining. Dabei wird
der Programmcode eines Schleifenkörpers so gestaltet, dass bei
der Abarbeitung einer Iteration bereits Berechnungen für die nächste Iteration
durchgeführt
werden. Dafür
werden meist andere Register als die tatsächlich benötigten verwendet und die Ergebnisse
zu gegebener Zeit in die relevanten Register kopiert.
-
Ist
der realisierte ALU-Grid Prozessor mit Zwischenregistern ausgestattet,
so bietet sich eine andere Art des Pipelining an: echtes Hardware-Pipelining. Dabei
können
die Zwischenregister als Pipeline-Register genutzt werden. Diese
Technik funktioniert allerdings nur, wenn das Ergebnis des kritischen
Pfads einer Iteration nicht für
die nächste
Iteration benötigt
wird. Damit der ALU-Grid Prozessor das Pipelining umsetzen kann, ist
entweder eine Befehlssatz-Erweiterung oder eine Erweiterung der
Dekodiereinheit erforderlich. In beiden Fällen muss die Konfigurationseinheit
mitgeteilt bekommen, welche Register den nicht benötigten kritischen Pfad
darstellen und dass Pipelining hier möglich ist.
-
Dies
wird am folgenden Beispiel deutlich: Würde das weiter oben beschriebene
Beispielprogramm den Vektor nicht aufsummieren, sondern lediglich
den Betrag jedes Elements wieder in den Speicher zurückschreiben,
so wäre
der kritische Pfad (im Beispiel R0) einer Iteration in der nächsten nicht
relevant. Im Folgenden ist der abgewandelte Programmcode des Beispiels
aufgeführt.
7 zeigt
eine mögliche
Zuordnung (ab der zweiten Iteration) der Befehle für die Ausführung in
Form einer Pipeline. Ein zusätzlicher
Befehl für
das Pipelining wurde hier nicht berücksichtigt.
| move
R1,#15 | ;15
Datenwerte |
| move
R2,#adresse | ;Startadresse
des Vektors |
| | |
| loop: | |
| load
R3,[R2] | ;ein
Element aus dem
;Speicher lesen |
| jmpnl
R3,not_negativ | ;ist
dieser nicht negativ? |
| neg
R3 | ;wenn
negativ: negieren |
| | |
| not_negativ: | |
| move
R0,R2 | ;Adresse
für STORE
;zwischenspeichern |
| add
R2,#4 | ;Adresse
für nächstes
;Element
erhöhen |
| store
[R0],R3 | ;absoluten
Wert wieder in
;den Speicher schreiben |
| sub
R1,#1 | ;ein
Datenelement wurde
;abgearbeitet |
| jmpnz
R1,loop | ;noch
mehr Datenwerte? |
-
Bei
der Pipeline-Ausführung
muss beachtet werden, dass die Datenrückführung hier im Beispiel nicht vom
Ende des Grid sondern von den Zwischenregistern in die Top-Register
stattfinden muss. Die Entscheidung über das Schleifenende muss
aber dennoch nach der letzten Pipelinestufe gefällt werden. Wurde der obere
Teil einer Iteration bereits ausgeführt, obwohl die Schleifenbedingung
nicht mehr erfüllt
ist, so sind keine weiteren Maßnahmen
bzgl. der Register notwendig. Da nur mit den Werten am Ende des
Grid weitergearbeitet wird, werden automatisch alle Zwischenergebnisse
in den Zwischenregistern verworfen. Erfolgen hingegen in einer anderen
als der letzten Pipelinestufe Schreibzugriffe auf den Hauptspeicher,
so müssen
diese unterdrückt
werden, bis klar ist, ob die jeweilige Iteration überhaupt
ausgeführt
werden muss.
-
Bei
einer weiteren beispielhaften Ausgestaltung wird angenommen, dass
der im Beispiel verwendete ALU-Grid
Prozessor Zwischenregister besitzt. In diesem Fall können Daten
aus den entsprechenden Zeilen innerhalb des ALU-Grid abgegriffen
werden, um die Dekodierung weiterer Befehle schon während der
Laufzeit der Ausführungsphasen
zu starten.
-
Jetzt
wird deutlich, aus welchem Grund für den ALU-Grid Prozessor nicht
unbedingt eine Branch-Prediction
notwenig ist: die beiden möglichen
Pfade eines kurzen Sprungs können
gleichzeitig mit der Predication-Technik im ALU-Grid angeordnet
werden oder es besteht die Möglichkeit,
den einen Pfad (Schleifenkörper) im
ALU-Grid auszuführen,
während
der andere Pfad (nachfolgender Programmcode) für die spätere Verwendung bereits unterhalb
im ALU-Grid angeordnet wird. Es bleiben somit nur noch Sprünge über große Distanzen,
die keiner Schleife zugeordnet werden können, und unbedingte Sprünge, die
aber bereits in der Dekodierungsphase aufgelöst werden.
-
Wird
eine Schleife mit mehreren Aussprung-Punkten (z.B. bei einer C-Break-Anweisung)
im ALU-Grid ausgeführt,
so kann die Dekodier- und Konfigurationseinheit Befehle von allen
möglichen
Sprungzielen vorab dekodieren und entsprechende „theoretische" Anordnungen in einem
Zwischenspeicher, ähnlich
einem Trace-Cache, zwischenspeichern. Wird einer der Sprünge genommen,
so kann die berechnete Konfiguration sehr schnell in das ALU-Grid
geladen und die Ausführung
fortgesetzt werden. Noch schneller kann die Umkonfiguration stattfinden,
wenn nicht ein zentraler Zwischenspeicher verwendet wird, sondern
die Konfigurationsregister im ALU-Grid mehrfach vorhanden und in
sog. Planes angeordnet sind. Dabei ist es möglich, bei der Ausführung mit
einem Plane zu arbeiten, während
in ein anderes Plane gleichzeitig eine neue Konfiguration geschrieben
wird. Somit kann von einer Konfiguration zur nächsten unmittelbar gewechselt
werden.
-
Bei
dem Einsatz eines Trace-Konfigurations-Cache oder mehreren Konfigurations-Planes
wird der Einsatz einer Art Branch-Prediction sinnvoll. Ihre Aufgabe
besteht dabei aber nicht darin, eine Vorhersage darüber zu machen,
ob ein spezieller Sprung genommen wird oder nicht, sondern darin,
mit welchem Sprung eine Schleife voraussichtlich verlassen wird.
Diese Vorhersage ist dafür
interessant, welcher Programmcode zuerst dekodiert und im Trace-Cache
oder einem anderen Plane abgelegt wird, damit er dann beim tatsächlichen
Verlassen der Schleife zur Verfügung
steht. Je länger eine
Schleife ausgeführt
wird, desto weniger wichtig wird diese Vorhersage, da immer mehr
Aussprung-Punkte bis zum Verlassen dekodiert worden sind.