Computerarchitectuur H&P App. C. Pipelining Kristian Rietveld http://ca.liacs.nl/
Motivatie Pipelining is een techniek die tegenwoordig in iedere CPU wordt gebruikt om de performance te verbeteren. Idee: gebruik maken van parallelisme dat te vinden is in de verschillende acties die nodig zijn om een instructie volledig uit te voeren. Laten we ons verplaatsen naar...
Assembly lines Wat zien we in de assembly line? De productie bestaat uit meerdere stappen. De stappen worden in parallel uitgevoerd. Productietijd: tijd die het kost om alle stappen te doorlopen. Throughput: aantal auto's per uur. - Aantal auto's dat per uur uit de laatste stap komt. - De throughput wordt gelimiteerd door de langzaamste stap! - We moeten de stappen balanceren.
Terug naar de CPU Een CPU voert instructies uit en het uitvoeren van een instructie bestaat uit verschillende stappen. We gaan hier exact hetzelfde principe toepassen: werk aan meerdere instructies in parallel. We noemen elke stap een pipe(line) stage of segment. De tijd tussen de stappen noemen we processor cycle. - Lengte bepaald door de tijd benodigd voor de langzaamste stage. - Vaak 1 clock cycle, heel soms 2, maar nooit meer.
Ideale geval Als de stages perfect zijn gebalanceerd en onder ideale omstandigheden, dan is de gemiddelde tijd per instructie met pipelining terug te brengen naar: Time per instruction on unpipelined machines Number of pipeline stages De speedup door pipelining is gelijk aan het aantal stages. - n stages: we werken aan n instructies tegelijkertijd. - Stel het uitvoeren van een instructie duurt 5 tijdunits: 1/5 instructie per tijdunit. Nu beginnen we elke tijdunit aan een nieuwe instructie, dus elke tijdunit is een instructie klaar. 1 instructie per tijdunit, versnelling factor 5. En natuurlijk komen we nooit op het ideale geval uit: - Stages niet perfect gebalanceerd, pipelining heeft wat overhead,...
Performanceverbetering Houd goed in de gaten ten opzichte van wat je de performance verbetering in kaart brengt. Startpunt: een processor die meerdere clock cycles per instructie nodig heeft, CPI > 1. Zoals we al zagen gaat in dit geval de CPI omlaag. Of: de processor heeft 1 lange clock cycle per instructie nodig. In dat geval wordt het door middel van pipelining mogelijk de clock cycle korter te maken (klokfrequentie gaat omhoog).
Pipelining Pipelining is een techniek in hardware, de programmeur ziet hier niets van, hoeft hier niets voor te doen. We bestuderen nu eerst pipelining aan de hand van een klassieke 5-stage RISC pipeline. - In hoofdstuk 3 bekijken we allerhande geavanceerde technieken die hierop voortbouwen. - In inleveropdracht 2 zullen we deze klassieke pipeline implementeren. Nu eerst: 5 benodigde stappen voor het uitvoeren van een instructie.
Implementatie RISC ISA We bekijken een eenvoudige implementatie van een RISC ISA. - In dit ontwerp heeft elke instructie ten hoogste 5 cycles nodig. - We bekijken alleen integer operaties. De stappen zijn als volgt: - Instruction Fetch (IF) Instruction Decode, Register fetch (ID) Execution (EX) Memory (MEM) Write-back (WB)
Instruction Fetch (IF) Het idee is het volgende: - Stuur de program counter (PC) naar het geheugen. - Haal de instructie op dat adres op. - Laat de PC naar de volgende instructie verwijzen (4 optellen).
Instruction Decode (ID) Decodeer de zojuist opgehaalde instructie. - Welk type? Wat zijn de operanden? Daarnaast worden benodigde register-operanden opgehaald uit de register file. - Vergelijk de registers om te kijken of er moet worden gebrancht. - Voer sign extension uit op de immediate waarde in de instructie, als nodig. - Bereken mogelijke branch target door PC en immediate op te tellen. (Decoding en register read kunnen in parallel in RISC, omdat de registernummers altijd op dezelfde plaats in de instructie staan).
Execution (EX) De ALU voert de daadwerkelijke operatie uit. De operanden zijn klaar gezet in de voorgaande cycle. Wat er wordt gedaan hangt af van instructie-type: - Register-register: voer de gevraagde operatie uit op de data opgehaald uit de register file. - Register-immediate: hetzelfde, maar dan op 1 register en immediate. - Memory reference: tel base en offset bij elkaar op om het geheugenadres te bepalen (effective address). Memory reference wordt dus uitgevoerd in geval van load/store instructie.
Memory access (MEM) Voer de load of store instructie uit. - Adres is berekend in voorgaande cycle. Ander type operatie: dan gebeurt er niets.
Write back (WB) Het resultaat wordt geschreven naar het destination register in de register file. - ALU instructie: resultaat afkomstig van ALU. - Load instruction: resultaat afkomstig van memory system.
Executietijden Branch: 2 cycles Store: 4 cycles Alle andere instructies: 5 cycles - (Moeten allen door tot en met de write-back stage). (Enige optimalisaties zijn hier natuurlijk ook mogelijk zonder pipelining).
Op naar de pipeline Eigenlijk zijn er weinig wijzigingen nodig: we kunnen gewoon elke clock cycle aan een nieuwe instructie beginnen! Dus hoewel een instructie 5 cycles kost om uit te voeren, beginnen we elke cycle aan een nieuwe instructie.
Pipeline voorbeeld
RISC RISC blijkt uitermate geschikt voor pipelining door de eenvoud. Je moet er bijv. voor zorgen dat de ALU binnen 1 cycle niet door twee instructies tegelijk wordt gebruikt. - RISC: ALU operatie of load-store, dus de ALU wordt of voor een echte ALU operatie gebruikt of voor adresberekening. We gebruiken aparte instructie en data geheugens (split caches), hierdoor kunnen IF en MEM tegelijkertijd plaatsvinden. Register file wordt op 2 plaatsen gebruikt: ID, WB. Dus de register file moet 2 reads en 1 write per clock cycle kunnen uitvoeren.
RISC pipeline Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.2.
Pipeline registers De verschillende instructies in uitvoering moeten van elkaar worden geïsoleerd en mogen elkaar niet beïnvloeden. Tussentijdse resultaten moeten worden opgeslagen. Dit gebeurt in pipeline registers die tussen de stages worden geplaatst. De resultaten van ID worden opgeslagen en dienen in de volgende cycle als bron voor de EX stage. - Naam van pipeline register: ID/EX
Pipeline registers (2) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.3.
Throughput vs. Latency Het is duidelijk dat middels pipelining de throughput wordt verhoogd. De latency neemt echter toe! Door pipeline kost het iets meer tijd om een individuele instructie uit te voeren. - Pipeline register delay, clock skew, enz. Dus hoewel een enkele instructie niet sneller wordt uitgevoerd, zorgt de hogere throughput er juist wel voor dat een programma sneller wordt uitgevoerd (kleinere execution time).
Dan nu het slechte nieuws... Tot nu toe klinkt het allemaal heel goed, helaas is het niet zo eenvoudig... Instructies zijn afhankelijk van elkaar - De volgende instructie kan pas worden uitgevoerd, wanneer de voorgaande af is. - Dit zorgt voor vertragingen. Branching: zolang we de uitkomst niet weten, weten we niet waar we verder moeten met het uitvoeren van het programma.
Hazards Een hazard verhindert de volgende instructie in het programma om de pipeline te betreden. We onderscheiden 3 klassen van hazards: Structural hazards. Veroorzaakt door resource conflicts. Data hazards. Veroorzaakt door afhankelijkheden tussen instructies. Control hazards. Veroorzaakt door branches en andere instructies die de PC aanpassen.
Omgaan met hazards Wanneer er een hazard optreedt moet de uitvoering van de volgende instructie worden vertraagd. - We spreken dan over een pipeline stall. Instructies issued later in tijd worden opgehouden. Instructies issued eerder in tijd moeten verder worden verwerkt om de stall op te lossen. Door het ophouden van instructies ontstaan er 'bubbels' in de pipeline.
Structural hazards Een structural hazard komt voor wanneer een bepaalde combinatie van instructies niet kan worden uitgevoerd door resource conflicten. - Voorbeeld: er is 1 register-file write port, maar er bestaat een situatie waarin de pipeline 2 register writes in 1 clock cycle wil uitvoeren. - Voorbeeld: er is een gedeelde single-memory pipeline voor data en instructies. Wanneer een instructie een data memory referentie bevat, kan deze niet tegelijkertijd met de instruction fetch voor de volgende instructie worden uitgevoerd.
Structural hazards (2) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.4.
Structural hazards (3) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.5.
Structural hazards (4) Als een processor kan worden verbeterd om geen structural hazards te hebben, zal deze altijd een lagere CPI hebben. Waarom doen de ontwerpers dit niet altijd? - Heeft te maken met kosten. Een structural hazard komt soms maar weinig voor en daarom wegen de kosten om deze geheel te vermijden niet op tegen de baten.
Data hazards Een data hazard komt voor wanneer door pipelining de volgorde waarin de operanden worden gelezen/geschreven verandert ten opzichte van sequentiele executie. Voorbeeld: DADD DSUB AND OR XOR R1, R2, R3 R4, R1, R5 R6, R1, R7 R8, R1, R9 R10, R1, R11
Data hazards (2) Vergelijk de volgorde waarin de operanden worden gelezen in opeenvolgende cycles. DADD DSUB AND OR XOR R1, R2, R3 R4, R1, R5 R6, R1, R7 R8, R1, R9 R10, R1, R11 Sequentieel 1: 2: 3: 4: 5: Read Read Read Read Read R2, R1, R1, R1, R1, R3; Write R1 R5; Write R4 R7; Write R6 R9; Write R8 R11; Write R10
Data hazards (3) Vergelijk de volgorde waarin de operanden worden gelezen in opeenvolgende cycles. DADD DSUB AND OR XOR R1, R2, R3 R4, R1, R5 R6, R1, R7 R8, R1, R9 R10, R1, R11 Unpipelined 1: 2: 3: 4: 5: Read Read Read Read Read R2, R1, R1, R1, R1, Pipelined R3; Write R1 R5; Write R4 R7; Write R6 R9; Write R8 R11; Write R10 1: 2: 3: 4: 5: IF Read R2, R3; IF EX; Read R1, R5; IF MEM; EX; Read R1, R7; IF Write R1; MEM; EX; Read R1, R9
Data hazards (3) Vergelijk de volgorde waarin de operanden worden gelezen in opeenvolgende cycles. DADD DSUB AND OR XOR R1, R2, R3 R4, R1, R5 R6, R1, R7 R8, R1, R9 R10, R1, R11 Unpipelined 1: 2: 3: 4: 5: Read Read Read Read Read R2, R1, R1, R1, R1, Pipelined R3; Write R1 R5; Write R4 R7; Write R6 R9; Write R8 R11; Write R10 1: 2: 3: 4: 5: IF Read R2, R3; IF EX; Read R1, R5; IF MEM; EX; Read R1, R7; IF Write R1; MEM; EX; Read R1, R9
Data hazards (4) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.6.
Data hazards (5) Hoe lossen we dit op? - Insert stalls. - Zorgt wel voor correcte uitvoering programma, maar vernietigt performance-winst door pipelining. Kunnen we iets slimmers bedenken?
Forwarding Als we goed kijken, zien we dat het resultaat van DADD niet nodig is tot na dit resultaat wordt berekend: - DADD, EX stage in cycle 3 produceert het resultaat. - DSUB, EX stage in cycle 4 (!) heeft resultaat pas nodig. We kunnen hier slim gebruik van maken door het resultaat tussen de pipeline registers te verplaatsen. - Dus voordat write back heeft plaatsgevonden! We noemen deze techniek forwarding, bypassing of short-circuiting.
Forwarding (2) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.7.
Forwarding (3) In het algemeen: een resultaat kan worden geforwardet tussen de pipeline registers behorende bij de uitvoer van de ene unit en de invoer van de andere unit. - Hoeft niet per se ALU naar ALU te zijn. - In het voorbeeld zien we ook MEM -> REG en REG -> REG.
Forwarding (4) Voorbeeld: DADD LD SD R1, R2, R3 R4, 0(R1) R4, 12(R1) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.8.
Forwarding (5) Helaas kunnen niet alle data hazards met behulp van bypassing worden opgelost... LD DADD AND OR R1, R4, R6, R8, 0(R2) R1, R5 R1, R7 R1, R9 Probleem hier is dat LD pas een resultaat oplevert aan het einde van cycle 4, DADD heeft dit al bij EX aan het begin van cycle 3. Helaas kunnen we de resultaten niet terug in de tijd transporteren.
Forwarding (6) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.9.
Forwarding (7) Om het probleem op te lossen zullen we een pipeline stall moeten introduceren. - Correcte executie van het programma gaat natuurlijk boven performance! Dit wordt gedaan door een stukje hardware genaamd de pipeline interlock. - Een pipeline interlock detecteert een hazard en introduceert stalls totdat de hazard is opgelost. - Dit gebeurt voor de instructie die de data wil gebruiken totdat de bron instructie deze data produceert. - Interlock zit vaak in ID stage en houdt issue van een instructie tegen.
Fowarding (8) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.10.
Control hazards Control hazards treden op door conditionele branch instructies. We kunnen niet aan de IF voor de volgende instructie beginnen zolang we de uitkomst niet weten. Een branch kan de PC wel of niet veranderen: - We zeggen taken branch of non-taken branch. Voor een taken branch wordt de PC pas op z'n vroegst aangepast aan het einde van ID. - In ID kan branch address calculation en register comparison worden gedaan.
Control hazards (2) Eenvoudigste oplossing: IF na een branch opnieuw doen zodra we in ID van de branch zien dat de branch wordt genomen. - De eerste IF wordt dan effectief gezien een stall. - 1 stall cycle geeft een performance verlies van 10% tot 30% afhankelijk van de mate waarin branches voorkomen. Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.11.
Control hazards (3) Er zijn verschillende manieren bedacht om de branch penalty tegen te gaan. - Pipeline vastzetten totdat resultaat bekend is (zagen we zojuist). - Ga ervan uit dat de branch niet wordt genomen. Opletten dat 'processor state' niet wordt veranderd totdat branch uitkomst bekend is. Als branch toch wordt genomen, instructies in de tussentijd uitgevoerd omzetten naar no-ops en IF opnieuw starten bij het branch target.
Control hazards (4) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.12.
Control hazards (5) Een andere mogelijkheid die voorheen veel is gebruikt is de 'delayed branch': branch instruction sequential successor branch target if taken De sequential successor is in het branch delay slot. Deze instructie wordt altijd uitgevoerd, ongeacht uitkomst van de branch. Het is de taak van de compiler om een geldige en nuttige instructie in het branch delay slot te plaatsen.
Control hazards (6) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.14.
Control hazards (7) Het aantal stall cycles veroorzaakt door branches heeft zijn weerslag op de behaalde speedup door pipelining. Dit aantal stall cycles wordt bepaald door hoe vaak branches voorkomen en wat de penalty is voor een branch. In het algemeen geldt dat voor diepere pipelines de branch penalty toeneemt. - Een techniek als delayed branches is voor dergelijke pipelines niet meer voldoende.
Branch prediction Er wordt uitgebreid gebruik gemaakt van technieken die proberen de uitkomsten van komende branches te voorspellen. We proberen hiermee stalls te vermijden, zoals de predict-not-taken aanpak. - Penalty voor misprediction is hoog: werk dat alvast is uitgevoerd moet allemaal ongedaan worden gemaakt (pipeline flush). We bekijken statische en dynamische aanpakken.
Static Branch Prediction Het idee is om een programma een aantal keer uit te voeren en 'op te nemen' of branches wel of niet worden genomen. - Losse branches hebben vaak een grote neiging om of bijna altijd te worden genomen of niet. - Bijv. loop branch of een if-conditie voor een error die in de praktijk nooit voorkomt. Vervolgens compileren we het programma opnieuw gebruikmakende van deze informatie. We leggen een voorspelling voor de branches vast in de code. Met SPEC zien we misprediction rates tussen de 3% en 24% (integer-programs doen het slechter).
Dynamic Branch Prediction Dynamic branch prediction wordt door de hardware gedaan tijdens het uitvoeren van het programma. Dit wordt gedaan aan de hand van data uit het verleden. - Branch-prediction buffer: een klein geheugen dat wordt geindexeerd met het lage deel van het adres van een branch instructie. (Vergelijk caching!) - Hierdoor wordt een bit gelezen die zegt of de vorige keer de branch wel of niet was genomen. - Het uiteindelijke resultaat wordt weer weggeschreven naar dit geheugen.
Dynamic Branch Prediction (2) 1-bit prediction heeft een probleem - Stel een branch wordt bijna altijd genomen, maar nu een keer niet. => Mispredict en de bit wordt omgedraaid. - Na die ene keer niet-genomen, wordt de branch juist weer genomen. Weer een mispredict. Om dit op te lossen wordt vaak een 2-bit methode gebruikt. - Pas na 2 foute voorspellingen wordt de bit omgedraaid. Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.18.
Dynamic Branch Prediction (3) We kunnen bijvoorbeeld een branch-prediction buffer maken met 4096 entries van 2-bits. Klinkt misschien te simpel om waar te zijn: maar geeft een misprediction rate tussen 1% en 18% voor SPEC89. Veel grotere buffers laten voor SPEC89 benchmarks geen grote verbeteringen zijn.
Implementatie Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.21.
Implementatie data hazards Stap van ID naar EX wordt vaak instruction issue genoemd. In ID kan worden nagegaan of er voor een instructie data hazards bestaan; zo ja: stall. Voorbeeld: bron uit load instructie, Read-After-Write (RAW) hazard. - Resultaat load instructie (write) wordt door de direct volgende instructie gelezen (read). - Met welke gevallen kunnen we te maken krijgen?
Impl. data hazards (2) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.24.
Impl. data hazards (3) Een en ander wordt geimplementeerd door gegevens uit de pipeline registers tussen de stages te vergelijken. Als er een hazard wordt gedetecteerd kunnen alle control signalen in ID/EX op 0 worden gezet, wat resulteert in een no-op. - IF/ID wordt hergebruikt om de gestallde instructie vast te houden. Forwarding: soortgelijk, alleen meer gevallen om te bekijken.
Impl. data hazards (4) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.27.. De multiplexers bij de ALU invoeren moeten worden uitgebreid voor alle verschillende forwarding invoeren.
Exceptions In een processor kunnen allerlei interrupts, faults en exceptions optreden. Voorbeelden: - I/O device interrupt. - System call. - Integer overflow. - Divide by zero. - Page fault. - Misaligned memory access. - Memory protection violation. - Illegal instruction. Vele verschillende eigenschappen, belangrijkste voor nu: resume vs. terminate.
Exceptions (2) Terminate: programma stopt na optreden exception. Resume: instructie waar exception optrad moet worden herhaald: - Exception vindt plaats. - Een ander programma (OS) slaat state huidige programma op. - Exception wordt verholpen. - State programma wordt teruggezet. - Fault instruction wordt opnieuw gestart. Wanneer een pipeline dit ondersteunt, wordt deze restartable genoemd.
Exceptions (3) Het moeilijkste type exception om te ondersteunen heeft twee eigenschappen: - (1) vindt plaats 'midden' in de instructie - (2) moet restartable zijn. Dit is nodig om virtual memory te kunnen ondersteunen. Tijdens de MEM stage kan een page fault optreden. Wanneer dit wordt opgemerkt zijn de instructie na de fault instruction al in uitvoering!
Exceptions (4) Alle instructies voor de fault instruction moeten worden afgemaakt, die na moeten worden afgebroken. Dit kan als volgt worden bereikt: - Bij de volgende IF wordt een trap instruction in de pipeline gezet. - Voor de instructies tussen deze trap en de fault instruction worden alle writes uitgezet zodat de processor state niet wordt aangepast. (Bijv. door nullen in de pipeline registers te schrijven). - De PC van de fault instructie wordt opgeslagen en later gebruikt voor de restart.
Exceptions (5) We onderscheiden precise en imprecise exceptions. Precise: pipeline kan instructies na de fault instructie afmaken en fault instructie later herstarten. Imprecise: wanneer bovenstaande niet kan worden gegarandeerd. - Voorbeeld: source operanden van de fault instruction al overschreven; bijvoorbeeld wanneer fault instruction langer in uitvoering is dan instructies die erop volgen. Sommige CPUs ondersteunen beide typen exceptions.
ISA complications Garantie MIPS instructie set: resultaat wordt alleen aan einde pipeline weggeschreven (committed). - Processor state wordt tussentijds niet aangepast. Bij sommige instructiesets bestaat deze garantie niet en wordt implementatie precise exceptions veel ingewikkelder. - Instructies die tussentijds processor state aanpassen moeten dan in geval exception worden teruggedraaid. - Aanpassingen uitstellen kan niet altijd als de volgende stappen van de instructie afhankelijk zijn van deze wijziging. - Er bestaan ook CISC architecturen met instructies die tussentijds het RAM geheugen aanpassen...
ISA complications (2) Multicycle operaties geven ook problemen met pipelining. Onderstaande VAX instructies verschillen in aantal klokcycles: kan zijn van één tot wel honderden cycles. - Vele data hazards tussen en ook binnen instructies. - Alle instructies binnen zelfde aantal klokcycles laten uitvoeren te ingewikkeld en leidt tot zeer lange pipeline. Hoe passen we dan toch pipelining toe? MOVL ADDL3 SUBL2 MOVC3 R1,R2 42(R1),56(R1)+,@(51) R2,R3 @(R1)[R2],74(R2),R3
ISA complications (3) Oplossing zagen we al een keer voorbij komen: - De CISC instructies worden omgezet in meerdere microinstructies. - Vervolgens worden de micro-instructies gepipelined. Intel doet precies hetzelfde (sinds 1995) en noemt dit micro-ops. Hier zien we weer waarom sinds de jaren 90 RISC cores standaard zijn geworden.
Multicycle operaties Floating-point operaties duren relatief gezien langer dan integer operaties. - Het is hierdoor niet praktisch om floating-pointer operaties binnen 1 of 2 klokcycli af te ronden - Dit zou een lage klokfrequentie betekenen, omdat er veel werk binnen die ene cyclus moet worden gedaan. Hoe lossen we dit op? - Zouden we floating-point operaties een langere latency kunnen geven dan integer operaties?
Multicycle operaties (2) Zouden we floating-point operaties een langere latency kunnen geven dan integer operaties? Dit is precies wat we kunnen doen: - We herhalen de EX stage zolang nodig. Aantal herhalingen varieert per operatie. - We kunnen meerdere functional units hebben waar we een instructie naar toe kunnen sturen. Als een benodigde functional unit voor een (FP-)instructie bezet is: stall door structural hazard.
Multicycle operaties (3) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.33.
Multicycle operaties (4) We kunnen de EX-stage ook laten bestaan uit meerdere pipeline segments. Op die manier kunnen we bijvoorbeeld aan meerdere FP adds tegelijkertijd werken. We kunnen voor elke functional unit definieren: - Latency: minimum aantal cycles tussen instructie dat resultaat produceert en instructie dat resultaat gaat gebruiken (aantal stages na EX waarin het resultaat wordt geproduceerd). - Initiation / repeat interval: minimum aantal cycles tussen two issues van hetzelfde type. Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.34.
Multicycle operaties (5) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.34.
Multicycle operaties (6) Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.37. Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.38.
Multicycle operaties (7) De toevoeging van multicycle operaties brengt een aantal nieuwe complicaties met zich mee: Divide unit is niet pipelined, hierdoor kunnen structural hazards voorkomen. Instructies hebben verschillende latencies, hierdoor kan het aantal register file writes binnen 1 cycle groter zijn dan 1. - En door de langere latencies komen RAW hazard stalls vaker voor. Instructies komen niet meer in de juiste volgorde aan het einde van de pipeline, hierdoor kunnen write after write hazards voorkomen. - Tevens geeft dit problemen bij het implementeren van precise exceptions.
MIPS R4000 8-stage pipeline, zodat klokfrequentie omhoog kan. Taken from Computer Architecture: A Quantitative Approach, fifth edition. Fig. C.41. IF PC selection, start i-cache access. IS Tweede helft i-cache access. RF Instruction decode, register fetch, i-cache hit detection. EX Execution. DF Data fetch, eerste helft cache access. DS Tweede helft cache access. TC Tag check, hadden we een hit? WB Write-back voor loads en reg-reg.