lOMoARcPSD|4653659

ERA - Zusammenfassung Einführung in die

Rechnerarchitektur
Einführung in die Rechnerarchitektur (Technische Universität München)

StuDocu wird von keiner Universität gesponsert oder unterstützt.

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)
 lOMoARcPSD|4653659

Adressierungsarten bei Befehlen

(x86 allows all the following except nr. 1, but that’s stupid)
Unmittelbar:
- inc 3
Register Addressierung:
- inc eax

Speicheradressierung:
Adresse wird zur Laufzeit berechnet (so ​not​ mov [0x3245], 3) → Iteration for example

Direkte Addressierung:
- inc [0x3245]
Register Indirekte Add.:
- inc [eax]
Based mode:
- mov dx, [ebx+12]
Based indexed mode:
- mov dx, [ebx+ecx]
Based indexed mode w displacement:
- mov dx, [ebx+ecx + 8]
Based indexed mode w displacement and scaling:
- mov dx, [ebx+ecx*4 + 8]
Speicherindirekte Zugriffe:
- Address is a pointer to another object (e.g. linked list)

CISC vs. RISC

CISC RISC

General: General:
- Variable Befehlslänge (verschiedene - Konstante Befehlslänge
Arten von Adresskodierung) -

PROS: PROS:
- Einfache Programmierung - Effizient
- Weniger Speicherbedarf - Schnell zu dekodieren
- Durch Mikroprogramme realisiert - Durch feste Verdrahtung realisiert

CONS: CONS:

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

- Komplexere Dekodierung - Schwieriger zu programmieren

- Redundanz (manche Teile vom Befehl - Kein Platz fuer zB lange Adresse im
ungenutzt) Befehl
- Probleme mit Speicherverwaltung - Unflexibel

Adressformate (So types of operands

and shit)

Nulladressform (Kellermaschine):
- Keine explizite Operandenspezifikation
- JVM
Einadressform (Akkumulatormaschine):
- Ein Operand (Ergebnis im akkumulator immer abgelegt und damit
weitergemacht) (Shit because unflexible and need to write and load AC
constantly)
- Von-Neumann-Entwurf, fruehe 8-Bit Prozessoren
Zweiadressform (Registermaschine):
- Ergebnis überschreibt ersten Operanden (meistens Register-Speicher-Modell,
also höchstens ein operand vom Speicher)
- IA-32
Dreiadressform (Reg.-Reg.-modell/ Speicher-Speicher-Modell):
- We can say where to store the answer
- Speicher speicher means tons of speicherzugriffe and befehle need lotsa storage
- Register-register not (since it’s not adresses, so almost all ​RISC ​use this)

IA-32
Aufrufkonvention:
- Caller speichert Variablen + Params
auf dem Stack
- Call pushed BZ (so return address in
this case)
- EBP ist die Basis vom Stack fürs
Unterprogramm
- ESP zeigt wo der Stack grad ist
- Aufrufer räumt Stack auf

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

- Little endian
- Wichtig: Kompatibilität in beide Richtungen
- Datentypen (Byte, word, dword, qword [8-64 bit])
- Register( general purpose vs single purpose) (aber eher wenige)
- Statusregister
- Adressierungsart(everything above, so pretty complex)
- Befehlsform(1-15 Byte)
- Parameter aufm Stack

ARM v8:
- RISC (32 bit pro Befehl → Nicht jede Konstante kann in Befehl, müssen mit aus
Pool oder mit shifts erstellt werden, nur relative Sprungadressen möglich)
- Register-register maschine
- LOAD STORE fuer Speicher, sachen kann man nur in Registern tun
- Register indirekte Adressierung mit 12 bit oder Register Offset
- Viel mehr Register, 64 bit → Register Parameter

Interrupts, Traps, Exceptions

Merkmale von allen:
- Signal wird am Ende vom Befehlszyklus abgefragt. Wenn da, Sichern vom
Befehlszähler, sprung zu interrupt handler/ exception vektor tabelle
*​Betriebssystem hat hier Kontrolle*​, zurück zum programm wenn handler
fertig ist

Interrupt: Erlaubt Reaktion auf externe Ereignisse

- Async, normal
Trap, Exception:
- Sync, real problem

Mehrbenutzersystem
System Modus:
- Kann alles, fuer Betriebssystem, soviel Speicher wie er will

Benutzermodus:
- Kein Zugriff auf I/O, kein Zugriff auf Konfigurationsregister, muss Speicher vom
OS anfragen

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

Wechsel:
- System -> Benutzer:​ ​Schreiben auf ein Kontrollregister/IRET
- Benutzer -> System: ​Muss kontrollierter sein, spezielle Befehle: “Trap/System
Call”
- Sichert Rückadresse, springt an bestimmte adresse, schaltet
Systemmodus ein, fuehrt code durch, springt zurück -> Sichert das nicht
jeder Code ausgeführt werden kann

Prozess = Heap + Programm + Kontext + Stack

Betriebssystem wechselt zwischen ihnen mit Interrupts

Nicht so​: Nicht so: SO: ​Virtueller

Jeder kann Ineffizient abgeschlossener
auf alles e Speicher für jeden
schreiben Speicher Prozess,
(inklusive nutzung Prozessor rechnet
OS) und virtuelle Adressen
sehen, der Prozesse in
Ineffizienter physikalische um
Speicher

Mit Memory management unit

Virtuelle Adressen
Problem: Jede virtuelle Adresse auf jedes physikalische Addresses abzubilden
bräuchte riesige Tabelle → Paging

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

Eintrag in Tabelle sieht so aus:

Zugreifen: ​-Virt. Adresse zerlegen, Basis in Tabelle finden, passenden Eintrag finden,
Checks: Eintrag gültig? Privilegiert? Nur lesen? Wenn gut, fertig umrechnen (​bei​ ​IA32
ist das ein Basisregister + index reg*skalierung + displacement)​, zugreifen.

Tradeoff: Groessere Seiten für weniger Speicher(verschwendung) vs. Kleine

Seiten damit man nicht ultra viel auslagern muss

Konservativ: OS legt physikalische Seiten an sobald Benutzer virtuelle anfragt

Lazy: OS legt erst an wenn Benutzer sie verwendet (exception)

Assembler Linker & Loader

Assembler:
- Pro: - Fast, hardwarenah
- Con: Wenig abstraktion, fehleranfällig
Assemblies Prozess:
- Zwei Pass Assemblierer →
Lauf 1​: Einlesen, Instruction Location Counter (ILC) sagt befehl, makros
einfügen ​Makrotabelle​ , symbole einsammeln (zB adressmarken) und mit ILC in
Symboltabelle​ tun, opcode einfuegen ​Opcodetabelle
ILC inkrementieren
Lauf 2​: Generierung Maschinencode, throws compile errors → creates Binaer
oder Objektdatei

Objektdatei​:
- Identifikation, Einsprungpunkt, referenz tabelle, befehle, relocation
woerterbuch (stuff that needs to be relocated, sprungziele zB), debug info
- Meist ELF (Executable and linkable format) Struktur
- Elf Header, Program Header, .text (code), .rodata (constants),
.data(allocated and defined memory), section header table (describes
sections of code)

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

Next: Linker

Makro Prozeduraufruf

Erfolgt bei Assemblierung Erfolgt zur Laufzeit

Braucht kein return Braucht return
n Kopien (so oft wie Makro) Nur eine Kopie im Code
Linker:
- Weniger Speicherbedarf für Assembler
- Besser wartbar

Problem: Alle .obj Programme zusammenpacken fucks up die relativen Adressen

Linker:
1. Tabelle von Modul + Länge
2. Anfangsadresse von jedem Modul bestimmen
3. Anfangsaddresse auf jede Referenz draufaddieren
4. Externe Aufrufe auch aktualisieren
Statische Bibliotheken Dynamisch Bibliotheken

Lauter .objs Bereits gelinkte .objs

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

Bibliotheksroutinen werden in Code Wird geladen wenn nötig, Bindung erfolgt

kopiert beim laden oder zur Laufzeit

Pro: Pro:
Automatisch vorhanden Nur Laden wenn nötig, spart Platz
Schnelleres Laden Kleiner Datei
Gemeinsam nutzbar
Austauschbar ohne neu Kompilieren zu
müssen

Con: Con:
Grossere Datei Versionskonflikte
Muss bei Update neu kompilieren Fehlt auf System wo Code runned
Jede obj muss die file selbst kopieren Langsameres Laden

Loader lädt den ganzen Kram dann am Ende

Compiler
Praeprozessor: ​- in: Quelltext
out: Quelltext mit ersetzten
makros, statischen libraries usw.
Compiler​:

Lexikalische Anal.:
- Liest Buchstaben, trägt
Variablen in Symboltabelle
ein, erzeugt Tokens (oft
pointers auf Symboltabelle
or constant)
Syntaktische Anal.:
- Checkt auf syntax errors, erstellt syntaxbaum
Semantische Anal.:
- Fuegt Typinformationen ein, checkt semantische Konsistenz (Typkonsistenz)
Zwischencode Generator:
- Oft in 3-Adressform oder Abstract Syntax Tree (um Ausführungsreihenfolge zu
bestimmen

Optimierung (maschinenunabhängig):
- Verschiedene Ziele möglich (Speicher, Effizienz, Geschwindigkeit etc.)

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

- Verschiedene Arten möglich (ISA-abhangig, Global vs lokal, sicher vs unsicher

etc.)
- Dead Code Elimination, Funktionen inlinen, SIMD, Loop splitting etc.
- Basisblock: First line entry, last line exit → Compiler optimiert
Basisbloecke

Codegenerierung & Optimierung (maschinenabhängig):

- Erzeugung Assembler/ maschinencode , Speicher zuweisung, register allokation
- Register sind wenig, rest auf Stack → Register spilling ​bad
- Linken & Assemblieren kommt hier auch

Laufzeitsystem:
- Dynamische Speicherallozierung
- Dynamische Bibliotheken
- I/O

Interpretiert Sprache Virtuelle Maschinen

Wird gelesen (evtl verarbeitet), Erst in speziellen Bytecode compiliert der

stückweise abgearbeitet (ruft funktionen auf allen virtuellen Maschinen läuft, dann
auf) von der virtuellen Maschine fuer die echte
Hardware weiter kompiliert/ interpretiert
OR special hardware

Pro: Pro:
Keine Kompilierung Portabel
Flexibler, dynamischer
Portabel

Con: Langsamer Con: Muss kompiliert werden

x86 Computer
Real Mode Protected Mode

Direkter Speicherzugriff, nix virtuell → Auf Virtueller Speicher, Zugriffsrechte

ein einziges Programm ausgelegt eingeschränkt → Mehr Programme
Speicher in 16 bit große Segmente Unterschiedliche Ringe:
aufgeteilt, adressen relativ zu diesen Ring 0: OS

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

Segmenten Ring 3: Applikationen

Andere Ringe können einander aufrufen,
Local vs Global Descriptor table,
multitasking, paging etc.

Arbeitsspeicherbereiche:
- 0KB - 640 KB: Lower Memory Area
- Speicher fuer BIOS Daten, OS (Interrupt vector Tabellen [0-400 Byte]), 16
Bit Applikationen
- 640 KB - 1 MB: Upper Memory Area
- Speicher für andere Hardwarekomponenten (​BIOS ROM, Videokarte​)
- 1MB - 1,06 MB High Memory Area:
- Max. Segmentstartadresse ist 0xFFFF0 (weil 16 bit pro segment)
- 32 Bit Programme brauchen 21tes Bit im Adressbus, manche 16 bit
wollen ohne
- 1 MB - 1 GB: Extended Memory
- Normal RAM (DOS/4GW extension needed for MS-DOS because
programs need more than 1 MB, but 32 bit protected mode isn’t
compatible with MSDOS → Extensions is bridge)

Bussystem:
- Bei 16 Bit ISA:
- Datenbus: 16 Bit
- Adressbus: 24 Bit
- Kontroll/Steuerbus (Lesen/Schreiben, Kontrolle ueber Bus etc.)

I/O:
- Besonderer Weg mit I/O zu reden IO hat separaten Adressraum, zB
OUT 20h, AL ; Schreibe Inhalt von AL nach I/O port 20h
- IN: ​Maus, Tastatur erzeugen interrupt requests (IRQ) → Programmable Interrupt
Controller (PIC) sagts dem Prozessor, prozessor machts, pic sagts der Maus
(nicht mit BIOS, da zwar rückwärtskompatibel aber langsamer)
- OUT: ​zB mit DMA Kontroller um nicht Prozessor zu unterbrechen fuer Sound

BIOS:
- Basic I/O System, where eip starts when booting computer

Booting:
- 1. Reset →Register mit vordefinierten Werten gestartet, zB EIP = 0xFFFF0

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

- 2. BIOS → Code an bei EIP wird ausgeführt, BIOS ROM an 0xF0000 - 0xFFFFF,
macht ein paar Hardware tests und init
- 3. Bootloader → BIOS lädt Bootloader, Bootloader kontrolliert, lädt mehr
Komponenten wenn nötig, spricht mit hardware über BIOS, lädt und init OS
- 4. OS → OS starts up
- 5. Programm → Programm wird gestartet

DMA Controller:
- Can control bus + directly access memory
- Communication & programmable with IO ports ​skips processor which is good

Mikroprogrammierung
Elemente sind Schaltnetze
(+Signalbuffer um Daten kurz zu
halten):
- zB ​Multiplexer
- zB ​Dekodierer​ (Funktion zB
one-hot encoding)

Fest verdrahtet Programmierbar

Direkte Umsetzung von ISA auf Gatter, ISA Opcodes dekodieren und
fuer simple ISAa Mikroprogramme ausloesen

Pro: Pro:
- Hohe Performanz - Leichteres Design
- Leichter korrigierbar
- Fehler nicht so schlimm
- Taktsteuerung

Con: Con:
- Entwicklung dauert - Langsamer
- Fehleranfällig
- Schwer anpassbar

Architektur Mikroprogramm

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

- Speicher
- 80 bit Befehle → Befehle können auch kodiert sein → Pro weniger speicher,
leichter programmierbar Con dekodieren, extra hardware
- Horizontal (nicht kodiert), vertikal (stark kodiert), quasi horizontal (optimal
kodiert ​ist unsere​)
- 4000 Befehle → 40 KB
- Tabelle wobei jeder Opcode auf ein Mikroprogramm verweist
- Mikroprogrammspeicher Optionen: ROM/PROM/RAM/Hybrid
- Leitwerk
- Berechnet Mikroinstruktionzähler, holt befehl, tut ihn in MI-Register
- Adressen multiplexer intern hat 5 Eingänge: 0, externe adresse,
mi-befehlszähler, Zählerregister, stack
- INST PLA (Instruktion Programmable Logic Array) bestimmt welche
genommen wird mit befehlen aus mi-register (bestimmt auch stack und
Zähler)
- Makrobefehl ausführen: JMAP loest mikro aus, dann makro bz auf
adressbus und in makro instruktionsregister lesen
Mikro Programmzyklus (getaktet):
- Adresse nächster Mikrobefehl bestimmen,
- Befehl holen und in Mikroinstruktion Register laden
- Signale lösen Programm aus
Rechenwerk
- Nur 4 bit, kann man aber verknüpfen und übertrag durchgeben
- See picture basically → Register Als Schaltwerke, ALU & ALU auswahl als
Schaltnetz/Multiplexer, Schiebeeinheiten und Auswahl signale auch Schaltnetze

Man kann Takte direkt aus MI ablesen → Anzahl MI Befehle + 3 (IFETCH)

Warum ISA und MI?

- ISA leichter programmierbar, komplexer
- MI kann Kombinationen haben die gefährlich sind (ohne MI mit fest verdrahtetet
ISA muss man dann eben sicherstellen, dass das nicht passiert)

Schaltnetze
ROM -> ​Decoder (One hot encodes addr) + Encoder (Takes one hot encoding makes it
into data)

Definitionen​:

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

Minterm = KNF = k-stelliges Monom, but perfect -> NOR

Maxterm = DNF = Disjunctives Polynom, but perfect -> NAND
Primimplikant: Kein anderer Term m existiert in DNF mit dem sich n verschmelzen lässt

Hazards:
- Spezifikationswidriger Wert des Ausgangssignals in Abhängigkeit des
Zeitverhaltens von Signalen in Schaltnetzen -> ​Temporäres problem
Races:
- Problem beim Ausgangswert durch Verzögerung bei Rückkopplung ->
Permanent problem
Umgehen davon durch Taktung (kostet aber mehr Zeit, weil man auf alle wartet),
anderes Schaltnetzdesign
Am billigsten nur NAND, wird in Praxis auch oft so gemacht

Schaltwerke

Endliche Automaten:
- Endliche Anzahl an zuständen
- Mealy Automat: ​Resultat hängt vom Zustand und
Eingang ab​ Sechstupel aus E(Eingangsmenge),
A,Q, 𝜆, 𝛿, q (Anfangszustand)
- Automatentafel/ Automatengraph fuer A = {abcd}, E
= {x,z,y}, Q={1,2}

Moore Mealy

- Resultat hängt nur von Zustand - Resultat hängt vom Zustand und
ab → Eingang bestimmt nur Eingang ab
Zustand

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

Definitionen:
- Prozess: Sequentielle Abfolge von Schritten
- Parallelität: Es gibt einen Zeitpunkt zu dem beide laufen
- Asynchron: Keine Zeitbeziehung
- Funktionalität: Funktional wenn Eingaben reproduzierbar und eindeutig auf
Ausgaben abgebildet werden (asynchron meist nicht funktional)
Taktung:
- Verschiedene Teile vom Computer oft unterschiedlich getaktet
- Taktung heute variabel, kann vom Nutzer (Dynamic Voltage and Frequency
Scaling [DVFS] → Kann für wenig energie optimieren) oder Temp (power
capping) gesteuert werden oder prozessorauslastung
- Synchronisiert die Maschine

Bauelement Schicht

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

Gatter implementiert durch Transistoren → Aufgebaut auf silizium wafers

Schaltungsentwurf

Optionen:
- Komponenten → MI
- Application-Specific
integrated circuit
- Programmable Logic
Device
- Programmierbare
Schaltungen →
Billiger, kleiner aber
weniger schnell als
ASIC, entwicklung
schneller als Gatter

SPLD (Simple Programmable Logic Device)

- Schaltnetz aus ‘and’ und ‘or’ → DNF
- Problem: Für komplexe schaltungen
kompliziert,schlechte skalierung
- PLA(Programmable Logic Array):
- And und Or array programmierbar,
mit “fuse maps” (einmal programmierbar)
- Pro: Einfach + schnell programmierbar, kann dicht implementiert werden
- Con: Doppeltes Programmieren aufwendig, langsame signal laufzeit,
grosse und/oder gatter können aufwendig sein
- PAL(Programmable/General Array Logik):
- PLA, nur and array programmierbar
- Pro: Leichter herzustellen, schneller, weniger fuses
- Con: Weniger flexibel
- Je nachdem non-volatile (PAL)/volatile (GAL)
- PROM:
- Inverted PLA
CPLD (Complex PLD):
- 10-1000 SPLD + Connection zwischen denen + I/O

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

FPGA (Field Programmable gate array):

- Schneller, vorhersehbarer für bestimmte cases als CPUs, billiger,
rekonfigurierbarer und leichter zu machen als ASICs
- Hat Logikblöcke (simpler als in CPLD) welche durch programmierbares Netzwerk
verbunden sind → Besser für komplexe Schaltungen
- Logikbloecke: Look up table + Multiplexer von einer SRAM (SRAM wird
programmiert) gesteuert mit 3-6 Bit eingang um jede einfache funktion zu
kodieren
- Verbindungen zwischen blöcken ist eig 70-80% des Ressourcenverbrauchs
Entwicklung von FPGA:
- Spezifikation
- Was will man, was kriegt man
raus/gibt rein, was will man
optimieren
- HDL → Hardware schreiben
- Simulation ob alles funktioniert
- Synthese
- Timing mit einbeziehen, wirkliche
Logikblöcke übersetzen,
optimierungen
- Place & Route
- Abbildung auf FPGA, Place = wohin
mit den Blöcken, Route = wie
verbinde ich sie
- Timing Simulation -> Hazard, Races?
- Bitstream gen.
- Die einzelnen SRAM zellen konfigurieren und in native FPGA Sprache
setzen

VHDL
Structural Behavioral Dataflow

Wirkliche Schaltungen Verhalten beschreiben Dazwischen, man

beschreiben Pro: Leicht und implementiert Automaten,
Pro: Kontrolle verständlicher boolean algebra
Con: Aufwendig Con: Weniger Kontrolle

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

Speicher
Memory wall “Von Neumann Flaschenhals”:
- Speicherzugriffe dauern, Befehle die auf Speicher zugreifen warten und
Prozessor ist im Leerlauf → Improve VNA fuer bessere Latenz und Bandbreite
Arten: RAM, ROM, PROM, (E)EPROM (Electrically erasable/ UV light)

SRAM​ (Static RAM) (Register und Cache):

Schreiben: bit und nicht bit anlegen
Lesen: Beide auf 1 → Einer wird auf 0
gezogen, von der Seite vom Inverter die immer
0 ist → Abfall registriert
Pro: Sehr schnell, Bezahlt Wert solang Strom
anliegt, unempfindlicher
Con: Gross, teuer, mehr Energiebedarf

DRAM ​(Dynamic RAM) (Hauptspeicher):

- Schreiben: Auswahlsignal setzen, 0 oder
1 an Bitleitung -> Lädt/entlädt
Kondensator
- Lesen: Auswahlsignal setzen, Wert
zwischen 0 und 1 an Bitleitung → Bei 0:
Kondensator lädt sich und Bitleitung wird
0, Bei 1: Kondensator gibt Ladung ab,
Bitleitung wird 1
Probleme: Lesen zerstört info, Kondensator verliert Ladung über Zeit
→ Regelmäßiger refresh, nach
lesen direkt wieder schreiben
Pro: Billig, simple
Con: Großer Energiebedarf,
Langsamer
- Heute oft Synchronous
DRAM
- Alle signale
(Column address
strobe, row address strobe, adresse) synchron, Speicherkontroller auf
dem Prozessor, Chip Select chooses row

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

- DRAM in matrizen, DIMM = Dual In-Line Memory Module, beim lesen

werden die Daten in einen Row-Buffer eingelesen (like mini cache)

Speicher und CPU zusammen? -> DRAM und Logik nicht ganz kompatibel, SRAM zu
teuer

Gross und langsamer Speicher oder schneller und kleiner Speicher → Cache

Cache
- Cache enthält immer Kopie aus
Hauptspeicher, unlike register
- Transparent verwaltet → Benutzer
merkt nichts davon, Hardware mit
Hilfe von Software entscheidet was
cached wird → Zeitliche Lokalität +
Räumliche Lokalität
- Immer ganze Zahlen laden, weil
billiger und Räumliche Lokalität
- Nicht-Assoziativer Cache:
- Jede Adresse ist eine
Cachezeile
- Pro: Leicht zu bauen, schnell
- Con: Oft verdrangung, unflexibel
- Fragen​:
- Welche Cachezeile verdrängt man? → Least recently/ Least frequently
used
- Wann aktualisiert man den Speicher? → Sofort, “write through”, Später,
“write back” (man merkt sich mit dirty bit das die Zeile geändert wurde)
- Cache-Miss: Wird Datum in Cache eingelagert? → Write-allocation, ja, No
Write-Allocation nein, cache macht nichts
- Cache vor oder nach MMU?
- Virtually indexed cache (vor MMU):
- Pro: Direkter Zugang, schneller
- Con: Mehrere Prozesse können gleiche virt. Adresse
verwenden → Vor Prozesswechsel Cache loeschen/ Tag um
Process Id erweitern → Langsamer, also besser für kleine
Caches
- Physically indexed cache (nach MMU):

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

- Pro: Nicht die Prozesswechselprobleme

- Con: Muss jedes mal durch MMU
- Lösung: ​TLB (Translation look aside buffer) - Cache for MMU,
merkt sich paging tabelle + L1, L2, L3 Cache (L1 virtually indexed)
+ verschiedene L1 caches für Instruktionen/Daten Zugriffe weil
andere Zugriffsmuster, bessere Cache Struktur, Vorverarbeitung
- Exklusiv vs Inklusiv:
- Exklusiv: Jedes Datum ist in nur einem Cache
- Inklusiv: Jedes Datum in jedem Cache
- Optimierung fuer Cache: Array of Structs (Struct is x and y; array of
struct;) vs Struct of arrays (struct is array of x, array of y; struct), loops
umschreiben
- Prefetching:
- Prefetch darf nie Exception verursachen
- Hardware: Next-Line Prefetcher/ Strided Prefetcher
- Software: Kann komplexere Muster hardcoden, muss aber code
verändern (nicht mehr transparent)
- Zu früh: Prefetched wird wieder ausgelagert,Zu spaet daten zu
spaet im cache
- Cache Pollution if you fetch wrong stuff

Pipelining
Metric: CPI (Cycles
per Instruction)/ IPC
Ideal: Bei k Takten
pro Befehl k Befehle
gleichzeitig in
Bearbeitung
→ Ausführen eines
Programms dauert
dann k-1 + n
Probleme:
- Pipeline fehlt
Ressourcen in
Hardware
Structural
Hazard
- Datenabhängigkeiten nicht erfüllt ​Data Hazard → ​Lösung: Forwarding

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

- Bedingte Sprünge verursachen Neustart ​Control Hazard → ​Lösung: Branch

Prediction → Predict if it’s gonna jump and fill pipeline accordingly, wenn falsch
Branch miss prediction (Jeder vorherige Sprung kommt in Tabelle → Hofft
dadurch muster zu erkennen e.g. 1 Bit prediction keep guessing the opposite of
what was last done with the jump)
- Befehle dauern länger (zB MUL) → Lösung: Weiter zerlegen
- Mehr Spekulation: Transactional Memory → Lots of prediction, has to be able to
be rolled back though

Parallelität
Dynamic Scheduling:
- Befehle out-of-order ausführen
- Pro: Schneller, paralleler
- Con: Mehr Buchhaltung, Speicher muss konsistent gehalten werden obwohl
Speicherzugriffe vertauscht werden
Superskalarprinzip:
- Mehrere Kerne, Dekodierer usw.
- Transparent?
- Pro: Leichter zu programmieren
- Con: Komplexe Hardware,
Compiler hat nicht alle Infos
Flynn’s Classification:
- SIMD: Hoehere Leistung, aber nur ein
Hardware Thread
- MIMD: Mehrere Threads, jeder führt
getrennte Instruktionsstroeme aus
(shared Resourcen je nachdem anders
Speicher immer shared und E/A
often, sonst getrennte computer​)
- Jeder Prozessor hat mehrere
threads (jeder Thread eigener
BZ und eigene Register, eigener Stack, eigene Befehle)
- Einfaches Multithreading -> Je nach takt umschalten
- Simultaneous MT -> Gleichzeitige Nutzung von Ressourcen → OoO
Konsequenzen:
- Mehrere Kerne, ein Speicher, ein Bus → Weg von normalen bussen, hin zu
direkteren Speicheranbindungen, mehrere Speicherkontroller direkt in Prozessor

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

- Cache → Nur ein Cache? Cache zu langsam. Organisation manuell? Sehr

schwierig vor allem mit Prefetcher usw. Aufteilung in cacheable? Sehr schwierig
- Automatische Cachekohärenz
- Snooping: Geteilter Bus zu Caches
- Write Invalidate: Schreibzugriffe invalidieren andere Zeilen
- Write Update: Schreibzugriffe propagieren neuen Wert an alle
- MSI und MESI
- Pro: Leicht zu implementieren
- Con: Busse skalieren schlecht, viele Invalidierungsnachrichten
MSI: ME(Exclusive)SI:

- Verzeichnisbasierte Kohärenz:
Zentrales Verzeichnis merkt sich wo was liegt, keine Busse aber mehr
Aufwand
- Problem: False sharing, Info wandert zwischen Cache obwohl es nicht
nötig ist

Parallelität Einfluss auf ISA:

- Synchronisation Befehle zwischen Threads nötig mittels Locks
- Mehrere Sockel:
- UMA (Uniform Memory access) Gleiche Latenz überallhin
- NUMA (Non-Uniform MA) Verschiedene Latenz je nachdem → Daten
Platzierung wichtig, üblich da Kontroller im Kern
- Scheduler teilt Software threads hardware threads zu
- Software threads teilen sich gleiche Ressourcen, also eng
gekoppelt und gleicher Adressraum Fork starts new thread, join
joins thread and waits for termination
- Prozesse verschiedene Ressourcen und Adressräume
- Einfachstes Modell für Synchronisation ist Sequential Consistency →
Result same as if the program were executed sequentially
- Teuer, langsam

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)

 lOMoARcPSD|4653659

- Spin Locks: Warte auf lock wenn vergeben Pro: Schnelle Reaktion Con:
Kostet Ressourcen für nix
- Yielding Locks: Falls Lock vergeben, mach was anderes Pro: Keine
Verschwendung Con: Langsamere Reaktion

E/A
- PCI: Peripheral Component Interconnect
- Verbunde mit CPU via Hostbridge

Heruntergeladen durch Quantyna Ysua (teodorapatrascu33@yahoo.com)