Hintergrund: Eine neue SIMD- und FPU-Einheit für PowerPCs

Mit Motorolas e500-Kern kommt zumindest für die Embedded-PowerPC-Prozessoren eine neue SIMD- und FPU-Einheit als Alternative zu der bislang bei den Desktop-Prozessoren (G4) verbreiteten AltiVec-Einheit. Motorola hatte das prinzipielle Konzept des e500-Kerns auf dem Microprocessor Forum 2001 vorgestellt, aber die SIMD-Einheit nicht genauer spezifiziert, sondern sprach nur von "AltiVec-ähnlich". Mit der kürzlichen Einführung der PowerQuicc-III-Prozessoren hat Motorola aber auch die vollständige e500-Dokumentation ins Web gestellt, die die neuen SIMD- und FPU-Befehle beschreibt. Die Dokumentation gibt darüber hinaus auch detailliert über die geplante 64-Bit-Erweiterung gemäß der Book-E-Verabredung mit IBM Auskunft. Die klassischen PowerPC-Gleitkommabefehle, wie sie auch im Book-E verankert sind, unterstützt e500 nicht, sondern bietet gemäß einem "Sonderparagraphen" in Book-E eine eigene Implementierung für FPU und SIMD, die die gleichen Register wie die Integer-Einheit benutzt.

Ob IBM den kommenden 64-Bit-PowerPCs ("Desktop-Power4") diese oder ähnliche 64-bittige SIMD-Erweiterungen statt einer eigenständigen 128-bittigen AltiVec-Einheit mit auf den Weg gibt, ist zwar noch offen (jedenfalls hat IBM eine diesbezügliche Behauptung bislang weder bestätigt noch dementiert), liegt aber als eine sinnvolle Möglichkeit auf der Hand. Auch Intel hat übrigens beim Umstieg auf 64 Bit dem Itanium die Multimedia-Einheiten wieder auf 64 Bit heruntergekürzt und emuliert das 128-bittige SSE aus der 32-Bit-Welt lediglich.

Motorolas e500 besteht aus einem modularen Kern, der durch verschiedene Application Processing Units (APU) erweitert werden kann, wobei diese Units direkt auf den Registersatz einwirken. Dieser Registersatz (GPR) umfasst 32 64-bittige Register, von denen für den normalen 32-Bit-Betrieb nur die unteren Registerhälften verwendet werden. SIMD- und Gleitkomma-Berechnungen übernimmt beim e500 eine APU namens Signal Processing Extension (SPE). Sie arbeitet mit den auf 64 Bit erweiterten GPRs, unterstützt derzeit aber auch im Skalarmodus nur einfache Genauigkeit mit 32 Bit. Im Unterschied zu AltiVec gibt es zusätzliche Testbefehle, die voll den IEEE-Exception-Regeln entsprechen. Alternativ kann sie aber auch wie bislang exception-freie (und schnellere) Befehle nutzen.

Die SPE-APU unterteilt die Register entweder in zwei 32-Bit-Bereiche (Integer oder Gleitkomma mit einfacher Genauigkeit) oder vier 16-Bit-Bereiche. SIMD mit Bytes, wie bei AltiVec, kennt sie nicht. Sie ist im wesentlichen optimiert für zwei 32-bittige Daten. Für die wohl wichtigste Signalprozessor-Aufgabe, die Fast-Fourier-Transformation, hält die ISA ein zusätzliches Goody bereit, nämlich brinc: Bit Reversed Increment. Insgesamt kommt die SIMD-Erweiterung der SPE-APU auf über 180 Befehle, die alle (außer brinc) mit ev.... beginnen. Darunter sind viele recht komplex wirkende Konstrukte wie: Multiply Half Words, Even, Guarded, Signed, Modulo, Fractional and Accumulate Negative (evmhegsmfan)

Während AltiVec und andere Multimedia-Einheiten (3Dnow!, SSE) vergleichsweise mühsam eine Division per Software iterieren müssen, kennt die SPE-APU auch eine parallele Division (evsdiv, evfsdiv) für zwei Integer- oder SP-Gleitkommawerte. Nur wer Wurzeln ziehen möchte, ist schlechter dran: Hier ist der Programmierer auf sich allein (und auf Newton-Raphson) gestellt.

Neben der SPE-APU besitzt e500 noch ein paar kleinere spezifische APUs, etwa zum Performance-Monitoring oder zum Verriegeln von Einträgen im Cache oder im Branch Target Buffer, was Zeitvorteile bei Echtzeitanwendungen bringt.

Gegenüber einer externen Unit hat die SIMD-Lösung des e500-Kerns mit Register-Sharing den Nachteil, über weniger Register zu verfügen und nur 64-bittig zu sein. AltiVec und SSE besitzen demgegenüber eigene 128-bittige Register. Andererseits bieten gemeinsame Register aber auch viele Vorteile, so sind alle Adressierungsarten bei Speicherzugriffen möglich, der ein oder andere Transfer zwischen Registern kann entfallen, Typwandlungen sind einfacher und der Programmfluss hat es auch leichter. Denn es dauert relativ lange, bis beispielsweise das Ergebnis eines Vergleiches von einer externen Einheit wie AltiVec zum Prozessorkonditions- oder Statusregister gelangt -- Intel hat darauf bei MMX und SSE gleich ganz verzichtet, was dann aber recht mühsame Abfragekonstrukte erfordert.

Die größere Registerbreite von SSE und AltiVec ist nicht zwangsläufig in allen Situationen von Vorteil. Häufig erfordert die hohe Parallelität nämlich eine recht komplexe Programmierung (oder ist schlechterdings gar nicht machbar). Für viele Matrix-Berechnungen ist zudem oft eine längliche Umsortierung der Daten nötig. Wie frühere Vergleiche zwischen dem 128-bittigen SSE und dem 64-bittigen 3Dnow! zeigten, konnte 3Dnow! bei geschickter Programmierung bei vielen Aufgaben gut mithalten, da es etwa im K6-2 mit zwei parallel arbeitenden Einheiten aufwarten konnte.

Motorolas e500-Implementierung im MPC8540/8560 arbeitet mit einer siebenstufigen Pipeline. Zwei Befehle pro Takt kann der Decoder an die Ausführungseinheiten schicken, unter denen sich zwei einfache Integer-Einheiten, eine Multi-Cycle-Einheit (MU), die beschriebene SPE-APU und eine Load-Store-Einheit (LSU) befinden. Die SPE-APU vermag einfache Operationen in einem Takt auszuführen, für Multiplikation und Multiply-Add benötigt sie im Zusammenspiel mit der MU vier Takte. Diese Operationen sind voll pipelined, das heißt, bereits nach einem Takt kann der Prozessor die nächste Operation nachschieben. Bei der Division gibt es eine variable Latenz mit 4, 11, 19 oder 35 Takten. Diese Division ist "ein bisschen" pipelined: während der Iteration werden immerhin die ersten beiden Pipeline-Stufen bereits wieder freigegeben.

Zum Vergleich: AltiVec im G4-MPC7450 berechnet einfache Integer-Operationen ebenfalls nur mit einer Latenzzeit von einem Takt (in der Low Latency Vector Unit), für Gleitkomma inklusive Multiplikation sind es jedoch vier Takte (allerdings ja gleich für vier SP-Gleitkommawerte). Multiply-Add (vaddfp) ist ebenfalls in vier Takten fertig und für die Vektor-Division benötigt AltiVec je nach gewünschter Genauigkeit drei oder fünf Vektorbefehle mit jeweils vier Takten, die sich aber zum Teil überlappen können. Mehr Informationen zu den Ausführungszeiten beim G4 gibt Motorola im Software Optimization Guide. (as)