2.3 Einfache Prozessoren und Prozessorkerne Grundkonzept des von-Neumann-Prinzips
von-Neumann-Prinzip Der Rechner ist zentral gesteuert und aus Funktionseinheiten aufgebaut. (Zentraleinheit, Speicher, Ein-/Ausgabeeinheit, Verbindungseinrichtung) Der Rechner ist nicht speziell auf ein zu bearbeitendes Problem zugeschnitten. Zur Lösung eines Problems wird ein eigenes Programm im Speicher ablegt. ("programmgesteuerter Universalrechner") Programme und Daten (und Ergebnisse) liegen im selben Speicher. Der Speicher besteht aus Plätzen fester Wortlänge, die über eine bestimmte Adresse einzeln angesprochen werden können.
Funktionseinheiten der von-Neumann-Architektur Prozessor, Zentraleinheit (CPU: "central processing unit") übernimmt die Ablaufsteuerung und Ausführung der Befehle Steuerwerk ("control unit") interpretiert die Maschinenbefehle erzeugt Steuerkommandos für andere Komponenten Rechenwerk (ALU: "arithmetic logical unit") führt alle Befehle aus, bis auf Ein-/Ausgabe- und Speicherbefehle Ein-/Ausgabesystem Schnittstelle des Rechners nach außen Ein- und Ausgabe von Programmen und Daten Speicher Ablage der Daten und Programme in Form von Bitfolgen Verbindungseinrichtung
Charakteristika des Operationsprinzips Zu jedem Zeitpunkt führt die CPU nur einen einzigen Befehl aus, und dieser kann (höchstens) einen Datenwert bearbeiten (SISD). Code und Daten stehen ohne Unterscheidung im selben Speicher. Es existieren keine speichertechnischen Maßnahmen, um sie vor ungerechtfertigtem Zugriff zu schützen. Der Speicher ist unstrukturiert und wird linear adressiert. Die Interpretation eines Speicherinhalts hängt nur vom aktuellen Kontext des laufenden Programms ab. Zwei-Phasen-Konzept der Befehlsverarbeitung: In der Interpretations-Phase wird aufgrund der durch den Befehlszähler angezeigten Adresse der Inhalt einer Speicherzelle geholt und als Befehl interpretiert. In der Ausführungs-Phase wird aufgrund der im Befehl enthaltenen Adresse der Inhalt einer weiteren Speicherzelle geholt und als Datenwert verarbeitet. Der Befehlsablauf folgt einer sequentiellen Befehlsfolge und ist streng seriell.
Vor- und Nachteile der von-Neumann-Architektur Vorteile Prinzip des minimalen Hardwareaufwandes Prinzip des minimalen Speicheraufwandes
Nachteile der von-Neumann-Architektur Die Verbindungseinrichtung (Hauptspeicher Û CPU) stellt einen Engpass dar: „von-Neumann-Flaschenhals“ Die Programmierung muss den sequentiellen Verkehr durch den von-Neumann-Flaschenhals planen Þ Auswirkungen auf höhere Programmiersprachen ("intellektueller Flaschenhals") geringe Strukturierung der Daten Maschinenbefehl bestimmt Operandentyp Þ semantische Lücke Datenstrukturen und Operationen einer höheren Programmiersprache Maschinendaten- strukturen und Maschinenoperationen Compiler
Harvard-Architektur Variante des von-Neumann-Rechner Für Code und Daten gibt es getrennte Speicher und getrennte Zugriffwege zum Prozessorkern. Engpass durch die zentrale Verbindungseinrichtung beim von-Neumann-Rechner wird vermieden oder zumindestens erweitert. heute insbesondere bei digitalen Signalprozessoren (DSPs) Bei fast allen heutigen Mikroprozessoren ist der auf dem Prozessor-Chip befindlichen Primär-Cache-Speicher als Harvard-Cache-Architektur organisiert. Code- und Daten-Cache-Speicher sind getrennt und mit eigenen Speicherverwaltungseinheiten und Zugriffspfaden versehen. Ansonsten wird das Operationsprinzip der von-Neumann-Architektur beibehalten.
2.3.2 Grundlegender Aufbau eines Mikroprozessors
Überlappende Befehlsausführung Befehl n: Bereitstellung u. Decodierung Ausführung Befehl n: Bereitstellung u. Decodierung Ausführung Befehl n+1:
2.3.4 Grundlegende Pipeline-Stufen Pipelining — „Fließband-Bearbeitung“ „ Pipelines beschleunigen die Ausführungsgeschwindigkeit eines Rechners in gleicher Weise wie Henry Ford die Autoproduktion mit der Einführung des Fließbandes revolutionierte.“ (Peter Wayner 1992) Befehlspipeline eines Rechners: Die Befehlsbearbeitung wird in n funktionelle Einheiten gegliedert. Ausführung geschieht überlappt.
Pipelining Unter dem Begriff Pipelining versteht man die Zerlegung einer Maschinenoperation in mehrere Phasen, die dann von hintereinander geschalteten Verarbeitungseinheiten taktsynchron bearbeitet werden, wobei jede Verarbeitungseinheit genau eine spezielle Teiloperation ausführt. Die Gesamtheit dieser Verarbeitungseinheiten nennt man eine Pipeline. Bei einer Befehlspipeline (Instruction Pipeline) wird die Ausführung eines Maschinenbefehls in verschiedene Phasen unterteilt, aufeinanderfolgende Maschinenbefehle werden jeweils um einen Taktzyklus versetzt ausgeführt.
Pipelining Jede Stufe der Pipeline heißt Pipeline-Stufe oder Pipeline-Segment. Pipeline-Stufen werden durch getaktete Pipeline-Register (auch latches genannt) getrennt. Ein Pipeline-Maschinentakt ist die Zeit, die benötigt wird, um einen Befehl eine Stufe weiter durch die Pipeline zu schieben. Idealerweise wird ein Befehl in einer k-stufigen Pipeline in k Takten von k Stufen ausgeführt. Wird in jedem Takt ein neuer Befehl geladen, dann werden zu jedem Zeitpunkt unter idealen Bedingungen k Befehle gleichzeitig behandelt und jeder Befehl benötigt k Takte, bis zum Verlassen der Pipeline.
Pipeline-Stufen und Pipeline-Register
Pipelining Man definiert die Latenz als die Zeit, die ein Befehl benötigt, um alle k Pipeline-Stufen zu durchlaufen. Der Durchsatz einer Pipeline wird definiert als die Anzahl der Befehle, die eine Pipeline pro Takt verlassen können. Dieser Wert spiegelt die Rechenleistung einer Pipeline wider.
Befehlsausführung (n = Anzahl Befehlsausführungen, k = Anzahl der Pipeline-Stufen) hypothetischen Prozessors ohne Pipeline: n*k Takte Pipeline-Prozessor mit einer k-stufigen Pipeline: k+n-1 Takte (unter der Annahme idealer Bedingungen mit einer Latenz von k Takten und einem Durchsatz von 1) Daraus ergibt sich eine Beschleunigung (speedup) von S = n*k / (k + n - 1) = k / (k/n + 1 - 1/n). Ist die Anzahl der in die Pipeline gegebenen Befehle unendlich, so ist die Beschleunigung gleich der Anzahl Pipeline-Stufen k
2.4 Phasen der Befehlsausführung einer fünfstufigen Befehlspipeline Befehl bereitstellen, Befehl decodieren, Operanden (in den Pipeline-Registern) vor der ALU bereitstellen, Operation auf der ALU ausführen und das Resultat zurückschreiben
Grundlegendes Befehlspipelining
Phasen der Befehlsausführung einer fünfstufigen Befehlspipeline Befehlsbereitstellungsphase (Instruction Fetch): Der Befehl, der durch den Befehlszähler adressiert ist, wird aus dem Hauptspeicher oder dem Cache-Speicher in einen Befehlspuffer geladen. Der Befehlszähler wird weitergeschaltet. Decodier- und Operandenbereitstellungsphase (Decode/Operand fetch): Aus dem Operationscode des Maschinenbefehls werden prozessorinterne Steuersignale erzeugt (1. Takthälfte). Die Operanden werden aus Registern bereitgestellt (2. Takthälfte). Ausführungsphase (ALU Operation): Die Operation wird auf den Operanden ausgeführt. Bei Lade-/Speicherbefehlen wird die effektive Adresse berechnet. Speicherzugriffsphase (memory access): Der Speicherzugriff wird durchgeführt. Resultatspeicherphase (Write Back): Das Ergebnis wird in ein Register geschrieben (1. Takthälfte).
Pipeline (Übersicht)
Pipeline (Instruction fetch) I-cache Add IF/ID Registers Instruction fetch (IF) MUX PC Instruction Register 4 1 32
Pipeline (Instruction Decode) Register File Register Addressing Result Register Selector ID/EX Registers I F / D R e g i s t r Instruction decode/ register fetch (ID) PC ALU Input Register 1 Register 2 Immediate Instruction 5 16 32 Sign Extended Registers Write Value
Pipeline (Execute) EX/MEM Registers ID/EX address calculation (EX) Execution/effective MUX ALU PC ALU Input Register 1 Register 2 Immediate Register True/False Conditional 32 ALU Output 1 Zero ? Store Value
Pipeline (MEM&WB) back (WB) MUX Write MEM/WB Registers D-cache MUX back (WB) Write MEM/WB Registers EX/MEM Memory access/branch completion (MEM) Load Memory Data Register ALU Result Register Store Value ALU Output True/False Conditional Load/Store Address Jump/Branch Target Address ALU Result Value
Diskussion Die Zykluszeit der Pipeline wird vom kritischen Pfad diktiert: der langsamsten Pipeline-Stufe. Alle Stufen nutzen verschiedene Ressourcen. Im Idealfall wird in jedem Takt ein Befehl in die Pipeline eingefüttert. (CPI=1).
2.4.3 Pipeline-Konflikte - drei Arten von Pipeline-Konflikten Pipeline-Konflikt: die Unterbrechung des taktsynchronen Durchlaufs der Befehle durch die einzelnen Stufen einer Befehls-Pipeline. Datenkonflikte: ein Operand ist in der Pipeline (noch) nicht verfügbar. Datenkonflikte werden durch Datenabhängigkeiten im Befehlsstrom erzeugt Struktur- oder Ressourcenkonflikte treten auf, wenn zwei Pipeline-Stufen dieselbe Ressource benötigen, auf diese aber nur einmal zugegriffen werden kann. Steuerflusskonflikte treten bei Programmsteuerbefehlen auf, wenn in der Befehlsbereitstellungsphase die Zieladresse des als nächstes auszuführenden Befehls noch nicht berechnet ist bzw. Wenn im Falle eines bedingten Sprunges noch nicht klar ist, ob überhaupt gesprungen wird.
2.4.4 Datenkonflikte und deren Lösungsmöglichkeiten Man betrachte zwei aufeinander folgende Befehle Inst1 und Inst2 Es besteht eine echte Datenabhängigkeit (true dependence) st von Inst1 zu Inst2, wenn Inst1 seine Ausgabe in ein Register Reg (oder in den Speicher) schreibt, das von Inst2 als Eingabe gelesen wird. Es besteht eine Gegenabhängigkeit (antidependence) sa von Inst1 zu Inst2, falls Inst1 Daten von einem Register Reg (oder einer Speicherstelle) liest, das anschließend von Inst2 überschrieben wird. Es besteht eine Ausgabeabhängigkeit (output dependence) so von Inst2 zu Inst1, wenn beide in das gleiche Register Reg (oder eine Speicherstelle) schreiben und Inst2 sein Ergebnis nach Inst1 schreibt. Gegenabhängigkeiten und Ausgabeabhängigkeiten werden häufig auch falsche Datenabhängigkeiten oder entsprechend dem englischen Begriff Name Dependency Namensabhängigkeiten genannt.
Abhängigkeitsgraph S1:ADD R1,R2,2 ; R1 = R2+2 S2:ADD R4,R1,R3; R4 = R1+R3 S3:MULT R3,R5,3 ; R3 = R5*3 S4:MULT R3,R6,3 ; R3 = R6*3 Abhängigkeitsgraph
Datenkonflikte Datenabhängigkeiten zwischen zwei Befehlen können Datenkonflikte verursachen, wenn die beiden Befehle so nahe beieinander sind, dass ihre Überlappung innerhalb der Pipeline ihre Zugriffsreihenfolge auf ein Register oder einen Speicherplatz im Hauptspeicher verändern würde. drei Arten von Datenkonflikten : Ein Lese-nach-Schreibe-Konflikt (Read After Write, RAW) wird durch eine echte Datenabhängigkeit verursacht Ein Schreibe-nach-Lese-Konflikt (Write After Read, WAR) wird durch eine Gegenabhängigkeit verursacht Ein Schreibe-nach-Schreibe-Konflikt (Write After Write, WAW) wird durch eine Ausgabeabhängigkeit verursacht
Datenkonflikte in einer Befehls-Pipeline IF ID EX MEM load Reg1,A load Reg2,B add Reg2,Reg1,Reg2 mul Reg1,Reg2,Reg1 WB time cycle time
WAR and WAW: can they happen in our pipeline? WAR and WAW can’t happen in DLX 5 stage pipeline because: All instructions take 5 stages, Register reads are always in stage 2, and Register writes are always in stage 5. WAR and WAW may happen in more complicated pipes.
Pipeline conflict due to a data hazard add Reg2,Reg1,Reg2 mul Reg1,Reg2,Reg1 IF ID EX MEM WB time cycle time Reg2 old Reg2 new wrong register read!
Lösungen für Datenkonflikte Software-Lösungen (Compiler scheduling) no-op Befehle einfügen Befehlsanordnung (instruction scheduling oder pipeline scheduling): Befehlsumordnungen, um no-ops zu entfernen Hardware-Lösungen: Konflikt muss per HW entdeckt werden!! Leerlauf der Pipeline: Die einfachste Art, mit solchen Datenkonflikten umzugehen ist es, Inst2 in der Pipeline für zwei Takte anzuhalten. Auch als Pipeline-Sperrung (interlocking) oder Pipeline-Leerlauf (stalling) bezeichnet. Forwarding: Wenn ein Datenkonflikt erkannt wird, so sorgt eine Hardware-Schaltung dafür, dass der betreffende Operand nicht aus dem Universalregister, sondern direkt aus dem ALU-Ausgaberegister der vorherigen Operation in das ALU-Eingaberegister übertragen wird. Forwarding with interlocking: Forwarding löst nicht alle möglichen Datenkonflikte auf.
Data hazard: Hardware solution by interlocking add Reg2,Reg1,Reg2 mul Reg1,Reg2,Reg1 IF ID EX MEM WB time Register Reg2 bubbles
Data hazard: Hardware solution by forwarding add Reg2,Reg1,Reg2 mul Reg1,Reg2,Reg1 IF ID EX MEM WB time
Pipeline hazard due to data dependence unresolvable by forwarding load Reg2,B add Reg2,Reg1,Reg2 IF ID EX MEM WB not possible! time cycle time
Unremovable pipeline bubble due to data dependence load Reg2,B add Reg2,Reg1,Reg2 IF ID EX MEM WB time bubble
2.4.5 Steuerflusskonflikte und deren Lösungsmöglichkeiten Steuerflussabhängigkeiten verursachen Steuerflusskonflikte in der DLX-Pipeline, da der Programmsteuerbefehl erst in der ID-Stufe als solcher erkannt und damit bereits ein Befehl des falschen Programmpfades in die Pipeline geladen wurde. Zu den Programmsteuerbefehlen gehören: die bedingten und die unbedingten Sprungbefehle, die Unterprogrammaufruf- und -rückkehrbefehle sowie die Unterbrechungsbefehle Nach bedingten Sprüngen, die genommen werden, startet die befehlsfolge mit drei Takten Latenz. Allerdings sind schon drei Befehle des falschen Pfads in der Pipeline.
Leertakte nach einem genommenen bedingten Sprung branch instruction branch target IF ID EX MEM WB time PC three bubbles
Lösung: Sprungrichtung schneller eintscheiden Sprungrichtung so schnell als möglich entscheiden und Zieladresse so schnell als möglich berechnen. Am besten bereits in der ID-Stufe nur noch ein Takt Latenz
Solution: Calculation of the branch direction and of the branch target address in ID stage However, then the ALU can no more be used for calculating the branch target address a structural hazard, which can be avoided by an additional ALU for the branch target address calculation in ID stage. And a new unremovable pipeline hazard arises: An ALU instruction followed by an (indirect) branch on the result of the instruction will incur a data hazard stall even when the result value is forwarded from the EX to the ID stage (similar to the data hazard from a load with a succeeding ALU operation that needs the loaded value). The main problem with this pipeline reorganization: decode, branch target address calculation, and PC write back within a single pipeline stage a critical path in the decode stage that reduces the cycle rate of the whole pipeline. Assuming an additional ALU and a write back of the branch target address to the PC already in the ID stage, if the branch is taken, only a one cycle delay slot arises
Software-Lösungen Verzögerte Sprungtechnik (delayed branch technique): Der Compiler füllt die Verzögerungszeitschlitze (delay slots). Ausfüllen der Verzögerungszeitschlitze mit Leerbefehlen. Statische Befehlsanordnung: Füllen mit Befehlen, die in der logischen Programmreihenfolge vor dem Sprung liegen Angewandt in der ersten Generation von RISC-Prozessoren, z.B. IBM 801, MIPS, RISC I, SPARC. In superskalaren Prozessoren, die mehr als einen Befehl holen und gleichzeitig verarbeiten können, erschwert die verzögerte Sprungtechnik die Befehlszuordnungslogik und die Implementierung präziser Unterbrechungen.
Hardware-Lösungen Pipeline-Leerlauf (Interlocking): einfachste, aber ineffizienteste Methode Spekulation auf nicht genommene bedingte Sprünge: die direkt nach dem Sprungbefehl stehenden drei Befehle in die Pipeline werden geladen Falls die Sprungbedingung zu „genommen“ ausgewertet wird, müssen die drei Befehle wieder gelöscht werden und wir erhalten die üblichen drei Pipeline-Blasen. Falls der Sprung nicht genommen wird, so können die drei Befehle als Befehle auf dem gültigen Pfad weiterverarbeitet werden, ohne dass ein Leertakt entsteht. Diese Technik stellt die einfachste der sogenannten statischen Sprungvorhersagen dar.
Branch prediction Branch prediction foretells the outcome of conditional branch instructions. Excellent branch handling techniques are essential for today's and for future microprocessors.
Hardware solution (Branch Prediction) IF stage finds a branch instruction predict branch direction (Branch Target Buffer necessary!) The branch delay slots are speculatively filled with instruction of the consecutively following path of the path at the target address After resolving of the branch direction decide upon correctness of prediction In case of misprediction discard wrongly fetched instructions
Two Basic Techniques of Branch Prediction Static Branch Prediction: The prediction direction for an individual branch remains always the same! Dynamic Prediction: The prediction direction depends upon previous (the “history” of) branch executions.
Static Branch Prediction The prediction direction for an individual branch remains always the same! the machine cannot dynamically alter the branch prediction (in contrast to dynamic branch prediction which is based on previous branch executions). So static branch prediction comprises: machine-fixed prediction (e.g. always predict taken) and compiler-driven prediction. If the prediction followed the wrong instruction path, then the wrongly fetched instructions must be squashed from the pipeline.
Static Branch Prediction - machine-fixed wired taken/not-taken prediction: The static branch prediction can be wired into the processor by predicting that all branches will be taken (or all not taken). direction based prediction, backward branches are predicted to be taken and forward branches are predicted to be not taken ==> helps for loops
Static Branch Prediction - compiler-based Opcode bit in branch instruction allows the compiler to reverse the hardware prediction. There are two approaches the compiler can use to statically predict which way a branch will go: it can examine the program code, or it can use profile information (collected from earlier runs)
2.4.6 Sprungzieladress-Cache Der Sprungzieladress-Cache (Branch-target Address Cache, BTAC) oder Sprungzielpuffer (Branch-target Buffer, BTB) ist ein kleiner Cache-Speicher, auf den in der IF-Stufe der Pipeline zugegriffen wird. Er enthält Paare von Spungbefehls- und Sprungzieladressen.
Sprungzieladress-Cache
Hardware solutions: BTAC The BTAC functions as follows: The IF stage compares PC against the addresses of jump and branch instructions in BTAC (Field 1). ---- Suppose a match: If the instruction is a jump, then the target address is used as new PC. If the instruction is a branch, a prediction is made based on information from BTAC (Field 3) as to whether the branch is to be taken or not. If predict taken, the most recent branch target address is read from BTAC (Field 2) and used to fetch the target instruction. Of course, a misprediction may occur. Therefore, when the branch direction is actually known in the MEM stage, the BTAC can be updated with the corrected prediction information and the branch target address.
BTAC (continued) To keep the size of BTAC small, only predicted taken branch addresses may be stored. Effective with static prediction! If the hardware alters the prediction direction due to the history of the branch, this kind of branch prediction is a dynamic branch prediction. Now the branch target address (of "taken") is stored also if the prediction direction may be "not taken". If the branch target address is removed for branches that are not taken ==> BTAC is better utilized however branch target address must be newly computed if the prediction direction changes to "predict taken"
2.4.8 Strukturkonflikte und deren Lösungsmöglichkeiten Struktur- oder Ressourcenkonflikte treten in unserer einfachen DLX-Pipeline nicht auf. Einen Strukturkonflikt kann man demonstrieren, wenn man unsere DLX-Pipeline leicht verändert: Wir nehmen an, die Pipeline sei so konstruiert, dass die MEM-Stufe in der Lage ist ebenfalls auf den Registersatz zurückzuschreiben.
Ein Strukturkonflikt, der durch eine veränderte Pipeline-Organisation verursacht wird load Reg2,A mul Reg3,Reg4,Reg5 IF ID EX MEM WB time cycle time Register file
Hardware-Lösungen zur Vermeidung von Strukturkonflikten Arbitrierung mit Interlocking: Die Arbitrierungslogik erkennt den Strukturkonflikt und hält den im Programmfluss späteren der beiden um die Ressource konkurrierenden Befehle an. Übertaktung: die Ressource, die den Strukturkonflikt hervorruft, schneller zu takten als die übrigen Pipeline-Stufen. In diesem Fall könnte die Arbitrierungslogik zweimal auf die Ressource zugreifen und die Ressourcenanforderungen in der Ausführungsreihenfolge erfüllen Ressourcenreplizierung: Vervielfachen von Hardware-Ressourcen .
2.4.9 Ausführung in mehreren Takten Problem Mehrtaktbefehle mögliche Lösungen: Pipeline anhalten: Die einfachste Weise, mit einem solchen Strukturkonflikt umzugehen, ist es, Inst2 in der Pipeline anzuhalten, bis Inst1 die EX-Stufe verlässt Ressourcen-Pipelining: EX-Stufe selbst als Pipeline implementieren die EX-Stufe kann in jedem Takt einen neuen Befehl entgegen nehmen (der Durchsatz ist 1). Ressourcenreplizierung: z. B. mehrere Ausführungseinheiten
Example of a WAW Hazard Caused by a Long-latency Operation and Out-of-order Completion div Reg3,Reg11,Reg12 mul Reg3,Reg1,Reg2 IF ID EX ... MEM WB time Register Reg3 several cycles later
Solutions to the Problem of Multiple-cycle Operations Interlocking: stall Inst2 in the pipeline until Inst1 leaves the EX stage pipeline bubbles, slow down a single pipelined FU: general-purpose FU for all kind of instructions slows down execution of simple operations multiple FUs: Inst2 may proceed to some other FU and overlap its EX stage with the EX stage of Inst1 out-of-order execution! instructions complete out of the original program order WAW hazard caused by output dependence may occur delaying write back of second operation solves WAW hazard further solutions: scoreboarding, Tomasulo, reorder buffer in superscalar
WAR possible?? WAR may occur if instruction can complete before a previous instruction reads its operand extreme case of o-o-o execution superscalar processors, not our simple RISC processor which” issues” and starts execution in-order)
Pipelining basics: summary Hazards limit performance Structural hazards: need more HW resources Data hazards: need detection and forwarding Control hazards: early evaluation, delayed branch, prediction Compilers may reduce cost of data and control hazards Compiler Scheduling Branch delay slots Static branch prediction Increasing length of pipe increases impact of hazards; pipelining helps instruction bandwidth, not latency Multi-cycle operations (floating-point) and interrupts make pipelining harder