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

aber dessen Fähigkeit zur Parallelverarbeitung, weil der Schleifenrumpf wegen der zahlreichen
Datenabhängigkeiten größtenteils sequentiell bearbeitet werden muss. So lassen sich innerhalb der
Schleife pro Takt nur 1,5 dyadische Operationen ausführen (zwei Ladeoperationen, zwei Additio-
nen, eine Multiplikation und ein Vergleich, also sechs Operationen die in insgesamt vier Befehlen
codiert sind), statt der zwei dyadischen Operationen, die erwartet werden könnten, wenn, wie hier,
sechs Busse zum gleichzeitigen Transport von Operanden und Ergebnissen zur Verfügung stehen.

Die Parallelität lässt sich für die gegebene Problemstellung jedoch signifikant erhöhen, und zwar
mit Hilfe der in Abschnitt 3.1.5 beschriebenen Software-Fließbandverarbeitung . Wie der Schleifen-
rumpf hierbei zu unterteilen ist, zeigt der Datenflussgraph in Bild 3.31a: In der ersten Stufe werden
die Vektorelemente geladen und der Schleifenzähler inkrementiert. In der zweiten Stufe wird das
Produkt der Vektorelemente gebildet. In der letzten Stufe werden schließlich die Produkte sukzes-
sive akkumuliert. Die Umsetzung des Software-Fließbands in ein (sehr schwer verstehbares)
Assemblerprogramm ist in Bild 3.31b dargestellt.

i

x y 1

1. Stufe

1: alu1 = alu2 = 0 ;

ld ld ld

2: add1 <= (alu1*, 1) ld1.l <= x ld2.l <= y

3: add2 <= (mul, alu2) blo <= (-, 97, loop) ;

4: blo.l = alu1*;

2. Stufe

5: ld1.r = ld2.r = alu1 blo.l = alu1;

6: loop: ld1.r = ld2.r = alu1 mul = (ld1, ld2) blo.l = alu1 ;

7: mul = (ld1, ld2) r0 = alu2 ;

8: chain = 0 ;

3. Stufe

sum

a

b

Bild 3.31. Skalarprodukt zweier Vektoren. a Datenfluss innerhalb der Schleife. b Assemblerpro-
gramm für den Zen-1

Ähnlich wie in Beispiel 3.4 werden der Schleifenzähler i und das Akkumulationsergebnis sum nicht
in Registern, sondern in den Verarbeitungseinheiten alu1 und alu2 gehalten, deren Initialisierung
mit Null das Assemblerprogramm einleitet. Anschließend werden in Zeile 2 die vom Übersetzer
erkannten, im Datenflussgraphen als dicke Kanten hervorgehobenen harten Verkettungen aktiviert.
Die verwendete Schreibweise abstrahiert von den tatsächlich codierten Operationen, ist aber besser
lesbar. Neben einem Schreibzugriff auf das Steuerregister chain sind mehrere Transportoperationen
für die Konstanten 1, x, y und 97 codiert.

Als vorbereitende Maßnahme wird in Zeile 3 die Ausführung der Schleifensprungoperation blo
(branch lower) das erste Mal initiiert. Dies ist erforderlich, weil ein entsprechend Bild 3.29 reali-
sierter Prozessor Verzweigungen mit zwei Takten Verzögerung bearbeitet. Mit dem in Zeile 4
beginnenden und auch endenden Prolog wird das Laden der ersten beiden Vektorelemente angesto-
ßen, sowie der zweite Schleifendurchlauf vorbereitet. Wegen der harten Verkettung von Multiplika-
tions- und Additionseinheit sind weitere Aktionen nicht erforderlich.

Der Kern des Software-Fließbands ist vollständig in Zeile 5 codiert. Pro Takt wird hier das Lesen
der jeweils nächsten beiden Vektorelemente initiiert, die zuvor geladenen Vektorelemente werden
durch weiche Verkettung zur Multiplikationseinheit transportiert und dort verknüpft. Das Produkt
wird schließlich automatisch akkumuliert. Bemerkenswert ist, dass die Ladeoperation sogar meh-
rere Takte Latenzzeit aufweisen darf und trotzdem nach dem Füllen des Software-Fließbands in
jedem Takt ein Akkumulationsergebnis generiert wird.