Workshopband als PDF - Mpc.belwue.de

MPC-WORKSHOP FEBRUAR 2013
Coremark / MHz
0,6
0,5
0,4
0,3
0,2
0,1
0
AMD
Hulk Janus 2.0 Am386DX
-Ox
CM / MHz 0,502 0,292 0,25
Abbildung 3: Optimierte Benchmark Coremark – Ergebnisse.
setzt wurde, welcher jedoch über keine Optimie-
rungsoptionen, wie z.B. der GCC-Compiler, verfügt.
Ein Nachteil besteht darin, dass zum einen nicht nur
der verwendete Compiler mitgetestet wird, sondern
auch dessen Optimierungsstufe, was einen direkten
Vergleich der Benchmark-Ergebnisse erschwert.
Ausgehend von diesen Tatsachen erreichte der
SIRIUS HULK einen Benchmark-Wert von
0,502 CM/MHz und der SIRIUS Janus 2.0 einen Wert
von 0,292 CM/MHz. Wie in Abbildung 3 ersichtlich,
ist der SIRIUS HULK damit bereits doppelt so leistungsfähig
wie ein AMD Am386DX und in etwa 72%
schneller als der SIRIUS Janus. Ausgehend von diesen
Resultaten stellte sich heraus, dass Optimierungspotential
vorlag, sowohl auf Seiten der Software, als
auch auf Seiten der Hardware.
A. Software
IV. OPTIMIERUNGEN
Die Verbesserung auf Compiler-Seite bezieht sich
auf die Einführung sogenannter Registervariablen. Der
Unterschied zu den bisher verwendeten Stackvariablen
besteht darin, dass eine im Code angelegte lokale
Variable nicht mehr auf dem Stack angelegt wird,
wodurch der Wert der Variablen jedes Mal bei Verwendung
mit Hilfe von Load- und Store-Instructions
geladen bzw. abgelegt werden muss, sondern stets in
einem freien Prozessorregister gehalten wird. Hierdurch
entfallen die Load- und Store-Instructions, was
die Codeausführung beschleunigt. Diese Optimierung
musste rein auf Seiten des Compilers vorgenommen
werden und hat je nach Anzahl der benötigten lokalen
Variablen Einfluss auf die Gesamtausführungszeit
eines Programmes. Anhand des Benchmarks
Coremark zeigte sich, dass es sich vor allem auf die
Ausführungszeit der CRC-Berechnungen auswirkte
und allgemein wie erwartet auf alle Codeabschnitte
mit lokalen Variablen. Eine Begrenzung dieser Optimierung
liegt einzig in der Verfügbarkeit freier Prozessorregister
zum jeweiligen Zeitpunkt, an dem der
Einsatz einer Registervariablen möglich wäre. Abbildung
4 zeigt beispielhaft die Verkürzung des auszuführenden
Codes durch den Einsatz von Registervariablen.
Abbildung 4: Einsatz von Registervariablen.
Bisher: Immer 3 Taktzyklen
15 0 15 0 15
0
Jetzt: Entscheidung anhand der Größe des Wertes
Beispiel: ADI (-Short), Wert < 63
15
15
Abbildung 5: Überladung der Instructions.
B. Hardware
0
0 1 0 0 1 1
Beispiel: ADI (-Short), Wert > 63 / „Umschalter“ = 63
0
1 1 1 1 1 1
15 0 15
0
Die Optimierung der Hardware bestand darin, verschiedene
Instructions zu überladen. Das Prinzip dahinter
wird in Abbildung 5 anhand des Befehls ADI
(Add Immediate) verdeutlicht. Bisher wurde die zum
Quellregister (grün coloriert) zu addierende Konstante
stets in zwei getrennten 16-Bit-Worten übertragen
(rot), unabhängig von der Größe der Konstanten. Da
es sich bei ADI jedoch um einen Immediate-Befehl
handelt, sind in diesem Falle jedoch keine Opcode-
Bits für ein Zielregister erforderlich. Somit sind insgesamt
sechs Bits innerhalb des Opcodes ungenutzt (in
Abbildung 5 grau dargestellt). Bei der Überladung
werden diese ungenutzten Bits nun dazu verwendet,
Konstanten zu definieren. Ist die Konstante größer als
sechs Bit, wird anhand eines „Umschalters“ dem Prozessor
mitgeteilt, dass die zwei darauffolgenden 16-
Bit-Worte die Konstante darstellen. Hieraus ergibt
sich eine verkürzte Ausführungszeit für all diejenigen
Konstanten, die einen Wert kleiner 63 besitzen. Der
Wert 63 dient in diesem Fall als „Umschalter“. Somit
können bei der Überladung im Idealfall 2 Zyklen pro
überladener Instruktion gespart werden.
Bei Sprungbefehlen fällt die ungenutzte Bitbreite
und somit die innerhalb eines Opcodes übertragbare
Konstante mit 10 Bit noch größer aus, sodass hieraus
ein maximaler Sprung von ±1022 realisierbar ist. Der
Wert +1024 dient als „Umschalter“ in diesem Falle.
Es gilt zu beachten, dass pro Konstanten-Wert immer
um zwei Byte (eine Instruction) gesprungen wird und
hieraus der Sprungbereich von ±1022 resultiert.
41