Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
1
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 1
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
RechnerarchitekturVorlesungsbegleitende Unterlagen
WS 2003/2004
Klaus Waldschmidt
Teil 12
Hardwaresystemarchitekturen
- Moderne Mikroprozessorkonzepte
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 2
Ar c h it e c t u r e
Superscalar ArchitectureVLIW
Multithreaded ArchitectureEPIC
CruseoTTA
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
2
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 3
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Parallel architecturesPAs
Data-parallelarchitectures
Function-parallelarchitectures
DPs ILPs
Thread-levelPAs
Instruction-levelPAs
Process-levelPAs
MIMDs
Vector architec-
tures
Asso-ciativeand
neutralarchitec-
tures
TLP
SIMDs Systolicarchitec-
tures
VLIWsEPICTTA
Pipelinedproces-
sors
Super-scalar
proces-sors
Distri-buted
memoryMIMD(multi-
computer)
SharedmemoryMIMD(multi-proces-
sor)
Small scalemulti-
proces-sors
Classification of parallel architectures
Simul-taneous
Multi-threading
SMT
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 4
The types of architecture are established not by architectsbut by society, according to the needs of thedifferent institutions. Society setsthe goal and assigns thearchitects the job offinding the meansof achieving them.
(Ecyclopedia Britannica)
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
3
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 5
Struktur moderner Mikroprozessoren
Memory Hierarchy
FU FU FU L/S RU RU RUDFUIFU
D-Cache
MMU
Class BoxSuperscalar Architectures, VLIW, Multithreaded Architectures, EPIC,
Cruseo,ADARC, TTA
I-Cache
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 6
Superskalare Architekturen
FU FU FU L/S RU RU RUDFUIFU
D-CacheI-Cache
Super-skalar
Wakeup-Logic
Out-of-orderexecution by
dataflow analysis
Select-Logic
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
4
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 7
Superskalare Architekturen
FU FU FU L/S RU RU RUDFUIFU
D-CacheI-Cache
Less complex Wakeup/Select-Logic
Heuristic distribution
ComplexityEffectiveSuperscalar Processor
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 8
Superskalar Pipelining
Program & Data
Data
Retire
Dispatch
Fetch
Decode
Rename
Reservation Stations
Reg. File/D-Cache
FU FU FU ... FU
Reg. File/D-Cache
Complete
Execute
Issue
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
5
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 9
Simultaneous Multithreading (SMT)
Issue
Execute
Complete
Retire
Dispatch
Program & Data
Data
Issue
Execute
Complete
Retire
Dispatch
Program & Data
Data
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 10
Mehrfädige Architekturen
Definitionen
Mehrfädige Architekturen:(Multithreaded Architectures, MTAs)wechseln Fäden, um Latenzzeiten zuverstecken („Latency Hiding“).
Fäden:(Threads) sind leichtgewichtige Prozesse.Ein (schwergewichtiger) Prozess (auchTask genannt) kann mehrere Fäden haben.Ein Faden besteht aus mehreren Befehlen.Die Fäden in einem Prozess teilen sicheinen (virtuellen) Adressraum
Latenzzeit:Wartezeit, die durch Abhängigkeiten innerhalb eines Fadens zwischenEinheiten entsteht.z.B. Speicherlatenzzeit, Netzwerk-latenzzeit.
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
6
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 11
Fadenwechsel-Strategien
Wann sollte ein Fadenwechsel erfolgen?
1. Zwischen Instruktionen:(Instrucion Interleaving) nutzt die Verarbei-tungspipeline am besten aus. Alle Latenz-zeiten können versteckt werden. Ein Faden-wechsel muss sehr schnell sein, und esmüssen ausreichend viele Fäden vorhandensein.
2. Zwischen Blöcken von Instruktionen:Gröbere Granularität, wenige häufige Faden-wechsel. Der Compiler kann die Länge der Blöcke optimieren.
3. Bei nicht erfolgreichen Cachezugriffenversteckt nur Speicherlatenzzeiten. Die Latenzzeit bei einem Cache Miss ist erheblich und nicht vorhersagbar.
4. Bei entfernten Speicherzugriffensetzt voraus, dass der Compiler die ent-fernten Zugriffe bereits markieren kann.Die Granularität ist hier sehr grob, dieHardwareunterstützung kann sehr gering –oder gleich Null sein.
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 12
Simultaneous Multithreading (SMT) Architecture
FU FU FU L/SDFUIFU
D-Cache
Select-Logic
I-Cache
RU RU
out-of-orderexecution by
dataflow analysisWakeup-Logic
Thread1 Thread 2
Thread1 Thread 2
Multiple Wake-up Logic,Multiple Register-Renaming
SMT
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
7
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 13
Tim
e (p
ro c
ycle
s)
Superscalar Multiprocessing SMT
Unutilized slot
Thread 1
Thread 2
Thread 3
Thread 4
Thread 5
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 14
Basic Superscalar Pipeline
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
8
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 15
SMT Pipeline
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 16
Compaq´s Alpha EV8
Goals
• Leadership single streamperformance
• Extra multistream performance withmultithreading- Without major architectural changes- Without significant additional cost
Architecture
• Enhanced out-of-order execution
• 8-wide superscalar
• Large on-chip L2 cache
• Direct RAMBUS interface
• On-chip router for system interconnect
• Glueless, directory-based, ccNUMAfor up to 512-way SMP
• 4-way simultaneous multithreading(SMT)
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
9
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 17
Multiprocessor System Block Diagram
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 18
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Global Memory
SecondaryCache
SecondaryCache
SecondaryCache
SecondaryCache
Pro-cessor
Pro-cessor
Pro-cessor
Pro-cesor
Bus
PrimaryCache
PrimaryCache
PrimaryCache
PrimaryCache
10
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 19
Multiprogrammed Workload
0%
50%
100%
150%
200%
250%
SpecInt SpecFP MixedInt/FP
1T2 T3 T4 T
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 20
Vorgeschichte
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
100x Leistungssteigerung in den letzten 10 Jahren:
• 20 x von Prozess- und Schaltkreistechnologie• 4 x von Architektur• 1,4 x von Compilertechnologie
Jetzt wird Hardware-komplexität ein Problem;Der Compiler soll mehr Verantwortung übernehmen.
(Quelle: Intel)
11
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 21
Compiler
FU FU FU FU
CPU
VLIW
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 22
VLIW �Very Long Instruction Word (128 bis 1024 bit)
• Sequentieller Strom breiter Instruktionswörter
• Statisches Scheduling der Instruktionen durch den Compiler
• Mehr als eine Instruktion kann zur Taktzeit zur Ausführung gebracht werden. Nur „in order issue“ ist möglich.
• Die Hardware für das Instruktionsfenster ist deutlich einfacher,da das Scheduling zur Laufzeit entfällt.
• Die Anzahl von Instruktionen in einem VLIW-Wort ist fest.
• VLIW ist eine Architektur-Massnahme während Superskalaritäteine Mikroarchitekturtechnik ist
• Befehle in einem VLIW-Wort müssen unabhängig sein.Dies begrenzt die Codedichte.
• Verwendet werden mikroprogrammierte Steuerwerke.
• VLIW-Prozessoren können schlecht auf dynamische Ereignisse reagieren.
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
12
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 23
FP-ALU I-ALU LOAD/ AdresseBefehl Befehl STORE
FP-ALU ALU Datenspeicher
Multiport-Registerfile
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
VLIW-Maschinenbefehl
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 24
VLIW architecture
I1 I2 I3 In
CU
Instruction stream
Operands& Results
Register unit
Interconnectionunit
Functionunits
Controlunit
Very longinstruction word
Memory unit
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
FU FU FU FU
13
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 25
VLIW-Architekturen
FU FU FU L/S RU RU RUDFUIFU
D-CacheI-Cache
VLI W
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 26
Warum nicht einfach VLIW?
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
1. VLIW ist nicht skalierbar ohne neuzu compilieren.
2. VLIW leidet unterSprungbefehlen.
3. VLIW leidet unter langen Speicherlatenzen.
Diese Probleme haben alle CPUs heutzutage!
14
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 27
Crusoe Transmeta
• Die Crusoe CPUs wurden von der FirmaTransmeta entwickelt.
• Die Crusoe-Lösung = VLIWHardware-Kern + Software-Aussenschale
• „Code-Morphing“ Software wandeltIntel x86 Befehle in VLIW um –zur Laufzeit!
• Ziel: schnelle CPUs mit geringer Leistungsaufnahme, aus herkömmlicherCMOS-Technik gemacht.
• Ungefähr 75 % der Logik-Transistorenwerden gespart.
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 28
Klassisches VLIW
Ein klassisches VLIW steht in einer 1 : 1 Beziehung zur Architektur
Neue Architektur � Neues VLIW � Neucompilierung
Very Long Instruction Word
Integer Integer Integer Integer Floating Point Floating Point BranchSubword Subword Subword Subword Subword Subword Subword
Integer Integer Integer IntegerFloating
PointFloating
PointBranch
Hardware
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
15
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 29
Hardware und Software Hybrid
„Transmeta´s Code Morphing technologychanges the entire approach to designingmicroprocessors. By demonstrating thatpractical microprocessors can be implemen-ted as hardware-software hybrids, Transmetahas dramatically expanded the design spacethat microprocessor designers can explorefor optimum solutions.
Microprocessor development teams maynow enlist software experts and expertise, working largely in parallel with hardwareengineers to bring products to market faster.
Upgrades to the software portion of a microprocessor can be rolled out inde-pendently for the chip. Finally, decoup-ling the hardware design from the systemand application software that use it freeshardware designers to evolve and eventually replace their designs withoutperturbing legacy software.“
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Alexander Klaiber,The Technology Behind Crusoe Processors
January 2000
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 30
Binärcode-Übersetzung durch Hardwarebei Superskalaren Prozessoren
SuperskalarDecode
Units
TranslateUnits
DispatchUnits
FunctionalUnits
In-OrderRetireUnit
„The x86 isn´t all that complex – it justdoesn´t make a lot of sense.“
Mike Johnson,Leader of 80x86 Design at AMD (1994)
Deswegen gibt es seit der Pentium II-Familie Binärcode-Übersetzung durch Hardware.
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
16
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 31
Compiler
Code Morphing Software
FU FU FU FUCPU
ISA
ISA
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 32
VLIW Hardware
FADD ADD LD BRCC
• Bei Intel heißt ein VLIW ein„Bundle“, bei Transmeta ein Molekül.
• Es gibt bis zu 4 Atome (Befehle)pro Molekül.
• Crusoe´s VLIW-Molekül werdenIn-Order ausgeführt;
• Die ursprünglichen x86-Befehlewerden Out-of-Order ausgeführt.
• Verschiedene Crusoe CPUs ver-wenden verschiedene Befehlssätze!
Floating-PointUnit
IntegerALU#0
Load/StoreUnit
BranchUnit
128-Bit-Moleküle
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
17
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 33
Crusoe Architecture
FU FU FU L/S RU RU RUDFUIFU
D-CacheTranslator - Translations - x86 Instructions
VLI WPhase 1:On instruction cache miss,x86 code translatedinto VLIWcode(code morphing)
Crusoe
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 34
Crusoe Architecture
FU FU FU L/S RU RU RUDFUIFU
D-Cache
VLI WPhase 2:
Execute translationuntil next
instruction cache miss
Crusoe
Translator - Translations - x86 Instructions
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
18
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 35
Zusammenfassung der Crusoe-Architektur
• Crusoe ist eine CPU-Architektur vonTransmeta, es gibt 3 CPUs auf dem Markt;
• Hauptziel: Geringe Leistungsaufnahme.
• Ein Crusoe CPU ist ein VLIW-Hardwaremit einer mitgelieferten Code-Über-setzungs(Code Morphing) Software;
• Code-Übersetzungen werden imÜbersetzungs-Cache gespeichert, durchCache-Logik gesteuert – Übersetzung „on-demand“.
• Crusoe VLIW Hardware unterstütztCode-Morphing durch:- Exception Handling durch Shadow
Registers, Gated Store Buffer;- Alias Hardware- Schreibgeschützter
x86-Instruktionsspeicher
• Crusoe Software unterstützt:- Spekulative Lade- und Speicher-Befehle- Begrenzte Predication („Select“);- Sprung-Vorhersage durch Code-
Instrumentation;
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 36
EPIC � Explicitly Parallel Instruction Computing
EPIC Semantik ist explizit parallel
add r 1 = r 2 + r 3 , ; kein Stop-Zeichensub r 4 = r 11 – r 2 ; ; Stop-Zeichen!
sub r 5 = r 1 – r 10 , ; kein Stop-Zeichensh1 r 14 = r 4 << r 8 …
Abhängigkeit
Abhängigkeit
• Compiler erzeugt Instruction Stream mitStop-Zeichen;
• Die Hardware darf alle Befehle zwischenStop-Zeichen parallel ausführen;
� Skalierbarkeit nach oben und nach unten;
� Etwas Parallelismus geht verloren!
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
19
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 37
Bundles und Hardware
In VLIW bildet der Compiler die VLIWs auf die FEs ab.
M F I M I B M I I M I B
BundleStream
fromI-Cache
Dispersal WindowFirst Bundle Second Bundle
DispersedInstructions
M0 M1 I1 B2B1B0F1F0I0
In EPIC bildet die CPU die Bundles auf die FEs ab.
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 38
M I I M I B M I B
BundleStream
fromI-Cache
DispersedInstructions
M0 M1 I1 B2B1B0F1F0I0
M BI M I BBundleStream
fromI-Cache
DispersedInstructions
M0 M1 I1 B2B1B0F1F0I0
Bundles und Hardware II
Kann ein Bundle nicht vollständig abgebildet werden, ….
… kommt nur ein neues Bundle hinzu.
M I I
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
20
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 39
EPIC Architecture(Explicitly Parallel Instruction Computing)
FU FU FU L/S RU RU RUDFUIFU
D-CacheI-Cache
VLI W
... Instruction Stream ...
Fetch0, 1 or 2 bundles,each containing
3 instructions
Compiler-identifiedgroups of independent
instructions
9 8 7 6 5 4 3 2 1
EPIC
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 40
EPIC Architecture
FU FU FU L/S RU RU RUDFUIFU
D-CacheI-Cache
VLIW
DynamicIn-OrderMapping of Instructions
onto Hardware9 8 7 6 5 4 3 2 1
EPIC
... Instruction Stream ...
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
21
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 41
EPIC Architecture
FU FU FU L/S RU RU RUDFUIFU
D-CacheI-Cache
VLIW
9 8 7 6 5 4101112
EPIC
3 2 1
... Instruction Stream ...
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 42
EPIC (IA-64)
Die IA-64 Architektur, die auf der EPIC (Explicitly Parallel Instruction Computing)Philosophie basiert, zeichnet sich im Wesentlichen durch drei Aspekte aus:
• Expliziter Parallelismus
ILP (instruction level parallelism) wird explizit im Maschinencode sichtbar ge-macht. Der Compiler ermittelt den Graddes ILP und teilt das Scheduling-Ergeb-nis der Hardware zur Ausführung mit.
• Eigenschaften zur Erhöhung des ILP
Die beiden wichtigsten Eigenschaften, die IA-64 bereitstellt, sind das predicationmodel und control speculation.
• Ressourcen zur parallelen Ausführung
Die IA-64 Architektur stellt wesentlich mehr Register als vergleichbare superskalareProzessoren zur Verfügung:128 Integer-Register, 128 Floating-point-Register und 64 Prädikats-Register.Die effiziente Nutzung mehrerer Funktions-einheiten erfordert viele Register. Ein IA-64-Bundle enthält jeweils drei 41bit-Befehle. Einzusätzliches Template eröffnet die Möglich-keit, explizit die Abhängigkeiten der Befehleauszudrücken. Außerdem erlaubt es dem
Compiler, verschiedene unabhängige In-struktionen über verschiedene Bundles zugruppieren.
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
22
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 43
Template5 Bit
Befehl41 Bit
Befehl41 Bit
Befehl41 Bit
128 Bit VLIW
Template:
Branch ;;FPMemory11110
BranchFPMemory11101
IntegerInteger ;;Memory00010
Integer ;;IntegerMemory00001
IntegerIntegerMemory00000
3. Befehl2. Befehl1. BefehlTemplate
… … … …
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 44
Einsatz von Befehlsprädikaten(Predication model)
In der IA-64 Architektur wird das „pre-dication model“ unterstützt, in dem derCompiler den Instruktionen ein Prädikatanfügen kann. Prädikate sind einfachetags, die eine bedingte Ausführung vonInstruktionen erlauben und zwar ab-hängig vom Wert des Prädikats. DerWert entspricht dem Ergebnis einer Vergleichsoperation (conditionalstatement).
Eine Instruktion wird normal ausgeführt, wenn der Wert des Prädikats wahr ist. Ist der Wert des Prädikats falsch, schreibtdie Instruktion ihr Ergebnis nicht in das Register oder den Speicher, auch wenndie Instruktion bereits zugeordnet wurde.
Dieses einfache Verfahren des „predicationmodel“ ist in der Lage, Verzweigungen zu be-seitigen, indem diese parallelisiert werden. Damit sinken auch die Performance-Verluste (penalties), die Verzweigungen in VLIW-Archi-tekturen verursachen können.
Das folgende Beispiel macht deutlich, wie ein herkömmlicher Compiler den C-Code einer if-then-else Anweisung in vier Basisblöcke auflöst. Der Prozessor muss die Instruktionen aller vier Basisblöcke seriell ausführen und somit sind derartige Verzweigungen starke Hemmnisse für die Instruktions-Parallelität auf VLIW-Ebene.
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
23
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 45
In der IA-64 Architektur werden die Prädikate durch die „compare“ Instruktion erzeugt. Der “then“ Pfad wird ausgeführt, wenn das Vergleichs-resultat wahr ist. Dies wird durch p1 markiert.Der “else“ Pfad wird ausgeführt, wenn das Ver-gleichsergebnis falsch ist. Dies wird durch p2 markiert.
p1 und p2 schließen sich gegenseitig aus (mutually exclusive), also nur eines von beiden kann zu gegebener Zeit wahr sein.
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 46
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Traditional Architecture EPIC Architecture
i nsti nst...p1, p2 � cmp ( x==y)j ump of p2
i nst 1i nst 2...j ump
i nst 3i nst 4...
i nsti nst...
if
then
else
if
then
else
i nsti nst
.
.
.
.p1, p2 � cmp ( a==b)
( p1) i nst 1( p2) i nst 2
.
.
.
( p2) i nst 3( p2) i nst 4
.
.
.
i nsti nst...
24
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 47
Control speculation
In der IA-64 Architektur kann der Compilerein spekulatives Laden ausführen, um dieSpeicherlatenz zu verringern. Dadurch wirdautomatisch auch der ILP erhöht. Dieser Vorgang wird als "hoisting" bezeichnet, in dem die Ausführung des Ladebefehls vor den Verzweigungsbefehl gehoben wird.
Hierzu wird ein neuer (speculative load (ld.s))Befehl eingeführt, der den Speicher-fetchdurchführt und eine Ausnahmeerkennung (exeption detection) veranlasst.
Eine check.s Instruktion initiiert dann dieAusnahmebehandlung. Dieser Vorgang läuft folgendermaßen ab:
Wenn ld.s eine Ausnahme erkennt, wirddas Zielregister mit einem token-bit mar-kiert. Die check.s Instruktion verzweigtzu der entsprechenden Interrupt-Routinezur Behandlung der Ausnahme, wenn das token-bit für dieses Register gesetzt ist. Durch den speculative load-Mecha-nismus wird die Ausführung eines Lade-befehls ermöglicht, bevor das Programmdie Gültigkeit der Adresse überprüft.
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 48
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Traditional Architectrure EPIC Architecture
.
.
.i nsti nst...j ump...l oadi nst...
.
.l d. si nsti nst...j ump...check. si nst...
Hoi
stin
g
Barrier
25
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 49
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
0
1
2
3
4
5
6
7
8
Co
mp
Eq
nt
Esp
r
Gcc S
c
Su
nb
Su
per
Tek
tr
TeX
Th
is
Tyc
ho
Xlis
p
Yac
c
Ave
rag
e
BB size BB expansion
Teilweise Prädikatierung des Instruktionssatzes
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 50
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
0
2
4
6
8
10
12
14
16
Co
mp
Eq
nt
Esp
r
Gcc S
c
Su
nb
Su
per
Tek
tr
TeX
Th
is
Tyc
ho
Xlis
p
Yac
c
Ave
rag
e
BB size BB expansion
Prädikatierung des gesamten Instruktionssatzes
26
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 51
EPIC ����VLIW
VLIW EPIC
�
VLIW ist nicht skalierbar,ohne neu zu kompilieren.
�
VLIW leidet unterSprungbefehlen
�
VLIW leidet unter langenSpeicherlatenzen
EPIC verwendet expliziteStopzeichen in der Befehlscodierung
EPIC verwendet Predicationund spekulative Ausführungen
EPIC verwendet spekulative Ladebefehle
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 52
Vergleich
�Flexibilität
�Hardware-aufwand
�Compiler-aufwand
F a z i t
EPIC ist einKompromiß
Pipeline < Superscalar < EPIC < VLIW
Pipeline < VLIW < EPIC < Superscalar
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
27
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 53
Itanium (IA-64)
� ISA (instruction set architecture): Befehlsformat
- 41 Bit- Instruktionen(Opcode, 6 Bit Predication, 2x 7 BitRegisteradressen, 7 Bit Zielregister-adresse, Spezialfelder für Integer-und Floating-Point-Arithmetik)
- 128 64 Bit General-Purpose-Register- 128 80 Bit Floating-Point-Register- 64 1 Bit Predication-Register
� Instruktionen werden zu Bundles zu-sammengefasst resp. werden in Bundles kodiert
- 1 Bundle = 128 Bit LIW(3 Befehle + Template )
� Keine NOOPs zum Auffüllen notwendig
� Bundles korrespondieren mit FU-Satz
Eine neue „Instruction group“ beginnt nacheiner "Stop"-Information, die im Templatekodiert ist. Somit können „Instruction groups“eine variable Größe besitzen.
Wichtig: Bundles und "Instruction groups" sind nicht das gleiche.
Die Instruktionen innerhalb einer „Instructiongroup“ können parallel ausgeführt werden, d.h. Instruktionen innerhalb einer „Instructiongroup“ dürfen keine RAW- und WAW-Ab-hängigkeiten aufweisen.
Wieviele Instruktionen in einer "Instructiongroup" parallel ausgeführt werden, hängt vonden verfügbaren Ressourcen (Anzahl und Artder Funktionseinheiten) ab.
� Instruktionen gehören zu einer „Instruction group“
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 54
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Instruktionsparallelität
Superskalar
• Skalierbarkeit• (Super-)Pipelining• Spekulation• Funktionseinheiten für Integer,
Floatingpoint, Load-Store, Branch• Laufzeit-Parallelität• Impliziter Parallelismus• out of order – issue
- Renaming- Reservation Stations- Scoreboarding
• SMT: eigener Registersatz / threadeigener Fetch-Mechanismus/thread
EPIC (VLIW)
• Skalierbarkeit• (Super-)Pipelining• Spekulation• Funktionseinheiten für Integer,
Floating-point, Load-Store, Branch• Compiler-Parallelität• Expliziter Parallelismus• in order – issue
- Einsatz von Befehlsprädikaten
• Große Zahl an Registern (teilweise softwarekonfigurierbar)
28
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 55
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
L/S FU1 FU2
(Daten) (Instruktionen)
Register File
Verbindungs-Netzwerk
Funktions-einheiten
I-Cache undD-Cache
Hauptspeicher
NC
U
Konfigurierungs-muster
....
....
Transport-Triggered-Architecture (TTA)Modell einer TTA-Maschine
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 56
Classbox einer Transport-Triggered-Architecture
FU FU FU L S RU RUDFUIFU
D-CacheI-Cache
Doit
TTA
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
29
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 57
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
TTAs weisen die folgenden vorteilhaften Eigenschaften auf:
• Modularität• Flexibilität• Skalierbarkeit• Hardware-Effizienz
Das Verbindungsnetzwerk benötigt nicht die vollständige Konnektivität, da Punkt zu Punkt-Verbindungen möglich sind.
Die Anzahl der Zyklen für die Transport-bewegung (moves) wird minimiert, da kein runtime matching zu erfolgen hat. Der NCU stellt den Netzwerk-Controller dar und übernimmt praktisch das Routingdes Netzwerkes.
Eine TTA-Instruktion hat damit das folgende Format:
Bus-1 field Bus-2 field Bus-M field
i src dst i src dst i src dst
Jedes Feld spezifiziert eine „move“ Operation von der Quelle zum Ziel. Das i-bit unterschei-det zwischen Immediate und Register-Spezifikation.
z.B. add r3, r2, r1 => r1 � 01 addr2 � 02 add
radd � r3
Eine 3-Adress-Operation bedeutet drei Bewegungen
01add, 02add: Operandenregister des Addierersradd: Ergebnisregister des Addierers
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 58
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Associative-Dataflow Architecture (ADARC)Modell einer ADARC-Maschine
FU
CU
FU
CU
FU
CU
FU
CU
I1 I2 I3 In
Associative inter-connection unit
Processingunits
n instructionstream
n localmemory units
30
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 59
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
The ADARC Architecture
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 60
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
31
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 61
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 62
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
COMPARE
SER/PAR
RESULT_NAME
OP_INPUT
OP_NAME
32
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 63
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Network Hardware
Rechnerarchitektur, WS 2003/2004Teil 12 Hardwaresystemarchitektur 2Seite 64
Johann Wolfgang Goethe-UniversitätTechnische InformatikKlaus Waldschmidt ©
Applications
ADARC as a Target-Architecture for Embedded Systems