Prozessorbau im Hardware-Software-Codesign - Moderne Prozessorarchitekturen: Prinzipien und ihre Realisierungen - page 292

Zum Beispiel vergleicht die Operation cmp in Zeile 3 der in Bild 4.9 dargestellten
VLIW-Befehlsfolge tatsächlich die Registerinhalte r7 mit r8 und nicht r7' mit r8,
weil nämlich r7' bei einem Einsprung über die Sprungmarke V4 nicht definiert ist.
Um dies zu erkennen, werden die Inhalte der Schattenregister jeweils bei Ausfüh-
rung einer set-Operation als ungültig definiert. - Die selektive Operationsauswahl
wurde u.a. in [108] mit dem Ergebnis untersucht, dass sich zwischen 29% und 50%
des sonst erforderlichen Speicherplatzes einsparen lässt.

Lade- und Speicherebefehle

Lade- und Speicherebefehle werden abweichend von der Regel - skalare Nemesis-
Befehle immer entsprechend der im Originalprogramm bestehenden Reihenfolge in
die VLIW-Befehlsfolge zu übertragen - ggf. dennoch umgeordnet. Oft ist es näm-
lich besser, Ladebefehle vor Speicherebefehlen auszuführen, da erstere Ergebnisse
erzeugen, die von nachfolgenden Befehlen möglicherweise noch benötigt werden,
während letztere nur die Aufgabe haben, Endergebnisse in den Hauptspeicher zu
übertragen (siehe hierzu auch Abschnitt 2.3.1, Seite 159 ff.).

Das Umordnen von Lade- und Speicherebefehlen ist wesentlich aufwendiger zu rea-
lisieren als das einfache Übertragen einzelner Befehle in die VLIW-Befehlsfolge, da
hierbei zusätzlich alle abhängigen Operationen berücksichtigt und ggf. verschoben
werden müssen. Vereinfachend wirkt sich jedoch aus, dass Nemesis X pro Takt nur
einen Lade- bzw. Speicherebefehl verarbeiten kann. Zur Vorgehensweise: Speiche-
rebefehle werden zunächst äquivalent zu allen anderen Befehlen bearbeitet. Sie las-
sen sich jedoch durch Ladebefehle verdrängen, die in die VLIW-Befehlsfolge über-
tragen werden, indem man die bereits codierten Speicherebefehle ggf. nach hinten
verschiebt und dabei jeweils durch ein Bit als umgeordnet kennzeichnet.
Das Prinzip ist in Bild 4.10 dargestellt: Die skalare Befehlsfolge auf der linken Seite
wird in die auf der rechten Seite gewandelt, wobei man alle in ihrer Reihenfolge ver-
änderten Lade- bzw. Speicherebefehle kennzeichnet, was hier durch das jeweils
angeheftete .p symbolisiert ist. Bei Bearbeitung der rechts dargestellten Befehls-
folge werden die Zugriffsadressen aller gekennzeichneten Ladebefehle (ld.p) in
einem Hardware-Puffer gesichert. Kommt es zur Ausführung eines gekennzeichne-
ten Speicherebefehls, wird die Adresse des Zugriffs mit den gespeicherten Adressen
verglichen und bei Gleichheit eines Eintrags eine Ausnahmebehandlung angesto-
ßen. Darin werden die bis zu diesem Zeitpunkt erzeugten Ergebnisse des aktuellen
Programmpfads (d.h. des Traces) verworfen 1 und die entsprechenden virtuellen
Befehle schließlich streng sequentiell durch Interpretation ausgeführt.
Weil jeder gekennzeichnete Ladebefehl einen Speicherebefehl verdrängt, der dabei
gekennzeichnet wird, und weil die Reihenfolge der Lade- bzw. Speicherebefehle
unter sich unverändert bleibt, ist es möglich, mit jedem gekennzeichneten Speiche-

1. Die Wirkung von Speicherebefehle wird dabei annulliert, indem man die in einem in Hardware

realisierten Schreibpuffer gehaltenen Zugriffsaufträge löscht. Normalerweise werden diese
beim Verlassen des separierten Programmpfads bearbeitet, d.h. bei Ausführung einer stop- oder
Sprungoperation.