Information Technology Reference
In-Depth Information
derung bei einigen Bausteinen durch Lesen eines Statusregisters zurücknehmbar
(wohl gemerkt: durch Lesen, nicht durch Schreiben).
Um zu erzwingen, dass auf Peripherieregister in der im Programm codierten Rei-
henfolge zugegriffen wird, gibt es unterschiedliche Verfahren. Einige Prozessoren,
z.B. der Pentium 4 von Intel [81], verfügen z.B. über einen separaten Ein-/Ausgabe-
adressraum, auf den mit Hilfe spezieller Befehle zugegriffen wird, die nicht umge-
ordnet werden. Ebenfalls möglich ist es, den die Peripherieregister enthaltenden
Adressraum mit Hilfe einer Speicherverwaltungseinheit zu identifizieren und bei
Zugriffen darauf das Umordnen der entsprechenden Befehle zu verhindern. Als eine
weitere gebräuchliche Vorgehensweise kann man einen Befehl vorsehen, der bei sei-
ner Ausführung erzwingt, dass alle zuvor gestarteten Speicherzugriffe beendet wer-
den, bevor ein neuer Zugriff begonnen wird. So verfügen z.B. die Prozessoren der
PowerPC-Familie von Motorola und IBM über den Befehl eieio (enforce in-order
execution of I/O) mit genau dieser Semantik [128, 67].
Sprungbefehle (Kontrollflussspekulation)
Das Vorziehen von Ladebefehlen entspricht in seiner Wirkung prinzipiell der in
Abschnitt 3.1.5 beschriebenen Datenflussspekulation, mit dem einzigen Unter-
schied, dass für superskalare Prozessoren die Befehle zur Laufzeit, für VLIW-Pro-
zessoren jedoch zum Zeitpunkt der Übersetzung eines Programms, umgeordnet wer-
den. Im Zusammenhang mit bedingten Sprungbefehlen existiert eine ähnliche Ana-
logie. Sollen zur Erhöhung der Operationsparallelität Befehle, die regulär auf einen
bedingten Sprung folgen, davor ausgeführt werden, ist zu berücksichtigen, dass
nicht feststeht, ob es wegen der sequentiellen Semantik des Programms überhaupt
zu einer Ausführung dieser Befehle kommen darf. Die auf einen bedingten Sprung
folgenden Befehle lassen sich zwar ausführen, die erzielten Wirkungen auf den Sta-
tus der Maschine müssen ggf. jedoch rückgängig gemacht werden können, falls sich
nämlich herausstellt, dass der Sprungbefehl sich anders verhält, als z.B. durch eine
Sprungvorhersage ermittelt wurde (siehe Abschnitt 2.2.4). Der erforderliche Auf-
wand ist vergleichsweise gering, sofern die erzeugten Ergebnisse zunächst in Rena-
ming-Register gespeichert werden und zur Wiederherstellung der Befehlsreihen-
folge ein Reorder-Buffer zur Anwendung kommt.
Das Prinzip lässt sich leicht anhand der in Bild 3.41 dargestellten Befehlsfolge
(links) beschreiben. Angenommen, durch eine Sprungvorhersage wird ermittelt,
dass von den in der Befehlsfolge codierten Sprungbefehlen der erste in Zeile 2 ver-
zweigt, die beiden anderen in den Zeilen 5 und 8 nicht verzweigen, dann werden die
entlang des so definierten Pfads codierten Befehle sequentiell oder parallel deco-
diert, die Operanden bzw. Ergebnisse umbenamt, hierzu ggf. Renaming-Register
reserviert, die Befehle im Reorder-Buffer protokolliert und deren Ausführung
gestartet (selbstverständlich unter Berücksichtigung der Abhängigkeiten).
Um Fehlvorhersagen erkennen und die bereits erzeugten Ergebnisse ggf. verwerfen
zu können, wird zusätzlich im Reorder-Buffer das Vorhersageergebnis (z.B.
„Taken“ in Eintrag 4) und in den reservierten Renaming-Registern jeweils die Posi-
Search WWH ::




Custom Search