Operationsparallel arbeitende Prozessoren - Moderne Prozessorarchitekturen: Prinzipien und ihre Realisierungen - page 214

ist dies an einem Beispiel dargestellt, wobei die Operationsfolge rechts durch eine optimierende
Transformation aus der Operationsfolge links erzeugt wurde (das Ergebnis ist nicht optimal, wie
sich durch Vergleich mit Bild 3.21c überprüfen lässt).
Eine bessere Möglichkeit des Umgangs mit einer solchen Problemstellung wurde an der TU Berlin
entwickelt. Statt die Sprungoperation br.cond in Zeile 2 von Bild 3.24a zu codieren und damit das
Ende eines parallel verarbeitbaren Operationspakets zu definieren, wird ein dem Programmiermo-
dell hinzuzufügender Befehl join.cond (in Bild 3.24a im Kasten angedeutet) verwendet. Er sorgt
dafür, dass die auf das Sprungziel folgenden Befehle ggf. parallel zu denen ausgeführt werden, die
im aktuellen Befehlspaket zusammen mit dem bedingten Sprung codiert sind. Durch eine solche
Modifikation lässt sich die Entscheidung, ob die Operationen des if- (in den Zeilen 3 bis 5) oder die
des else-Zweigs (in den Zeilen 6 bis 8) parallel zum Vergleich bzw. dem bedingten Sprung ausge-
führt werden, von der Übersetzungszeit zur Laufzeit verschieben.
Zwar ist die Befehlsfolge wegen des den if-Zweig abschließenden unbedingten Sprungs geringfü-
gig umfangreicher (sieben statt sechs Operationen), sie ist dafür jedoch schneller bearbeitbar, wenn
die Sprungentscheidung korrekt vorhergesagt wird (ein Takt statt zwei Takte). Ein wichtiger Neben-
effekt ist außerdem, dass sich der Ressourcen-Bedarf durch Verwendung der join-Operation ver-
mindern lässt. Während nämlich die Operationsfolge in Bild 3.24b für die Additionen und Subtrak-
tionen vier Funktionseinheiten zur Bearbeitung erfordert, sind dies in Bild 3.24a nach Modifikation
nur noch zwei Funktionseinheiten. Die Einsparung ist z.B. nutzbar, um das Maß an Parallelverar-
beitung in einem Programm zu verbessern.

1: cmp.eq p1, p0 = r1, 0 1: cmp.eq p1, p0 = r1, 0;;

2: (p1) br.cond else

2: (p1) sub r2 = r3, r4

3: add r2 = r3, r4

3: (p1) add r5 = r5, 1

join.cond

4: sub r5 = r5, 1

4: (p1) br.cond end

5: br end;;

5: add r2 = r3, r4

6: else:
7:

6: sub r5 = r5, 1;;

sub r2 = r3, r4

7: end:

8: add r5 = r5, 1;;

9: end:

a

b

Bild 3.24. Optimierung eines if-then-else-Konstrukts. a Das nicht optimierte Assemblerprogramm.
b Assemblerprogramm nach Optimierung des else-Zweigs

Die Erweiterung existierender Prozessoren um die Fähigkeit zum Umgang mit join-Operationen ist
sehr einfach, sofern man berücksichtigt, dass die vor und nach dem Verzweigungspunkt codierten
Operationen entsprechend der Definitionen des Programmiermodells der IA-64-Architektur auch
sequentiell ausgeführt werden können und somit die Funktionalität der join-Operation dieselbe ist,
wie die einer herkömmlichen Sprungoperation. Falls jedoch tatsächlich über mehrere verzweigende
Sprünge hinweg parallelisiert werden soll, sind einige komplexe Architekturerweiterungen notwen-
dig: Zum Beispiel müssen mehrere Sprungentscheidungen vorhergesagt und gleichzeitig auf unter-
schiedliche Adressbereiche zugegriffen werden können, was neben einer Mehrfach-Sprungvorher-
sageeinheit einen Multiport-Cache oder Trace-Cache erfordert (Abschnitt 2.2.4 ff. und 3.2.4).

Optimierungstechniken
(trace scheduling, loop unrolling, software pipelining)

Trace-Scheduling. Die Geschwindigkeit, mit der VLIW-Prozessoren arbeiten, wird
wesentlich durch das Maß an Parallelität beeinflusst, welches statisch in den Befeh-
len codiert ist. Es überrascht daher nicht, dass die VLIW-Prozessorarchitektur durch