Datorarkitekturer med operativsystem ERIK LARSSON

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) Abstraktionsnivå 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?

Utvärdering av applikationsprogram 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

Utvärdering av applikationsprogram 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

Utvärdering av applikationsprogram 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)

Utvärdering av applikationsprogram 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

Karaktärsdrag hos RISC processorer 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): FI DI EI Med enkla och få instruktioner, blir kontrollenheten enklare.

Karaktärsdrag hos RISC processorer Load-and-store architecture: Endast LOAD och STORE instruktioner refererar data i minnet (primärminnet). Pipeline vid minnesreferenser: FI DI CA TR CA: Compute adress, TR: Transfer

Karaktärsdrag hos RISC processorer 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.

Karaktärsdrag hos RISC processorer 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) R 0 Alla register R N Level i Register window In Local Out CWP: Current Window Pointer Level i+1 Level i+2 CWP CWP In Local Out In Local Out 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

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

Delayed load problem 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.

Delayed load problem 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 CA TR FI DI EI FI DI EI FI DI CA TR FI DI EI FI DI EI FI DI EI FI DI EI Här är R1 tillgängligt Här används R1 Här är R1 tillgängligt Här används R1

Delayed load problem 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 FI DI CA TR FI DI EI FI DI EI FI DI CA TR FI DI EI FI DI EI FI DI EI FI DI EI Här är R1 tillgängligt Här används R1 Här är R1 tillgängligt Om kompilatorn inte hittar en instruktion, tas en NOP (no operation) instruktion 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 Tid SSA SP P Pipelining Superpipelining FI DI CO FO EI WO FI DI CO FO EI WO FI DI CO FO EI WO FI DI CO FO EI FI DI CO FO EI WO FI DI CO FO EI WO FI DI CO FO EI WO FI DI CO FO EI WO WO Superscalar pipelining FI DI CO FO EI WO FI DI CO FO EI WO FI DI CO FO EI FI DI CO FO EI WO WO

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: FI DI CO FO EI FI DI CO FO EI FI DI CO FO EI WO WO WO

SSA Decode, dispatch, rename Instruktions buffert Fetch unit Instructions cache Floatingpoint unit Register file Instruktionsfönster Instruction issuing Integer unit Minne Integer unit Data cache Commit

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; Basic block 1 Basic block 2 Basic block 3 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

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

True data dependency MUL R4, R3, R1 FI DI R4 CO R3 FO * R1 EI ADD R2, R4, R5 R2 R4 + R5 Här vill I2 ha resultat från * WO Här görs * FI DI CO FO EI WO FO EI WO FI DI CO STALL FO CO EI WO FO EI Här skrivs resultatet till R4 WO FI DI CO FO CO EI WO FO EI WO

True data dependency 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)

True data dependency MUL R4, R3, R1 FI DI R4 CO FO R3 * EI R1 Här vill I2 ha resultat från * FI DI CO WO FO WO WO FI DI CO EI WO FO EI ADD R2, R4, R5 R2 R4 + R5 EI FI DI CO EI WO FO EI WO WO FI DI CO EI WO FO EI WO FI DI CO EI WO FO EI WO Här skrivs resultatet till R4 FI DI CO EI WO FO EI WO FI DI CO EI WO FO EI WO

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 antidependency 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 -------- ADD R4, R2, R5 Med nya register: MUL R4, R3, R1 -------- ADD R7, R2, R5 R4 R3*R1 R4 R2+R5 R4 R3*R1 R7 R2+R5 Anti dependency Givet var: MUL R4, R3, R1 -------- ADD R3, R2, R5 Med nya register: MUL R4, R3, R1 -------- ADD R6, R2, R5 R4 R3*R1 R3 R2+R5 R4 R3*R1 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 Decode, dispatch, rename Instruktions buffert Fetch unit Instructions cache Floating-point unit Register file Instruktions-fönster Instruction issuing Integer unit (+) Minne Integer unit (*) Commit Data cache

Parallell exekvering I3 och I4 är i konflikt om samma functionella funktionella enhet (*) 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 I5 behöver resultatet från beräkningen i I4 Alla instruktioner kräver 1 klockcykel för exekvering förutom I1 som kräver två klockcykler I2, I2, I5 I5 och och I6 I6 är är i i konflikt om om samma functionella funktionella functionella 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 FP ADD MUL Writeback/ complete Cykel 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 FP ADD MUL Writeback/ complete Cykel 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 FP ADD MUL Cykel 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 I6 kan starta före I5 och parallellt I4: MUL R5, R6, R7 R5 R6 * R7 med I4. Programmet tar bara 6 I5: ADD R10, R5, R7 R10 R5 + R7 cykler (jämfört med 8 i fallet med inorder issue and in-order I6: ADD R11, R2, R3 R11 R2 + R3 completion) Decode/Issue Execute Writeback/ Cykel FP ADD MUL complete 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

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 i486 1989 25MHz 5 1 No 1 5W Power 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