This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Universität Hamburg
MIN-FakultätFachbereich Informatik
64-040 Rechnerstrukturen
64-040 Modul IP7: Rechnerstrukturenhttp://tams.informatik.uni-hamburg.de/
lectures/2011ws/vorlesung/rs
Kapitel 20
Andreas Mäder
Universität HamburgFakultät für Mathematik, Informatik und NaturwissenschaftenFachbereich InformatikTechnische Aspekte Multimodaler Systeme
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
Bewertung der ISA
Kriterien für einen guten BefehlssatzI vollständig: alle notwendigen Instruktionen verfügbarI orthogonal: keine zwei Instruktionen leisten das GleicheI symmetrisch: z.B. Addition ⇔ SubtraktionI adäquat: technischer Aufwand entsprechend zum NutzenI effizient: kurze AusführungszeitenStatistiken zeigen: Dominanz der einfachen Instruktionen
A. Mäder 3
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
Bewertung der ISA (cont.)I x86-Prozessor
Anweisung Ausführungshäufigkeit%1. load 22%2. conditional branch 20%3. compare 16%4. store 12%5. add 8%6. and 6%7. sub 5%8. move reg-reg 4%9. call 1%10. return 1%Total 96%
A. Mäder 4
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
Bewertung der ISA (cont.)nInstruction compress eqntott espresso gcc (cc1) li Int. average
load 20.8% 18.5% 21.9% 24.9% 23.3% 22%
store 13.8% 3.2% 8.3% 16.6% 18.7% 12%
add 10.3% 8.8% 8.15% 7.6% 6.1% 8%
sub 7.0% 10.6% 3.5% 2.9% 3.6% 5%
mul 0.1% 0%
div 0%
compare 8.2% 27.7% 15.3% 13.5% 7.7% 16%
mov reg-reg 7.9% 0.6% 5.0% 4.2% 7.8% 4%
load imm 0.5% 0.2% 0.6% 0.4% 0%
cond. branch 15.5% 28.6% 18.9% 17.4% 15.4% 20%
uncond. branch 1.2% 0.2% 0.9% 2.2% 2.2% 1%
call 0.5% 0.4% 0.7% 1.5% 3.2% 1%
return, jmp indirect 0.5% 0.4% 0.7% 1.5% 3.2% 1%
shift 3.8% 2.5% 1.7% 1%
and 8.4% 1.0% 8.7% 4.5% 8.4% 6%
or 0.6% 2.7% 0.4% 0.4% 1%
other (xor, not, . . .) 0.9% 2.2% 0.1% 1%
load FP 0%
store FP 0%
add FP 0%
sub FP 0%
mul FP 0%
div FP 0%
compare FP 0%
mov reg-reg FP 0%
other (abs, sqrt, . . .) 0%
Figure D.15 80x86 instruction mix for five SPECint92 programs.
A. Mäder 5
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
Bewertung der ISA (cont.)I MIPS-Prozessor
0 % 5 % 10% 15% 20% 25% 30% 35% 40%
load
and /o r / xo r
add/sub
cond branch
store
compare
cal l / return gap gcc gzip mcf perl
37%
12%
10%
5 %
13%
16%
3 %
0 % 5 % 10% 15% 20% 25% 30% 35% 40%
load int
add/sub int
load FP
add/sub FP
mul FP
store FP
cond branch
and /o r / xo r
compare int
store int applu a r t equake lucas swim
26%
15%
20%
10%
8 %
7 %
4 %
4 %
2 %
2 %
SPECint2000 (96%) SPECfp2000 (97%)
A. Mäder 6
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
Bewertung der ISA (cont.)I ca. 80% der Berechnungen eines typischen Programms
verwenden nur ca. 20% der Instruktionen einer CPUI am häufigsten gebrauchten Instruktionen sind einfache
Instruktionen: load, store, add. . .⇒ Motivation für RISC
A. Mäder 7
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
CISC – Befehlssätze
Complex Instruction Set ComputerI aus der Zeit der ersten Großrechner, 60er JahreI Programmierung auf AssemblerebeneI Komplexität durch sehr viele (mächtige) Befehle umgehenCISC BefehlssätzeI Instruktionssätze mit mehreren hundert Befehlen (> 300)I sehr viele Adressierungsarten, -KombinationenI verschiedene, unterschiedlich lange InstruktionsformateI fast alle Befehle können auf Speicher zugreifen
I mehrere Schreib- und Lesezugriffe pro BefehlI komplexe Adressberechnung
A. Mäder 8
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
I Übergabe von ArgumentenI Speichern des ProgrammzählersI explizite „Push“ und „Pop“ Anweisungen
I Zustandscodes („Flags“)I gesetzt durch arithmetische und logische Anweisungen
Konsequenzen+ nah an der Programmiersprache, einfacher Assembler+ kompakter Code: weniger Befehle holen, kleiner I-Cache− Pipelining schwierig− Ausführungszeit abhängig von: Befehl, Adressmodi. . .− Instruktion holen schwierig, da variables Instruktionsformat− Speicherhierarchie schwer handhabbar: Adressmodi
A. Mäder 9
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
CISC – Mikroprogrammierung
I ein Befehl kann nicht in einem Takt abgearbeitet werden⇒ Unterteilung in Mikroinstruktionen (∅ 5. . . 7)
I Ablaufsteuerung durch endlichen AutomatenI meist als ROM (RAM) implementiert, das
Mikroprogrammworte beinhaltet
1. horizontale MikroprogrammierungI langes Mikroprogrammwort (ROM-Zeile)I steuert direkt alle OperationenI Spalten entsprechen: Kontrollleitungen und Folgeadressen
A. Mäder 10
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
+ CISC-Befehlssatz mit wenigen Mikrobefehlen realisieren+ bei RAM: Mikrobefehlssatz austauschbar− (mehrstufige) ROM/RAM Zugriffe: zeitaufwändig
I horizontale Mikroprog. vertikale Mikroprog.
A. Mäder 11
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
horizontale Mikroprogrammierung
MikroprogrammierungA. Mäder 12
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
vertikale Mikroprogrammierung
Mikroprogrammierung
A. Mäder 13
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
RISC – Befehlssätze
Reduced Instruction Set ComputerI Grundidee: Komplexitätsreduktion in der CPUI internes Projekt bei IBM, seit den 80er Jahren: „RISC-Boom“
I von Hennessy (Stanford) und Patterson (Berkeley) publiziertI Hochsprachen und optimierende Compiler⇒ kein Bedarf mehr für mächtige Assemblerbefehle⇒ pro Assemblerbefehl muss nicht mehr „möglichst viel“ lokal
in der CPU gerechnet werden (CISC Mikroprogramm)
A. Mäder 14
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
I benötigen in der Regel mehr Anweisungen für eine AufgabeI werden aber mit kleiner, schneller Hardware ausgeführt
I Register-orientierter BefehlssatzI viele Register (üblicherweise ≥ 32)I Register für Argumente, „Return“-Adressen, Zwischenergebnisse
I Speicherzugriff nur durch „Load“ und „Store“ AnweisungenI alle anderen Operationen arbeiten auf RegisternI keine Zustandscodes (Flag-Register)
I Testanweisungen speichern Resultat direkt im Register
A. Mäder 15
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
RISC – Befehlssätze (cont.)
Konsequenzen+ fest-verdrahtete Logik, kein Mikroprogramm+ einfache Instruktionen, wenige Adressierungsarten+ Pipelining gut möglich+ Cycles per Instruction = 1
in Verbindung mit Pipelining: je Takt (mind.) ein neuer Befehl− längerer Maschinencode− viele Register notwendigI optimierende Compiler nötig / möglichI High-performance Speicherhierarchie notwendig
A. Mäder 16
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
CISC vs. RISC
ursprüngliche DebatteI streng geteilte LagerI pro CISC: einfach für den Compiler; weniger Code BytesI pro RISC: besser für optimierende Compiler;
schnelle Abarbeitung auf einfacher Hardwareaktueller StandI Grenzen verwischen
I RISC-Prozessoren werden komplexerI CISC-Prozessoren weisen RISC-Konzepte oder gar RISC-Kern auf
I für Desktop Prozessoren ist die Wahl der ISA kein ThemaI Code-Kompatibilität ist sehr wichtig!I mit genügend Hardware wird alles schnell ausgeführt
I eingebettete Prozessoren: eindeutige RISC-Orientierung+ kleiner, billiger, weniger Leistungsverbrauch
A. Mäder 17
Universität Hamburg
MIN-FakultätFachbereich Informatik
Computerarchitektur - Befehlssätze / ISA 64-040 Rechnerstrukturen
ISA Design heute
I Restriktionen durch Hardware abgeschwächtI Code-Kompatibilität leichter zu erfüllen
I Emulation in Firm- und HardwareI Intel bewegt sich weg von IA-32
I erlaubt nicht genug ParallelitätI hat IA-64 eingeführt („Intel Architecture 64-bit“)⇒ neuer Befehlssatz mit expliziter Parallelität (EPIC)⇒ 64-bit Wortgrößen (überwinden Adressraumlimits)⇒ benötigt hoch entwickelte Compiler
GrundideeI Operation F kann in Teilschritte zerlegt werdenI jeder Teilschritt fi braucht ähnlich viel ZeitI alle Teilschritte fi können parallel zueinander ausgeführt werdenI Trennung der Pipelinestufen („stage“) durch RegisterI Zeitbedarf für Teilschritt fi � Zugriffszeit auf Register (tco)
Pipelining-KonzeptI Prozess in unabhängige Abschnitte aufteilenI Objekt sequenziell durch diese Abschnitte laufen lassenI zu jedem gegebenen Zeitpunkt werden zahlreiche Objekte
bearbeitetKonsequenzI lässt Vorgänge gleichzeitig ablaufenI „Real-World Pipelines“: Autowaschanlagen
Arithmetische PipelinesI Idee: lange Berechnung in Teilschritte zerlegen
wichtig bei komplizierteren arithmetischen OperationenI die sonst sehr lange dauern (weil ein großes Schaltnetz)I die als Schaltnetz extrem viel Hardwareaufwand erfordernI Beispiele: Multiplikation, Division, Fließkommaoperationen. . .
+ Erhöhung des Durchsatzes, wenn Berechnung mehrfachhintereinander ausgeführt wird
(RISC) ProzessorpipelinesI Idee: die Phasen der von-Neumann Befehlsabarbeitung
Berechnungsbeispiel: Version mit 3-stufiger Pipeline
Reg
Clock
Comb.logic
A
Reg
Comb.logic
B
Reg
Comb.logic
C
100 ps 20 ps 100 ps 20 ps 100 ps 20 ps
Delay = 360 psThroughput = 8.33 GOPS
SystemI Kombinatorische Logik in 3 Blöcke zu je 100 ps aufgeteiltI neue Operation, sobald vorheriger Abschnitt durchlaufen wurde⇒ alle 120 ps neue Operation
I allgemeine Latenzzunahme⇒ 360 ps von Start bis Ende
Vor- und Nachteile+ Pipelining ist für den Programmierer nicht sichtbar!+ höherer Instruktionsdurchsatz ⇒ bessere Performanz− Latenz wird nicht verbessert, bleibt bestenfalls gleich− Pipeline Takt limitiert durch langsamste Pipelinestufe
unausgewogene Pipelinestufen reduzieren den Takt unddamit die Performanz
− zusätzliche Zeiten, um Pipeline zu füllen bzw. zu leeren
Dimensionierung der PipelineI Längere PipelinesI Pipelinestufen in den Einheiten / den ALUs (superskalar)⇒ größeres K wirkt sich direkt auf den Durchsatz aus⇒ weniger Logik zwischen den Registern, höhere TaktfrequenzenI Beispiele
Strukturkonflikt / Structural HazardI mehrere Stufen wollen gleichzeitig auf eine Ressource zugreifenI Beispiel: gleichzeitiger Zugriff auf Speicher Beispiel
⇒ Mehrfachauslegung der betreffenden RessourcenI Harvard-Architektur vermeidet Strukturkonflikt aus BeispielI Multi-Port RegisterI mehrfach vorhandene Busse und Multiplexer. . .
Datenkonflikt / Data HazardI eine Instruktion braucht die Ergebnisse einer vorhergehenden,
diese wird aber noch in der Pipeline bearbeitetI Datenabhängigkeiten der Stufe „Befehl ausführen“ Beispiel
ForwardingI kann Datenabhängigkeiten auflösen, s. BeispielI extra Hardware: „Forwarding-Unit“I Änderungen in der Pipeline SteuerungI neue Datenpfade und Multiplexer
I zusätzliche (Hardware) KontrolleinheitI verschiedene StrategienI in Pipeline werden keine neuen Instruktionen geladenI Hardware erzeugt: Pipelineleerlauf / „pipeline stall“
„Scoreboard“I Hardware Einheit zur zentralen Hazard-Erkennung und
-AuflösungI Verwaltet Instruktionen, benutzte Einheiten und Register
3. Sprungvorhersage / „branch prediction“I Beobachtung: ein Fall tritt häufiger auf:
Schleifendurchlauf, Datenstrukturen durchsuchen etc.I mehrere Vorhersageverfahren; oft miteinander kombiniert+ hohe Trefferquote: bis 90%Statische Sprungvorhersage (softwarebasiert)I Compiler erzeugt extra Bit in Opcode des SprungbefehlsI Methoden: Codeanalyse, Profiling. . .
Dynamische Sprungvorhersage (hardwarebasiert)I Sprünge durch Laufzeitinformation vorhersagen:
Wie oft wurde der Sprung in letzter Zeit ausgeführt?I viele verschiedene Verfahren:
I Schleifen abrollen / „Loop unrolling“I zusätzliche Maßnahme zu allen zuvor skizzierten VerfahrenI bei statische Schleifenbedingung möglichI Compiler iteriert Instruktionen in der Schleife (teilweise)− längerer Code+ Sprünge und Abfragen entfallen+ erzeugt sehr lange Codesequenzen ohne Sprünge⇒ Pipeline kann optimal ausgenutzt werden
I lange Pipelines mit vielen Phasen: Fetch (Prefetch, Predecode),Decode / Register-Renaming, Issue, Dispatch, Execute, Retire(Commit, Complete / Reorder), Write-Back
I je nach Implementation unterschiedlich aufgeteiltI entscheidend für superskalare Architektur sind die Schritte
vor den ALUs: Issue, Dispatch ⇒ out-of-order Ausführungnach -"- : Retire ⇒ in-order Ergebnisse
Reservation Station für jede FunktionseinheitI speichert: initiierte Instruktionen die auf Recheneinheit wartenI –"– zugehörige OperandenI –"– ggf. ZusatzinformationI Instruktion bleibt blockiert, bis alle Parameter bekannt sind und
wird dann an die zugehörige ALU weitergeleitetI Dynamisches Scheduling: zuerst ’67 in IBM360
(Robert Tomasulo)I ForwardingI Registerumbenennung und Reservation Stations
Scoreboard erlaubt das Management mehrererAusführungseinheitenI out-of-order Ausführung von MehrzyklusbefehlenI Auflösung aller Struktur- und Datenkonflikte:
RAW, WAW, WAR
EinschränkungenI single issue (nicht superskalar)I in-order issueI keine Umbenennungen; also Leerzyklen bei WAR- und
WAW-KonfliktenI kein Forwarding, daher Zeitverlust bei RAW-Konflikten
Spezielle Probleme superskalarer Pipelines− weitere Hazard-Möglichkeiten
I die verschiedenen ALUs haben unterschiedliche LatenzzeitenI Befehle „warten“ in den Reservation Stations⇒ Datenabhängigkeiten können sich mit jedem Takt ändern
− Kontrollflussabhängigkeiten: Anzahl der Instruktionen zwischenbedingten Sprüngen limitiert Anzahl parallelisierbarerInstruktion
Superskalar – Interrupts (cont.)I Verfahren ist von der „Art“ des Interrupt abhängig
I Precise-Interrupt: Pipelineaktivitäten komplett BeendenI Imprecise-Interrupt: wird als verzögerter Sprung
(Delayed-Branching) in Pipeline eingebrachtZusätzliche Register speichern Information über Instruktionen diein der Pipeline nicht abgearbeitet werden können (z.B. weil sieden Interrupt ausgelöst haben)
I Definition: Precise-InterruptI Programmzähler (PC) zur Interrupt auslösenden Instruktion
ist bekanntI Alle Instruktionen bis zur PC-Instruktion wurden vollständig
ausgeführtI Keine Instruktion nach der PC-Instruktion wurde ausgeführtI Ausführungszustand der PC-Instruktion ist bekannt
I superskalare Architektur (mehrere ALUs)I CISC-Befehle werden dynamisch in „µOPs“ (1. . . 3) umgesetztI Ausführung der µOPs mit „Out of Order“ Maschine, wenn
I Operanden verfügbar sindI funktionelle Einheit (ALU) frei ist
I Ausführung wird durch „Reservation Stations“ kontrolliertI beobachtet die Datenabhängigkeiten zwischen µOPsI teilt Ressourcen zu
I „Trace“ CacheI ersetzt traditionellen AnweisungscacheI speichert Anweisungen in decodierter Form: Folgen von µOPsI reduziert benötigte Rate für den Anweisungsdecoder