Also "Pipeline" dürfte klar sein - hier bitte keine Definition - das ist kein Lehrwerk. Wichtig (1.) Pipeline (2.) Pipeline-Stufe = Pipeline-Segment. (3.) Pipeline-Register (4.) Pipeline-Maschinentakt = Zeit die benötigt wird einen Befehl eine Stufe weiter zu schieben. (5.) Durchsatz einer Pipeline = Anzahl der Befehle, die die Pipeline pro Takt verlassen können. Stufen einer Befehls-Pipeline: - Befehl bereitstellen - Befehl decodieren - Operanden - Operation auf der ALU - Resultat zurückschreiben. IF - Instruction Fetch ID - Instruction Decoder/Register Fetch EX - Execute/Adress Calculation MEM - Memory Access WB - Write Back DLX-Pipeline: - Befehlsbereitstellungs- oder IF-Phase - Decodier und Operandenbereitstellungsphase oder ID-Phase - Ausführungs-Phase oder EX-Phase - Speicherzugriffsphase oder MEM-Phase - Resultatsspeicherphase oder WB-Phase (1.) Pipeline-Konflikte (2.) Pipeline-Hemmnisse (Pipeline Hazards) = Die Situationen, die zu Pipeline-Konflikten führen - Datenkonflikte: Operand steht in der Pipeline noch nicht zur Verfügung - Struktur und Ressourcenkonflikte: Zwei Pipeline-Stufen brauchen dieselbe Ressource gleichzeitig - Steuerflusskonflikte: Bei Programmsteuerbefehlen (Sprungbefehlen): Zieladresse noch nicht bekannt (1.) Datenabhängigkeiten: (a) Echte Datenabhängigkeit - Lese-nach-Schreibe-Konflikt (Read after Write - RAW) (b) Gegenabhängigkeit - Anti dependence - wird gelesen und anschließend überschrieben - WAR (c) Ausgabeabhängigkeit - Output Dependence - WAW - schreiben beide ins gleiche Register Behandlung von Datenabhängigkeit (1.) Durch den Compiler (2.) Leerlauf der Pipeline - Erkennung durch Hardware - Pipeline Leerlauf - Stalling - Pipeline-Sperrung - Interlocking Steuerflusskonflikte: (a) Steuerflussänderung: Sprungbefehle erzeugen Steuerflussänderung (b) Steuerflussabhängigkeiten (c) Steuerflusskonflikte Lösung: (1.) Statische Befehlsanordnung durch den Compiler (2.) Verzögerte Sprungtechnik - Delayed Branch Technique Wichtig sind Verzögerungsschlitze - Delay Slots. Entweder durch die Hardware - die Sprungbefehle erkennt. Und Leerbefehle einfügt - oder es macht unser Compiler. Also DLX macht Compiler - alle heutigen Prozessoren durch Hardware (1.) Pipeline-Leerlauf. Ineffizient (2.) Spekulation auf nicht genommene bedingte Sprünge. Das ist ganz raffiniert: Wenn wir die Sprünge als nicht genommen annehmen, dann tun wir einfach alle Befehle nach dem Sprung laden. Sollte jetzt der Sprung trotzdem genommen werden, dann müssen wir nicht neu laden. Sondern wir löschen die Befehle - das kann man ja einfach machen - das klingt jetzt kompliziert - aber das ist es gar nicht - wenn wir gleich die neuen Befehlen neu laden würden, das wäre wohl eine Katastrophe. Aber das machen wir. Wir laden nichts. Und das sieht schon schwer aus. Ist aber nicht. Wir fügen einfach jetzt, obwohl sie schon in der Pipeline sind 3 NOP's ein. Und wenn wir davon ausgehen, dass sie nichts verändern, die NOP's. Dann ist das gar kein Problem. Jetzt: (3.) Genomme Sprünge vorherberechnen: Sprungziel - Adresse muss nicht neu berechnet werden. Das heißt, tun wir jetzt einfach mal so, als ginge uns das gar nichts an - wie kompliziert das ist, eine Vorhersage zu machen oder zu sagen, welche Befehle geladen werden. Es geht nur um die Adresse. Die muss bekannt sein - sagen wir einfach mal so. Und dafür gibt es einen: Sprungziel-Cache. Sprungzieladress-Cache (Branch Target Adress Cache - BTAC) oder Sprungziel-Puffer (Branch Target Buffer - BTB) Der gehört zur IF-Stufe. Enthält: (1.) Adresse (Branch Adress) - also die Adresse von unserem Befehl - ist logisch, wir brauchen einen Index, in dem Cache. Und wenn wir beim Sprungbefehl sind, müssen wir sagen, wir sind hier bei diesem Befehl, was sind unsere Daten? (2.) Zieladresse (Target Adress) - das ist das worum es geht (3.) Optional - Vorhersagebits (Prediction Bits) - ist logisch, dass man machen kann, aber nicht muss - nette Erweiterung für eine mögliche Vorhersage. - Dynamische Sprungvorhersage - Sprungziel-Cache (Branch Target Cache) - Rücksprungadressstapel (Return Adress Cache) bei CALL Einfachste Sprungvohrsagen: (1.) Predict always not taken (2.) Predict always taken (3.) Predict backward taken, forward not taken. Dann kommen wir jetzt zu Super-Skalar. Davon die Prozessor-Pipeline. Bei einer Pipeline, führen wir zwar mehrere Befehle zeitlich überlappend gleichzeitig, in dem jede der Mikrobefehle gleichzeitig ausgeführt werden, aber: Bei einem Superskalaren-Prozessor führen wir gleichzeitig mehrere Befehle gleichzeitig aus. Also ich hatte an Parallelität: (1.) MMX (2.) Pipelining (3.) Mehrkern Das muss aber heißen: (1.) MMX (2.) Pipelining (3.) Superskalar (4.) Mehrkern. Wenn da steht add r0, r1 add r2, r3 add r4, r5 add r6, r7 add r8, r9 Dann können die in die Pipeline geholt werden, einer nach dem anderen: Dann kommt: add r0, r1 in der IF-Phase add r2, r3 in der IF-Phase und add r0, r1 in der ID-Phase add r4, r5 in der IF-Phase und add r2, r3 in der ID-Phase und add r0, r1 in der EX-Phase usw. Aber sie können auch auf ein Mal 5 Befehle auf ein Mal holen add r0, r1 add r2, r3 add r4, r5 add r6, r7 add r8, r9 Sie haben Superskalar 5-Ausführungseinheiten und holen alle 5 Also (1.) befehl 11 befehl 12 befehl 13 befehl 14 befehl 15 (2.) befehl 21 befehl 22 befehl 23 befehl 24 befehl 25 Jetzt kann man das noch mischen: Superskalar mit Pipelining. Dann holt man 5 Befehle und steckt sie nach dem bekannten Muster jeweils in eine Pipeline. Also zunächst befehl11, befehl21 in die Pipeline der ersten Ausfürhungseinheite befehl12, befehl22 in die Pipeline der zweiten Ausfürhungseinheite usw. Dynamische Sprungvorhersagetechnik Spekulationsrichtung wird in Abhängigkeit vom bisherigen Programmablauf getroffen. Prädiktor: Bit Ein- und Zweibitprediktoren (1.) Ein-Bit-Prädiktor: - genommen - nicht genommen - T (taken - genommen) - NT (not taken - nicht genommen) T->NT NT->T T->T NT->NT Jetzt kommt noch eine Erweiterung: (1.) MMX (2.) Pipelining (3.) Superskalar (4.) Multithreading (5.) Mehrkern.