Zusammenfassung

Bsp:

• kompletter Rechner
• Blöcke mit angepasster Leistungsfähigkeit
• Kosten, problemangepasste Varianten entsprechend der Anwendung

• Datenbreite 8 Bit (größere Daten zusammengesetzt)
• wenig leistungsfähiger Befehlssatz aber Bitbefehle
• Adressraum 16 Bit
• geringe Taktfrequenz
• Oszillator: Taktgenrator mit externem Quarz
• Zeitbegrenzung: Zeitbezug für Timer

• Datenspeicher
  • klein, adressierung wie Register
  • teilweise vordefiniert für andere Funktionen
• Programmspeicher
  • kleinere adressiebarer Bereicht
  • typ ROM (EEPROM)
• Daten- und Programmspeicher extern über Speichererweiterungsinterface
  • im Adressraum der Proz
  • Anwendung reduziert E/A Anschlüsse

Einchip Controller

• E/A
  • 4x 8 Bit parallele E/A
  • normale Byte E/A
  • auch bitweise
  • synchronisiert (2 draht Handshake) → RDY und DAV aus anderen Ports
• Speichererweiterung und spez. E/A benutzt i.a. Ports oder Bits aus pralleler E/A
• 3 Timer: Zeitgeber / Zähler
• 1x serielle E/A: USART
  • Übertragunsrate mit Timer einstellbar
• Interrupt Behandlung / Auslösung
  • Timer
  • serieller Kanal
  • Syncsignale der parallelen Ports
  • einzelne parallel Biteingänge
• E/A ist im Datenregisterbereich
• E/A → programmierbar, Steuerregister im Datenregisterbereich

Bsp: Wage + Preisrechner

• Kern mit 16 Bit Datenformat
• interner ROM in verschiedenen Varianten
• interner RAM in verschiedenen Varianten
• Speichererweiterung durch spezielle Ports mögl → externe Buscontroller
• Taktgeber wie 2.1
• E/A
  • 4 universelle 16 Bit parallel digitale E/A
  • 2 spezielle (10 / 2 Bits)
  • 2 USART
  • 5 Universaltimer
  • ADC mit 10 mögl Eingängen (Zeitmultiplex) (Port 5 kann analoge Spannungen durchschalten)
• Capcom
  • 2x Timer
  • 16x Register mit digitalem Komparator

• Einchipkozept
• Typenvielfalt
• → µController und DSP Vorlesung

• in CISC verwendet
• Teil des Steuerwerks (Ablaufsteuerung)
• µOps

• Vorteile:
  • Realisierung einfacher und komplexer Befehle mit den selben Mitteln
  • übersichtliche Befehlsimplementierung
  • evtl. ladbarer Mikrocode
• Nachteil:
  • für jeden Befehl mehrere Schritte nötig

• IBM 360
• Z80
• X86
• i-432

• Alpha
• IA64
• Sparc
• PowerPC

aktuell:

• extern CISC, intern RISC

• Durchsatz: Befehle pro Zeit (bei gefüllter Pipeline)
• Latenz: Zeitaufwand für einen Befehl

• Sprungbefehle
  • Adressbereitstellung in der Dekodiephase
  • Waretphase (delayslots)
  • statische Vorhersage
  • dynamische Vorhersage
    • branchprediction buffer
    • branchtarget buffer
    • branchtarget cache

• Datenabhängigkeiten
  • Bypass, Operandforwarding

bef 1
.
.
.
JMP m1
.
.
.
bef 2
bef 3 
bef 4

bef 2 und bef 3: Warteplätze

• 1 bit Vorhersage

• 2 bit Vorhersage

IF: instruction first IS: instruction second RF: register fetch, instruction decode EX: execution DF: data first DS: data second TC: tag check WB: write back

• Problem: bei komplexeren Ausführungen dominiert die Ausführungsphase das Zeitverhalten
• → mehrere Ausführungseinheiten (evtl spezialisiert)

Bsp: 4 stufige sequenzielle Befehlsfole BL/BD wie normale Pipeline

• zusätzlich BD steuert aufgrund Befehlscode DD → Ex-Einheiten. verlange passenden freie Einheit
• nach jeder Ex Einheit folgt parallele writeback Einheit
• WB muss unter Einhaltung der Befehle zurückschreiben
• Problem: Befehlsdecoder kann komplex werden
  • → 2 stufige decodierung
    • Vordecodierung in Befehlslesephase zur Aufteilung der Befehle
    • parallel spezielle Befehlsdecodierung je Ex-Einheit zur eigentlichen Befehldecodierung

• Problem: alles parallel außer BL (zeitlicher Engpass)
• → BL auch parallel (soviel gleichzeitig lesen, wie Ex-Einheiten da sind)
• Bsp: 4 Ex-Einheiten ein Befehslswort hat parallel 4 Befehle
  • 4x BL
  • 4x BD
  • 4x EX
  • 4x WB

• zu lösende Probleme
  • Bef müssen im Speicher so stehen, dass sie bei BL zu den passenen Ex-Einheiten kommen
  • Compiler muss Befehl verzögern falls aktuell zu wenig passenden Ex-Einheiten
  • Compiler muss NOP ergänzen falls aktuell keine Befehle für keine Ex-Einheit
  • Compiler benötigt Datenanalyse um Befehle parallel abzuarbeiten, die untereinander Datenabhängig sind (evtl verzögern/umsortieren)

• theoretisch leistungsfähigstens Mikroparallel Konzept
• maximale Parallelität bei vergleichsweise einfacher Logik
• komplexer Compiler
• sehr spezieller Maschinencode
• sehr breiter Befehlsbus
• gut nur bei gleicher Ausführungszeit aller Ex-Einheiten

• Grundidee:
  • Befehle kommen sequenziell vom Speicher
  • bei freier Ex-Einheit sofort belegt
  • bei belegten benötigten Ex-Einheiten werden Befehle gepuffert und nachfolgende werden vorgeholt
• umsortieren entsprechend der freien Ex-Einheiten
• WB wie in BL

• Probleme
  • Datenabhänigkeiten
  • Befehle, die Daten von anderen verzögerten Befehlen brauchen dürfen nicht vorgezogen werden

• Ziel: Prozessor- und Speicherzugriff mit angepasstem Zeitverbrauch
• technische Parameter erhöhen
  • Prozessortakt
  • Speicherzugriffszeit

• beziehen sich auf einzelne Zugriffe / Zugriffsfolgen
• → Adresspipelining

<Addr1> <Daten1>
        <Addr2> <Daten2>

• Nutzung von Speicherbänken

• Prozessor greift nie auf Hauptspeicher bei Speicherzugriffen zu sonder nutzt cachelogik

• “Tag” dient dem Adressvergleich

• Vergleich mit kompletter HS Adresse
• + alle Datenworte im Cache unabhängig voneinander
• - aufwendiger Adressvergleich (langsamer und aufwendige HW)

• Teil der Adresse
• → Tag k-Bit, n Bit Adresswort → 1 Tag = 2^(n-k) mögliche Adressen, davon nur 1 gleichzeitig möglich
• + weniger aufwendiger Adressvergleich
• - mit einer höherwertigen Tag-Adresse werden andere blockiert
  • Ausweg: Tag adressiert ganzen Block und dieser wird in Cache blockiert
• Cacheprobleme bei geänderter Grundarchitektur

P1	P2
|	|
C1	C2
|	|
---------
---------

   HS (gemeinsamer)

• Kopien in allen Caches müssen zu allen Zeiten gleich sein → geeignetes Protokoll

Princeton mit Cache

• 4.100 (ohne E/A)
• Befehle und Daten im gleichen Cache

Havard mit Cache

• 4.120
• Befehle und Daten in getrennten Caches + HS

Havard / Princeton Mischform

• Befehle und Daten in getrennten Caches aber gemeinsamer HS

Speicherverwaltung (Übersetzung logisch → physisch Adressen)

• Havard + gem
  • getrennte Speicherverwaltung (Befehle + Daten)
  • vor Cache

• on demand
• pre demand, vor dem Bedarf mittels Warscheinlichkeit → Laden immernur wenn ein MISS erfolgt

• bei direct mapped nicht notwendig
• bei n-way-cache n-fache Entscheidung
• bei vollassz. cache volle Entscheidung über zu ersetzende Zellen
  • LRU: die Zelle, die am längsten keinen Hit mehr hatte ersetzen
  • pseudo LRU: nur für kurz zurückliegende Ereignisse Überblick bewahren

write through

• CPU muss auf Arbeitsspeicher warten → kein Vorteil durch cache

write back

• Phase 1 cache immer aktueller als RAM
• Phase 2 Controller aktualisiert RAM (CPU unabhängig)
• → dirty bit um bei Ersetzungsstrategie Zellen auszuschliessen deren Wert noch nicht zum Hauptspeicher zurückgeschrieben wurde (Vermeidung von Verdrängung)

snooping

• Controller: beobachten der Zugriffe fremder Master auf den eigenen cache

• Konsistenz: Übereinstimmung cache Speicher
• Kohärenz: Übereinstimmung zwischen verschiedenen caches mittels snooping und MESI-Protokol

• welche Architekturmerkmale sind realisiert
• PentiumPro
  • gem. Havard L1 Daten/Befehle

RISC Architektur CISC Ergänzung über Mikroprogrammierung

• complex instruction decoder
  • Erkennung der CISC Befehle + Start des zugehörigen Mikroprogramms
• microcode sequencer
  • steuert Abfolge des entsprechenden Mikroprogramms
• Mikroprogramm: besteht aus CISC Befehlen

skalare Architektur

• mehrere instruction decoder
• mehrere Ausführungseinheiten
  • 2x Int “normale Befehle”
  • 2x Float
  • 1x Meminterface unit Datenspeicher Zugriffe über L1 Datencache

Befehlspipeline

• instruction cache unit (greift über instruction cache auf Befehle zu)

• branch prediction
• über
• out-of-order Execution

• retirement register
• register renaming

weitere Beispiele

• Verkaufsargument
• reicht Leistung für gewünschte Funktion?
• Preiswert
• Softwaretechnik

• Takt erhöhen
• bessere Architektur

• Arbeit entspricht den ausgeführten Befehlen
• Notwendig: richtige Befehlshäufigkeit → statistische Ermittlung über viele Programme
• Ausführungszeit eines Befehls (Problem: Pipeline)

L = 1/T (Taktzykluszeit in ns)
T = summe(pi * ti)

• MIPS - million instructions per sencond

L[MIPS] = Befehlsanzahl/Zeit in µs
L[MIPS] = f[MHz]/CPI
CPI = Taktanzahl/Befehlsanzahl clocks per instruction

• Problem: exakte Berücksichtigung der modernen Architekturmerkmale nicht möglich
  • Deshalb: Relative MIPS (Vergleichsmaschine festlegen)
  • Klassische Referenzmaschine: VAX 11/7 80 („1-MIPS-Maschine“)

Lrel = Lref*(refZeit/aktZeit)

• L [MFLOPS] wie L [MIPS] aber MFLOPS million floatingpoint operations per second

Lgk[MFLOPS]=Anzahl GK-Befehle/Zeit in µs (bei GFLOPS in ns)

• wieviel Teit braucht Rechner für konkrete Funktionalität (Programm)
• Einflüsse
  • E/A Architektur
  • Compiler, Laufzeitbibliotheken
  • gewählte Beschreibung der Funktion

→ Test mit Benchmarkprogrammen

• Quellprogramm
  • Compiler, OS wird mitgetestet
  • für verschiedene Umgebungen nutzbar
  • → verschiedene Umgebungen vergleichbar

Auswahle bzw Systhese von Benchmarkprogrammen

• Prozessor / Speicher Benchmark
  • Codestücke ohne OS
  • → Maschinenprogramm
    • Maschinenbefehl entspricht pi Auftreten von L Berechnung
  • → MIPS Berechnung
• Systembenchmark
  • Codestücke mit E/A und OS Funktionen
• Sammlung von relativ großen Programmen aus veschiedenen Anwendungsklassen
  • Physik, Robotik, Simulation, Numerik, Tabellenkalkulation

SIMD

• 1 Befehl auf n Datenelemente

MISD

• n Befehle wirken auf 1 Datenelement

MIMD

• wesentliche Parallelrechner

• CPUs über gemeinsamen Speicher verbunden
• CPUs über Multimaster Bus verbunden

• z.B. serielle / parallele E/A
• LAN, WAN