Datorarkitekturer med operativsystem

Datorarkitekturer med operativsystem ERIK LARSSON

Översikt

•  Reduced instruction set computers (RISC) •  Superscalar processors

Semantic gap

•  Alltmer avancerade programmeringsspråk tas fram för att göra programvaruutveckling mer kraftfull

•  Dessa programmeringsspråk (Ada, C++, Java) ger högre abstraktionsnivå, konsistens och kraft

•  Det semantiska gapet ökar (högnivåspråk-maskinspråk)

Abs

trakt

ions

nivå

Högnivåspråk

Maskinspråk

Semantiskt gap

Utvärdering av applikationsprogram

•  Många studier har gjorts för att ta fram karaktärsdrag av maskinkod som genererats från högnivåspråk

•  Intressanta aspekter:

– Hur ofta används varje instruktion? – Hur används operander? Och hur ofta?

– Hur mycket används hopp, loopar, anrop till procedurer/funktioner/subrutiner?


Typ Instruktioner i högnivåspråk (%)

Instruktioner i maskinspråk (%)

Minnesreferenser (%)

Pascal C Pascal C Pascal C Tilldelning 45 38 13 13 14 15

Loop 5 3 42 32 33 26 Call 15 12 31 33 44 45

Villkor (if) 29 43 11 21 7 13 Andra 6 1 3 1 2 1

Många tilldelningar i högnivåspråk men dessa ger få instruktioner i maskinspråk och relativt få minnesreferenser

Relativt få loopar men looparna resulterar i många maskininstruktioner och många minnesreferenser


Typ Instruktioner i högnivåspråk (%)

Instruktioner i maskinspråk (%)

Minnesreferenser (%)

Pascal C Pascal C Pascal C Tilldelning 45 38 13 13 14 15

Loop 5 3 42 32 33 26 Call 15 12 31 33 44 45

Villkor (if) 29 43 11 21 7 13 Andra 6 1 3 1 2 1

Få CALL (anrop till funktioner/procedurer/subrutiner) men de ger många instruktioner i maskinspråk och relativt många minnesreferenser

Relativt många villkor med de ger relativt få maskininstruktioner och relativt få minnesreferenser


•  Fördelning av maskininstruktioner (frekvens av användande):

–  Flytta data (move): ~33%

– Villkorliga hopp: ~20% – ALU operationer: ~16%

•  Adressering – Komplexa adressering: ~18% (memory indirect,

indexed+indirect, displacement+indexed, stack)

– Enkel adressering: vanligast (adress kan beräknas i en klockcykel, register, register indirekt, displacement)


•  Typer av operander –  74-80% av operander är skalärer (heltal, flyttal,

tecken, etc), vilka kan lagras i register (icke-skalär, t ex array)

– Resterande (20-26%) är arrayer; 90% är globala variabler

–  80% av skalärer är lokala variabler •  Slutsats: Lagring i register

Utvärdering av applikationsprogram •  Trots att endast 10-15% av högnivå

instruktionerna var funktion/procedure/subrutin anrop, så svarar dessa CALL och RETURN instruktioner för:

–  31-43% av maskininstruktionerna

–  44-45% av minnesreferenserna •  För procedurer:

– Endast 1.25% har fler än 6 parametrar

– Endast 6.7% har fler än 6 lokala variabler

– Antal nästlingar är ofta få (korta) och mycket sällan längre än 6

int x, y; float z; void proc3(int a, int b, int c) {

---------------- } void proc2(int k) {

int j, q; ---------------- proc3(j, 5, q); }

void proc1() { int i; ---------------- proc2(i); }

main () { proc1(); }

Karaktärsdrag hos RISC processorer

•  Enkla och få instruktioner •  Enkla och få adresseringsmöjligheter •  Fixt (fast) instruktionsformat

•  Stort antal register •  Load-and-store architecture


•  Målet med enkla och få instruktioner är att kunna exekvera snabbare. De flesta instruktion exekveras i en enda maskincykel (efter fetch och decode)

•  Pipeline (utan minnesreferenser):

•  Med enkla och få instruktioner, blir kontrollenheten enklare.

FI DI EI


•  Load-and-store architecture: – Endast LOAD och STORE instruktioner refererar data i

minnet (primärminnet).

•  Pipeline vid minnesreferenser:

– CA: Compute adress, TR: Transfer

FI DI CA TR


•  Instruktioner använder få adresseringsmöjligheter: –  Typiskt: register, direkt, register indirekt, displacement

•  Instruktioner har fixt (fast) längd och uniformt format

– Detta förenklar och snabbar upp laddning och avkodning. Processorn behöver inte vänta på att hela instruktionen är laddad innan avkodning kan påbörjas

– Uniformt format, dvs opcode och adressfält är placerat på samma position för olika instruktioner, gör att avkodning förenklas.


•  Stort antal register – Register kan användas för att lagra variabler och för

“mellanlagring” resultat. Det minskar behov av att använda upprepade load och store med primärminnet.

– Alla lokala variabler från CALL/RETURN strukturer (anrop till funktioner, procedurer, subrutiner) kan lagras i register.

•  Vad händer vid anrop till funktioner och procedurer? – Register innehåll måste sparas, parametrar ska föras över,

återhopps adresser ska sparas. Relativt mycket minnes access, vilket tar mycket tid.

– Med många register, kan nya register allokeras vid anrop

Hopp till subrutiner (och funktioner) R0

RN

Level i Level i+1 Level i+2

Alla register

Register window In Local Out

In Local Out

In Local Out

CWP: Current Window Pointer

instruktion 1 call proc A instruktion 3 instruktion 4 call proc A instruktion 6

procA: instruktion 11 call proc B instruktion 13 return

procB: Instruktion 21 Instruktion 22 return

CWP

CWP

CWP

Delayed load problem

•  LOAD och STORE instruktioner refererar data i minnet (primärminnet). Alla andra instruktioner opererar enbart på register (register-till-register instruktioner).

•  LOAD och STORE instruktioner hinner inte bli exekverade på en klockcykel.

LOAD R1, X ADD R2, R1 ADD R4, R3

FI DI CA TR FI DI EI

FI DI EI

Här är R1 tillgängligt


•  Två alternativ: – Hårdvaran gör delay (stall) av instruktioner som följer

efter LOAD

– Kompilatorn ändrar ordningen genom delayed load (jämför med delayed branching)

•  Med delayed load exekveras alltid instruktionen som följer en LOAD instruktion (inget stall). Det är programmerarens (kompilatorns) ansvar att se till att instruktionen direkt efter LOAD inte behöver just det värde som laddas.


•  Om programmet är: LOAD R1, X ADD R2, R1 ADD R4, R3 SUB R2, R4

•  Genererar kompilatorn: LOAD R1, X ADD R4, R3 ADD R2, R1 SUB R2, R4


FI DI EI


FI DI EI

Här används R1


FI DI EI


FI DI EI

Här används R1


•  Om programmet är: LOAD R1, X ADD R2, R1 ADD R4, R2 SUB R4, X

•  Genererar kompilatorn: LOAD R1, X NOP ADD R2, R1 ADD R4, R2 STORE R4, X

•  Om kompilatorn inte hittar en instruktion, tas en NOP (no operation) instruktion


FI DI EI


FI DI EI

Här används R1


FI DI EI


FI DI EI

Här används R1

FI DI CA TR

RISC eller CISC?

•  Ett entydigt svar är svårt att ge •  Flera prestanda jämförelser (benchmarking) visar att RISC

exekverar snabbare än CISC

•  Men, det är svårt att identifiera vilket karaktärsdrag som är avgörande. Det är svårt att jämföra; t ex olika halvledartekniker, kompilatorer

•  Ett argument för CISC: Den enklare RISC konstruktionen gör att program behöver mer minne (fler instruktioner) jämfört med samma program för en CISC processor

•  Processorer av idag använder sig ofta av lite RISC och lite CISC

Några exempel •  CISC

– VAX 11/780 Nr. of instructions: 303 Instruction size: 2 – 57 bytes Instruction format: not fixed Addressing modes: 22 Number of general purpose registers: 16

– Pentium Nr. of instructions: 235 Instruction size: 1 – 11 bytes Instruction format: not fixed Addressing modes: 11 Number of general purpose registers: 8 (32-bitar mode), 16 (64-bitar mode)

Några exempel

•  RISC – Sun SPARC

Nr. of instructions: 52 Instruction size: 4 bytes Instruction format: fixed Addressing modes: 2 Number of general purpose registers: up to 520

– PowerPC Nr. of instructions: 206 Instruction size: 4 bytes Instruction format: not fixed (but small differences) Addressing modes: 2 Number of general purpose registers: 32

Några exempel

•  ARM (Advanced RISC Machine och Acorn RISC Machine) Antal instruktioner (standard set): 122 Instruktions storlek: 4 (standard), 2 (Thumb) byte Instruktions format: fixerat (olika mellan standard och Thumb) Adresserings modes: 3 Antal general purpose register: 27 (16 kan användas samtidigt) Dagens ARM processorer kan exekvera både standard set (32 bitars instruktioner och 16 bitars Thumb instruktions set. Thumb består av en delmängd av 32-bitars setet, kodat som 16-bitars instruktioner).

Sammanfattning •  Både RISC och CISC försöker lösa samma problem

– minska det semantiska gapet. CISC alternativet innebär att instruktioner görs alltmer komplexa RISC alternativet innebär att göra instruktionerna enklare

•  Viktiga kännetecken för RISC arkitekturer är:

Få och enkla instruktioner Få adresserings möjligheter Load-store arkitektur Instruktioner har fix längd och format Många register är tillgängliga

•  Viktigt för RISC utveckling är att maximera effektiviteten i pipelines •  En processorer av idag använder sig ofta av lite RISC och lite CISC

kännetecken

Översikt

•  Reduced instruction set computers (RISC) •  Superscalar processors

Superscalar architecture

•  En superscalar architecture (SSA) tillåter att mer än en instruktion initieras samtidigt och exekveras oberoende av varandra.

– Skalär: heltal, flyttal –  Icke-skalär: array, matris, vektor

•  I pipelining är flera instruktioner aktiva men de är alla i olika pipeline steg

•  Utöver pipelining, tillåter SSA att flera instruktioner exekverar samtidigt (i samma pipeline steg). Det är möjligt att initiera flera instruktioner i samma klockcykel; instruction level parallelism (ILP)

Pipelining

•  Pipelining

•  Superpipelining

•  Superscalar pipelining

WO FI DI CO FO EI WO FI DI CO FO EI






Tid SSA SP P

Superpipelining

•  Superpipelining är en teknik där varje steg i en pipeline delas i substeg

•  Genom att dela upp varje steg i två, innebär det att pipelinen ger resultat två gånger snabbare (jämför med att ha flera steg i pipeline)

•  Att dela upp steg mer eller att ha fler pipeline steg blir svårare; svårt att få alla steg lika långa och mycket konflikter

– Alternativ: superscalar architecture

Superscalar architecture (SSA)

•  Ett exempel, tre parallella enheter: –  en flyttalsinstruktion och två heltalsinstruktioner Kan exekveras samtidigt (som tidigare kan flera

instruktioner vara aktiva i en pipeline)

Flyttal: Heltal: Heltal:

WO FI DI CO FO EI WO FI DI CO FO EI WO FI DI CO FO EI

SSA

Instructions cache

Instruktions buffert

Decode, dispatch, rename

Register file

Integer unit

Integer unit

Floating-point unit

Instruction issuing Minne

Data cache

Instruktions-fönster

Commit

Fetch unit

Instruktionsfönster

•  Instruktions fönster (instruction window) är de instruktioner som processorn har att välja mellan vid en viss tidpunkt.

•  Instruktions fönstret ska vara så stort som möjligt för att ge möjlighet att effektivt välja instruktioner som ska exekveras

•  Problem: – Svårt att hämta instruktioner i hög hastighet

– Konflikter i pipeline (branches, struktural, data)

Instruktionsfönster (instruction window) •  Lite C kod:

for (i=0; i<last; i++){ if (a[i]>a[i+1]){

temp = a[i]; a[i] = a[i+1];

a[i+1] = temp; }

}

•  Assembly kod: R7: adress till a[i], R3: adress till a[i], a[i+1], R4: last, R6: i L2 move R3, R7

lw R8, (R3) R8 <- a[i] add R3, R3, 4 lw R9, (R3) R9 <- a[i+1] ble R8, R9, L3 move R3, R7 sw R9, (R3) a[i] <- R9 add R3, R3, 4 sw R8, (R3)

L3 add R6, R6, 1 add R7, R7, 4 blt R6, R4, L2

Basic block 1

Basic block 2

Basic block 3

Instruktionsfönster (instruction window)

•  Instruktionsfönstret kan göras större (än basic blocks) genom branch prediction; spekulativ exekvering

•  Med spekulativ exekvering, tas instruktioner från “predicted path” får “ses” i instruktions fönstret

•  Instruktioner från “predicted path” exekveras;

– Om prediction är rätt; fortsätt (commit) – Annars, ta bort (effekten blir att de inte exekverats)

Problem med parallell exekvering

•  Problem som förhindrar parallell exekvering i SSA liknar de problem som skapade problem i pipelines

•  Konflikter i pipelines:

– Resource (resurs) konflikter – Kontrollkonflikter

– Datakonflikter » True data dependency

» Output dependency

» Anti-dependency

True data dependency

•  True data dependency (data konflikt/hazard) uppkommer när resultat (output) från en instruktion behövs som indata i följande instruktion:

MUL R4, R3, R1 R4 ← R3 * R1 -------- ADD R2, R4, R5 R2 ← R4 + R5


MUL R4, R3, R1 R4 ← R3 * R1 ADD R2, R4, R5 R2 ← R4 + R5


WO FI DI CO FO EI

Här görs “*”

Här skrivs resultatet till R4

WO FO EI WO CO FO EI STALL

WO FI DI CO FO EI WO CO FO EI

Här vill I2 ha resultat från “*”


•  True data dependency måste detekteras och hanteras – Enklast är att göra stalls – Alternativ, för att undvika stalls, är att låta hårdvara

eller kompilator leta upp instruktioner som kan exekveras (tills konflikt undvikts)

I2: ADD R2, R4, R5

MUL R4, R3, R1 R4 ← R3 * R1 ADD R2, R4, R5 R2 ← R4 + R5


WO FI DI CO FO EI WO FI DI CO

WO FI DI CO EI

Här skrivs resultatet till R4

WO FO EI WO CO FO EI

WO FI DI CO EI WO CO FO EI WO FI DI EI WO CO FO EI WO FI DI EI WO CO FO EI

WO FI DI EI WO CO FO EI WO FI DI EI WO CO FO EI

Här vill I2 ha resultat från “*”

Output dependency

•  Output dependency existerar om två instruktioner skriver till samma plats. Om den senare instruktionern exekveras före den första blir det fel:

MUL R4, R3, R1 R4 ← R3 * R1 -------- ADD R4, R2, R5 R4 ← R2 + R5

Anti-dependency

•  En anti-dependency existerar om en instruktion använder en plats (minne/register) medan någon nästföljande instruktion skriver till den platsen.

•  Om den första instruktionen inte är klar medan en efterföljande instruktion skriver på samma plats, blir det fel: MUL R4, R3, R1 R4 ← R3 * R1

-------- ADD R3, R2, R5 R3 ← R2 + R5

Output dependency och anti-dependency

•  Output dependency och anti-dependency är inte “inbyggda” konflikter på grund av programmet

•  De är lagringskonflikter som uppkommer på grund av hur programmeraren eller kompilatorn använder register och minnesplatser

•  I exemplen ovan – Output dependency: R4 används av båda

instruktioner för att lagra resultat

– Anti-dependency: R3 används av den senare instruktionen för att lagra resultat

•  Om fler register används, kan dessa problem avhjälpas med register renaming

Register renaming

•  Reservation stations and reorder buffers för register renaming

•  Vid instruction issue

– Om operand är tillgänglig i register eller reorder buffer » Kopieras till reservation station (värde behövs ej längre i

register(kan skrivas över))

– Om operand ej tillgänlig än » Kommer bli tillgängligt från funktionell enhet

Register renaming: Output dependency och anti-dependency

•  Output dependency •  Givet var: MUL R4, R3, R1 R4 ← R3*R1 -------- ADD R4, R2, R5 R4 ← R2+R5

•  Med nya register: MUL R4, R3, R1 R4 ← R3*R1 -------- ADD R7, R2, R5 R7 ← R2+R5

•  Anti dependency •  Givet var:

MUL R4, R3, R1 R4← R3*R1 -------- ADD R3, R2, R5 R3← R2+R5

•  Med nya register: MUL R4, R3, R1 R4←R3*R1 -------- ADD R6, R2, R5 R6←R2+R5

Spekulering

•  Branch prediction och continue issuing – Commit när branch villkor är kännt

•  Load speculation

– Undvik load och cache miss delay » Prediktera effektiv adress

» Prediktera load value

» Load för väntande store

» Bypass store värden till load enhet

Parallell exekvering

•  Instruktioner kan alltså exekveras i en annan ordning än den som är given i programmet. Detta är inget problem så länge resultatet blir rätt.

•  Exekveringspolicies: –  In-order issue with in-order completion

–  In-order issue with out-of-order completion – Out-of-order issue with out-of-order completion

Parallell exekvering

•  Antag en superscalar processor: –  Två instruktioner kan hämtade (fetch) och avkodade (decoded) –  Tre funktionella enheter kan arbeta parallellt; en flyttals enhet,

en heltals adderare, och en heltals multiplicerare – Resultat från två instruktioner kan skrivas tillbaka (written back)

samtidigt

Instructions cache

Instruktions buffert

Decode, dispatch, rename

Register file

Integer unit (*)

Integer unit (+)

Floating-point unit

Instruction issuing Minne

Data cache

Instruktions-fönster

Commit

Fetch unit

•  Antag ett program: I1: ADDF R12, R13, R14 R12 ← R13 + R14 (float. pnt.) I2: ADD R1, R8, R9 R1 ← R8 + R9 I3: MUL R4, R2, R3 R4 ← R2 * R3 I4: MUL R5, R6, R7 R5 ← R6 * R7 I5: ADD R10, R5, R7 R10 ← R5 + R7 I6: ADD R11, R2, R3 R11 ← R2 + R3

•  Alla instruktioner kräver 1 klockcykel för exekvering förutom I1 som kräver två klockcykler

I5 behöver resultatet från beräkningen i I4 I5 behöver resultatet från beräkningen i I4

Parallell exekvering I3 och I4 är i konflikt om samma functionella enhet (*)

I2, I5 och I6 är i konflikt om samma functionella enhet (+)

I3 och I4 är i konflikt om samma funktionella enhet (*)

I2, I5 och I6 är i konflikt om samma functionella enhet (+)

I2, I5 och I6 är i konflikt om samma funktionella enhet (+)

In-order issue with in-order completion I1: ADDF R12, R13, R14 R12 ← R13 + R14 (flyttalsberäkning) I2: ADD R1, R8, R9 R1 ← R8 + R9 I3: MUL R4, R2, R3 R4 ← R2 * R3 I4: MUL R5, R6, R7 R5 ← R6 * R7 I5: ADD R10, R5, R7 R10 ← R5 + R7 I6: ADD R11, R2, R3 R11 ← R2 + R3

Decode/Issue

Execute Writeback/complete

Cykel

FP ADD MUL

I1 I2 1

I3 I4 I1 I2 2

I5 I6 I1 STALL 3

I3 I1 I2 4

I4 I3 5

I5 I4 6

I6 I5 7

I6 8

In-order issue with in-order completion

•  Instruktioner startar och exekverar i exakt samma ordning som om instruktionerna skulle exekverats sekventiellt

•  Resultat skrivs tillbaka (completion) i samma ordning

•  En instruktion får inte starta (issued) förrän tidigare instruktioner har startat

•  För att garantera in-order completion görs stalls vid konflikter och när en instruktion behöver fler klockcykler

•  Utnyttjandet av parallellsim begränsas, t ex om I3 och I6 bytte plats kan I4 och I6 samt I3-I5 exekveras parallellt

•  I SSA, målet är hårdvarulösningar för att maximera parallellism

In-order issue med out-of-order completion I1: ADDF R12, R13, R14 R12 ← R13 + R14 (flyttalsberäkning)

I2: ADD R1, R8, R9 R1 ← R8 + R9 I3: MUL R4, R2, R3 R4 ← R2 * R3 I4: MUL R5, R6, R7 R5 ← R6 * R7 I5: ADD R10, R5, R7 R10 ← R5 + R7 I6: ADD R11, R2, R3 R11 ← R2 + R3

Decode/Issue

Execute Writeback/complete

Cykel

FP ADD MUL

I1 I2 1

I3 I4 I1 I2 2

I5 I6 I1 I2 3

I3 I1 4

I4 I3 5

I5 I4 6

I6 I5 7

I6 8

Out-of-order completion

Out-of-Order Issue (OOI) med Out-of-Order Completion (OOC)

•  Med In-order issue kan inte nya instruktioner exekveras när processorn detekterat en konflikt och därför gör stall

•  Processorn kan med Out-of-order issue “se framåt” för nya instruktioner som skulle kunna exekveras parallellt med de som för tillfället körs

•  Med Out-of-order issue försöker processorn lösa dessa problem genom att se framåt (look ahead) bland de avkodade instruktionerna och starta (issue) någon eller några instruktoioner i någon ordning, givet att programmet exekveras korrekt

OOI med OOC •  Om kompilatorn genererade följande sekvens:

I1: ADDF R12, R13, R14 R12 ← R13 + R14 (float. pnt.) I2: ADD R1, R8, R9 R1 ← R8 + R9 I6: ADD R11, R2, R3 R11 ← R2 + R3 I4: MUL R5, R6, R7 R5 ← R6 * R7 I5: ADD R10, R5, R7 R10 ← R5 + R7 I3: MUL R4, R2, R3 R4 ← R2 * R3

Decode/Issue Execute Writeback/complete

Cykel FP ADD MUL

I1 I2 1

I6 I4 I1 I2 2

I5 I3 I1 STALL 3

I6 I4 I1 I2 4

I5 I3 I6 I4 5

I5 I3 6

7

8

I4 och I6 exekveras parallellt, liksom I3 och I5

OOI med OOC I1: ADDF R12, R13, R14 R12 ← R13 + R14 (flyttalsberäkning) I2: ADD R1, R8, R9 R1 ← R8 + R9 I3: MUL R4, R2, R3 R4 ← R2 * R3 I4: MUL R5, R6, R7 R5 ← R6 * R7 I5: ADD R10, R5, R7 R10 ← R5 + R7 I6: ADD R11, R2, R3 R11 ← R2 + R3

Decode/Issue Execute Writeback/

complete Cykel

FP ADD MUL

I1 I2 1

I3 I4 I1 I2 2

I5 I6 I1 I3 I2 3

I6 I4 I1 I3 4

I5 I4 I6 5

I5 6

7

8

I6 kan starta före I5 och parallellt med I4. Programmet tar bara 6 cykler (jämfört med 8 i fallet med in-order issue and in-order completion)

Konflikthantering •  Med in-order issue med in-order-completion behöver

processorn bara hantera true data dependency, men inte output dependency och anti-dependency.

•  Med out-of-order issue med out-of-order completion behöver processorn hantera true data dependency, output dependency och anti-dependency

– Output dependency MUL R4, R3, R1 R4 ← R3 * R1

- - - - ADD R4, R2, R5 R4 ← R2 + R5

– Antidependency MUL R4, R3, R1 R4 ← R3 * R1

- - - - ADD R3, R2, R5 R3 ← R2 + R5

Arkitekturer

•  PowerPC 604 –  6 oberoende exekverings enheter:

» 1 branch execution unit

» 1 load/Store unit

» 3 integer units

» 1 flyttals enhet

–  In-order issue

•  PowerPC 620 – Som PowerPC604 men out-of-order issue

Arkitekturer

•  Pentium –  3 oberoende exekverings enheter

» 2 heltals enheter

» 1 flyttals enhet

–  In-order issue (2 instruktioner per klockcykel)

•  Pentium II till 4 – Som Pentium men med out-of-order exekvering

–  5-7 oberoende exekverings enheter

Effektförbrukning

•  Komplexitet pga dynamisk schemaläggning och spekulering kräver mer effekt

•  Multipla kärnor (cores) kan vara bättre

Microprocessor Year Clock Rate Pipeline Stages

Issue width

Out-of-order/ Speculation

Cores Power

i486 1989 25MHz 5 1 No 1 5W

Pentium 1993 66MHz 5 2 No 1 10W

Pentium Pro 1997 200MHz 10 3 Yes 1 29W

P4 Willamette 2001 2000MHz 22 3 Yes 1 75W

P4 Prescott 2004 3600MHz 31 3 Yes 1 103W

Core 2006 2930MHz 14 4 Yes 2 75W

UltraSparc III 2003 1950MHz 14 4 No 1 90W

UltraSparc T1 2005 1200MHz 6 1 No 8 70W

Sammanfattning

•  Typiskt för superscalar architectures är: –  Flera pipelines som verkar parallellt; – Out-of-order issue&out-of-order completion;

– Register renaming. •  Alla teknikerna syftar till att öka prestandan.

Sammanfattning

•  Experiment har visat: – Att enbart lägga till extra enheter (typ pipelines) är inte

effektivt;

– Out-of-order är väldigt viktigt; det tillåter look ahead för “independent” instruktioner;

– Register renaming kan förbättra prestanda med mer än 30%; in this case performance is limited only by true dependencies.

– Viktigt med fetch/decode där instruktions fönstret är tillräckligt stort

Documents

Datorarkitekturer med operativsystem