Dat1E K1-1 - En pipelinet mikroarkitektur. Espen Højsgaard Rune Højsgaard Christian Iversen

Transkript

1 Dat1E K1-1 - En pipelinet mikroarkitektur Espen Højsgaard Rune Højsgaard Christian Iversen 1

2 Indhold Indhold 2 1 Sammenfatning Ambitioner Resultat Forløb Overordnet design Målsætninger for designet Udvidelse af datastien Kontrol Forwarding Hvorhen? Forwarding fra LW Detektering Hazards Misprediction detection unit Hazard detection unit Kontrol af flow Design af hopforudsiger Statisk og dynamisk forudsigelse Tilgængelig information Hoptabellen Model 1: Den naive hopforudsiger Model 2: Hopforudsiger med dynamisk indlæring Model 3: Hopforudsiger med 2-bit hophistorie Teoretisk ydelse Model 1: Den naive hopforudsiger Model 2: Hopforudsiger med dynamisk indlæring Model 3: Hopforudsiger med 2-bit hophistorie Det valgte design Implementation Kildekode Analyse af ydelse Benchmarks Hopforudsiger-benchmarks Obligatoriske benchmarks Bemærkninger om CPI

3 5.2 Kritisk vej Afprøvning Strategi Intern afprøvning De enkelte instruktioner Forwarding Hazards Beskyttelse af register $ Resultater Litteratur 25 A Diagrammer 26 A.1 Pipeline A.2 Hopforudsiger A.3 Styrelogik til hopforudsiger A.4 Hopcache-register B Delayed branching 29 C Afprøvning 31 C.1 test.asm C.2 Afvikling af afprøvning C.3 Udskrift af kørsel C.4 pipelined-miss.k D Hopforudsigelsespræcision 45 E Kodeeksempler til hopforudsigeren 45 F Benchmarks 45 F.1 AsmBsort F.1.1 statistik F.2 AsmCopy F.2.1 statistik F.3 AsmFib F.3.1 statistik F.4 AsmQsort F.4.1 statistik F.5 AsmScatter F.5.1 statistik F.6 fac F.6.1 statistik

4 F.7 fib F.7.1 statistik F.8 mergesort F.8.1 statistik F.9 primes F.9.1 statistik G Kontrol 90 H Kildekode 90 H.1 alu.k H.2 BranchCache.k H.3 BranchController.k H.4 BranchHash.k H.5 BranchPLA.k H.6 BranchPred.k H.7 control.k H.8 forwarddetectionunit.k H.9 hazarddetection-unit.k H.10 misprediction-unit.k H.11 pipelined.k H.12 stall-and-nop-control.k

5 1 Sammenfatning Dette er en besvarelse af første del af den karaktergivende opgave på kurset Datalogi 1E 2003, Københavns Universitet [6]. Læseren forventes at have læst opgaveformuleringen samt - som minimum - at have samme forudsætninger som en elev, der har fulgt kurset. Formålet med opgaven var at implementere en pipelinet mikroarkitektur, der kunne udføre en delmængde af MIPS-instruktionssættet. 1.1 Ambitioner Det var vores mål at lave en korrekt og effektiv arkitektur, der var modulær og overskuelig. Dette skulle opnås ved at anvende teknikkerne i [3] til at udvide det deri gennemgåede design, således at det kunne håndtere de ekstra instruktioner opgaven krævede. 1.2 Resultat Resultatet lever op til vores mål omend clockfrekvensen ikke er blandt de højeste. Ydelsen af arkitekturen er relativt høj ift. clockfrekvensen, når vi sammenligner med de benchmarks, der er blevet offentliggjort på fagets nyhedsgruppe Forløb Vi er overordnet tilfredse med forløbet af opgaven. Dog har fejl i Kreds og SimSys 2 taget en del tid, hvorfor vi ikke har haft tid til at iterere over designet samt implementere de i afsnit 5.2 gennemgåede optimeringer. Det skal dog retfærdigvis siges, at vedligholderne af programmerne har været hurtige til at rette fejlene når de blev rapporteret. 1 diku.dat1e 2 se nyhedsgruppen og 5

6 2 Overordnet design I denne opgave skal vi som sagt designe en pipelinet mikroarkitektur. Vi har - som opgaveteksten [6] anbefaler - valgt at tage udgangspunkt i arkitekturen fra [3, kap. 6]. Læseren forventes at have læst dette kapitel, hvorfor vi i denne opgave kun vil fokusere på tilføjelser/forskelle fra det deri beskrevne design. I dette afsnit vil vi diskutere designet med undtagelse af hopforudsigeren, der behandles i afsnit 3. Et overblik over vores design kan fås ved at se på diagrammerne i appendiks A.1. Vi vil ikke beskrive designet på transistor-niveau, men i stedet på et abstraktionsniveau, hvor det er trivielt at anvende teknikkerne fra [3] til at opnå det ønskede. 2.1 Målsætninger for designet Vores overordnede målsætning for designet var, at mikroarkitekturen skulle være korrekt og effektiv. Korrekthed opnås ved at de enkelte instruktioner udføres korrekt og at samspillet mellem dem, i form af hazards og forwarding, fungerer. Desuden skal mikroarkitekturen kunne håndtere interaktionen med hukommelsessystemet på en måde, som lever op til specifikationerne af MemIOSys [4, pp 64]. Effektivitet opnås ved en optimeret vægtning af CPI og clockfrekvens. Da vi først kender clockfrekvensen, når arkitekturen er implementeret, vil denne vægtning bero på et kvalificeret skøn baseret på vores erfaringer fra implementationen af enkelt-/dobbeltcyklus arkitektur (løsning af [5]). Desuden har vi haft nøgleprincipperne på s i [3] i tankerne under designet - specielt good design demands good compromises og make the common case fast. De to instruktionsmix på figur 3.38 s. 189 i [3] har været grundlag for anvendelsen af sidstnævnte princip. 2.2 Udvidelse af datastien Arkitekturen i [3] understøtter ikke alle de i opgaven krævede instruktioner. Vi vil her kort gennemgå de udvidelser af datastien, der har været nødvendige for at overkomme denne begrænsning. BNE Kræver ikke ændringer af datastien, da BEQ allerede er understøttet. I-type For at understøtte I-type instruktionerne, er det nødvendigt at den fortegnsforlængede konstant kan føres ind i ALU en. Desuden bruger de logiske instruktioner (ANDI og ORI) nul-forlængelse (jf. [3, A-55,A-57]), hvilket fortegnsforlængeren ændres til at kunne håndtere. JAL Understøttelse af JAL medfører at konstanten 31 skal føres ind i den mux, der vælger destinationsregister. Desuden skal adressen på den efterfølgende instruktion (PC+4) kunne skrives til registrene i WB-fasen. JR Læst data fra registrene skal kunne skrives til PC. 6

7 2.3 Kontrol Vi bruger hovedsageligt samme kontrolsignaler som i [3]. Dog har vi valgt at fjerne den separate ALU-kontrol pga. I-type-instruktionerne, der - i modsætning til R-type - ikke specificerer regneoperationen i de seks mindst betydende bit. Derved forsvinder fordelen ved at separere kontrollen af ALU en ud fra hovedkontrollen. Udvidelserne af datastien har desuden tilføjet nogle kontrolsignaler: BNE, JumpReg og Link. Disse bruges henholdsvis af instruktionerne BNE, JR og JAL. Vi har placeret en tabel over kontrolsignalerne i appendiks G. 2.4 Forwarding Som i [3] har vi lavet en enhed til at håndtere forwarding: forwarding detection unit (FDU). Forwarding er et af de steder, hvor vi har forsøgt at vægte CPI og clockfrekvens. Spørgsmålet er hvor i pipelinen, der skal forwardes til Hvorhen? Vi havde en forventning om at ALU en ville være tæt på at være på den kritiske vej. Derfor ville vi så vidt mulig undgå at sætte andre komponenter i serie med denne, for ikke at forlænge signalvejen i EX-fasen. Ift. til clockfrekvens ville det derfor være ønskeligt, om vi kunne undgå at forwarde til EX-fasen, da dette kræver to muxer foran ALU en. Problemet ville så være, at der skulle forwardes til ID-fasen. Forwarding direkte fra ALU en ville ikke være en løsning, da vi dermed alligevel ville forlænge den (potentielt) kritiske vej. I stedet ville vi være nødt til at indsætte en bobbel mellem instruktionerne i ID- og EX-faserne, hvis der skulle forwardes. Da vi formoder at instruktioner ofte bruger udregningen fra den foregående instruktion, ville denne løsning øge CPI betragteligt. Vi har derfor valgt at holde CPI nede ved at forwarde fra de to foregående instruktioner til EX-fasen mod til gengæld at øge den potentielt kritiske vej, ved at sætte muxer foran ALU en. Uden om registrene De registre, som Kreds stiller til rådighed (RegisterFile [4, p 85]), muliggør ikke at man skriver til og læser fra det samme register i samme cyklus - dvs. det er muligt, men man får ikke den just skrevne værdi. Dette problem løses ved at lade det data, der bliver skrevet til registrene, erstatte den læste værdi. Altså forwarding fra WB-fasen til ID-fasen Forwarding fra LW Instruktionen LW er speciel ift. til de andre instruktioner, der skriver til registre. Det data den skriver kommer fra hukommelsen og er derfor først tilgængeligt i slutningen af MEM-fasen. Hvis dette data skulle forwardes direkte fra MEM- til EX-fasen, ville hukommelsessystemet komme til at sidde i serie med ALU en, hvilket ville give en meget lang signalvej. 7

8 Derfor vægter vi i det tilfælde, hvor der skal forwardes fra en LW-instruktion til instruktionen lige efter, clockfrekvensen frem for CPI. Vi indsætter en bobbel mellem de to instruktioner, således at data fra LW-instruktioner kun kan forwardes fra WB-fasen Detektering Kontrolsignalerne til muxerne har betydning for, hvor lang signalvejen gennem ALU en bliver. For at de skal være tilgængelige hurtigst muligt, har vi valgt at detektere evt. forwarding i ID-fasen, således at kontrolsignalerne til muxerne før ALU en blot skal forstærkes i EX-fasen. Dette giver ikke anledning til problemer, da destinationsregistrene for de foregående instruktioner er til rådighed i ID-fasen. 2.5 Hazards Vi har opdelt hazards i to grupper: fejlforudsigelser og resten. Fejlforudsigelser er den gruppe af hazards, der opstår når hop-forudsigeren gætter forkert. Den anden gruppe består kun af ovenfor beskrevne hazard ifm. LW samt et problem med selvmodificerende kode, der er kommet ind i pipelinen. Første gruppe håndteres af en enhed vi har navngivet misprediction detection unit (MDU) og anden gruppe af hazard detection unit (HDU) Misprediction detection unit MDU en håndterer som nævnt fejlforudsigelser. Da hop-forudsigeren jf. opgaveteksten [6, p 2] kun må bero sit gæt på adressen af instruktionen og ikke typen, skal MDU en derfor undersøge om alle instruktioner er blevet efterfulgt af instruktionen fra den rigtige adresse. Hvis det ikke er tilfældet, skal pipelinen ryddes fra den forkerte instruktion til og med IF-fasen og den korrekte adresse skal skrives til PC. Det vil desuden være oplagt at give hop-forudsigeren respons på dens gæt, når vi ved om det var korrekt eller ej. Hop og forgreninger håndteres som en delmængde af fejlforudsigelser og i det følgende vil vi gennemgå hvilke faser af pipelinen, MDU en skal behandle de forskellige typer instruktioner. BEQ/BNE Forgreninger kan først undersøges når deres betingelse er undersøgt, dvs. efter ALU en. Da vi som tidligere nævnt helst vil undgå at forlænge den signalvej ALU en er en del af, har vi valgt først at undersøge udfaldet i MEM-fasen. Alternativt kunne vi vælge at træffe beslutningen allerede i ID-fasen. Det ville forudsætte at vi indsatte noget sammenligningslogik i ID-fasen samt at vi indsatte bobler før forgreningsinstruktioner, da vi ellers ville skulle forwarde fra ALU en. Forgreningsinstruktioner, der brugte resultatet fra den foregående instruktion og som var blevet forudsagt korrekt ville have en CPI på 2, mens de forkert forudsagte ville have en CPI på 3. Med vores løsning er de tilsvarende tal henholdsvis 1 og 4. 8

9 Hvilket valg, der er det bedste, afhænger af hop-forudsigerens effektivitet. Hvis vi forudsætter at forgreninger altid bruger resultatet fra den foregående instruktion, så skal den procentdel af hop-forudsigerens gæt, der er korrekte (betegnet x), mindst være x 1 + (1 x) 4 < x 2 + (1 x) 3 4 3x < 3 x 1 2 < x for at vores løsning er bedst. Forudsætningen er ikke nødvendigvis sand, hvorfor effektiviteten af hop-forudsigeren skal være bedre end ovenfor beregnet, da CPI for løsningen i ID-fasen ville være lavere. Vi antager at vores hop-forudsiger bliver tilstrækkelig effektiv til at det kan betale sig først at foretage forgreningen i MEM-fasen. Forsinket forgrening I [3] s. 350 og 444 nævnes det at MIPS bruger delayed branching. Vi har spurgt opgavestilleren, Martin Zachariasen, og fået at vide at dette er forældet og ikke bruges på kurset (korrespondancen kan ses i appendiks B). Vi vil derfor undlade at bruge delayed branching. JR Vi ville helst have håndteret JR i EX-fasen, da dette ville give lavere omkostninger ved fejlgæt. Men for ikke at skulle forstærke signalerne for meget i EX-fasen - og måske forlænge den kritiske vej - valgte vi at håndtere JR i MEM-fasen i stedet. Alternativt kunne vi have valgt ID-fasen, men det ville kræve, at der blev indsat bobler, hvis der skulle forwardes. Desuden var vi bange for at signalvejen ville blive kritisk, hvis den skulle igennem registrene, FDU og MDU. J/JAL Disse to instruktioner er ikke afhængige af de foregående instruktioner og det kan derfor allerede i ID-fasen verificeres om den efterfølgende instruktion er rigtig. andre Da hop-forudsigeren ikke kender instruktionens type, er vi nødt til at undersøge om alle ikke-hop-instruktioner er blevet efterfulgt af instruktionen fra den efterfølgende adresse. Det vil dog formentlig være et meget sjældent forekommende problem, da vi - som omtalt i afsnit 3 - kun gemmer information om hop-instruktioner. For ikke at trække for meget på PC i ID-fasen, har vi valgt at undersøge forudsigelsen i EX-fasen i stedet, hvor PC er mindre brugt Hazard detection unit Udover de hazards som MDU en detekterer, er der som sagt to andre. Den ene følger af at vi ikke vil forwarde data læst fra hukommelsen direkte fra MEM-fasen - den er behandlet i afsnit Den anden følger af at en SW i MEM-fasen kan skrive til adressen, hvor en anden instruktion i pipelinen er hentet fra (selvmodificerende kode). I det sidste tilfælde skal pipelinen ryddes fra den ændrede instruktion til og med IFfasen og adressen på den ændrede instruktion skal skrives til PC. 9

10 2.5.3 Kontrol af flow Til at koordinere styringen af pipelinen har vi indført en enhed: stall and NOP control (SANC). Denne enhed skal styre flowet igennem pipelinen og indsætte bobler ud fra det input den får fra MDU en, HDU en og hukommelsen. Før vi diskuterer, hvordan koordineringen skal foregår, vil vi først kigge på, hvordan arkitekturen skal reagere, når hukommelsen ikke kan følge med. holdandwait Hvis hukommelsen ikke kan levere data i den nuværende cyklus markerer den det ved at sætte signalet holdandwait højt. Denne markering viser os ikke om det er dataporten og/eller instruktionsporten, der ikke er klar, men vi kan udelukke det første, hvis der ikke enten er en LW- eller en SWinstruktion i MEM-fasen. I det tilfælde er det derfor muligt at lade pipelinen fra ID-fasen til WB-fasen fortsætte uhindret, hvorved vi bruger ventetiden på at løse evt. hazards i pipelinen og mellem den instruktion vi venter på og instruktionen i ID-fasen. Hvis instruktionen i MEM-fasen bruger data-porten til hukommelsen er vi nødt til at fastholde instruktionerne i IF- og MEM-fasen, da vi ikke ved hvilken af dem vi venter på. Der er ingen grund til at gøre noget ved instruktionen i WB-fasen, da den ikke spærrer for flowet og fordi det ikke gør nogen skade at den skriver den samme værdi til det samme register flere cykluser i træk. Hvis instruktionen i EX-fasen derimod ikke behøver at komme videre i pipelinen (f.eks. en NOP-instruktion), så kan instruktionen i ID-fasen passere til EX-fasen. Vi vil dog kun foretage dette skift i tilfælde af at det er en SW-instruktion der er i MEM-fasen, da vi ellers kan skabe en LW-hazard (se afsnit 2.4.2). Indsættelse af bobler Tidligere har vi omtalt indsættelse af bobler og fjernelse af instruktioner fra pipelinen, men vi har ikke defineret, hvordan det skulle foregå. Det råder vi bod på i dette afsnit. En bobbel er en instruktion, hvor alle kontrolsignalerne er lave, hvilket medfører at den ikke påvirker hverken registre eller hukommelse. Så hvis vi vil indsætte en bobbel i f.eks. EX-fasen betyder det at vi skriver nuller for alle kontrolsignalerne, der går ind i ID/EX-grænsen. Hvis vi skal fjerne en instruktion i, så er der to tilfælde: instruktionen b i fasen bagefter skal blive hvor den er eller den skal passere videre/fjernes. I det første tilfælde skal vi indsætte en bobbel i den fase hvor instruktion i er. I det andet skal vi indsætte en bobbel i den fase, hvor instruktion b er. På den måde er det kun instruktion i, der bliver fjernet uden at påvirke instruktionerne før og efter. SANC en sørger for at kategorisere informationen fra HDU en, MDU en og hukommelsen i en af ovenstående grupper. Ud fra dette nulstiller den de kontrolsignaler, der går ind i de rigtige grænser og sætter skriv-flagene til grænserne samt PC. Bevar instruktionsadressen Når vi indsætter bobler er det vigtigt at adressen på instruktionen får lov at passere videre. På den måde kan MDU en altid regne med, at fasen, 10

11 før den instruktion den undersøger, indeholder adressen på den efterfølgende instruktion - selvom den reelt ikke befinder sig i den pågældende fase. 11

12 3 Design af hopforudsiger En pipelinet mikroarkitektur har en lang række klare fordele over et enkelt- eller flercyklusdesign, men introducerer også nye problemstillinger. Blandt disse må forudsigelse af hop betragtes som et af de mest væsentlige[2, 2.12]. Hvis pipelinen skal tømmes for derefter at fyldes igen, opstår en lang pause. Hvis dette problem ikke løses effektivt, vil ydeevnen af den færdige processor være i fare. Vi vil derfor i dette afsnit gennemgå designet af hopforudsigeren, grundlaget for at have en sådan, og tre forskellige modeller for dennes implementation. 3.1 Statisk og dynamisk forudsigelse Hopforudsigere kan deles ind i to grupper. En statisk hopforudsiger er tilstandsfri og betragter kun den øjeblikkelige situation, hvorimod en dynamisk forudsiger bruger en mænge hukommelse til at huske tidligere hop, og deres udfald. Moderne processorer bruger dynamisk hopforudsigelse[1], da disse gætter rigtigt relativt flere gange end de statiske [2, 2.12][1, 2.10]. 3.2 Tilgængelig information Det er et krav i opgaveteksten[6, p 2] at valg vedrørende hop skal tages i IF-fasen, for at minimere forsinkelsen ved hop. Da instruktionskoden på dette tidspunkt ikke er kendt, må forudsigelsen alene bero på instruktionsadressen. Andre processorer deler ikke dette design, og kan således basere gættet på instruktionskoden [1][2], hvis hoppen ikke tidligere har været igennem hopforudsigeren, og derfor er ukendt. Typisk gættes der på at hoppet tages hvis der hoppes bagud, og at det ikke tages hvis der hoppes fremad[2]. Oversættere kan bruge denne viden til at lave programmer der har færre fejlgæt. Vi nyder ikke denne fordel, og alle hop vil derfor blive gættet forkert første gang de gennemløbes. Da vi kun kan basere et gæt på instruktionsadressen, kan vi ikke lave en statisk forudsiger. Vi vil derfor se på tre løsningsmodeller der benytter dynamisk forudsigelse. 3.3 Hoptabellen Enhver dynamisk hopforudsiger har en tabel over n tidligere hop. Tabellen gemmer som minimum (iadr,hop) instruktionsadresse og hop-bitten. Alt efter hvilken model der vælges, kan det være nødvendigt med ekstra information. Vi har valgt ikke kun at gemme hop, men hele hop-adressen da vi så kan førsøge at forudsige alle typer hop, i modsætning til kun at forudsige betingede hop. Størrelsen af hopcachen er begrænset, da et signal der skal trække mange komponenter bruger længere tid på at stabilisere sig [4, p 32]. Når data skal udvælges fra hopcachen, skal der bruges en mux. Denne mux vil blive en af de begrænsende faktorer, da alle registre skal forbindes til den. Det er således vigtigt at udnytte cachen effektivt, da en udvidelse ud over 12

13 Figur 1: En adresse indlæres igen en hvis grænse vil forårsage en forøget klokcyklustid. Omvendt vil det ikke være nyttigt at lave en meget effektiv udnyttelse, hvis denne kræver så store mængder kontrollogik at cyklustiden må forøges. På denne baggrund søger vi at implementere en art prioriteret liste, der ikke husker de nyeste hop, men de mest brugte. Af de n registre i tabellen, kaldes det øverste den primære hopcache (PHC). De resterende registre kaldes sekundær hopcache (SHC) 1, 2,...n 1. Den primære hopcache indeholder det nyeste hop, og de sekundære registre indeholder ældre hop. Når et nyt hop læres, sker det ved at alle registre gøres en position ældre, hvorefter den nye adresse placeres i PHC. Når et allerede kendt hop - gemt i SHC n - mødes igen, byttes SHC n ud med PHC. Denne metode giver ikke fuldt ud en prioriteret liste, da PHC kan byttes ud med en af de laveste SHC er (vist i figur 2), hvis man rammer et hop der ikke har været behandlet igennem længere tid. Denne ulempe opvejes dog af designets simplicitet. Enhver SHC kan kun skrives til fra to kilder - den foregående SHC (PHC en for SHC 1 ), eller PHC. Ligeledes kan PHC en kun skrives til fra to kilder - den indgående hopinformation, eller den SBC der indeholder gammel information om hoppet. Dette, at løsningen kræver mindre kontrollogik end en fuld prioriteret liste, gør den lettere at implementere, og tillader flere SHC er. Findes en adresse ikke i cachen, gættes der på den næste instruktion. 3.4 Model 1: Den naive hopforudsiger Den naive hopforudsiger har lidet at tilføje til hopcachen som den ser ud. Denne type forudsiger gætter på at et hop har samme udfald som sidste gang det blev taget. Det er ikke vanskeligt at implementere denne model, men den har et antal problemer (se afsnit 3.7.1). 3.5 Model 2: Hopforudsiger med dynamisk indlæring Denne model adskiller sig fra den foregående, ved ikke blindt at vælge samme udfald som sidst. I stedet bruges informationen fra MDU en (afsnit 2.5.1) til at begrænse indlæringen til de rigtige gæt. Dette forbedrer de situationer hvor et hop er tæt på at være altid-taget eller aldrig-taget. 13

14 Figur 2: Alderskorruption 3.6 Model 3: Hopforudsiger med 2-bit hophistorie Det ville være ønskeligt om forudsigeren kunne tilpasse sig hvert hop, og lære både af forkerte og rigtige gæt. En 2-bit hopforudsiger har disse egenskaber [3, p , ]. Ved at benytte en historie over de to sidste hop, er det muligt først at ændre på gættet for et givet hop når der er foretaget to forkerte gæt (dette er vist i figur 3). Ligesom den dynamiske forudsiger, har denne model forøget gætsikkerhed på hop der er tæt på at være altid-taget eller aldrig-taget, men i modsætning til den dynamiske fremgangsmåde, kan der her læres at et hop i en periode tages, så i en periode ikke tages, for så at tages igen, o.s.v. Figur 3: 2-bit-forudsiger 3.7 Teoretisk ydelse Model 1: Den naive hopforudsiger Den naive forudsiger har den svaghed at den lærer på de forkerte tidspunkter. Dette gør at den kan være dårligere end altid at gætte på næste instruktion. Da forudsigeren altid lærer af sidste resultat, vil en løkke hvor et betinget hop der tages hver anden gang (se eksempel 1, figur 4) have 0 korrekte gæt! I en løkke der gennemløbes 10 gange (eksempel 2, figur 5), vil bne-instruktionen gættes forkert første gang, da hoppet ikke er kendt. Desuden vil den gætte forkert sidste gang, da hoppet her skiller sig ud fra sidste gennemløb. Denne effekt forværres når løkken indlejres i en anden løkke. Hvis vi betragter en dobbelt-løkke der udføres gange (eksempel 3, figur 6), vil den ydre løkke have 8 gæt rigtige ud af 14

15 10, eller 80% træfsikkerhed. Den indre løkke vil have samme antal rigtige per gennemløb. Den totale træfsikkerhed er derfor = 88 ud af = 110 mulige (80%) Model 2: Hopforudsiger med dynamisk indlæring Da denne model ikke lærer af fejl, vil den i eksempel 1 have 50% rigtige, hvilket er lige så godt som at gætte på næste instruktion hver gang. Et en altid skiftende situation som denne, kan man dårligt forvente mere af en forudsiger. I eksempel 2 vil den gætte hoppet forkert sidste gang, men vil i modsætning til den naive forudsiger ikke huske dette!. Derfor vil de 9 sidste gennemløb af den indre løkke i eksempel 3 kun have 1 fejl, da hoppet første gang forudsiges som taget, hvorfor træfsikkerheden er = 97 ud af 110 mulige (88%) Model 3: Hopforudsiger med 2-bit hophistorie Denne model er i de givne eksempler lige så effektiv som den dynamiske forudsiger, da der på intet tidspunkt er et hop der ikke tages, to gange i træk. I eksempel 3 vil den inderste BNE blive nedgraderet til 10, for derefter at blive opgraderet til 11 igen (som vist på figur 3). En 2-bit hopforudsiger opfører sig derfor på samme måde som den dynamiske, dog af en anden grund. Denne model kan endvidere lære at et hop der tidligere har været taget, ikke længere skal tages. Det formår den dynamiske ikke, men den er til gengæld mere stædig, hvilket kan være en fordel. 3.8 Det valgte design Da det ikke er fuldkommen klart om en dynamisk eller 2-bit forudsiger er den mest effektive, har vi implementeret begge, og målt på dem med de benchmarks der er udleveret. Resultatet heraf kan ses i afsnit

16 4 Implementation Dette afsnit har til hensigt at give et overblik over vores implementation, således at læseren ved hvor i kildekoden implementationsdetaljer skal findes. Desuden vil vi kort gennemgå vores konventioner samt de programmer og versioner af samme, som kildekoden er rettet imod. 4.1 Kildekode Kildekoden er skrevet i Kreds v Komponenter er i videst muligt omfang blevet kaldt det samme som i foregående afsnit, [3] og på diagrammerne (se appendiks A). Kommentarer er regelmæssige og på dansk, hvilket kombineret med Kreds nærmest symbolske syntaks, gør koden selvforklarende. Implementationen af vores mikroarkitektur er opdelt i filer - en for hver af de større enheder, der også lægger navn til filerne. Alle filerne kan findes i appendiks H samt på elektronisk form i di030298/k11. 16

17 5 Analyse af ydelse Vi vil i dette afsnit undersøge ydelsen af vores arkitektur. Dette vil vi gøre ved at se på, hvor hurtigt den afvikler en række programmer (benchmarks). Desuden vil vi se på den kritiske vej og om denne kan afkortes, således at clockfrekvensen bliver højere. 5.1 Benchmarks Før vi måler ydelsen af den endelige arkitektur, vil vi først undersøge effektiviteten af de diskuterede hopforudsigere, således at den optimale kan vælges Hopforudsiger-benchmarks For at bestemme hvilken hopforudsiger, der er mest effektiv, har vi kørt de udleverede benchmarks på en version, hvor hopforudsigeren har dynamisk indlæring, en version med 2-bit hophistorie og en arkitektur hvor hopforudsigeren er fjernet. Vi har derefter udregnet træfsikkerheden for forgreningsinstruktioner (BEQ, BNE), da disse instruktioner er de eneste interessante. Ved J og JAL er adressen kendt efter første besøg, og den ændres ikke medmindre der er tale om selvmodificerende kode, hvilket under alle omstændigheder er dårligt for ydelsen på en moderne arkitektur [2, 2.36]. Ved JR har man kun en ringe chance for at gætte rigtigt, da den samme stump kode typisk kaldes fra flere forskellige steder. Hyppigheden af BNE og BEQ er desuden højere end for de resterende hop-instruktioner tilsammen! Resultatet af kørslen ses i appendix D. Der er et antal interessante ting at bemærke om resultaterne. Begge hopforudsigere er virkelig effektive (> 99%) i AsmBsort og AsmCopy. Disse benchmarks indeholder en håndfuld hopinstruktioner der tages gang på gang. Der ses en forbedring på en faktor 20 eller mere, i forhold til ikke at bruge en hopforudsiger. Ved to benchmarks - fib1 og AsmFib, er der ingen forskel på hvorvidt der bruges hopforudsiger eller ej. Dette skyldes sandsynligvis at disse programmer indeholder hop der tages hver anden gang, eller i et tilfældigt mønster. Enhver hopforudsiger vil have svært ved den situation. Kun i ét tilfælde var det tydeligt ugunstigt at bruge en hopforudsiger. Benchmarket AsmScatter er lavet med henblik på at stresse cachen til hukommelsen 3, men det viser sig at den også stresser hopforudsigeren. Der er ingen nævneværdig forskel på den dynamiske- og 2-bits forudsigeren i gennemsnit, eller i bedste benchmark. Til gengæld kan 2-bit forudsigeren ikke klare Asm- Scatter hvor den scorer 2%, hvilket ca. er en faktor 30 ringere end ikke at forudsige hop. Alene af denne grund udpeges den dynamiske hopforudsiger som vinder. På denne baggrund benyttes den dynamiske hopforudsiger i vores løsning. 3 Ifølge den tilhørende README-fil 17

18 5.1.2 Obligatoriske benchmarks Kørslerne af de obligatoriske benchmarks er opsummeret i følgende tabel. Udskrifter er placeret i appendiks F, hvor også udskrifter fra programmet mips kan findes. Sidstnævnte indeholder bla. opgørelser over hvor mange gange hver instruktion er blevet udført. Program Simuleret køretid Antal clockcykler Antal instruktioner CPI AsmBsort 1.013,87µs ,014 AsmCopy 205,907µs ,148 AsmFib 400,876µs ,461 AsmQsort 466,489µs ,524 AsmScatter 314,261µs ,738 fac1 15,5276µs ,371 fib1 605,657µs ,226 mergesort1 1120,34µs ,298 primes1 955,915µs ,065 Vi har ikke mulighed for at kommentere de simulerede køretider, da vi ikke har et sammenligningsgrundlag. Derimod er det interessant at bemærke variationen i CPI-værdierne Bemærkninger om CPI Eftersom de aritmetiske og logiske operationer har en CPI på én - hvis man tillægger bobler forårsaget af LW-hazards (se afs ) til LW - er det kun hop-instruktioner og hukommelsessystemet, der kan bringe CPI over én. Vi vil kommentere de to ekstremer samt et middeltilfælde. AsmBsort Det lave CPI for dette program vidner om at de relativt mange LW-instruktioner (33%) ikke stresser hukommelsessystemet. Dette er naturligt, eftersom der er tale om bubble-sort, der sammenligner data fra naboadresser, hvorved det udnyttes til fulde, at cachen er optimeret ift. spatial placering. Desuden er hopforudsigerens effektivitet for programmet tydelig, eftersom hop-instruktioner udgør 33%, uden at det bringer CPI væsentligt over én. AsmScatter Fra afsnit ved vi at forgreningsforudsigelsen for dette program er dårlig (33,44% korrekte). CPI-bidraget fra BEQ og BNE er således ( ) (1 33, 44% + 4 (100% 33, 44%)) = 0, 4735 De dårlige gæt kan altså ikke alene få CPI op på 1,738, hvilket stemmer overens med beskrivelsen af programmet 4 : Tilgang til lagerområder organiseret så de stresser 4 taget fra /usr/local/del1/dat1e/k1/benchmarks/readme på DIKU s system 18

19 cachens associativitet. Dvs. at det formentlig hovedsageligt er de 26,29% LW- og SW-instruktioner, der bringer CPI en op. primes1 Programmet stresser hukommelsessystemet i det ekstreme. Hvis vi udregner CPIbidraget fra de instruktioner, der ikke bruger hukommelsessystemet (vi ser bort fra den påvirkning hentning af instruktioner har) fås: ( ) (1 81, 77% + 4 (100% 81, 77%)) = 0, 9491 Her har vi brugt hopforudsiger-præcisionen fra afsnit samt antaget at alle JRinstruktioner gættes forkert og at alle J/JAL-instruktioner gættes rigtigt. Sidstnævnte antagelser er ikke væsentlige for pointen, da instruktionerne udgør 16% af instruktionerne. Resten af CPI-værdien (5,065-0,9491=4,1159) kan kun komme fra hukommelsessystemet. Dvs. vi kan konkludere at programmet ikke udnytter cachens optimering ifm. spatial og temporal placering. 5.2 Kritisk vej Vi har undersøgt slack-diagrammet for vores arkitektur for at finde de steder, hvor en optimering vil have størst effekt på clockfrekvensen. Den kritiske vej i vores arkitektur er vejen fra PC til skriv-signalerne for grænserne ID/EX og EX/MEM. Denne vej går igennem hukommelsessystemet og SANC en. Da vi kan se, at der på en række af signalerne er en stor forsinkelse i udbredelsen, er vi nået frem til følgende steder, hvor signalvejen kan forkortes: PC Eftersom PC bliver brugt i flere forskellige signalveje, kan vi øge udbredelseshastigheden ved at dele PC en op. Denne optimering er implementeret i kredsløbet og vi har - ved at bruge en separat PC til hukommelsessystemet og en anden til resten af IF-fasen - opnået en forbedring på ca. 3MHz i clockfrekvensen. Grænserne Hvis vi kunne gøre grænserne mindre, dvs. føre færre linjer ind i dem, ville skriv-signalerne til dem opnå en højere udbredelseshastighed, da færre flip-flops skulle styres. Desværre er der ikke umiddelbart nogen signaler vi kan undvære i faserne, så her kan vi ikke optimere. Cachen holdandwait-flaget fra hukommelsessystemet er kritisk. Eftersom dette flag markerer, at det efterspurgte data ikke befinder sig i cachen, vil en hurtigere cache gøre dette signal tilgængeligt tidligere. For at gøre cachen hurtigere kan vi f.eks. give den en lavere associativitet, hvorved der skal vælges mellem data fra færre cache-banker. Endvidere er det muligt at de enkelte cache-banker kan gøres hurtigere ved en optimeret vægtning af blok-størrelse kontra antal bit i blok-mærkerne. 19

20 Hvis ovenstående optimeringer har en betydelig effekt, vil de ikke alene bringe clockfrekvensen voldsomt op, da signalvejen gennem ALU en er tæt på at være kritisk. Vores ALU er ikke specielt hurtig og der vil formentlig være en væsentlig gevinst ved at bruge noget af vores rigelige transistorbudget på at optimere den. En mulig forbedring kunne være at implementere et carry-select-skema i stedet for blot at bruge adder-komponenten fra Kreds. 20

21 6 Afprøvning Vi vil i dette afsnit diskutere, hvordan vores mikroarkitektur kan afprøves, så det overbevisende sandsynliggøres, at den er korrekt. 6.1 Strategi Vores afprøvning består af to dele: en intern og en ekstern. Den interne tager udgangspunkt i arkitekturen og de overvejelser vi har gjort os i forbindelse med designet og skal vise at problemstillingerne er løst korrekt. Den eksterne test skal vise at reelle programmer, som vi ikke har konstrueret, kan afvikles korrekt. Der er i opgaveteksten [6, p 3] refereret til en række testprogrammer, som vi vil lade udgøre den eksterne test. I resten af afsnittet vil vi derfor kun gennemgå den interne test Intern afprøvning I de følgende afsnit vil vi gennemgå de ting, der skal afprøves og opstille ækvivalensklasser. Det er ikke et krav i opgaveformuleringen, at arkitekturen skal kunne håndtere instruktioner, der er ugyldige eller ikke ligger i den mængde arkitekturen understøtter. Vi vil derfor ikke teste med sådanne instruktioner. Da vi således kun vil teste med instruktioner, som arkitekturen understøtter og da vi ikke forventer nogen fejlsituationer, vil vi samle alle tests i et program. Korrektheden af mikroarkitekturen afprøves ved hjælp af testprogrammet samt programmet mips 5. mips kan generere en sporfil (mips <program> 3 <sporfil>) ved kørslen af et program. Sporfilen indeholder information om hvilke data, der bliver skrevet til hvilke registre og adresser i hukommelsen og i hvilken rækkefølge det sker. Denne sporfil kan så sammenholdes med udførelsen af det pågældende program på vores arkitektur, ved at bruge parameteren -trace<sporfil>. I tilfælde af uoverensstemmelser mellem de to kørsler, vil simulationen komme med en fejlmeddelelse De enkelte instruktioner Som det første vil vi undersøge de enkelte instruktioner for sig. Det falder nok ikke direkte ind under en intern test, men vi mener det er berettiget, da de eksterne testprogrammer ikke nødvendigvis bruger alle instruktionerne. Ækvivalensklasser for tal Da alle I- og R-type instruktioner opererer på tal, vil vi først opdele de mulige tal i ækvivalensklasser og finde grænsetilfælde. Da indlejrede konstanter skal fortegns-forlænges for de aritmetiske operationer samt BEQ og BNE, men nul-forlænges for de logiske, skal der testes med både negative og positive indlejrede konstanter. 5 programmet findes på DIKU s system: dat1e/simsys/bin/i686-linux-redhat7.3/mips 21

22 De værdier, der kan være i registrene, vil vi ligeledes teste med både positive og negative tal. Vi har altså fire ækvivalensklasser for tal: positive/negative indlejrede konstanter og positive/negative tal fra registre. Grænsetilfælde indenfor disse klasser er henholdsvis: 0 og (2 15 1), 1 og ( 2 15 ), 0 og (2 31 1), 1 og ( 2 31 ). I-format (undtaget BEQ og BNE) I-type instruktioner udfører en operation på indholdet af et register og en indlejret konstant. Resultatet gemmes i et register. Vi antager at udførelsen af instruktionen ikke påvirkes af, hvilke registre der læses fra/skrives til (register $0 undtaget - det testes 6.1.5). Det er derfor blot interessant at vælge det data, som operationen udføres på. Hver af instruktionerne testes derfor på de 16 mulige kombinationer af de grænsetilfælde for tal, der er nævnt i foregående afsnit. For at kunne lave de meget store tal uden at skulle skrive flere tusinde linjer, bruges R-type instruktionen add inden den er testet. Fejl i denne kan gøre testen af I-type instruktionerne ikke testes korrekt, men vi forventer så at evt. fejl i add fanges i den specifikke afprøvning af add. R-format (undtaget JR) R-type instruktioner udfører en operation på indholdet af to registre og gemmer resultatet i et register. Vi tester på de 16 mulige kombinationer af grænsetilfælde for tal i registre på hver instruktion. Hop-instruktioner Hop-instruktioner kan ikke testes direkte vha. tracefilen, da deres funktion ikke er at ændre på registre/hukommelse (JAL undtaget). I stedet placeres instruktioner, der skriver til registre, de steder, hvor det kan forventes at hop-instruktionen fører hen. En forkert implementeret hop-instruktion må forventes at kunne føre til en hvilken som helst adresse, hvilket vi ikke kan teste. I stedet indsætter vi to forskellige registerpåvirkende instruktioner: lige efter hop-instruktionen og der hvor hop-instruktionen peger hen. For at kunne skelne er det vigtigt at hop-instruktionen ikke peger på den efterfølgende instruktion. Mindre oplagte fejl, der fører til andre steder i koden, vil med stor sandsynlighed ikke forårsage det samme spor som en korrekt afvikling og fejlen vil så blive opdaget. Det vil dog være svært at se hvilken instruktion, der forårsagede fejlen, men eftersom vi ikke forventer fejl i den endelige udgave, er det underordnet. BEQ/BNE Da BEQ og BNE læser fra to registre, tester vi med de i alt 16 muligheder for kombinationer af grænsetilfældene. J/JAL Disse instruktioner læser ikke fra nogen registre og vi vil derfor kun teste hver af dem med en værdi, jf. ovenstående generelle overvejelser om hop. 22

23 JR Ved at teste JAL før JR kan vi bruge JAL i testen af JR, hvilket gør det nemmere at indsætte en meningsfuld adresse i det register, som JR skal hoppe til. Det kan tænkes at arkitekturen kun understøtter hop til adresser i register $31, da dette er den oplagte anvendelse (ifm. JAL). Da instruktionen muliggør hop til adresser fra alle registre, testes - udover register $31 - også et vilkårligt af de andre registre. LW og SW Disse instruktioner kan - som de andre instruktioner, der bruger adresser - ikke testes med alle grænsetilfælde. Der testes derfor med adresser sammensat af det nedre grænsetilfælde (nul) for både indlejret konstant og registerværdi samt med vilkårlige ikkenul-værdier. Data kan testes med begge grænseværdier, 0 og Samlet er det otte test af hver af de to instruktioner Forwarding Det skal testes at der forwardes korrekt mellem de forskellige faser. Hvordan testes forwarding Pga. hukommelsessystemet kan vi ikke være sikre på at instruktioner, der står lige efter hinanden i koden, kommer ind i pipelinen lige efter hinanden. For at opnå dette, udføres test-sekvenserne i løkker, således at instruktionerne bliver hentet til cachen. I det sidste gennemløb (måske før) vil instruktionerne i test-sekvensen komme ind i pipelinen lige efter hinanden og forwardingen vil blive testet. Hvilke ting skal testes Det skal testes at der kan forwardes både en, to og tre instruktioner frem. Desuden skal det testes at der ikke forwardes fra register $0. Vi antager at det ikke har betydning, hvilken instruktion der er tale om og tester derfor blot vilkårlige instruktioner Hazards Der er som nævnt i afsnit 2.5 to slags hazards i vores design: fejlforudsigelser og resten. Fejlforudsigelser testes ved en separat test-kørsel, hvor hop-forudsigeren altid foreslår adresse FFFFFFFF 16. Test af LW-hazarden forudsætter at instruktionerne kommer ind i pipelinen lige efter hinanden, hvorfor vi udfører dem i løkker - jf. diskussionen om test af hop-instruktioner. SW-hazarden testes ligeledes i en løkke. Ved hvert gennemløb skrives en ændret instruktion til den samme adresse inden i løkken, hvorved vi i (de) sidste gennemløb vil få testet SW-hazarden. Vi forventer ikke at det har nogen betydning, hvilken type instruktion, der ændres - den skal blot have en effekt på enten hukommelsen eller et register, så den kan spores. Da det er nemmest at ændre en I-format instruktion i en løkke (læg en lille konstant til) bruger vi addi. 23

24 6.1.5 Beskyttelse af register $0 Det skal testes at det ikke er muligt at skrive til register $0. Hvilken instruktion, der er tale om og hvilket data, der forsøges skrevet er ikke interessant. Vi prøver derfor med en addi-instruktion. 6.2 Resultater Vi har konstrueret et assemblerprogram ud fra ovenstående kriterier. Programmet kan ses i appendiks C.1 og rækkefølgen af tests følger ovenstående afsnit. Fejlforudsigelser er testet med samme program, men i en udgave af mikroarkitekturen, hvor mikroarkitekturen som sagt er ændret til at foreslå FFFFFFFF 16 hele tiden. Den modificerede udgave af pipelined.k (pipelined-miss.k) kan ses i appendiks C.4. Udskrifter fra afviklingen af såvel den interne som de eksterne tests, kan ses i appendiks C. Alle tests afvikledes korrekt. 24

25 7 Litteratur [1] Intel Corporation. IA-32 Intel Architecture Software Developers Manual, [2] Intel Corporation. Intel Pentium 4 and Intel Xeon Processor Optimization Reference Manual, [3] David A. Patterson and John L. Hennessy. Computer organization and design : the hardware/software interface. Morgan Kaufmann Publishers, Inc., second edition, [4] Signe Reuss and Martin Zachariasen. Datalogi 1E, kursusbog 2003: Kreds. Number 3 in 4. HCØ Tryk, [5] Martin Zachariasen. En enkelt/dobbelt-cyklus mikroarkitektur. Dat1E godkendelsesopgave 2, oktober [6] Martin Zachariasen. En pipelinet mikroarkitektur. Dat1E karakteropgave 1-1, november

26 A Diagrammer A.1 Pipeline 26

27 A.2 Hopforudsiger 27

28 A.3 Styrelogik til hopforudsiger 28

29 A.4 Hopcache-register B Delayed branching From: "Martin Zachariasen" <martinz@diku.dk> To: "Rune Højsgaard" <rune@hojsgaard.dk> Sent: Monday, November 10, :02 AM Subject: Re: Delayed branch Hej Rune Det var kun nogle ældre versioner af MIPS som benyttede delay branching. Det bliver slet ikke benyttet i vores simulatorer - og iøvrigt på dette kursus. Mvh. Martin On Sat, 8 Nov 2003, Rune Højsgaard wrote: > Hej, > > Vi undrede os over at COD på s. 350 nævner at MIPS bruger delayed > branching, da dette ikke er nævnt i hverken G2 eller K11. Det viser sig > at mips-programmet [1] på DIKU s system ikke lever op til dette, hvilket > følgende kørsel viser: > > syn G2$ mips /usr/local/del1/dat1e/g2/logtst.hex 2 > > : ADDI $1,$0,8080 $1 <- FFFF8080 > : ORI $1,$1,808 $1 <- FFFF8888 > : ANDI $1,$1,8800 $1 <

30 > C : ADDI $1,$1,8800 $1 < > : BEQ $0,$1,2 > : 3021EFFF ANDI $1,$1,EFFF $1 < > : BEQ $0,$1,3 PC < > --- > : ADDI $1,$1,1 $1 < > C : AC01FFF4 SW $1,FFF4($0) OUT[FFFFFFF4] : > : AC01FFFC SW $1,FFFC($0) OUT[FFFFFFFC] : > > : FC STOP > > [...] > > BEQ-instruktionen ved adresse 0x18 efterfølges af en SW-instruktion, der burde blive udført. > Men nej - er det en fejl eller en feature (og skal vi eftergøre det)? > > [1] /usr/local/del1/dat1e/simsys/bin/i686-linux-redhat7.3/mips > > MVH Espen, Rune & Christian > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system ( > Version: / Virus Database: Release Date:

31 C Afprøvning Herunder følger afprøvningsprogrammet samt udskrifter fra kørslerne af testprogrammerne. Filerne kan findes i mappen di030298/k11 på DIKU s system. C.1 test.asm Følgende er programmet til intern test: ; Tilføj / fjen _ ikke _ instruktioner FØR testen ; af selmodificerende kode! ; Addressen på instruktionen som skal ændres ; er hard - codet. ; De store tal og , der ; ikke kan skrives direkte, gemmes i henholdsvis ; register $11 og $10 addi $10, $0, addi $10, $10, 1 ; 2^15 add $10, $10, $10 ; 2^16 add $10, $10, $10 ; 2^17 add $10, $10, $10 ; 2^18 add $10, $10, $10 ; 2^19 add $10, $10, $10 ; 2^20 add $10, $10, $10 ; 2^21 add $10, $10, $10 ; 2^22 add $10, $10, $10 ; 2^23 add $10, $10, $10 ; 2^24 add $10, $10, $10 ; 2^25 add $10, $10, $10 ; 2^26 add $10, $10, $10 ; 2^27 add $10, $10, $10 ; 2^28 add $10, $10, $10 ; 2^29 add $10, $10, $10 ; 2^30 add $10, $10, $10 ; -2^31 = addi $11, $10, -1 ; 2^31-1 = ; Værdien -1 gemmes i register $12 addi $12, $0, -1 ; ; Afprøvning af de enkelte instruktioner ;; I- format addi $1, $0, 0 ; Registerværdi = 0 addi $1, $0, -1 addi $1, $0, addi $1, $0, addi $1, $11, 0 ; Registerværdi = addi $1, $11, -1 addi $1, $11, addi $1, $11, addi $1, $12, 0 ; Registerværdi = -1 addi $1, $12, -1 addi $1, $12, addi $1, $12, addi $1, $10, 0 ; Registerværdi = addi $1, $10, -1 addi $1, $10, addi $1, $10, slti $1, $0, 0 ; Registerværdi = 0 slti $1, $0, -1 slti $1, $0,

32 slti $1, $0, slti $1, $11, 0 ; Registerværdi = slti $1, $11, -1 slti $1, $11, slti $1, $11, slti $1, $12, 0 ; Registerværdi = -1 slti $1, $12, -1 slti $1, $12, slti $1, $12, slti $1, $10, 0 ; Registerværdi = slti $1, $10, -1 slti $1, $10, slti $1, $10, andi $1, $0, 0 ; Registerværdi = 0 andi $1, $0, -1 andi $1, $0, andi $1, $0, andi $1, $11, 0 ; Registerværdi = andi $1, $11, -1 andi $1, $11, andi $1, $11, andi $1, $12, 0 ; Registerværdi = -1 andi $1, $12, -1 andi $1, $12, andi $1, $12, andi $1, $10, 0 ; Registerværdi = andi $1, $10, -1 andi $1, $10, andi $1, $10, ori $1, $0, 0 ; Registerværdi = 0 ori $1, $0, -1 ori $1, $0, ori $1, $0, ori $1, $11, 0 ; Registerværdi = ori $1, $11, -1 ori $1, $11, ori $1, $11, ori $1, $12, 0 ; Registerværdi = -1 ori $1, $12, -1 ori $1, $12, ori $1, $12, ori $1, $10, 0 ; Registerværdi = ori $1, $10, -1 ori $1, $10, ori $1, $10, ;; R- format register 1: register 2: add $1, $0, $0 ; 0 0 add $1, $0, $11 ; add $1, $0, $12 ; 0-1 add $1, $0, $10 ; add $1, $11, $0 ; add $1, $11, $11 ; add $1, $11, $12 ; add $1, $11, $10 ; add $1, $12, $0 ; -1 0 add $1, $12, $11 ; add $1, $12, $12 ; -1-1 add $1, $12, $10 ; add $1, $10, $0 ; add $1, $10, $11 ; add $1, $10, $12 ; add $1, $10, $10 ; sub $1, $0, $0 ; 0 0 sub $1, $0, $11 ;