Aufgabe Inhalt 1..4 Aufbau PC, Mikroprozessor, Mikrocontroler 5..8 von Neumann, Abarbeitung eines Befehls Speicherhierarchie und Cache 23..

Transkript

1 Aufgabe Inhalt 1..4 Aufbau PC, Mikroprozessor, Mikrocontroler 5..8 von Neumann, Abarbeitung eines Befehls Speicherhierarchie und Cache Paging, Relocation, Segmentation, virtueller Speicher Pipelining und Scoreboarding Sprungvorhersage, Branchtargetbuffer, Branchfolding Leistungsbewertung von Rechnerarchitekturen Bussysteme E/A PIO, DMA, IOP Taxonomie nach Flynn, UMA, NUMA, CCNUMA Superskalare Architekturen, Shadowregister und Registerrenaming

2 1.) Unterschied zw. Mikroprozessor und Mikrocontroller Prozessor Kontroller Verwendung: allgemeine Aufgaben speziell auf Aufgabe zugeschnitten bzw. Für diese programmiert Speicher: Cache (Ram), Ram, EEProm bzw. Flash Eventuell mit MMU (statischen und flüchtigen Speicher) IO: Systembusse A/D sowie D/A, serielle (z.b. I2C), Grafik (LCD oder VGA),CAN... Einsatzgeb: universell Chipkarten, Automatisierung, embedded Devices Prozessor: nur eine Recheneinheit Kontroller: autonome Verarbeitungseinheit 2.) Bestandteile eines modernen PC s - Gehäuse - Netzteil - Hauptplatine (Motherboard mit Chipsatz) darauf: CPU Speicher (SD/DDR/...) Grafikkarte Netzwerkkarte Soundkarte - Festplatten + event. Extra Controller - Peripherie (USB/PS2/SERIELL...) 3.) Schnittstellen moderner PC externe: serielle, parallele, PS2, USB, FireWire, Netzwerk, Grafik (VGA/DVI...), Audio IN/OUT interne: IDE, Floppy, SATA, SCSI, 4.) Aufbau Grafikkarte RAM, RAMDAC, Schnittstellencontroller (AGP/PCI/PCIX/VESALOCALBUS), GPU, BIOS, Monitorschnittstelle

3 5.) Rechnerarchitektur von Neumann - gemeinsamer Speicher für Daten und Programme hohe Auslastung auf dem Datenbus da dieser von Daten und Code geteilt wird - taktgesteuert verhindert Konflikte durch Synchronisation, aber Befehle werden in festem Zeitraster abgearbeitet - Verarbeitungsbreite der Befehle ist fest, egal ob NOP oder DIV planbare Busbelastung aber Verschwendung bei kurzen Befehlen - programmgesteuerte Funktion nicht spezialisiert, kann alles aber nur weniges richtig gut - Speicher linear adressiert Adressberechnung nötig - sequenzielle Programmabarbeitung

4 6.) einfache CPU Rechenwerk Registersatz, speichern von Operanden und Ergebnissen ALU, Arithmetisch-Logische Einheit, das Rechenherz, verknüpft Operanden^w durch z.b. DIV, ADD, AND, OR, LSHIFT, RSHIFT Statusregister, speichert Zustände der ALU nach Operationen (z.b. Überlauf, Vergleichsergebnisse,...) TS, TargetSelect, Ergebnis in Register oder Speicher schreiben Steuerwerk: Logik, steuert Zusammenspiel der Komponenten BC, Befehlszähler, erzeugen der Adresse des nächsten Befehls Befehlsdecoder, decodiert den Befehl in Opcode und Operanden/Adressen Befehlsregister, speichert Opcode sowie Operanden/Adressen MBR: MemoryBufferRegister, Zugriff lesen/schreiben auf den Speicher Puffern (Latches)

5 7.) Abarbeitung des Befehls in 5 Schritten 1. Phase IF Instruction Fetch (Befehl holen) -> Befehl vom Datenbus bzw. aus dem Cache holen 2. Phase DC Decode (Befehl_Opcode ermitteln sowie benötigte Register/Speicher) -> feststellen um welchen Befehl es sich handelt, Operanden des Befehls ermitteln, entsprechende Verarbeitungseinheit der ALU scharf schalten, event. Statusregister zurücksetzen 3. Phase OF Operand Fetch (benötigte Operanden holen) -> Operanden aus den Registern/Speicher holen und der ALU zur Verfügung stellen 4. Phase EX Execute (ausführen der Operation) -> ausführen der Operation def. Durch Opcode 5. Phase WB WriteBack (schreiben der Ergebnisse) -> sichern der Operationsergebnisse 8.) Warum 5 Phasen? -> Synchronisierung der CPU-Verarbeitungseinheiten -> planbarer Zugriff auf Busse -> parallele Abarbeitung von Befehlen -> einheitliches Schema für die Bearbeitung unterschiedlicher Befehle (in Bezug auf Länge und Aufbau des Befehls) 9.) Speicherhierarchie erläutern, Auswirkung auf virtuelle Speicherverwaltung Speicher Speed Register Primärspeicher CPU_Speed Cache Level 1 annähernd CPU_Speed Cache Level 2 ca. 0,25 CPU_Speed Hauptspeicher ca. 0,1 CPU_Speed Festplatte Sekundärspeicher ca. 20 ms CDROM,MO Bandlaufwerke Tertiärspeicher ca. 500 ms Speicher werden in der Hierarchie vom Register abwärts stetig langsamer aber auch größer. Austausch zwischen den Schichten erfolgt über Datenblöcke. Auswirkung: je tiefer der Zugriff vom Register aus gesehen desto mehr Zeit vergeht bis Daten verfügbar sind. Durch die wesentlichen Größenunterschiede der Speichermedien ist eine virtuelle Speicherarchitektur möglich, d.h. es kann mehr Speicher adressiert werden wir physikalisch vorhanden ist. Dies erreicht man durch auslagern bzw. einlagern von Speicherbereichen über die Hierarchiegrenzen hinweg. Allerdings ist dazu eine Umrechnung der Speicheradressen notwendig, die unter Umständen wertvolle zeit kosten kann. Oft ist auch ein Auslagern von Speicherbereichen eines Prozesses bei einem Kontextswitch notwendig (z.b. flushen der Caches).

6 10.) Merkmale Speicherhierarchie sowie Techniken Speicher Speed Technik Register CPU_Speed FkipFlop, flüchtig, sehr klein Cache Level 1 annähernd CPU_Speed FlipFlop, flüchtig, Kb Cache Level 2 ca. 0,25 CPU_Speed FlipFlop, flüchtig 8MB Hauptspeicher ca. 0,1 CPU_Speed Transistor-Kondensator, flüchtig...4gb Festplatte ca. 20 ms magnetisches Verfahren, Platte, nicht flüchtig, 500 GB CDROM,DVD, blueray optisches Verfahren, nicht flüchtig,...50gb MO-Disk Magneto-optisches Verfahren nicht flüchtig,... Bandlaufwerke ca. 500 ms magnetisches Verfahren, Band, nicht flüchtig, GB Wichtige Merkmale beim Datenaustausch zwischen den Ebenen: Block placement - wo wird der Block geschrieben BestFit, WorstFit, FirstFit, RotatingFirstFit, BinaryBudy Block identification - wie wird der Block adressiert Direct, full mapped, set Block replacement - welcher Block soll wann/wie ausgelagert werden Auswahl: LRU, FIFO, RANDOM (FixedSize) Write Strategie - wann werden Blocks geschrieben Verzögert (z.b. OnFlush, Kontextswitch) Sofort (AfterChange) 11.) Warum Caches -> Hauptspeicher langsam, langer Zugriff, Pufferung durch schnellen, intelligenten Cache -> Steigerung der Geschwindigkeit, Pipeline im Ideal immer voll, niedrigere Busbelastung, ausnutzen der räumlichen und zeitlichen Lokalität 12.) Funktionsweise von Caches Cache ist wesentlich schneller als Hauptspeicher und wird zur Pufferung benutz. -bei Zugriff auf Hauptspeicher prüfen ob angeforderte Daten im Cache vorhanden sind -> NEIN: einlagern der Daten (abhängig von Cacheline-> Größe des eingelagerten Bereichs) -> JA: Zugriff direkt auf Cache - falls Cache voll/belegt auslagern von Cachlines in den Hauptspeicher nach Verdrängungsmechanismus/Replacementpolicy (z.b. RANDOM, LRU, FIFO,...) - Einlagerung / Zugriff durch Adressübersetzung (Assoziativität -> full, set, direct mapped)

7 13.) Beitrag zur Geschwindigkeitssteigerung von Caches Zugriffszeit MM: Zugriffszeit Cache: Trefferrate Cache: Tm Tc Pc Durchschnittliche Zugriffszeit: Tavg = Tc*Pc + Tm*(1-Pc) Da Cachezugriff min. um den Faktor 10 schneller ist ergibt sich bei einer hohen Pc ein erheblicher Zeitgewinn. 14.) Unterschied Cache MM -> Cache ist wesentlich schneller als MM (Speichertechnologie, Cache ist aus FlipFlops, MM aus Transistor und Kondensator) -> Cache ist wesentlich kleiner als MM (für FF braucht man min. 6 Transistoren -> Teuer!!!) -> Cache meist in der CPU auf dem DIE (näher an der CPU) -> Cache <-> CPU eigener BUS, dadurch exklusiver Zugriff -> MM wird linear adressiert, Cache über Tabellen durchsucht 15.) Begriffe zeitliche Lokalität, räumliche Lokalität in Bezug auf Rechnerarchitekturen und erläutern sie deren Einsatzmöglichkeiten zeitliche Lokalität: räumliche Lokalität: ein verwendetes Datum wird mit hoher Wkt in näherer Zukunft wieder verwendet auf ein benutztes Datum folgende Daten werden mit hoher Wkt ebenfalls benutz Anwendung im Cache: - zeitliche Lokalität, weil häufig benutze Daten im Cache vorliegen - räumliche Lokalität, weil ein/auslagern von Daten erfolgt in Lines bzw. Blockweise Anwendung beim Prefetching / Peekahead: - räumliche Lokalität, folgende Befehle im voraus lesen oder abarbeiten Anwendung beim TLB: - zeitliche Lokalität, weil häufig umgesetzte/angefragte Adressen gespeichert werden Caches werden im allgemeinen in jeder Ebene der Speicherhierarchie eingesetzt um den Datenverkehr zu puffern.

8 16.) zeitliche Lokalität, räumliche Lokalität am Beispiel eines iterativen Berechnungsverfahrens Summe aller Zahlen im Speicher von Addr 100 bis 200, Pseudocode 0 s:=0 1 c:=0 2 s: = s + mem(100+c) 3 c: = c +1 4 if c<= 100? 5 ja -> springe nach c,s zeitlich Lokal mem(100+c) räumlich Lokal 17.) Berechnung durchschnittliche Zugriffszeit Trefferrate: Pc = 99/100 Zugriff Cache: Tc = 10 ns Zugriff MM: Tm = 70 ns Tavg = Pc*Tc + (1-Pc)*Tm = 99/100 * 10ns + (1-99/100)*70ns = 10,6ns 18.) Begriff der Assoziativität erläutern -> Bezug des Hauptspeichers zum Cache hinsichtlich der Adressumsetzung, Aufteilung des Caches nach Methoden direct mapped: jedem Speicherbereich des MM ist direkt eine Cacheline zugeordnet Full Assoziativ: jeder Speicherbereich des MM kann an jeder beliebigen Stelle im Cache stehen Set assoziativ: Aufteilung des Caches in Set s zu einer Anzahl von Cachelines, jeder Speicherbereich des MM kann eine fixe Cacheline in jedem Set belegen

9 19.) Kosten und Nutzen der Assoziativität 1,4,32 bei einem Cachespeicher mit 32 Cachelines in Relation setzen Aufwand Nutzen 1 einfacher Aufwand gering, häufige Cache-Misses, trashing sehr wahrscheinlich 4 vierfacher Aufwand 4fach weniger Cache-Misses als bei 1facher Assoziativität 32 32facher Aufwand weite Teile können ungenutzt sein, (32*32Bit-Komparator,,,) so gut wie nie Konflikte In diesem Beispiel bestes Verhältnis von Kosten und Nutzen bei 4fach Assoziativität. Allgemein: je höher die Assoziativität, um so höher die Kosten (Platz und damit Geld). Ab einem gewissen Grad der Assoziativität wird der Platzbedarf für Komparatoren so hoch das zu kaskadierten Lösungen gegriffen wird Suche in den Cachelines erfordert mehr Zeit. 4fache Assoziativität mit 32 Byte pro Cacheline wird unter anderem in der UltraSparc verwendet (Tanenbaum, Computerarchitektur, Auflage 5, S. 344, ISBN: ) 20.) Vorteile von Prefetching in Bezug auf Cache Prefetchning nutzt die räumliche Lokalität der Daten. Durch vorrausschauendes lesen von Daten aus dem MM kann die Verarbeitungsleistung ernorm gesteigert werden. Wird der Cache nur nach einem CacheMiss gefüllt ist ein zeitverschwendender Zugriff auf den MM notwendig. Zu der wesentlich geringeren Geschwindigkeit des MM muss man auch die Latenz des Speicherzugriffes an sich (Adressumsetzung, Adressierung durch MBR/TLB/MMU) hinzurechnen. Diese Latenz lässt sich durch Prefetching wirkungsvoll kompensieren. 21.) Warum Ersetzungsstrategien für Caches -> Größe des Caches im Vergleich zum MM gering -> ein- und auslagern von Speicher notwendig LRU: der, der am seltensten benutzt wurde fliegt raus RANDOM: zufälliger Eintrag wird ausgewählt und geändert FIFO: der, der am längsten im Cache ist fliegt raus ROBBIN: zyklisch, 1 dann 2 dann 3... n Eintrag fliegt raus FINFO/LIFO: der, der am längsten im Cache ist wird nicht geändert Problem: trashing!!!

10 22.) in Hardware leicht zu realisierende Ersetzungsstrategie für Cache LRU der am wenigsten verwendete fliegt raus, dafür zwei Ansätze: Mittels Countern: Counter pro Eintrag, der beim einlagern der Daten auf definierten Wert gesetzt wird, bei jedem Cachezugriff auf einen andren Bereich Decrementierung (-1) des Counters, bei jedem Zugriff auf diesen Bereich Incrementierug (+1) des Counters. Counter mit dem niedrigsten Wert am wenigsten genutzt. Mittels Matrix: -> Assoziativität ist n -> Aufbau von n*n-matrix -> Zugriff auf i -> Spalte i auf 1 -> Zeile i auf 0 der am längsten nicht verwendete Block i ist der mit nur Nullen in Spalte i Realisierung in Hardware: N*N Matrix aus FF, S Spaltenweise zusammengefasst, K Zeilenweise zusammengefasst, Auswertung mittels nicht(q), Spaltenweise mit UND verbunden ) Welche Ziele verfolgt man mit Speicherverwaltung -> Schutz von Speicherbereichen / Protection (z.b. Schutz von OS-Speicherbereichen, nicht Ausführbarkeit des Stack und Heap) -> Relocation (Zerlegung in Segmente, Addressierung über Segmentadresse und Offset, jedes Segment beginnt mit Offset 0 -> freie Verschiebbarkeit von Programmen und Prozeduren, Mehrfachnutzung ermöglichen, ermöglicht kompelieren von Modulen ohne auf deren Startadressen rücksicht nehmen zu müssen) -> Trennung von großem Logischen Adressraum von relativ kleinem physischem Adressraum -> intelligentes Swaping und Paging möglich -> schnelle Antwortzeiten (geringe Latenzen) durch Caching Speicherverwaltung ist in der Regel für den Programmierer transparent. Nur Betriebssystementwickler und Studenten müssen darüber bescheid wissen.

11 24.) Welcher virtuelle Adressraum steht einem Programm auf einer 32-Bit-Architektur zur Verfügung, wenn noch 9 weitere Programme auf dem Rechner laufen? Weiterhin 32 Bit (4 Gbyte), da der virtuelle Speicherbereich jedem Programm voll zur Verfügung steht. 25.) Probleme bei Nutzung von virtuellen Adressen bei Caches darstellen, erläutern und bewerten beide möglichen Methoden zur Lösung zur Beschleunigung der Umrechnung. Benennen der derzeit eingesetzten Methode zur Umrechnung von virtuellen in reale Adressen. Probleme: -> Umrechnung virtuell <-> real nötig Frage: an welcher Stelle umrechnen (vor oder nach Cache)??? (Beachte hier: Ziel ist es so viel wie möglich auf dem Cache zu arbeiten) two possibilities: (Dude, watch DAGON, on of the greatest and most famous horror-movies) -> Cache arbeitet mit virtuellen Adressen -> keine Umrechnung bei Cachezugriff nötig ABER -> zwei Programme können auf gleiche virtuelle Adresse zugreifen, benutzen dabei aber unterschiedliche physische Adressen (was für den Cache intransparent ist) -> Cache arbeitet mit realen Adressen ABER -> Adressumrechnung vor jedem Cachezugriff notwendig (Zeitaufwendig) Genutzt wird IMHO virtuelles Caching da bei heutigen Designs das Prinzip der räumlichen und zeitlichen Lokalität vorherscht (Cachezugriff = Normalzustand).

12 26.) Was ist der Translation Lookaside Buffer TLB -> hält bereits übersetzte Adressen (virtuell -> real) vor -> bei Speicherzugriff wird parallel zur suchen in den Pagetablen der TLB durchsucht -> TLB relativ klein -> parallele suche -> sehr schnell Ergebnis Adresse schon übersetzt oder auf Pagetables warten -> wenn Adresse in TLB gefunden -> direktes legen dieser auf den Adressbus, anfordern des Speichers SONST -> Adressübersetzung mittels Pagetable, eintragen der Übersetzung in den TLB, zugriff auf Speicher Warum?... TLB schneller... Lokalitätsprinzip... SPEEED! Wo?... zwischen CPU und Speicher... muhar... also auf dem virtuellen Adresspfad mit einem Abzweig Richtung Pagetables, das andere Ende des TLB ist in der realen Speicherwelt verankert ) Verfahren zur dynamischen Speicherverwaltung nennen und Stichpunkte... paging: -> Speicher in Seiten fester Größe einteilen -> Speicher eines Prozesses wird auf diese Seiten aufgeteilt -> Speicher muss nicht zwingend im physikalischen Speicher aufeinander folgen -> Adressierung über Pagetable -> PROBLEM: durch feste Größe der Seiten entstehen Speicherlöcher (2 KB Code in 4KB Seite...) segmentation: -> Speicher wird in Segmente mit variabler Größe aufgeteilt -> Teile eines Prozesses (Code, Stack, Heap) liegen in unterschiedlichen Segmenten -> Segmente können wachsen und schrumpfen -> Adressierung: Segmentadresse und Offset im Segement -> PROBLEM: durch uneinheitliche Segmentgröße kann der Speicher fragmentieren ->EXTERNE FRAGMENTIERUNG paged segmentation: -> Pages in Segmenten -> dadurch bessere Ausnutzung des Speichers (Segmente müssen um vielfaches einer Page wachsen) -> 2 stufige Adressumsetzung (Segment -> Page -> Offset) -> Page kann in sich über mehrere Segmente erstrecken ->PROBLEM: relativ hoher Verwaltungsaufwand

13 relocation: -> abbilden des virtuellen Speichers auf zusammenhängenden realen Speicher -> angeforderter Speicher kann nie größer sein wie physikalisch vorhanden -> Adressauflösung über Rellokationregister (RR) 28.) Erläutern Relocation... Erläutern: siehe oben Anmerkung: das RR wird bei Kontextswitch umgeladen und enthält neue Startadresse des Speichers oder jedem Prozess ein eigenes RR zuordnen Einprozesssystem: -> unkritisch, Nutzung von nur einem RR -> Prozess kann fast gesamten Speicher nutzen (bis auf OS-Bereiche) Mehrprozesssystem: -> Prozesse müssen sich Speicher teilen -> wachsen des Speichers des Speichers nicht möglich Batch: Speichernutzung vorhersag- und damit reservierbar Interaktiv: dynamische Speicheranforderung, mit Relocation problematisch 29.) Probleme Relocation siehe 27,28 30.) Paging erläutern -> siehe 26,27 -> Adresse wird zerlegt in Page und Offset

14 31.) Leistungsfähigkeit des Pagings und Strategien zur Organisation der Seiten -> Umrechnung von Pages über Pagetable -> braucht Zeit -> jeder Prozess hat eigene Pagetable -> braucht Platz Nachladestrategien: Superfluity: -> alle Daten eines Prozesses werden geladen, egal ob sie verwendet werde oder nicht PROBLEM: Zeitverschwendung und verwendeter Speicher kann nicht größer wie physikalischer sein Demand paging: -> nur das einlagern was gebraucht wird ERGEBNIS: angeforderter Speicher kann größer sein als physikalisch vorhanden PROBLEM: wenn angeforderte Daten nicht im Speicher sind -> PageFault und dadurch Kontextswitch (sollten Sie Erläuterungen zum eben geschriebenen brauchen hören sie auf zulesen, exmatrikulieren sie sich und werden sie ordentlicher Assozialer im Sinne der APPD) 32.) Seitenersetzungsstrategien beim Paging FIFO, LRU, RANDOM,... siehe Ersetzungsstrategien beim Cache 33.) invertierte Seitetabelle nicht invertiert: Zuordnung von virtuell auf real 1:1, dh. Abhängig von Pagegröße sehr große Übersetzungstabelle -> teuer invertiert: -> Zuordnung von real auf virtuell, da weniger reale Adressen als virtuell -> kleinere Übersetzungstabelle nötig -> virtuelle Adressen werden mittels Hash auf diesen kleineren Bereich abgebildet, Kollisionsliste verwaltet Überschneidungen 34.) Skizze Adressumsetzung aus einer virtuellen bei 2-stufiger Adressumsetzung

15 35.) Kurz die Idee des Pipelinings erläutern -> Abarbeitung eines Befehls in meherere atomare Schritte zerlegt -> jeder Schritt hat klar definierte, feste Aufgabe welchen in konstanter Zeit abgearbeitet wird -> klare Definition welcher Schritt auf welche Register/Funktionen/Speicher zugreift dadurch parallele Abarbeitung von Befehlen möglich -> Geschwindigkeitsgewinn SUM: homogene Befehle, wenige Adressmodi, seltene Speicherzugriffe Load/Store-Architektur, viele Register, einfache Befehle 36.) 5 Stufen einer Pipeline, Aufgaben dieser Stufen Aufbau für Wirtschaftsinformatiker: IF DC OF EX WB IF Instruction Fetch holen des Befehls aus dem Cache/Speicher DC Instruction Decode decodieren des Befehls, ermitteln Befehlstyp und Operanden- oder Speicherzugriff OF Operand Fetch zugriff auf Register, holen von Operanden EX Execute Ausführen des Befehls (ALU) bzw. Adressumrechnung WB Write Back Ergebnis speichern Aufbau für tigthe checker: IF DR EX MA WB IF Instruction Fetch holen des Befehls aus dem Cache/Speicher DR Decode and Read steigende Flanke: decodieren des Befehls, ermitteln Befehlstyp fallende Flanke: Operanden- oder Speicherzugriff EX Execute Ausführen des Befehls (ALU) bzw. Adressumrechnung MA Memory Access zugriff auf MM, Ergebnis direkt im Speicher ablegen (überbrückbar) WB Write Back Ergebnisse in Registern sichern 37.) Zugriff auf Ergebnisse von vorhergegangener Befehle beschleunigen -> nach dem dritten Abarbeitungsschritt (EX) Ergebnisse in Schattenregister schreiben -> dadurch Zugriff auf Ergebnisse bereits 2 Takte zeitiger möglich FORWARDING -> erfordert zusätzliche Datenleitungen und Scoreboard (Belegung des Scoreboards checken, wenn nachfolgender Befehl auf Register X zugreift und dieses im Schattenregister einen gültigen Werte enthält -> zugriff auf Schattenregister)

16 38.) Probleme beim Pipelining Strukturelle Konflikte: gleichzeitiger Zugriff auf Resourcen Lösung1: aufteilen der der Zugriffe auf steigende und fallende Flanken IF DR EX MA WB IF DR EX MA WB IF DR EX MA WB IF DR EX MA WB IF DR EX MA WB Lösung2: umsortieren von Befehlen (z.b. durch Compiler) Datenkonflikte: zugriff auf Register, deren Werte noch nicht zur Verfügung stehen oder Falsche Ergebnisse beinhalten dirty read, dirty write Lösung1: durch Software (einfügen von NOP s oder semantisch invariantes umsortieren) Lösung2: verwenden eines Scoreboardes Lösung3: Forwarding über Schattenregister (Bypass) Steuerkonflikte: Sprünge, Sprung steht erst nach DR fest, nächster Befehl schon im IF Lösung1: einfügen von NOP s (doof weil Zeitverschwendung) Lösung2: delayed branching -> Befehlsfolge umsortieren (wenn sich der Sprung nicht auf Ergebnisse vorangegangener Befehle bezieht), berechnen des Sprunges und Ausführung der Befehle nach dem Sprung Lösung3: Sprungvorhersage, spekulative Ausführung der nachfolgenden Befehle 39.) Belegungsmatrix zwei unterschiedliche Beispiele Sinn: strukturelle Konflikte erkennen und vermeiden IF DR EX MA WB IF DR EX MA WB IF DR EX MA WB IF DR EX MA WB IF DR EX MA WB -> MA und IF greifen beide auf den Speicher zu -> WB und DR greifen auf Register zu

17 40.) Ziele der RISC-Achitektur, Auswirkungen auf Pipeline -> jeder Befehl gleich lang, gleiche Ausführungszeit -> einheitliches Befehlsformat -> Load/Store-Architektur (Operationen nur über Register, explizite Befehle für Speicherzugriff -> Verringerung von Buskonflikten) Auswirkung auf Pipeline: -> durch geringen Befehlsumfang schnelleres Decode möglich -> durch einheitliche Ausführungszeit Vermeidung von dirty read und write Konflikten -> durch einheitliches Befehlsformat und Operation nur über Register einfachere Planung von Zugriffen auf Speicher 41.) Warum besitzen die meisten Architekturen nichtlineare, multifunktionale Pipelines unifunktional: multifunktional: linear: nichtlinear: alle Befehle haben ein Belegungsschema unterschiedliches Befehlsformat (jmp xyz und add x,y,z ; jmp <adresse> add <t>,<s1>,<s2>) jede Hardwareeinheit wird in genau einer Stufe der Pipe benötigt Überschneidung beim zugriff auf Hardwareeinheiten in unterschiedlichen Stufen der Pipe Warum? Nichtlinear: Multifunktional: lineare Pipe müsste länger sein und zugriff auf Hardwareeinheiten flexibel gestaltet werden -> hoher Aufwand in Silizium und Zeit zum Anpassen der Einheitenzuordnung, nichtlineare Pipe besser da hier durch Umsortieren der Befehle (z.b. durch Compailer) Strukturelle Konflikte vermieden werden können bei einer unifunktionalen Architektur würde jeder Befehl in jeder Stufe der Pipe die entsprechende Einheit belegen, durch multifunktionale Pipe können nicht benutzte Einheit von folgenden Befehlen bereits verwendet werden 42.) Welche Konflikte vermeidet man in der Pipe durch Harvard-Architektur -> getrennten Speicher und Bus für Daten und Befehle (Harvard) -> vermeidet strukturellen Konflikt IF und WB, da IF auf Code und WB auf Daten zugreift 43/44.) Was sind und warum kommt es zu Strukturellen Konflikten und Datenkonflikten in der Pipe? siehe 38

18 45.) Wozu dient das Scoreboard? Funktionsweise... -> im Scoreboard wird festgehalten welcher Befehl welche Register verwendet -> dient zur Vermeidung von dirty reads/writes (read_after_write und write_after_read und write_after_write RAW, WAR, WAW) Funktionsweise: -> wenn ein Befehl ein Register lesend benötigt wird in der Decodephase im Scoreboard nachgesehen ob dieses bereits schreibend verwendet wird, wenn nicht lesen sonst warten -> wenn ein Befehl ein Register schreibend verwenden will, schauen ob schon belegt ja: warten nein: ins scoreboard eine 1 für das entsprechende Register eintragen nach Abschluss der WB-Phase Freigabe in Scoreboard durch nullsetzen 46.) Warum Verarbeitung Sprungbefehl in Architekturen ohne Sprungvorhersage potentiell längere Verzögerung als jeder andere Konflikt? -> große Anzahl von bedingten Sprüngen ( ca. 11%) -> ohne Vorhersage verliert man 2 Takte durch annulieren der 2 nachfolgenden Befehle (ca. 10 Prozent Leistungseinbuße) -> Executephase kann nicht abgebrochen werden (bsp. DIV braucht 10 Takte, wenn der schon in der ALU ist muss er fertig abgearbeitet werden...) 47.) Qualität der Sprungvorhersage -> Einfluss auf die Länge der Pipe -> schlechte Sprungvorhersage und lange Pipe -> spätes feststehen ob Sprung genommen oder nicht -> viele nachfolgende Befehle bearbeitet -> müssen alle annuliert werden -> ineffektiv -> je besser Sprungvorhersage, desto länger kann Pipe sein -> je besser Sprungvorhersage, desto weniger Annulierungen nötig -> effektiver 48.) Vergleich statische und dynamische Sprungvorhersage, Erläutern statisch: ->durch den Programmierer oder Compiler (Analyse des Codes notwendig) indem vorbelegte bedingte Sprungbefehle verwendet werden (bei MMIX wird vor den bedingten Sprung ein P gestellt für hohe Wahrscheinlichkeit das dieser Sprung genommen wird, BZ unwahrscheinlich, PBZ seht wahrscheinlich) dynamisch: -> durch den Prozessor über Branchhistorybits in welchen die Sprunggeschichte des bedingten Sprunges gespeichert wird -> anpassen der Sprungwahrscheinlichkeit an den Programmablauf Vergleich: -> statische Voraussage hat Trefferquote von ca % -> ausreichend für kurze Pipelines, allerdings muss der Compailer den Code analysieren (sehr schwierig) -> dynamische Voraussage hat Trefferquote von ca. 98%, allerdings muss sich der Prozessor um die Verwaltung der Branchhistory kümmern

19 49.) Worin liegt der Nutzen einer statischen Sprungvorhersage, Anforderungen an Befehlssatz, welches Werkzeug führt die Vorhersage durch und wie gelangt man an die Notwendigen Eingaben -> Beschleunigung des Programmablaufs durch vermeiden von Annulierungen in der Pipe -> kein Aufwand für eine dynamische Sprungvorhersage -> Taken or Not Taken im Befehl implementiert -> Aussage ob Sprung wahrscheinlich oder unwahrscheinlich durch Mnemonic codiert -> Programmfortführung steht bereits nach Decode fest -> Eingaben von: -> Codeanalyse durch Compailer bzw. Profilbasierend, Vergabe von taken oder not taken an Gruppen von Befehlen (z.b. erkennen von Schleifenkonstrukten, If s...) -> Testen -> stupides rödeln lassen der App, Sprünge protokollieren 50.) Branchpredichtbist, Branchhistorytable, Branchadressbit, Branchtargetbuffer Branchpredichtbits: -> speichert die Sprungwahrscheinlichkeit Bsp: Bit Zustände Aufteilung not taken, 1 taken strongly not taken, 1 not taken, 2 taken, 3 strongly taken strongly not taken 7 strongly taken Wenn Sprung genommen wurde -> +1 sonst -1 Kleiner Wert: geringe Sprungwahrscheinlichkeit Branchhistorytable: -> speichert Sprünge, deren Branchpredictbits sowie die Adresse des Sprungs (siehe Branchadressbits!!!) sowie möglicherweise das Ziel des Sprunges (siehe Branchtargetbuffer!!!) Branchadressbit: -> die Bits der Adresse des Sprunges, mit welchem der Sprung in der Branchhistorytable identifiziert wird (bei MMIX der untern Bits der Adresse), die komplette Adresse des Sprunges wird zur eindeutigen Identifizierung ebenfalls gespeichert! Branchadressbit dient nur dem schnellen finden des Sprunges in der Branchhistorytable!!! Branchtargetbuffer: -> speichert das Ziel des Sprunges (keine Adressberechnung mehr nötig)

20 51.) Sprungvorhersage mittels Branchpredictbits erläutern und diskutieren Sie wie viele Bits gewählt werden sollten. -> jeder Sprung in der Branchhistorytable besitzt sogenannte Branchpredictbits -> diese geben Auskunft darüber, ob der Sprung genommen oder nicht genommen wurde -> Sprung genommen -> Counter +1, sonst 1 (siehe Skizze) -> siehe 50! Da mit einem Bit nur 2 Zustände gespeichert werden können ist die Falschvoraussagewahrscheinlichkeit ( schönes Wort!!!) in geschachtelten Schleifen sehr hoch (nach jedem Neustart einer inneren Schleife wird eine Falschvoraussage getätigt). Abhilfe schafft hier die Erweiterung der Branchpredictbits auf 2 (4 Zustände). Die Praxis hat gezeigt das mehr als 3 PBBit s kaum eine Leistungssteigerung bringen. 52.) Warum wurde der Branchtargetbuffer eingeführt? Aufbau? Welche Einträge? -> Ergebnis der Adressberechnung des Sprungziels steht erst nach Decode and Read zur Verfügung -> kostet Zeit -> deshalb Speichern des Sprungziels in Branchtargetbuffer (inkl. Befehlsadresse des Sprungs) -> auch möglich: Operartion, welche sich am Sprungziel befindet ebenfalls speichern Befehl kann direkt in Pipeline gepackt werden -> beinhaltet: Sprünge die genommen wurden Sprungadressencache

21 53.) Wann wird der Branchtargetbuffer untersucht, wann werden Einträge hinzugefügt, wann entfernt? Untersucht: -> während IF-Phase, da die Adresse des zu fetchenden Befehls bekannt ist kann somit direkt im BTB nachgesehen werden. Letztlich muss die Decode_and_Read-Phase ergeben ob ein Sprung genommen oder abgelehnt wird (denn erst an dieser Stelle ist ein Zugriff auf die Statusregister der ALU, welche bedinget Sprünge bestimmen, möglich) -> hinzufügen: Sprung ist noch nicht in BTB und wurde genommen -> gelöscht: Sprung ist im BTB und wurde nicht genommen 54.) Warum ist der Branchtargetbuffer nicht groß? -> parallele Suche notwendig damit schnell -> n Komparatoren a m Bits -> hoher Schaltungsaufwand -> deshalb ist er klein -> Programme beschäftigen sich 90% der Zeit mit 10 % des Codes -> Anzahl der Sprünge in einem solchen Segment abzählbar (meint relativ gering) 55.) Charaktersieren Sie den Returnadressbuffer... -> enthält Rücksprungadresse (Befehlsposition nach dem Sprungbefehl) für aufgerufene Routinen -> wenn Subroutine abgearbeitet keine Adressberechnung des Rücksprungziels notwendig -> kann in BHT oder BTB gespeichert werden 56.) Was versteht man unter Branchfolding? Vorteile? -> im BTB wird der Befehl, auf welchen der Sprung verweist, mitgeführt -> handelt es sich um einen unbedingten Sprung oder steht das Ergebnis eines bedingten Sprunges schon fest (keine statusändernder Befehl vor dem bedingten Sprung) kann die Operation aus dem BTB bereits als nächster Befehl in die Pipeline eingefügt werden, der Prefetchbuffer kann dann ebenfalls schon mit den Befehlen am Sprungziel (Sprungzieladresse +1) gefüllt werden BRANCH FOLDING