Emnehefte - Mikroprosessorer

Transkript

1 Emnehefte - Mikroprosessorer ISSN: /Kompendium [1] [2] Vegar Johansen Revidert av Henning Gundersen desember 2011

2 2

3 Innholdsfortegnelse Innholdsfortegnelse Litt prosessorhistorie prosessoren prosessoren prosessoren prosessoren Pentium-prosessoren Itanium-prosessoren Core i7-prosessoren Eksempel på et brikkesett (chipset) Siste tids utvikling Blokkskjema for en Intelprosessor Pipeline Branch prediction Cachehukommelse Organisering av cache - hukommelser Skriveprinsipper ved cachehukommelser og et eksempel på en protokoll MESI-protokollen Forenklet programmeringsmodell for en Intel prosessor Registerblokker En prosessors operasjonsmodi Real mode Protected mode Virtuell-8086 mode System Management Mode Eksempel på et pagingsystem med en 32-bits Intel prosessor Flat minnemodell Beskyttelse av IO - porter Instruksjonsrepertoar Det første assemblyprogrammet for Intel prosessor

4 7 Interrupt i en mikroprosessor Et realmode eksempel Advanced Programmable Interrupt Controller (APIC) Message Signaled Interrupts (MSI) RISC - og CISC - arkitektur i prosessorer CISC RISC Feilkontroll Sjekksum CRC - sjekk IO bussystemer i en PC Universal Serial Bus (USB) Litteraturreferanser Appendiks 1 - Instruksjonsrepertoaret i Intel x86-familien

5 1 Litt prosessorhistorie Prosessorer levert fra Intel har vært benyttet i PC-er fra begynnelsen av 1980-tallet. Intel har garantert at en ny prosessor hele tiden skal være kompatibel med tidligere prosessorer de har levert. Dette innbærer at kode skrevet for en 8086-prosessor kan kjøres på nye Intel-prosessorer. Prosessorfamilien disse tilhører, kalles gjerne x86- familien. Under er vist en historisk oversikt for denne familien samt bilder av en av de siste Intel utgavene. Prosessorbetegnelser Klokketakt Databuss Adresserbart minne Lansert bredde(bit) (Bytes) år Mhz 8 64kB Mhz 16 1MB MHz 16 16MB MHz 32 4GB MHz 32 4GB 1989 Pentium 200 MHz 2x32 4GB+L1cache 1993 PentiumPro 200 MHz 2x32 64GB+L1/L2cache 1995 Pentium4 3.8 GHz 2x32 64GB+L1/L2cache 2000 Itanium 2* 1.6 GHz = 1 petab 2002 Pentium D 3.2 GHz 2x32 64GB 2005 Pentium EE 3.46 GHz 64 64GB 2005 Inte Core 2 Quad 2.83 GHz 64 64GB 2008 Intel Core i7 (4 kjerner) 3.2 GHz QPI Quick Path Interconnect 2008 Xeon 7460 (server) 2.3 GHz 64 1 TB 2008 Tabell 1.1 En historisk oversikt over noen av Intels prosessorer. *128-bits heltalls og floating-point registre 5

6 Figur 1.1 Bilde av en Intel Core i7. [2] prosessoren Første IBM PC ble lansert i 1981 og prosessoren i denne var en 8088 med en 8-bits databuss ut, men med 16-bits intern arkitektur prosessoren hadde vært på markedet i tre år når denne PC en så dagens lys prosessoren 286-prosessoren kom også på markedet bare få måneder etter at denne PC en ble lansert. 286 hadde en 24 bits adressebuss noe som ga et adresseringsområde på 16 MB. Denne prosessoren kunne operere i to modus, real mode og protected mode. I protected mode kunne prosessoren håndtere virtuelt minne som gjør det mulig for prosessoren å adressere et større adresseområde enn det adresseområdet som dekkes av fysisk internminne i maskinen. Det som var uheldig med 286 prosessoren var at denne kunne koble om fra realmode til protected mode, men ikke omvendt vei uten en restart av maskinen prosessoren 386 prosessoren var den første prosessoren fra Intel som hadde gjennomført 32-bits arkitektur. (IA32, IA står for Intel Architecture). Denne kunne også operere i virtuell 86 modus i tillegg til real mode og protected mode. Den nye modusen simulerte real mode 86 - prosessorer og gjorde det mulig å starte flere slike. Dette gjør det mulig å kjøre flere DOS-programmer samtidig og de vil være beskyttet i forhold til hverandre. Hvert DOSprogram får tildelt 1 MB med minne prosessoren Med 486 prosessoren fikk vi etter hvert integrert den modulen som regner med tall med komma (flyttallsprosessor = floating point unit = FPU) på prosessorbrikken. (Slike prosessorer kan også behandle heltall.) Flyttallsprosessorer hadde tidligere vært en selvstendig brikke. En annen nyhet i 486 var cachehukommelse for å øke ytelsen. 6

7 Sammen med en mulighet for å overføre data mellom minne og prosessor ved såkalt burst mode, resulterte dette i at 486 fikk en ytelse lik det dobbelte av ytelsen til 386. Burst mode betyr at vi kan gjøre mange dataoverføringer etter hverandre til eller fra et sammenhengende minneområde. Hver overføring besto av 4 byter (32 bits databuss) Pentium-prosessoren Pentiumprosessoren hadde en arkitektur som nærmer seg en 64-bits arkitektur. Den hadde en 64-bits databuss ut, den har 2 ALU er internt og blir på den måten en slags 2x32 bits prosessor. Den interne cachehukommelsen (L1 cache) ble utvidet til 8kB for instruksjoner og 8 kb for data. Pentium E (extreme edition) hadde følgende hoveddata: Klokketakt GHz Dual core, hvilket betyr 2 komplette prosessorkjerner på samme brikke L2 cache integrert på prosessorbrikken. L1 datacache består av 2stk 16 kb. L2 cache har kapasitet på 2MB for hver kjerne, totalt 4MB Itanium-prosessoren Itanium er en 64-bits prosessor (IA64) som ble lansert i 2002 i samarbeid med Hewlett Packard. Den har blant annet følgende data: 64 bits flat adresseringsmodell 64 bits databuss 128 interne heltalls register, bredde 64 bit 128 interne flyttalls register, bredde 82 bit cachenivå: L1 32k, L2 256k, L3 32MB IA32 kompatibel Skalerbare systemer opp til 32 prosessorer, men det finnes systemer med 512 prosessorer 25 mill transistorer i CPU og 300 mill i cache. Tukwila er kodenavnet på den neste generasjon av Itanium. Selv om denne er noe omgitt av hemmelighets kremmeri antas det at denne skal ha av mange kjerner og at den skal benytte SMT (Simultaneous multithreading). Denne teknikken tillater mange tråder (små eksekverbare enheter) å bli kjørt samtidig og dermed øke ressursytelsen i prosessoren. Prosessoren vil ha 4 kjerner og 30 MB cache pr prosessorbrikke. 7

8 Core i7-prosessoren Core i7 ble lansert i november Her er gjort en del arkitektur endringer og av hovedpunkter for 940-utgaven nevner vi: 4 kjerner klokketakt 2.93 GHz 8MB L2 cache 36 bit fysisk adressebuss 731 mill transistorer (det kan nevnes at Xeon 7460 med sine 6 kjerner har 1.9 milliarder transistorer) 25.6 GB/s minne båndbredde 8

9 1.1 Eksempel på et brikkesett (chipset) Intel Core 2 Extreme Processor 12.8 GB/s FSB PCI Express 2.0 Graphics x16 PCI Express 2.0 Graphics x16 12 USB porter 480 Mb/s 6 PCI Express x1 500MB/s Intel Gigabit LAN MCH Memory Controller Hub IOCH IO Controller Hub BIOS support DDR GB/s - minne DDR GB/s - minne 2 GB/s Intel High def Audio 6 Serial ATA, 3 Gb/s Figur 1.2 Et hovedkort med prosessor, memory controller hub (MCH), og IO controller hub (ICH)( før 2008). Memory Controller Hub (MCH) ble en flaskehals i det systemet som er vist i figur 1.2. Et brikkesett som er Intel Corebasert består i utgangpunktet av tre brikker. Den ene brikken utgjør prosessoren. De andre benyttes som en brikke som skal tilpasse kommunikasjonen mellom prosessor, minne og skjermkort. Den kalles Memory Controller Hub (MCH). Denne brobrikken er programmerbar og initialiseres i forbindelse med oppstarten av systemet. Den har som oppgave å tilpasse kontrollsignaler, bussbredder og overføringshastigheter mellom prosessor skjermkort og internminne. Bussen som går ut fra prosessoren kalles ofte for Front side bus (FSB) og har høye overføringsrater. Som det fremgår av figur 2.1 over er det for tiden (2006) mulig med 8.5 GByte/s. Siden databussen er på 64 bit = 8 byte, vil dette kunne uttrykkes i antall overføringer à 8 byte og vi får da busstakten lik MByte/8 lik ca 1600 MHz. I 9

10 datablad for prosessoren finner vi informasjon om at FSB kan ha overføringstakt tilsvarende 1600 MHz. Dette tilsvarer altså ca 1600 millioner 64 bits overføringer i løpet av ett sekund. Et lite tankeeksperiment for å illustrere dette: Om vi tenker oss at 1 bit dekker en avstand på 1 mm, vil vi få ca mm. Dette tilsvarer en avstand på ca 2 ganger rundt jordkloden. MCH har også som oppgave å tilpasse overføring til skjermkortet via en PCI Express buss. Overføringsraten her er 16x PCIExpress som tilsvarer 8 GB/s. (Forkortelsen PCI står for Peripheral Component Interconnect). PCIExpress bussen er en videreutvikling av den gamle PCI-bussen som var en parallell buss. Den gamle PCI-bussen slik den ble benyttet i en PC hadde 32-bits bredde og en overføringstakt på 33 MHz. Det innebar at vi kunne overføre 4Byte 33Millioner ganger pr sekund hvilket gir en overføringstakt på 133 MByte/s. PCIExpress er en seriell buss. Det kan fortone seg noe merkelig siden vi tradisjonelt har tenkt at parallelle busser gir raskere overføring. Vi har jo stadig sett utvidelse av bussbreddene fra 8 -, 16 -, 32 - til 64 bit i den hensikt å få overført flere byter om gangen og øke overføringsraten. Nå er det imidlertid slik at det er mye lettere å øke hastigheten om vi benytter serielle linjer i stedet for parallelle. Dette skyldes blant annet at ved høy overføringshastighet kan vi få såkalt skewing av signalet, noe som innebærer at over en parallell bus vil signalene over de ulike linjene komme fram til destinasjonen til ulike tidspunkt. Ved parallell overføring er en avhengig av at signalene kommer fram til samme tidspunkt. Det er en imidlertid ikke om en benytter serielle busser. En PCIExpress buss er en full duplex linje det vil si sending og mottak kan skje samtidig. En slik duplex forbindelse kalles en lane og basishastigheten for en slik forbindelse er 2.5 GHz/s i hver retning. En byte overføres sammen med to tilleggsbit. Disse to tilleggsbitene er nødvendige av synkroniseringshensyn. En regner med ca 25 % overhead ved denne kommunikasjonen slik at vi får maksimalt 250 MB/s i hver retning for en enkel forbindelse. Vi kan kjøre flere lanes parallelt for å øke overføringskapasiteten og for en x16 forbindelse kan vi få 4000 MB/s. 10

11 ICH - eller IO Controller Hub har som oppgave å tilpasse hastighet, foreta serie- til parallell omforming, tilpasse bussbredder og hastigheter etc. Av typiske oppgaver denne har nevner vi: - PCI Express grensesnitt - PCI- grensesnitt - USB grensesnitt - IDE/SATA grensesnitt ICH-brikken inneholder ellers blant annet interrupt kontrollere (8259 og IO APIC), DMA kontroller, timere etc. IDE (Integrated Device Electronics) er det gamle grensesnittet som ble brukt mot disker og er basert på parallell overføring. SATA (Serial Advanced Technology Attachment) er det nye grensesnittet og baseres på seriell overføring. Den første versjonen av SATA hadde en overføringsrate på 1.5 Gbit/s. Her opererte en med 20 % overhead slik at reell overføringshastighet ble 1.2 Gbit/s = 150 MByte/s. I 2004 kom en SATA versjon med 3 Gbit/s (SATA II eller SATA300 som den også kalles). Denne versjonen er kompatibel 1.5 standarden. I midten av av 2007 fikk vi en økning i overføringsrate for denne standarden til 6 Gbit/s. I tabell 1.1 finner du en oversikt over noen av IO bussene. 11

12 SATA Parallell ATA IEEE1394 USB2.0 PCIe v 2.0 b Hastighet MB/s 800 Mb/s 480Mb/s 500 MB/s pr lane MB/s =100MB/s =60MB/s Kabellengde 2 m 46 cm 4.5 m 5 m Ikke spesifisert Powerkabel Ja Ja Nei Nei Nei Antall enheter pr kanal Tabell 1.1 En sammenligning av ulike IO busser. Mens vi er inne på IO busser bør vi nevne SCSI bussen. SCSI står for Small Computer System Interface og var et parallelt grensesnitt som har vært mye brukt mot disker, spesielt på arbeidsstasjoner, men også på PC er. Den siste versjonen av denne parallelle SCSI (Ultra 320) hadde overføringskapasitet på 320 MByte/s. Like etter tusenårsskifte innså en at denne stødige bussen måtte endres til en seriell utgave for å imøtekomme kravene til ytelse. Dette resulterte i SAS eller Serial Attached SCSI. Denne standarden forelå i Dette er en seriell buss med 3Gbit/s tilsvarende 300MByte/s som overføringsrate og samtidig overføring i begge retninger (full duplex). Ved å sette sammen flere slike serielle overføringsveier kan ytelsen økes. SATA SAS Ytelse 3.0 Gb/s HalF-duplex 6.0 Gb/s (fullduplex) Tilkobling Driver 1 m internkabel En enhet, bare SATA Software transparent med parallell ATA 6 m ekstern kabel SATA og SAS Software transparent med parallell SCSI Tabellen 1.2 viser en sammenligning mellom SATA og Serial Attached SCSI. 12

13 1.2 Siste tids utvikling. Front side bus (FSB) kom inn i utviklingen av Pentium pro og ble også benyttet i Pentium 4. Dette medførte at om en ønsket en løsning med 4 prosessorer, ville hver av disse få sin egen FSB som var koblet til Memory Controller Hub. Dette gjorde at Memory controller hub ble kompleks siden den måtte ha over 1000 pinner bare for å realisere de 4 FSB ene. Memory controller hub ble således en flaskehals. CPU CPU DRAM MCH CPU CPU MCH ICH Figur 1.2 Dedicated Highspeed Interconnects, Båndbredden er 34 Gbyte/s. En 4-kjernes prosessorløsning med FSB slik den så ut i 2007 er vist i figur 1.2. Med mange kjerner på en chip blir kravet til båndbredde betydelig. Den nye bussløsningen som følger etter FSB kalles for Intel QuickPath Interconnect (QPI). Denne bussen er benyttet for Core i7, Xeon og Itanium prosessorer. Bussen er skalerbar og gir høy ytelse med lave kretstekniske kostnader og Intel hevder dette er en løsning for fremtiden. Løsningen er basert på høyhastighets point-to-point linker som krever halvparten av signalene som FSB-løsningen hadde og kan gi inntil 50% høyere ytelse i forhold til sistnevnte. I QPI konseptet kan en velge hvorvidt Memory Controller Hub (MCH) og IO Controller Hub skal integreres på prosessorbrikken. 13

14 Figur 1.3 Her er prosessorer og minnekontroller integrert på prosessorbrikken og FSB er erstattet av QPI (Quickpath Interconnect) busser. MCH står for Memory Controller hub. Blokkskjematisk kan en slik arkitektur se ut som figur 1.4 under. Figur 1.4 Fire kjerner med bussløsningen QuickPath Interconnect. Linkene er full duplex, det vil si det kan overføres data begge veier samtidig. I noen arkitekturer kan de diagonale linkene mellom prosessorene velges bort. Om CPU A ønsker data fra CPU D må forespørselen gå gjennom prosessor C eller B. 14

15 En link består av flere lanes som hver har en seriell overføring. Dette gjør at dette blir en form for parallell overføring. Dette er mye det samme konseptet som benyttes ved PCI Express med noen mindre justeringer. Intel oppgir en 20-bits QPI link med 3.2 GHz klokketakt til å ha en overføringskapasitet på 25.6 GB/s. Mer generelt med definisjonen av en 20-lanes QPI som vil overføre 8 bytes per klokketakt, 4 i hver retning. Dette beregnes som følger: 3.2GHz * 2 bits/hz (double data rate) * 20 (QPI link width) * 2 (bidirectional) * (64/80) (data bits/flit bits) / 8 (bits/byte) = 25.6 GB/s Figur 1.5 Brikkesett med en Core i7 prosessor og QPI busser. 15

16 Figur 1.5 viser en moderne arkitektur der prosessorbrikken har en innebygd memory controller hub (MCH). X58 er en chip som dermed ikke inneholder en MCH og Intel kaller den en IO hub. Denne brikken tilpasser busshastigheter mot prosessor via QPI [3], med ICH via en mer langsom DMI buss (Direct Media Interface med en overføringsrate på 2GB/s), samt et grafikk kort via PCI Express

17 2 Blokkskjema for en Intelprosessor I figur 2.1 under vist et forenklet blokkskjema for en Intelprosessor. L1 - kodecache Branch prediction m/buffer Intruksjonskø IP Dekodede instr L3, L2 cache ALU ALU FPU (80 bits SSE m /128 bits kode og data U-pipe V-pipe arkitektur arkitektur Interface mot MCH memory controller hub Adr bus Registerblokk (rax,rbx, etc (stack-reg) Eksekveringsblokk Data bus L1 - datacache Figur 2.1 Forenklet blokkskjema for en kjerne i en µprosessor. Eksempel på cache-størrelse pr i dag (juni 2009) er: L1 - Datacache 32 kb L1 Instruksjonscache 32 kb L2 kode og data cache 2-3 MB L3 - kode og data cache 32 MB Vi starter omtalen av prosessoren med noen hovedpunkter. Prosessoren har: - 64 bits databuss, 32, 36 eller 40 bits adressebuss - L1 datacache og instruksjonscache (32kB hver) - innebygd L2 cache (inntil 2-3MB pr prosessorkjerne) 17

18 - busshastighet inntil 1333 MHz - klokketakter 2-4 GHz - to ALU er - innbygd flyttallsprosessor (80 bits registre, registerstack) - to pipelines (U- og V - pipeline), hver med minst 20 trinn - prosessoren er superscalar - SSE4 Streaming SIMD Extension 4, 128 bits heltallsaritmetikk, - branch prediction 2.1 Pipeline Før vi går videre med mer detaljer som gjelder for en Intelprosessor, ønsker vi å forklare begrepet pipeline. For å illustrere begrepet pipeline antar vi en instruksjonssekvens som består av 10 instruksjoner I1 I10 og om vi holder oss til Intelprosessor - har vi to pipelines U og V. Se figur 2.2. Om vi følger instruksjonen I1 i figur 2.2 ser vi at denne hentes i PF fasen (PreFetch og klokkeperiode 1) til pipe U. Dernest blir den dekodet i D1-fasen og klokkeperiode 2, adresser til data beregnes i D2 (klokkeperiode 3), instruksjonen eksekveres i EX-fasen (klokkeperiode 4) og resultater skives til register eller cache WB-fasen (WriteBack, klokkeperiode 5). Eksekveringen av en instruksjon er altså delt inn ulike trinn og hvert av disse opererer selvstendig. Det betyr at når instruksjon I1 flyttes til dekodingsblokken D1, blir PF-trinnet ledig og kan benytte PFtrinnet til å hente neste instruksjon som vil være I3 i vårt eksempel, siden I2 ble hentet til V-pipen. Det som foregår innen ett trinn kaller vi µoperasjoner, slik at utførelsen av en instruksjon består av mange µoperasjoner. Eksempler på slike µoperasjoner er for eksempel å klokke data inn i et register, stille inn hvilke operasjon en ALU skal utføre etc. Når en pipeline i figur 2.2 er helt fylt opp med instruksjoner, vil vi fra klokkeperiode 6 og utover få fullført en instruksjon for hver klokkeperiode og hver pipe. Dette innebærer en betydelig ytelsesforbedring. Under normal programutførelse vil instruksjonene tenkes utført i den rekkefølge vi skrev instruksjonene i vårt program. Et problem vi får med denne løsningen er hva som skjer når en branch-instruksjon kommer. Vi skal drøfte dette litt senere i kapitlet i forbindlese med begrepet branch prediction. For øvrig er en pipeline i de nyere Intelprosessorer 18

19 inndelt i trinn. Dette egner seg greit som et utgangspunkt når vi skal forklare arbeidsgangen ved en instruksjonsutførelse i en Intel kjerne. Pipelining PF U V U V U V U V U V I 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 I 9 I 10 D1 I 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 D2 I 1 I 2 I 3 I 4 I 5 I 6 EX I 1 I 2 I 3 I 4 WB I 1 I 2 Klokkeper Figur 2.2 To pipelines U og V med 5 trinn i hver. 18 Alle Intelprosessorene av nyere dato inkluderer to on-chip L1 cachehukommelser, en for data og en for instruksjoner. Arkitekturen herfra og inn mot kjernen blir således en Harvard arkitektur. For Intel Core er L1 datacache på 32 kb. Denne datacachen har cachelinjer på 64 bytes og benytter prinsippet med eight-way set-associative organisering. Dette betyr at en cachehukommelse ikke er byteorganisert slik vi tenker internminnet i en PC, men at den er organisert i cachelinjer og i dette tilfellet inneholder en cachelinje 64 byter. Se mer om cachehukommelser i kapitel 4 i kompendiet. L2 cache forsyner L1 instruksjonscachen og L1 datacachen. L2 er en cache som holder både data og instruksjoner og har en kapasitet på 2-3 MB for hver prosessorkjerne. Den er av typen 8-way set-associative og benytter cachelinjer på 128 bytes. Hva dette betyr kommer vi tilbake til i kapitel 4. Prosessorkjernen består av fire hovedblokker. Disse er: Hente og dekodingsblokk: Henter programinstruksjoner fra L2 cache, dekoder disse til en rekke µoperasjoner og lagrer resultatene i L1 instruksjons cache. Out Of Order eksekveringslogikk: Den eksekverer µoperasjoner i en rekkefølge som er optimal sett ut fra ytelse, ledige ressurser og data avhengighet. Som et eksempel kan en tenke seg at en heltallsaddisjon - som en av ALU ene skal ta seg av - er klar for eksekvering, men ALU ene er opptatt. Vi kan da få utført en flyttallsoperasjon i FPU i stedet dersom kravet til dataavhengighet ikke hindrer dette. Dette betyr at µoperasjonene 19

20 kan bli utført i en annen rekkefølge enn den de ble hentet fra L2 cachen og dette gjør at prosessoren også har en superskalar arkitektur. Eksekveringsenheter: Disse enhetene eksekverer µoperasjoner, henter nødvendige data fra L1 data cache og lagrer disse midlertidig i register i registerfilen. Minne subsystem: Denne enheten inkluderer L2-cache og systembussen, som brukes for å aksessere internminnet når L1 og L2 cache gir cache miss. Systemet benyttes også i forbindelse med IO. En såkalt Trace cache er plassert mellom instruksjonsdekoder og eksekveringskjerne. Grunnen til dette er blant annet følgende: Maskinkodeinstruksjonene for en nyere Intelprosessor er et sett instruksjoner som har ulik lengde. Noen instruksjoner er en bytes instruksjoner andre er bygd opp over flere byter og er store og kompliserte. Prosessoren dekoder maskininstruksjoner til RISC-lignende instruksjoner av lik lengde (µoperasjoner). De dekodede RISC-lignende instruksjonene kalles µoperasjoner. Disse µoperasjonene gjør det enklere når en i senere trinn skal kunne schedule (timeplanlegge) instruksjonsutførelsen slik at instruksjonene ikke nødvendigvis utføres i den rekkefølge de ble hentet fra L2 cachen eller skrevet av programmereren. Dette innebærer at dekoding til µoperasjoner støtter muligheten for å gjøre prosessoren superscalar. Her ligger også grunnen til at Intel markedsfører sine nyere prosessorer som en CISCprosessor, men med en RISC kjerne. Datacachen arbeider etter prinsippet som kalles write-back. Det innebærer at data bare skrives til internminnet når de fjernes fra cachen fordi en trenger plass til nye data der. En Intel prosessor av nyere dato kan også dynamisk konfigureres til å støtte writethrough caching, hvilket betyr at data som skrives til cache også skrives til minnet samtidig. Denne siste teknikken sikrer at data i internminnet alltid er gyldige. L1 datacache kontrolleres av to bit i et kontrollregister. Bitene kalles CD (cache disable) og NW (not write-through). Det fines også to instruksjoner som kan benyttes for å kontrollere datacachen. Både L2 og L3 cache kan være f eks 8-way set associative med cachelinje størrelse på 128 bytes. For å få med andre viktige egenskaper ved nyere 20

21 Intelprosessorer tegner vi om figur 2.2 noe. Se figur 2.3. Syst L2 cache buss B T B F e t c h & D e c BTB L1 - TC Instruksjonscache (μoperasjoner) ROM R e n / A l l o c μ O p s k ø S c h e d u l e r 128 integer registre 128 flyttalls registre ALU er & FPU & SSE L1 D a t a c a c h e Figur 2.3 Blokkskjema for en Intelprosessor. TC står for Trace Cache og inneholder dekodede instruksjoner (μoperasjoner). RISC-operasjonene passerer gjennom en pipeline som er inndelt i trinn. Figur 2.4 under viser en slik pipeline TCnxtIP TCfetch Drive Alloc Ren Que Flg 9 Drive Sch Disp RF E B x r C k Figur 2.4 En pipeline som viser detaljnivå ved en instruksjonseksekvering. TC i figurene 2.3 og 2.4 over står for Trace Cache og er det samme som instruksjonscachen som holder ferdig dekodede instruksjoner. Hvis instruksjonscachen er i ferd med å gå tom for dekodede μoperasjoner, vil nye bli hentet inn via de to første 21

22 blokkene BTB (BranchTargetBuffer) og Fetch & Decode. De maskinkodede instruksjonene fra L2 cache - 64 byte om gangen - hentes inn sekvensielt. BTB kan endre denne rekkefølgen avhengig av om det finnes branch-instruksjoner og hva en predikerer (tipper) utfallet av disse vil bli. Når instruksjonene er hentet inn, vil dekodingsblokken skanne bytene for å bestemme instruksjonsgrensene. Det er nødvendig fordi instruksjonene har ulik lengde. Når maskinkodeinstruksjonen oversettes kan den gi fra en til fire μoperasjoner. Hver av disse μoperasjonene er på 118 bit og utgjør en RISC-instruksjon. Et BranchTargetBuffer (BTB) nær instruksjonscachen vedlikeholdes med informasjon om de siste branch-instruksjonene. Når en branch-instruksjon forekommer blant instruksjonene, vil info fra BTB bli konsultert. Hvis det allerede eksisterer en entry for instruksjonen i BTB, vil en benytte dette til å bestemme hvorvidt en skal utføre hoppet eller ikke. Om det ut fra dette blir besluttet at et hopp skal utføres, vil destinasjonsadressen for hoppet bli benyttet til å forhåndshente instruksjoner fra denne adressen. I tidlige Pentiumprosessorer benyttet en bare to bit for å beskrive historien i forbindelse med branch prediction, mens en i senere prosessorer har benyttet flere bit for prediksjonen. Har en mange trinn i en pipeline, blir straffen ved å spå galt i forbindelse med en branch-instruksjon desto større. BranchTargetBuffer i nyere Intelprosessor er organisert som en 4-way set-associative cache med 512 linjer. Hver entry bruker adressen til branch-instruksjonen som tag. En entry inkluderer også destinasjonsadressen samt et felt med historie-bit (4 bits). Ved hjelp av disse bitene kan prosessoren basere sin prediksjon på et mer robust grunnlag. En algoritme som benyttes kalles Yeh s algoritme. Betingede branch-instruksjoner som ikke har noen historie i BTB-systemet blir håndtert etter en fast prediksjonsalgoritme som f eks sier at hoppadresser som representerer IPrelative tilbakehopp skal utføres, mens hoppadresser som representerer hopp til en adresse lenger frem i koden ikke skal utføres. Denne regelen reflekterer typisk en programsløyfe. De ferdig dekodede μoperasjoner er ordnet i den rekkefølge de ble programmert, men det er tatt hensyn til resultatet av prediksjonen. Noen få instruksjoner krever mer enn fire 22

23 μoperasjoner. Det er f eks tilfellet for noen streng - operasjoner og i slike tilfelle må en kjøre noe kode fra en ROM for å generere inntil flere hundre µoperasjoner. Det femte trinnet i pipelinen, kalt Drive trinnet, har ansvar for leveranse av ferdig dekodede instruksjoner til rename-/allocator-blokken. Det som leveres er basert på branch prediksjonsystemets avgjørelser. I den delen som følger etter Drive -trinnet kan det foretas omstokking av instruksjonsrekkefølgen i den hensikt å få instruksjonene eksekvert så raskt som mulig. Allocate-trinnet allokerer ressurser til instruksjonen. Det kan utføre blant annet følgende funksjoner: Allokeringstrinnet kaprer en entry i et buffer (ReOrder Buffer=ROB) som holder orden på når en av inntil 126 samtidige μoperasjoner er fullført. Allokeringstrinnet allokerer også ett av 128 heltalls- eller flyttallsregistre for å kunne lagre resultatdata i. Allokeringstrinnet allokerer en entry i en av de to μoperasjons-køene som holder μoperasjonen før instruksjons-schedulingstrinnet. ROB er et sirkulært buffer som kan holde inntil 126 µoperasjoner og inneholder 128 hardware registre. Hver entry i dette bufferet består av følgende felter: State som sier om mikrooperasjonen er schedulet og klar for eksekvering, er avlevert og under eksekvering eller om den er ferdig eksekvert. Minneadresse for den instruksjonen som genererte μoperasjonen Den aktuelle mikrooperasjonen. Alias register en μoperasjon kan referere til et av 16 registre (EAX, EBX etc). Ved hjelp av renaming trinnet kan registeret omdirigeres til et av 128 hardwareregistre. μoperasjoner kommer inn til ROB i opprinnelig rekkefølge. Etter hvert slippes de inn til (dispatches) eksekvering i en rekkefølge som ikke nødvendigvis er den opprinnelige. Kriteriene for at en μoperasjon skal slippes inn til eksekvering er at den riktige ALU en/fpu n/sse blokken er ledig og at alle nødvendige data for denne μoperasjonen er tilgjengelige. Til slutt fjernes μoperasjonen fra ROB. 23

24 Trinnet Micro-Op Queuing. Etter ressursallokering og register renaming kan μoperasjonen legges i en av to køer der de holdes til det blir plass i schedulerne. Den ene av køene er for minneoperasjoner (loads/stores) og den andre er for µoperasjoner som ikke har minnereferanser. Hver kø benytter FIFO prinsippet, men det er ingen ordnet rekkefølge mellom køene. Dette innebærer at en μoperasjon kan leses ut av en kø uten tanke på rekkefølge i forhold til den andre køen. Dette gir større fleksibilitet i forhold til schedulingen. Schedulerne er ansvarlig for å hente μoperasjoner fra μoperasjonskøen og levere disse til eksekvering. Hver scheduler sjekker at mikrooperasjonene har alle nødvendige data klare og hvis eksekveringsenheten som skal brukes er ledig, henter scheduleren μoperasjonen og eksekveringen starter. Flere μoperasjon kan leveres for eksekvering i en klokkeperiode. Hvis mer enn en μoperasjon er klar for samme eksekveringsenhet, vil scheduleren slippe disse til i tur og orden. Dette er en type FIFO tankegang som favoriserer eksekvering i rekkefølge, men på dette tidspunktet er instruksjonsstrømmen allerede blitt rearrangert som følge av branch-instruksjoner og dataavhengighet slik at de er omstokket i forhold til opprinnelig rekkefølge. Det finnes fire porter mellom scheduler og eksekveringsenhet. Port 0 brukes til heltall og kommatall med unntak av enkle heltallsoperasjoner og håndtering av gal prediksjon ved branch-instruksjoner. Disse siste er allokert til port 1. I tillegg allokeres SSE modulen til disse to portene. De to andre portene brukes til lasting og lagring av data til og fra minne. Heltalls og kommatall register fil brukes til å holde operander i forbindelse med eksekveringen. Eksekveringsenheten henter data fra både registerfil og fra L1 cache. Et eget trinn i pipelinen brukes til å beregne flaggsettingen; dette er typiske input til en branch-instruksjon. De trinn i pipelinen som følger etter denne har med branch-kontroll å gjøre. Denne funksjonen sammenligner det aktuelle branch-resultatet med prediksjonen. Hvis en prediksjon viser seg å være gal, vil μoperasjoner på ulike trinn i pipelinen fjernes. Den riktige branch-destinasjonen leveres så til Branch Predictor etter Drive -trinn som så restarter hele pipelinemodulen fra en ny adresse. 24

25 Til slutt i dette kapitlet skal vi forklare begrepet SSEx der x er et versjonsnummer. Forkortelsen SSEx står for Streaming SIMD Extension x. Dette er en arkitektur og et instruksjonssett som benyttes i forbindelse med multimedia problemstillinger. SIMD - arkitektur står for Single Instruction Multiple Data og innebærer at samme operasjon kan utføres parallelt og samtidig på mange dataverdier. Om vi f eks ønsker å gjøre et bilde lysere, kan vi få til dette ved å addere et heltall til alle pikselverdier i bildet. Om vi tenker oss at gråtonen i et bilde er gitt i en byte, kan vi ved hjelp av SIMD-arkitekturen få addert denne verdien til mange pikselverdier parallelt. Det er samme operasjonen som skal utføres på alle pikselverdiene og med arkitekturen vist i figur 2.5 blir dette effektivt. Figur 2.5 Illustrasjon av SIMD-arkitektur. 2.2 Branch prediction For å gjøre pipelining mer effektiv, er det nødvendig å holde alle trinn i pipelinen fulle. Det blir imidlertid et problem når en instruksjon som skal eksekveres er en instruksjon som representerer et brudd på den sekvensielle utførelsen av programmet slik vi har det ved en call, en betinget eller ubetinget branch på assemblynivå eller en if - setning eller en loop (while) setning. Anta følgende kode og en pipeline på 4 trinn (fetch, decode, execute og save(write): if (x > 0) { a=4;b=5;c=6; } d=7; 25

26 Cyc Fetch Decode Execute Save 1 if (x>0) 2 a=4 if (x>0) 3 b=5 a=4 if (x>0) 4 c=6 b=5 a=4 if (x>0) 5 c=6 b=5 a=4 6 c=6 b=5 7 c=6 Figur 2.6 Her illustreres hvordan pipelinetrinn ser ut når x>0. Hvis x er større enn 0, vil instruksjonene i pipeline slik figur 2.6 viser, siden if - delen av if - else setningen vil bli utført. Hvis x er mindre eller lik 0 skal if - delen ikke eksekveres. Neste instruksjon i pipelinen skal være d=7, og instruksjonene som berører a, b, og c skulle ikke vært i pipelinen. I dette tilfellet blir det nødvendig å kansellere den effekten disse instruksjonene har hatt på prosessoren og fjerne instruksjonene fra pipelinen. Om vi tenker oss at dette kunne gjøres, vil instruksjonen d=7 bli hentet fra starten av klokketakt 4, når resultatet av sammenligningen x>0 er kjent. I dette tilfellet vil pipeline n opptre mindre effektivt, siden noen av trinnene ikke eksekverer gyldige instruksjoner. Det vil ta 7 klokkesykler og eksekvere disse to instruksjonene. Om det var mulig å se inn i fremtiden og kjenne resultatet av sammenligningen i if setningen, ville det hjelpe oss til å holde de riktige verdiene i pipelinen til enhver tid. Hvis vi visste på forhånd at resultatet av sammenligningen ble false kunne prosessoren laste inn instruksjonen d=7 i stedet for instruksjonen a=4. Om dette var tilfellet ville de to instruksjonene kun kreve 5 klokkesykler. Det er dette som er ideen bak branch prediction konseptet. Vi skal prøve å gjette på hvordan utfallet av denne testen vil bli. Hvis vi gjetter korrekt vil pipelinen bli full, hvis ikke har vi lastet instruksjoner i pipelinen som må fjernes.. Det viser seg at en i dagens prosessorer gjetter riktig i % av tilfellene ved branch prediction. 26

27 Cyc Fetch 1 if(x>0) Decod e 2 a=4 if Execut 3 b=5 (x>0) a=4 if (x>0) 4 d=7 Figur 2.7 Om x<=0 og vi ikke har branch prediction, vil pipeline se ut som vist over. Feil b=5 5 d=7 e Feil a=4 Feil b=5 6 d=7 Save if (x>0) Feil a=4 Feil b=5 7 d=7 Cyc Fetch Decode Execute Save 1 if (x>0) 2 d=7 if (x>0) 3 d=7 if (x>0) 4 d=7 if (x>0) 5 d=7 Figur 2.8 Om x<=0 og vi har gjettet riktig i branch prediction blokken, vil pipeline se ut som vist i figur 2.8. Et eksempel på bruk av en 2-bits sekvenskrets for å håndtere branch prediction er vist i figur 2.9. Her er linjen Tilstand i tabellen nåtilstand, verdiene i linjen prediksjon i tabellen kan anta verdiene Not Taken (N) eller Taken (T) og utfall er det riktige svaret etter at instruksjonen er eksekvert. 27

28 Anta at vi i forbindelse med en branch-instruksjon finner tilstandsbit lik 00. I denne tilstanden vil vi predikere Not Taken. Om utfallet blir Not Taken, vil vi ikke få en endring i tilstandsbitene for denne instruksjonen. Om utfallet blir Taken endres tilstandsbitene til 01. I tilstanden 01, vil vi også i utgangspunktet predikere Not Taken når vi kommer til denne branch-instruksjonen neste gang. Det vil altså si at med utgangspunkt i tilstand 00 vil vi måtte ha to prediksjoner med Not Taken før vi kommer til å predikere Taken. I dagens prosessorer er det brukt flere bit for å gjøre prediksjonen bedre. Tilstand Prediksjon N N N N T T N N Utfall N N T T N N T Figur 2.9 Her benyttes en 2 bits teller for å holde orden på historikken, det vil si hva som har skjedd ved forgrenings - instruksjon på et tidligere tidspunkt av eksekveringen. 28

29 3 Cachehukommelse. Undersøkelser har vist at det ved en normal programkjøring vil være svært mye gjenbruk av instruksjoner og data. Eksempler på dette er en programsløyfe der vi kjører om igjen de samme instruksjonene et antall ganger og der utgangen fra sløyfa er bestemt av en betingelse i denne. Dette danner grunnlaget for å legge inn en mindre, men svært rask hukommelse så nær prosessor - kjernen som mulig. De nyere Intelprosessorer har både L1-, L2- og L3-cache innebygd på prosessorbrikken. Siden hardware i en slik hukommelse er komplisert og rask betyr det at den er kostbar. Derfor har en cachehukommelse begrenset kapasitet. Når prosessoren skal aksessere minnet sjekker den først cachen. Hvis data eller instruksjon finnes her, leses disse med en hastighet som er 10 ganger høyere enn om vi måtte lese fra internminnet (intern RAM). Når data finnes i cachen sier vi at vi har en cache hit, i motsatt fall snakker vi om en cache miss. For å illustrere egenskapene ved en cache tar vi et regneeksempel: RAM aksess tid 50 ns Cache aksesstid 8 ns Cache hit forholdet 0.85 (det vil si at 85 % av minneaksessene finnes i cachehukommelsen) Gjennomsnittlig aksesstid vil da beregnes slik: 0.85*8ns + (1-0.85)(8 + 50)ns = 15.5 ns Når data finnes i cachen (cache hit) bruker vi bare 8 ns på å hente dataene (eller instruksjonene). Det er tilfellet i 85 % av alle minnereferanser. Når data ikke finnes i cachen (cache miss), vil vi først bruke tid på å sjekke om de er der. Dette tar 8 ns. Dernest vil vi bruke tid på å hente data fra internminnet noe som tar 50 ns. Om mesteparten av vårt program befinner seg i cachen ser vi at vi har mye å vinne på en cacheløsning. Intelprosessorene av nyere dato har to L1 cachehukommelser en for data og en for instruksjoner. Hver av disse har en kapasitet på inntil 32 kb. Det finnes for tiden også prosessorer som har fra 2 til 6 prosessorkjerner, og to kjerner kan ha en felles L2 cache 29

30 på inntil 2-3 MB. Aksesstiden til en L2 cache er noe høyere enn til en L1-cache. Fra L2 cachen overføres data og instruksjoner til begge L1 cachehukommelsene, både datacachen og instruksjonscachen. L2 cachen kan være organisert som en såkalt 8-way set associative cachehukommelse. Hva dette betyr skal vi beskrive i de neste kapitlene. 3.1 Organisering av cache - hukommelser. Cachehukommelsen skal inneholde data og instruksjoner som er kopi av innholdet i internminnet. Internminnet er vi vant til å tenke på som et byteorganisert minne. Det betyr at den minste adresserbare enheten vi kan hente ut av dette er en byte. En cachehukommelse er ikke byteorganisert, men bygd opp av såkalte cachelines som hver består av mange byter. Hvorfor er en cachehukommelse så rask? Hvordan kan vi på kort tid avgjøre om vi har en cache hit? Svaret på disse spørsmålene ligger i måten cachehukommelsene er organisert på. Vi skal se på tre måter å organisere cachehukommelser på, nemlig: - Set associative cache - brukes mest - Direct mapped cache - litt lite fleksibelt - Fully associative cache - krever komplisert hardware Figur 3.1 viser en prinsippskisse av hvordan en two ways set associative cache kan være organisert. Denne organiseringen er et kompromiss mellom de to andre prinsippene, som som nevnt over - har sine åpenbare svakheter. I figur 3.1 antar vi cachelines på 16 byter. Det vil si at når vi leser data fra internminnet til cache leses det alltid 16 byter for å fylle opp en cacheline. Når data hentes eller skrives til cache fra CPU-siden antar vi i vår modell en 32-bits databuss og at vi derfor overfører 4 byter parallelt. Videre er det - for å få det enkelt - antatt 16-bits adresser mot minnet. Når vår cache sies å ha two ways går det på at vi har dobbelt opp med tag-felter og datablokker. Hadde vi hatt bare ett tag-felt og en datablokk hadde vi hatt en direct mapped cache organisering. 30

31 16 bits adresser Intern minnet 0x0000 0x0004 0x000C 16 byte 0x2200 etc Cache Set nr Tag1 Tag2 Data1 Data tag 10 bit setnbr 2 bit offs 4 bit 4 byte CPU Figur 3.1 En two ways set-associative cache. Det finnes en animasjon på nettet av denne cache-modellen som du bør kjøre hvis du vil studere virkemåten. Lenken dit er: Hvis vi har kun ett set i figur 3.1, får vi en full associative cache. Dette stiller harde krav til hardware siden en innkommende tag skal sammenlignes med alle tagene i cachen samtidig. Det som ligger i associative minne er at innkommende adresse skal sammenlignes samtidig med alle tagfelter i cachen. Hvis vi deler inn cachen i set, vil vi få en samtidig sammenligning mellom innkommende adresse og tagfeltene i dette settet. 31

32 For vår cache gjelder altså følgende: L = antall bytes pr cacheline = 16 K = i hvilken grad cachen er associative = 2 (two-ways) N = antall set = 4 K=1 gir direct mapped cache. N=1 gir full assosiative cache som er krevende på hardwaresiden. Kompromisset blir et set associative cache minne. Adressene i vår modell er på 16 bit. Ved en set associative cache splittes adressen i 3 felter, tag-felt på 10 bit, set nr på 2 bit og offset på 4 bit (innen en cacheline). 10 bit tag 2 set nr 4 bit offs Som et eksempel kan vi se på en 16-bits adresse lik 0x2204 eller binært Denne gir en tag = 088, et set nr = 0 og en offset = 4. Offset er hvilken 32-bits (4bytes) blokk som skal hentes ut av en cacheline på 16 bytes og inn til CPU. For å forstå hvordan dette med offset i en datablokk virker, har vi en skisse i figur 4.2 for å illustrere dette. 32

33 1 cacheline 1 byte Set 0 Offs 0 Offs 4 Offs 8 Offs C Set 1 Offs 0 Offs 4 Offs 8 Offs C Set 2 Offs 0 Offs 4 Offs 8 Offs C Offs 0 Offs 4 Offs 8 Offs C Set 3 Figur 3.2 Skisse av en datablokk i en cache. 1 byte i hver liten subkube. Figur 3.3 viser forholdene slik de er i L1 cache i en tidlig Pentiumprosessoren. Det er som nevnt over en two-way set associative cache med 128 sets. Dette gir 256 entries og det er 32 bytes i en cachelinje, eller 64 byte pr set. Dette gir en kapasitet på 32 bytes*256 = 8 KBytes. 33

34 Way 0 Way 1 Set0 tag data tag data Set1 tag data tag data Set2 tag data tag data.... Set127. tag data tag data 32 bytes 32 bytes Figur 3.3 Two-way set associative cache slik L1 cache i Pentium er realisert. Størrelsen på cachen er 8 kbyte. Taggene i denne cachen er såkalt treports, det betyr at de kan aksesseres fra tre ulike blokker samtidig. To av disse blokkene er U og V pipeline som aksesserer datacachen for å finne eller legge inn operander. Den tredje porten brukes i forbindelse med snooping. Buss snooping brukes for å vedlikeholde data i et flerprosessor-/flerkjerne- system hvor hver prosessor har sin egen cache. Prosessoren overvåker systembussen og om den registrerer en lesing/skriving som utføres av en annen prosessor, kjøres en såkalt inquire cycle for å finne ut om adressen på bussen er lagret i intern cache. Hvis så er tilfellet, vil cachen bli oppdatert. Dette er også årsaken til at adressebussen er en toveis buss. En IO-enhet kan skrive direkte til minnet (DMA). Hvis et ord i internminnet er endret på denne måten, vil det også kunne gjøre cachelinjer ugyldig. 3.2 Skriveprinsipper ved cachehukommelser og et eksempel på en protokoll. Når cachen blir full og vi skal ha inn nye data eller instruksjoner, må en gammel cachelinje ofres for å gi plass til den nye. En algoritme som brukes i denne sammenheng 34

35 går ut på å velge en cachelinje som har vært lite brukt i det siste (Least Recently Used LRU algoritmen). Når en linje i cachen skal erstattes, er det et par forhold vi må ta hensyn til. Hvis den gamle linjen i cachen ikke er endret, kan den overskrives uten at vi først skriver den til internminnet. Hvis vi har skrevet til den cachelinjen som skal ofres, må vi først skrive innholdet i denne til internminnet før vi fornyer cachelinjen. Det enkleste skriveprinsippet ved cachebruk er såkalt write through. Bruker vi den teknikken vil alle skriveoperasjoner endre innholdet både i cachen og i internminnet. Andre prosessorer kan overvåke bussen og registrere når skriving skjer og således fornye sine cachelinjer slik vi nevnte over. Et alternativt skriveprinsipp er å benytte såkalt write back for å redusere antall skrivinger til minnet. Her vil oppdateringer i utgangspunktet bare skje til cachen. Når en oppdatering skjer, vil en Update bit for denne cachelinjen bli satt. Når en blokk skal erstattes, skrives denne til minnet hvis Update bit for cachelinjen er satt. Problemet med write back er at deler av internminnet er ugyldig og aksesser til minnet fra IO - enheter kan bare tillates gjennom cache. Dette krever en kompleks kretsløsning. Målinger viser at ca 15 % av alle minnereferanser er skriveoperasjoner, men det finnes applikasjoner der denne prosenten kan nærme seg 50 %. Etter hvert som datateknologien har utviklet seg er det blitt vanlig å operere med mer enn en cachehukommelse. For moderne ser vi at vi har L1-, L2 og L3-cache integrert på prosessorbrikken. Dette øker ytelsen på grunn av korte overføringsveier og frigjør systembussen til annen aktivitet. 35

36 3.3 MESI-protokollen En protokoll som benyttes i noen multicore prosessorer er en write-invalidate protokoll og kalles MESI-protokollen. Her markeres tilstanden til en cachelinje som Modified, Exclusive, Shared eller Invalid. Modified innebærer at tilstanden til en cachelinje er modifisert (ikke lik det som er i internminnet) og er tilgjengelig bare for denne cachen. Exclusive tilstanden innebærer at denne cachelinjen er den samme som den i internminnet og er ikke til stede i noen andre cachehukommelser. Shared: Linjen i cachen er den samme som i internminnet og kan være tilstede i andre cachehukommelser. Invalid: Denne cachelinjen holder ikke gyldige data. På nettstedet kan du se en animasjon av MESI i en flerprosessorløsning. 36

37 4 Forenklet programmeringsmodell for en Intel prosessor I dette kapitlet skal vi fokusere på hvordan vi som programmerere på assemblynivå må forholde oss med tanke på programmering av denne prosessoren. 4.1 Registerblokker I prosessorene er det en blokk som omtales som registerblokken. Denne blokken består av flere 64- eller 32-bits registre. Når vi skal programmere i assemblykode får vi kontakt med noen av disse registerne direkte. Registerne vi skal fokusere på, er skissert i figur 4.1 og 4.2. AX EAX AH AL EBX BH BL ECX CH CL EDX DH DL 32 - bit 16 - bit 8-bit Figur 4.1 Registerblokk i en Intel Core (General purpose registers) Registerne kan brukes som 8-, 16-, eller 32-bits registre. Sammenhengen er da slik at to 8-bits registre som for eksempel AL (A-register Low byte) og AH (A-register High byte) til sammen utgjør et 16-bits register som benevnes AX. AX = AH + AL, BX = BH + BL, CX = CH + CL, DX = DH + DL Betegnelsen EAX, EBX osv angir 32-bits registre. Ønsker vi å jobbe med 64-bits registre brukes betegnelser som RAX, RBX, RCX etc. 37

38 Disse registerne kan brukes fritt av en programmerer som generelle registre. Det betyr at du ved hjelp av programinstruksjoner på assemblynivå kan legge inn 8-, 16- eller 32-bits data (tall og tegn) i disse. I tillegg til at disse registerne kan brukes som generelle registre, har Intel også tillagt registerne noen dedikerte (mer spesielle eller unike) oppgaver. Anta for eksempel at du skal sende data ut eller inn gjennom IO - porter. Skulle vi skrive dette i C, ville vi bruke følgende funksjoner: outportb(portnr, data); temp = inportb(portnr); // for å sende data ut gjennom en port // for å hente data inn gjennom en port og legge data // i lagerplassen temp Hvis du skulle gjøre dette i assembly kode, ville det bli litt mer detaljert koding. Intel har nemlig bestemt at data du ønsker ut gjennom en IO-port, på forhånd må legges i registeret AL (ved 8-bits porter) og at registeret DX (16 bits) skal holde på portadressen. Dette betyr at om du skulle sende ASCII-koden for stor A ( 0x41 = ) gjennom en IO-port med portadresse = 0x378, kan dette skrives slik i assemblykode: mov al, 0x41 mov dx, 0x378 out dx, al // flytt ASCII-koden for A til AL-registeret // flytt IO - adressen til DX-registeret // send data fra AL gjennom den porten som dx - registeret // peker ut Tilsvarende blir det da muligheter for å sende data inn til prosessoren og internminnet ved å skrive følgende instruksjoner: mov dx, 0x378 in al, dx // flytt IO-adressen til DX-registeret // send data fra AL gjennom den porten som DX-registeret // peker ut mov temp, al // flytt data fra registeret AL til internminnets lagerplass // kalt temp 38

39 Dette betyr altså at AL-registeret og DX-registeret har spesielle oppgaver knyttet til IO - kommunikasjon. Slik er det med noen andre registre også. BX - registeret kan brukes til å holde en adresse i minnet som vi ønsker å aksessere. BX - registeret kan f eks brukes til å aksessere startadressen for et array av byter. CX-registeret ofte brukes til å telle antall runder i en programsløyfe. I tillegg til de registerne vi har nevnt så langt, finnes register som brukes når prosessoren skal adressere minnet. Disse er vist i figur 5.2. Registerne ESI (Extended Source Index) og EDI (Extended Destination Index) brukes for eksempel når vi skal programmere strenger og når vi skal arbeide med arrays eller tabeller av data. Registeret EIP (Extended Instruction Pointer) brukes til å holde orden (adressen til) på hvor prosessoren skal finne neste instruksjon i et kjørende program i minnet. EFlag er et 32-bits register som angir statusregister i prosessoren. Dette registeret kan vi tenke oss er satt sammen av frittstående bit der hver bit rapporterer viktige begivenheter i prosessoren. Eksempler på slike viktige begivenheter i prosessoren er når resultatet av en operasjon blir 0, når et register får en verdi som er større enn det registeret kan ta vare på (overflow), etc. Det finnes også bit i dette registeret som settes ved programinstruksjoner. Et eksempel på dette er om vi ønsker at prosessoren skal kunne akseptere interrupt på sin INTR-inngang. Om vi nullstiller bit 9 i dette registeret (IFbitet), vil alle interrupt som kommer på INTR - inngangen bare prelle av og neglisjeres. Om vi setter denne biten til 1 åpner vi for interrupt på INTR-inngangen. Programteknisk enabler vi interrupt (verdien på denne biten) ved å skrive: asm{ } sti i vårt c-program kan vi disable denne biten ved å skrive: asm{ cli 39

40 } ESI EDI EBP ESP SI DI BP SP EFLAGS EIP IP 32-bit 16 - bit Figur 4.2 Registre som brukes til å adressere minnet i en nyere Intel prosessor. ESP (Extended Stack Pointer) brukes til å holde orden på et spesielt dataområde i minnet som kalles stack. En stack kan vi tenke oss som en tønne med åpning på toppen og lukket bunn. Data legges alltid inn på toppen av tønna (pushes) og skyver data som befinner seg der fra før lengre ned i tønna. Data tas ut igjen fra stack ved å hente data ut fra toppen av den. Ved uthenting vil tall som ligger lengre ned i tønna rykke oppover i tønna og vi får nye data på toppen. Se figuren 4.3. Dette innebærer at data som ble lagt inn på stacken sist, kommer først ut igjen. Vi sier at arbeidsmåten følger prinsippet med LastIn/FirstOut (LIFO - prinsippet). 40

41 Push Tallene 3 og 4 inn på stack Pop Tallet 4 fra stack Figur 4.3 Lagring og henting av data fra stackområdet i minnet. Henting og lagring av data på stack går raskere enn om vi henvender oss til et vanlig dataområde i minnet. Det skyldes at ESP-registeret holder orden på adressen i stacken automatisk ved å telle seg opp og ned for hver pop og push instruksjon og vi slipper å oppgi adressen i instruksjonen. Ved siden av å oppbevare vanlige data midlertidig, lagres også returadresser ved kall til funksjoner her på stack. Registerrepertoaret for en nyere Intel prosessor inneholder også såkalte segmentregistre. Disse benyttes når prosessoren skal adressere minnet, og det bringer oss over til tema i neste kapitel om adresseringsmodi i en nyere Intel prosessor. 41

42 42

43 5 En prosessors operasjonsmodi 5.1 Real mode Det som karakteriserer real mode er følgende: Den gamle DOS-modusen, basert på prosessoren 8086 Segmentert minne, 64 KByte som segmentstørrelse Eksempler på minnesegment er segment som inneholder instruksjoner, segment som inneholder data og et spesielt segment som kalles stacksegment. Dette siste kan brukes til lagring av lokale variable (f eks lokale variable i en funksjon i et C-program) og lagring av returadresser ved et funksjonskall. Adresseringsområdet 1 MByte, det vil si vi trenger 20 adressebit i adressebussen. Vi kan illustrere en adresseberegning på følgende måte: Offset gitt av f eks IP-registeret Kode segment Segmentregister CS Figur 5.1 En segmentert minnemodell i real mode. Her er ingen beskyttelse av segmentene. Anta at vi under en programutførelse skal finne en instruksjon på adresse 0x50200 og at segmentet starter på adresse 0x Kodesegmentregisteret vil inneholde følgende binærtall (16 bits startadresse): Instruksjonspeker vil inneholde følgende binærtall(16 bits offset):

44 Adresseberegningen blir da utført etter algorimen som først skifter de 16 bitene i CSregisteret 4 bit mot venstre og trekker inn 0 er i enden. Vi får da en 20-bits startadresse som vist under. Til denne adressen adderer vi innholdet i instruksjonspekeren IP: Startadresse (fra CS): Offset (fra IP): Resulterende fysisk adresse blir: Resultatet av addisjonen blir en 20-bits adresse nok til et adresseområde på 1 MByte. Anta nå at vi skulle gjøre en adressering til en byte som befinner seg i et datasegment. Prinsippet blir tilsvarende det vi gjorde for et kodesegment. Forskjellen er bare at vi benytter datasegmentregisteret for å holde på startadressen og et annet register f eks BX for å gi offset i forhold til startadressen. 5.2 Protected mode Det som karakteriserer protected mode er følgende: Segmentert eller sideinndelt minne, 4 GByte som maks segmentstørrelse og f eks 4 KByte som sidestørrelse Adresseringsområdet 64 TByte virtuelt minne Maksimum fysisk intern minnekapasitet er 4GByte 44

45 Pentium prosessor EIP Segment selector Intern- Adressebuss (32 bit) Internminnet Offset fra et register f eks EIP minnet Kode segment Deskriptor for kodesegmentet Startadresse - 32 bit Deskriptortabell Figur 5.2 Segmentert minnemodell, ell med deskriptorer brukt når prosessoren kjøres i protected mode. En deskriptor er en informasjonsblokk på 64 byter som holder viktig informasjon om et segment. Det betyr at vi har en deskriptor for hvert segment. Inne i en deskriptor finner vi blant annet en startadresse på 32 bit for segmentet. Når en fysisk adresse i f eks et kodesegment skal beregnes gjøres det ved å addere denne startadressen til innholdet i EIP registeret. Det er ingen bit skifting før addisjonen slik vi hadde ved adresseberegning i realmode. En adresse til en instruksjon i et kodesegment antas å være binært (0x14531a87). Om vi antar at vi har 13 bit fra selector til å velge entry deskriptor i deskriptortabellen kan vi finne det aktuelle tabellelementet og dernest hente ut startadressen. Selector i figuren over er på 16 bit. 13 av disse bitene brukes som en indeks innover deskriptortabellen. Vi kan således ha 2 13 = 8k ulike deskriptorer. Nå er det imidlertid slik at en annen bit i selectoren bestemmer om segmentet er et globalt eller et lokalt segment. Et globalt segment vil være et segment som kan nyttes av alle programmer, mens et lokalt segment normalt kun benyttes av en bruker. Det blir således mulig å ha inntil 16 k med segmenter totalt 8k segmenter for en bruker og 8 k med segmenter som alle kan ha aksess til. 45

46 Vi skal se litt nærmere på innholdet i en deskriptor. Segment limit (0 15) Base address (0 15) P-bit,DescPrivLev (2 bit) Base addr (16 23) Base address (24 31) G Segm limit (16-19) G bit = 0 max 1 MB G bit = 1 max 4kB*SegmLimit0 19 Figur 5.3 En deskriptorblokk i Intel prosessor. Innholdet i en deskriptorblokk er blant annet baseadresse på 32 bit som forteller hvor et segment starter. I tillegg ligger det opplysninger om hvor stort segmentet er (segment limit). Det er satt av 20 bit for denne størrelsen. Det høres ut til å være lite siden vi da bare kan angi segmentstørrelser på 1 MB. For å kunne operere med større segmentstørrelser har vi en såkalt granularity bit (G) som fungerer som følger. Hvis denne biten er 0, vil vi oppfatte de 20 segment limit bitene som angivelse av segmentstørrelse direkte det vil si opp til 1 MB segmentstørrelse. Hvis G - bitet er 1, skal vi multiplisere tallet i segment limitbitene med 4096 (4 K) og får dermed segmentstørrelser opptil 4 Gbyte (1M*4K = 4 G). 4 GB segmentstørrelse er det største vi kan ha i et 32-bits system. Et av feltene i en segmentdeskriptor kalles deskriptor priviledge level (DPL). En Intel prosessor kan opererer med 4 priviledge levels i sitt beskyttelsessystem. Hensikten er å kunne beskytte en bruker mot en annen og operativsystemet mot inntrengen fra brukere. Priviledge level 0 er nivået med høyest prioritet og her kjøres rutiner som hører operativsystem kjernen til. På laveste priviledge level nivå 3 kjøres våre brukerprogrammer. På nivå mellom de to vi har nevnt kan en se for seg rutiner f eks drivere eller BIOS rutiner som en bruker ønsker å benytte. Segmentene som inneholder instruksjonskode (kodesegmentene) er altså plassert på ulike nivå. En illustrasjon av dette er vist i figur 5.4. LINUX benytter bare nivå 0 og 3. Operativsystemkjernen kjører på nivå 0, og våre brukerprogram på nivå 3. 46

47 Lavest rettighet Drivere/biblioteks-rutiner 0 og 1 Operativsyst- kjerne 2 Drivere Figur 5.4 Illustrasjon av priviledge levels i Intel prosessor. Intel opererer med flere deskriptortabeller. To av disse er global deskriptortabell og lokal deskriptortabell. Den lokale deskriptortabellen inneholder deskriptorer for segmenter som vårt brukerprogram har skapt. Den global deskriptortabellen inneholder deskriptorer for segmenter som hører BIOS eller operativsystemet til, men som vi kan kalle fra vår brukerapplikasjon. Når vi kaller en av disse systemrutinene må vi krysse grensene mellom to eller flere priviledge levels. Dette kan for eksempel foregå gjennom såkalte call-gates. En call-gate er i seg selv en deskriptor og inni denne deskriptoren ligger blant annet opplysninger om hvilke priviledge level en kallende rutine må ha for å få aksess til en funksjon i et segment i en mer privilegert ring (lavere numerisk verdi). Operativsystemene inneholder rutiner som vi som brukere kan ha glede av fra tid til annen, for eksempel rutiner for utskrift til skjerm, henting av fil fra disk etc. Call-gates for slike prosedyrer kan settes opp slik at de tillater aksess fra alle priviledge levels. Mer priviligerte call-gates kan settes opp slik at de bare tillater aksess fra operativsystemet (f eks rutiner som initialiserer driver for ytre enheter). 47

48 5.2.1 Virtuell-8086 mode En tredje modus prosessoren kan operere i, kalles virtual-8086 mode. Den benyttes når vi ønsker å kjøre DOS-baserte programmer under Windows. Prosessoren kjører disse programmene i beskyttet modus (protected mode) og hver applikasjon kjører innenfor hvert sitt 1 MB adresseområde. Segmentregisterne brukes slik de benyttes i real mode. Denne modusen ble implementert i 386 prosessoren. Applikasjonene kjøres på laveste priviledge level, level 3. Pentium Fysisk minne Virtuell maskin #1 1 MB Virtuell maskin #2 1 MB Virtuell maskin #3 1 MB Figur 5.8 DOS-applikasjoner kjøres i virtuell 86-mode. Hver applikasjon kan får tildelt 1 MB minne. Disse minneblokkene kan ligge hvor som helst minneområdet. 5.3 System Management Mode - Håndterer minne eller Chipset feil. - Administrerer systemets sikkerhetsfunksjoner, f. eks shutdown ved høy CPU temperatur. - Kontrollerer strømforsyningsoperasjoner, f. eks styring av spenningsregulator modulene. 5.4 Eksempel på et pagingsystem med en 32-bits Intel prosessor En annen måte å organisere et minne på er å tenke det sideinndelt. Dette er aktuelt når vi benytter virtuelt minne å gjøre. En page kan f eks ha en størrelse på 4kB og har en fast størrelse i motsetning til segmenter som har ulik størrelse (maks 4GB). I et virtuelt minnesystem kan en som programmerer forestille seg å ha til disposisjon et system som 48

49 har en minnekapasitet tilsvarende kapasiteten avsatt på et eksternt masselager f eks en disk. Figur 5.5 illustrerer oppbygningen av dette systemet. Virtuell adresse: 32 bits lineær adr = Pagenr (20bit) + 12 bits offs CPU med MMU PageTable 4 kb 4 kb.... Intern minnet Frame Adr 4 kb 4 kb Figur 5.5 Her illustreres hvordan et rent pagingsystem system opererer. Selector Offset Virtuell adresse Segment desciptor + Lineær adr page directory page offset Frame Directory entry Page table entry Page direct Page table Fysisk minne 49

50 Figur 5.6. I en Intel prosessor kan en kombinere segmentert og sideinndelt minne slik figuren viser. Om en applikasjon ikke trenger segmentering, men benytter kun et enkelt sideinndelt 32 bits adresseområde, gjøres dette ved å sette opp alle segmentregistrene med samme selektor som har segmentstart ved adresse 0 og maksimumsstørrelse lik 4 GB. Instruksjonsoffset vil således bli en lineær adresse med et enkelt adresserom, det vil si i realiteten normal paging. Dagens operativsystem for en nyere Intel prosessor virker på denne måten og vi kaller denne modellen en flat minnemodell. 5.5 Flat minnemodell Med flat minnemodell, vil minnet sett fra programmererens side fortone seg som et enkelt, sammenhengende adresseområde, gjerne kalt lineært adresseområde. Instruksjonskoder og data tas vare på i dette området. Den minste enheten vi kan adressere er en byte og adresseringsområdet er fra adresse 0 til Lineær adresse Lineært adresse 0 Figur 5.7 Flat minnemodell. område 50

51 Når en Intelprosessor av nyere dato startes opp, vil den kunne legges i en av flere mulige operasjonsmodi. Disse modiene er real mode, protected mode og virtuell 86 mode. Umiddelbart etter en reset legges prosessoren i real mode. 5.6 Beskyttelse av IO - porter For å beskytte IO - porter benyttes 2 prinsipper: - Rettighetsnivået til din applikasjon sammenlignes mot 2 bit i eflag - registeret (bit 12-13) og du vil ikke få aksess til IO-porten om CPL>IOPL. - Alternativ 2 er å benytte en bitmap løsning (IO - permission map). I denne bitmappen vil hver IO - port være representert med en bit og en 0 i en bitposisjon kan bety at du har aksess mens en 1 er kan bety at du ikke har. Se figur Bitnummer 0 Start End Figur 5.9. En io-map der en bit representerer en ioport og forteller om vi har aksessrettigheter eller ikke. En 0 kan for eksempel bety at en har aksessrettigheter. 51

52 52

53 6 Instruksjonsrepertoar Asssemblyinstruksjonene for en nyere Intelprosessor kan deles inn i følgende grupper: - Dataoverføringsinstruksjoner (mov, push, pop, ) - Aritmetiske instruksjoner (add, sub, inc, dec, cmp, mul, div) - Bit manipulasjonsinstruksjoner (and, not, xor) - Strenginstruksjoner (lods, stos) - Betingede, ubetinget hopp (branch-instruksjoner), loopinstrukskoner og kall av prosedyrer(jmp, jz, loop, call) - Software interrupt-instruksjoner (int - interrupt, iret retur fra interrupt) - Prosessor kontrollinstruksjoner (clc clear carry, cli enable interrupt) - Floating point instruksjoner (fadd, ) - SSE-instruksjoner En oversikt over dette instruksjonsrepertoaret finner i appendiks Det første assemblyprogrammet for Intel prosessor Programmet skal skrive et program som i utgangspunktet er et c-program. Programmet skal addere tallet 3 og 4 og få svaret 7. Selve addisjonen skal gjøres i assemblykode men vi fletter assemblykoden inn i et C-program. For å flette assemblykode inn i et c-program benytter vi direktivet _asm { }. Assemblyinstruksjonene legges inn mellom klammene i dette direktivet. #include <conio.h> void CR_LF(); // prototype for funksjonen CR_LF() void addi(char a, char b); // prototype for funksjonen addi() void main(void) { char a,b; a=getche(); // les første karakter fra tastatur og gi ekko på // skjermen 53

54 } CR_LF(); a=a-0x30; b=getche(); CR_LF(); b=b-0x30; addi(a,b); // linjeskift // konverter fra ASCII til binær // les andre karakter fra tastatur og gi ekko på // skjermen // linjeskift // konverter fra ASCII til binær void CR_LF(){ putch(10); putch(13); } // CRLF void addi(char a,char b){ char sum=0; _asm{ mov al, a; mov bl, b; add al, bl; add al, 0x30; // konverter til ASCII mov sum,al; } putch(sum); CR_LF(); } Legg merke til at vi må konvertere ASCII-koden til et binært tall før addisjonen. Dette gjøres ved å subtrahere 0x30 fra ASCII-koden. Vi ønsker å studere noe nærmere hva som skjer i C når vi kaller en C-funksjon. Vi ser på følgende C-eksempel: #include <stdio.h> 54

55 void add(int x, int y); void main(){ int a,b; a=5; b=7; add(a, b); } void add(int x, int y){ int c; c=x+y; printf( Summen er %d\n, c); } Ved en titt på figur 6.1 merker vi oss at begge variablene 5 og 7 beslaglegger ett ord hver i stakkområdet. Dette skyldes at vi har deklarert a og b variabelen som int og dette blir da 16-bits tall i følge standard ANSI C. Lokale variable blir lagret på stakk når vi skriver programmet i C. Den nedre delen av stakken blir opprettet når vi startet main()-funksjonen. Den første verdien som legges på stakk er den originale verdien i BP-registeret, verdien denne hadde når main() tok kontrollen ved starten av programmet. BP-registeret er en slags reserve stakkpeker, og denne vil oppdateres til å peke ved starten av stakkområdet (adresse 1012) tildelt for vårt program. Starten på stakken er altså ved adresse Når kompilatoren ser programlinjen int a, b; reserveres 2 ord for variablene a og b. Figur 7.1 viser at disse blir lagret umiddelbart etter den originale BP registerverdien. Dermed kan kompilatoren referere til variabelen a ved operanden [BP-2]. Variabelen b aksesseres ved operanden [BP-4]. Vi merker oss at rekkefølgen på variablene lagret i run-time stakken er identisk med rekkefølgen de ble deklarert i. Når C - kompilatoren ser funksjonskallet add(a, b), opprettes et arbeidsområde for funksjonen i overensstemmelse med en standard C calling convention. Resultatet blir som vist i øvre delen av figur Vi minner også om at når data pushes på stakk, vokser stakken mot lavere adresser i et system basert på en Intelprosessor. Etter at 55

56 parametrene er lagt ut på stakk, vil returadressen pushes. Dette er den adressen som gjør at vi finner tilbake til neste instruksjon i main() etter at funksjonen add() er ferdig kjørt. I prosjekt 3 vil vi sjekke dette nærmere og vil oppdage at parameteroverføringen og lagringen på stack kan avvike litt fra det vi har beskrevet her. SP A returadr 5 (x) For addem() 100C 7 (y) 100E (b) 5 (a) gammel bp Run-time stack For Ny bp main() Figur 6.1 Ved funksjonskallet add( ) opprettes et arbeidsområde på stakk som vist i figuren. 56

57 7 Interrupt i en mikroprosessor Vi vil gjennomgå interrupt forutsatt en Intelprosessor i real mode for å få litt enkle forhold. I denne modusen vil f eksempel en Intelprosessor ha to interrupt innganger, NMI og INTR inngangene. NMI (Non Maskable Interrupt) har høyest prioritet. Et interrupt på denne inngangen blir tatt hånd om umiddelbart uansett tilstand for prosessoren. Denne inngangen benyttes derfor ofte i forbindelse med overvåking av tilførselsspenning til prosessoren. Om denne faller under en viss terskel iverksettes dette interruptet og en avbruddsrutine sørger for å lagre unna det viktigste av status- og registerinnhold når avbruddet inntrådte. Dette NMI - interruptet er som navnet sier ikke maskerbart, det vil si det finnes ingen mulighet for å forhindre det ved hjelp av programinstruksjoner. Det er imidlertid mulig med et avbrudd som kommer til INTR inngangen på prosessoren. I en PC kommer et slikt signal fra en interruptkontroller PIC8259 (PIC = Peripheral Interrupt Controller). Vi kan se på denne kontrolleren som en blokk som samler sammen interrupt fra ulike hardware kilder og prioriterer disse i forhold til hverandre. En slik kontroller har i utgangspunktet 8 innganger og vi har 2 slike kontrollere i en PC. Disse to kontrollerne kobles sammen og en av de 16 IRQ inngangene benyttes i denne sammenkoblingen. Derfor har vi bare 15 innganger til vår disposisjon. Kontrollerne tilordner hver av disse et nummer og de er prioritert i forhold til hverandre (se figur 8.1). IRQ0 har høyest prioritet. IRQ linjene er såkalte flankestyrte det vil si at når den ytre enheten leverer en positiv signalflanke, vil en forespørsel et interrupt request - bli registrert i kontrolleren. Kontrolleren sjekker prioriteten til det innkommende avbruddet og om ingen andre interrupt med høyere prioritet finnes registrert eller kjører i øyeblikket, vil det nyankomne avbruddet bli videresendt til INTR inngangen på prosessoren. Det vil si det er ikke helt sikkert: I kontrolleren finnes også et maskeringsregister der vi kan hindre avbruddet i å bli videresendt. Dette registeret kan vi nå ved hjelp av en OUT assemblyinstruksjon og på den måten programteknisk hindre at visse interrupt blir iverksatt. Med avbrudd menes en prosess der prosessoren overfører programkontroll til en av 256 mulige interruptrutiner (betjeningsrutiner). Disse avbruddsrutinene er nummerert fra 0 til 255 og disse numrene kalles typenummer. I real mode har vi en tabell kalt interrupt vektortabellen (IVT) i minnet fra adresse 0 til 1023 (1 kb med adresser). Den inneholder startadressen til ulike interruptrutiner. 57

58 7.1 Et realmode eksempel Vi skal nå ta et konkret eksempel å se på hvordan et tegn kan mottas på COM1-porten på en PC ved bruk av interrupt. Figur 7.1 under illustrerer hvordan dette fungerer. Anta at en karakter ankommer på inngang 1 kodet som en asynkron karakter med startbit og stoppbit. Denne karakteren legges i RxD som er mottaksregisteret. Om vi på forhånd har forberedt avbrudd ved mottak ved å sette en bit i enableregisteret (IER), vil hardware i modulen sende et interrupt til interruptkontrolleren (Peripheral Interrupt Controller (PIC) 82C59A). En slik interruptkontroller har 8 innganger og kan sende et avbruddssignal over til prosessorens INTR-inngang. Inn til denne interruptkontrolleren kommer avbruddsignal fra inntil 7 avbruddskilder. For en PC er disse fordelt slik tabell 8.1 viser. I denne interruptkontrolleren finnes blant annet tre registre. Det første, Interrupt Request Register (IRQR) benyttes for å markere hvilke interrupt som er kommet inn fra IRQ pinnene. Det andre benyttes for å maskere interrupt fra en kilde (Mask Register) og det tredje registeret viser hvilket interrupt som er under betjening. CPU INTR 4 PIC 8259 IR3 eller IR IER OUT2 2 3 IR-rutine Data 6 RxD RxD 1 IntVektTab IVT Figur 7.1 Avbrudd ved seriekommunikasjon. 58

59 INTA fra CPU PIC 82C59A I n IRQ7 INTR til CPU Interrupt Priority resolver t R e q Databus u e IRQ0 s 8 bit Mask reg 8 bit In-service reg 8 bit s adr 0x21. adr 0x20 t Figur 7.2 Blokkskjema for interrupt kontrolleren 8259 som finnes Ri en PC. e Interrupt Request Register er et 8-bits register og en ener i f eks bit 4 sier at det har g kommet inn en forespørsel om interrupt på IRQ4 inngangen (COM1-porten). I Interrupt Mask Register (IMR,adresse 0x21) vil en tillate et interrupt fra en IRQ inngang om korresponderende bit i Mask register er satt til 0. En 1 i en f eks bit 4 vil stanse interrupt fra inngang IRQ4 (COM1-porten) slik at avbruddet ikke blir videresendt til prosessorens INTR inngang. Om bit nr 4 i InServiceRegister (ISR, adresse 0x20) er satt, indikerer dette at interrupt fra IRQ 4 er under betjening. Når et interrupt fra en kilde ikke er hindret av bitsetting i maskeringsregisteret og ingen andre interrupt med høyere prioritet er under betjening, vil et interruptsignal sendes over til prosessoren. Prosessoren vil blant annet lagre unna returadresse (CS og IP) og statusregister. Den vil også nullstille IF-, TF-bitet i statusregisteret. Det neste som står for tur er å finne startadressen til interruptrutinen den som skal lese av tegnet som ligger i mottaksregisteret på COM1-porten. Hvordan finner vi denne? For å finne denne vil prosessoren først motta et typenummer fra interruptkontrolleren. Dette typenummeret viser hvilken IRQ-inngang på interruptkontrolleren som er årsak til 59

60 interruptet. I vårt eksempel er dette IRQ4 (COM1-porten) noe som skulle gi typenummer 4. Dette typenummeret skal brukes til å peke til riktig plass i interruptvektor tabellen, der startadresse til vår interruptrutine (mottaksrutine) ligger. I en PC skjer dette på følgende måte: prosessoren multipliserer typenummeret med 4. Grunnen til det er at hver adresse beslaglegger 4 byter, to for kodesegmentregister og to for instruksjonspeker. Instruksjonspeker verdien lagres på laveste adresse av de 4 bytene. Se figur 7.3. Nå er det imidlertid slik i en PC at de første 8 interrupt adressene i vektortabellen er reservert fra Intels side slik at første ledige interrupt for interrupt fra interruptkontrolleren starter med typenummer 8. Hardware interrupt 0 (IRQ 0) har derfor typenummer 8, hardwareinterrupt 1 (IRQ 1) har typenummer 9 etc. Dette betyr at IRQ 4 får typenummer 0x0C eller 12 desimalt. Dermed kan vi beregne hvor i interruptvektortabellen vi skal finne startadressen til vår interruptrutine slik: 12*4 = 48 Fra adresse 48 i intern RAM og fire byter utover finner vi startdressen til vår mottaksrutine. Innholdet i bytene 48 og 49 blir lastet til IP-registeret, mens innholdet i 50 og 51 blir lastet til CS registeret. Dermed vil neste instruksjon som hentes, være den første instruksjonen i mottaksrutinen. Det som skjer videre er at mottaksrutinen kjøres noe som resulterer i at tegnet i mottaksregisteret leses av og legges i et bufferområde i minnet. Dernest returnerer en fra interruptrutinen og går tilbake til det programmet som kjørte før avbrudd. 60

61 Intern RAMhukommelse IntVektorTab 256 adresser (1k) Startadr til interrupt-rutine KodesegmentRegister (CS) Instruksjonspeker (IP) Adr Adr bit Figur 7.3 Figuren viser hvordan startadressen til en interruptrutine ligger lagret i interrupt vektortabellen. Interruptvektor tabellen ligger på de laveste adressene (de første 1 kb) i intern RAM-hukommelse. 61

62 Interrupt type nr 0 Divisjon med 0 1 Single step modus (debugging) 2 (NMI) CPU:RAM-feil/ 3 CPU breakpoint debugging 4 Numerisk overflow 5 Printscreen 6 Resevert 7 Resevert 8 IRQ0 Timer tick, klokke som oppdateres ca 18.2 ganger pr sekund 9 IRQ1 Keyboard A IRQ , interrupt kontroller nr 2 B IRQ3 COM2, serieport 2 C IRQ4 COM1, serieport 1 D IRQ5 LPT2: parallellport (skriver) 2 E IRQ6 Floppy disk F IRQ7 LPT1: parallellport (skriver) 1 10 BIOS: Videofunksjoner 11 BIOS: Bestem konfigurasjon 12 BIOS: Bestem størrelse på RAM 13 BIOS: Funksjoner for harddisk 14 RS232 IO 15 KassettIO 16 Tastatur 17 Funksjoner for printerport 18 Kaller basic tolker i ROM 19 Boot maskin (CTRL+ALT+DEL) 1A Les sanntidsklokken 1B CTRL-BREAK 1C Kalles etter hvert INT8 1D Adresser til videoparamtre 1E Adresser til diskparamtre 1F Adresser til beskrivelse av karaktersett 20 DOS: Avslutt program 21 DOS: DOS interrupt 22 Adressen til rutinen for DOS:Avslutt program 23 Adressen til rutinen for DOS:CTRL C 24 Adressen til rutinen for DOS: Kritisk feil 25 DOS: Les harddisk/diskett 26 DOS: Skriv til harddisk/diskett 27 Avslutt og installer resident program 28 DOS: Tomgangsrutine Diverse 33 Funksjoner for musdriver Reservert 62

63 41 Adresse til første harddisk Reservert 46 Adresse til andre harddisk 47-6F Diverse og noen ledige 70 IRQ 8 - CMOS sanntidsklokke 71 IRQ9 sammenkoblet med IRQ2 72 IRQ10 Ledig 73 IRQ11 Ledig 74 IRQ12 PS2-mus 75 IRQ13 Koprosessor 76 IRQ14 Harddiskkontroller 77 IRQ15 - Ledig 78 - FF Ledig + brukes av basictolkeren Tabell 7.1 Oversikt over interrupt i en IBM (IBM-kompatibel) PC. I protected mode er det noe andre forhold. Det finnes et register i prosessoren som peker til en Interrupt deskriptortabell (IDT). På samme måte som i real mode kan man her ha 256 ulike interrupt. Disse ligger ikke lagret som segmentregister: offset i IDT, men det er i stedet satt av 8 byter for hvert interrupt (entry) i denne tabellen. Disse 8 bytene representerer en såkalt gate deskriptor til avbruddsrutinen. En gate brukes her i betydningen kall til et program som kjører i et annet privilegienivå; avbruddsrutiner kjører ofte i ring 0. Formatet for en gate deskriptor er vist i figur 7.4 under. Target segmentoffset (16 31) Presentbit, priv level, type segm, DWord count Target segment selector Target segment offset [0:15] Figur 7.4 Felter i en gate deskriptor. 63

64 IDT - registeret i CPU en holder både baseadresse og limitverdi for tabellen og den kan derfor ligge hvor som helst i minnet. Årsaken til at en prosessor overfører kontroll til en avbruddsrutine, kan deles inn i tre grupper: Ved avbrudd fra ytre enheter. Ved en programinstruksjon (f eks INT x der x er et typenummer fra 0 til 255) som overfører kontrollen til en avbruddsrutine med type nr x Ved såkalte unntak eller exceptions (eksempel divisjon med 0, segmentation violation, etc) Avbrudd fra ytre enheter er slik vi har sett i seriekommunikasjonseksemplet foran og foregår ved at den enheten som ønsker oppmerksomhet gir fra seg et signal som til sist ender på en INTR pinne på prosessoren. I en PC vil signalet først gå innom en 8259 avbruddskontroller. I DOS er alle disse tilordnet faste nummer slik som vist i tabellen over. Andre eksempler på slike avbrudd har vi når vi trykker en tast på tastaturet eller når vi har bedt om lesing av en fil fra disk. Når disken er ferdig med å lese data fra diskplaten og levert disse til internminnet genereres også et interrupt. Avbrudd ved programinstruksjonen INT x. Denne assemblyinstruksjonen vil gjøre at programutførelsen fortsetter i en avbruddsrutine med typenummer x. Vi kan bruke denne instruksjonen til å kjøre rutiner i BIOS eller i operativsystemet. I C er geninterrupt(x) en makro for assemblyinstruksjonen INT x. Ved software interrupt er ikke 8259 funksjonen inne i bildet. Det betyr at vi ikke har maskeringsmuligheter eller prioriteringsmuligheter ved software interrupt. Måten disse INT - instruksjonene brukes på, er at en instruksjon INT x inneholder flere funksjoner (f eks åpne, lukke filer, les, skriv eller søk i fil etc). Hvilken av disse funksjonene en skal velge å kjøre er bestemt av innholdet i et CPU-register f eks AH registeret i en Intel prosessor før INT- instruksjonen kjøres. AH - registeret vil dermed fungere som en funksjonsvelger innenfor INT x rutinen. Software interrupt kalles ofte synkrone interrupt, mens hardware interrupt kalles asynkrone interrupt. Forklaringen på dette er at en int instruksjon alltid kommer på 64

65 samme sted når en applikasjon kjøres, mens tidspunktet når en ytre enhet gir fra seg et interruptsignal er helt tilfeldig. 7.2 Advanced Programmable Interrupt Controller (APIC) Etter 8259-kontrolleren utviklet Intel en mer avansert interruptkontroller. Denne skulle blant annet behandle delte avbrudd mer elegant og har viktige oppgaver i et flerprosessor/flerkjerne-system. Registrene i 8259 fikk vi tak i ved å benytte IO instruksjoner. En APIC er memorymapped og vi henvender oss til registrene i denne ved å benytte minneadresser. Under er vist et blokkskjema for en APIC. Buss og I Lokal interrupt enhet: system n Prioritetsenhet kontroll JTAG test logikk t e r n Vektor felt Vektor dekoder ICC bus arbitation IO interrupt enhet ICC- buss b 32 bits timer u ICC buss kontroll s Redirection tabell Figur 7.5 Blokkskjema for en APIC (Advanced Peripheral Interrupt Controller). Nyere Intelprosessorer har en APIC modul innebygd, men APIC modulen kan også være en egen brikke. APIC n har også en innebygd 32-bits timer og såkalt JTAG testlogikk som brukes for å teste den integrerte kretsen. Avbruddsrutinene i protected mode behandles noe forskjellig fra real mode. I protected mode har vi fortsatt 256 forskjellige avbrudd og det eksisterer interruptrutiner for disse avbruddene. Vektortabellen nederst i DOS minnet gjelder ikke lenger, men er erstattet med Interrupt Descriptortabell (IDT). Hvis prosessoren kjører i Virtuell 86 mode eller protected mode, vil avbruddsrutinen for avbruddene 0x08 0x0E - det vil si IRQ0 til 65

66 IRQ6 - undersøke hvorvidt kravet til avbrudd kom fra prosessoren (exception) eller fra en IRQ linje (ytre enhet). Dersom det er en exception fra CPU vil disse avbruddene bli brukt som følger: Interrupt nr Funksjon 8 Dobbel exception (en ny exception oppstår mens et annet behandles) 9 Koprosessor segmentfeil (på gamle maskiner) A Kall til et ugyldig TSS (Task State Selector) ved multitasking B Ugyldig segment C Stakk overflyt D Generell beskyttelsesfeil E Feil med minnefordeling Tabell 7.2 Oversikt over noen exceptions. 7.3 Message Signaled Interrupts (MSI) For maskiner som har bussene fra PCI 2.2 og fram til PCI Express (Peripheral Component Interconnect) åpnes det for en alternativ måte å generere interrupt på fra en ytre enhet. Tradisjonelt har en ytre enhet tilgang til en interruptpinne som blir aktivisert når enheten ønsker oppmerksomhet fra CPU-siden. Hver ytre enhet har hatt en IRQ - linje som den aktiviserer når den ønsker å avbyte CPU en. I PCI - konseptet benyttes meldinger som skal erstatte den tradisjonelle måten å sende interrupt på. Den ytre enheten sender en kort melding til en avtalt minneadresse noe som medfører at chipsettet vil levere interrupt til CPU en. For MSI-X består meldingen av en adresse og en 32-bits heltallsverdi og omtales som en vektor. MSI-X er implementert både i LINUX (5.x) og Windows (Vista, Windows server 2008) og vil føre til enklere hardware med reduksjon i antall pinner. Det finnes som antydet - to utgaver av MSI nemlig MSI og den mer avanserte utgaven MSI-X (X står for extended). MSI-X kom med PCI 3.0 busstandarden. MSI kan takle inntil 32 interrupt, mens MSI-X opererer med inntil 2048 uavhengige interrupt. 66

67 Av andre karakteristikker nevner vi: - Færre pinner reduserer kostnader ved kretsdesign. - Datamengden i meldingen kan variere. - Interruptene kan ikke deles, slik at en MSI er koblet kun til et interrupt. - Ved pinnebasert design kan en få race conditions ved en DMA - skriving til minnet. For å unngå dette må en ved pinnebaserte løsninger lese fra den ytre enheten for å finne ut om DMA - skrivingen var ferdig. Dette har noe innvirkning på ytelsen. MSI-X tillater hver ytre enhet å allokere et antall interrupt og gir hvert interrupt separate adresseområder samt åpner for maskering pr vektor. En vanlig misforståelse i forbindelse med MSI konseptet er at de tillater en ytre enhet å sende data til CPU en som en del av interruptet. Det forholder seg slik at data som sendes i forbindelse med skrivingen til denne avtalte minneadressen brukes av chipsettet til å bestemme hvilket interrupt som skal trigges og på hvilken CPU det skal avbrytes. Det er ingen mulighet for den ytre enheten å sende tilleggsinformasjon til interruptrutinen (handler). Begrepet Dynamic Interrupt Redirection er sentralt i forbindelse med MSI-X. Det innebærer blant annet at et interrupt kan sendes til en spesifikk prosessor for hver IO forespørsel. En server kan f eks foreta informasjonsdeling mellom OS, driver og PCI enhet noe som bidrar til å redusere forsinkelser knyttet til interruptet. En kan operere med affinity hvilket i denne sammenheng betyr at samme IO-enhet kan få sitt interrupt kjørt på samme prosessor i et flerprosessormiljø, noe som også bidrar til bedre ytelsen. Dette skyldes at ved en slik løsning slipper en i noen grad å fornye f eks cache, TLB er etc siden de allerede er tilgjengelig i minnet. 67

68 68

69 8 RISC - og CISC - arkitektur i prosessorer Som vi har sett finnes det datamaskiner tilpasset ulike formål, alt fra mikrokontrollere som skjøtter enkle dedikerte oppgaver i en distribuert industriell kontekst - til de mest avanserte prosessorarkitekturene i tungregneanlegg. Om vi tenker oss et nivå på prosessorene tilsvarende det vi finner i PC verden, ser vi ofte at disse deles inn i to kategorier, nemlig RISC - og CISC - prosessorer. Forkortelsene står for henholdsvis Reduced Instruction Set Computer og Complex Instruction Set Computer. Intel leverte i starten prosessorer med CISC arkitektur, men som nevnt tidligere snakker de om sine nyere prosessorer som CISC prosessorer med RISC kjerne. Vi skal se på egenskaper ved CISC prosessorer først. 8.1 CISC CISC arkitektur karakteriseres av følgende: - Stort og fleksibelt sett med instruksjoner (inkludert mer avanserte instruksjoner for f eks strengbehandling). - Assemblyprogrammene blir kortere enn ved RISC-arkitektur. - Disse er kompatible med forgjengerne innen en prosessorfamilie (eks x86 familien). - Instruksjonsdekodingen blir tyngre med lange og kompliserte instruksjoner hvilket betyr lengre utviklingstid for dekoderne. 69

70 8.2 RISC Det som karakteriserer en RISC-arkitektur er følgende: - Analyse av program under eksekvering avslører at det ofte er stor gjenbruk av kode og data. Det er også noen registre som brukes mye og noen som brukes mindre. RISC arkitekturen utnytter disse egenskapene til å forenkle design og øke ytelsen. Noen tall fra undersøkelser på dette området viser følgende prosentfordeling når det gjaldt hvor mye instruksjoner i ulike kategorier ble brukt ved eksekvering av ulike typer programvare. - flytting av data 45 % - programflyt (hopp) 29 % - aritmetiske operasjoner 11 % - sammenligningsinstruksjoner 6 % - logikk 4 % - shift 3 % - bitmanipulasjonsinstruksjoner 2 % - øvrige < 1 % Dette viser at det er fornuftig å optimalisere instruksjoner som har med flytting av data og som bestemmer programflyten (branch-instruksjoner og funksjonskall). Det er fornuftig f eks å forbedre arkitekturen ved håndtering av branch-instruksjoner med branch prediction moduler. Dekodingen av instruksjoner blir enkel idet instruksjonene i størst mulig grad har lik lengde. Dermed kreves mindre utviklingstid og en kommer raskere på markedet. Instruksjonsrepertoaret i RISC er begrenset, men instruksjonene utføres meget effektivt, mens antall instruksjoner for å kunne utføre en oppgave gjerne blir flere. 70

71 9 Feilkontroll Når vi overfører data fra et sted til annet, er det viktig at data som ble sendt mottas riktig i andre enden av kommunikasjonskanalen. Det samme gjelder når vi lagrer data i minnet, da er det viktig at data som leses er de samme som de ble skrevet tidligere. Vi har tidligere omtalt paritetskontroll som en måte å sjekke om data er riktige på. To litt mer robuste måter å gjøre feilkontroll på er å benytte sjekksum eller såkalt CRC sjekk. (CRC står for Cyclic Redundancy Check). Vi skal ta fram eksempler her som illustrerer disse. 9.1 Sjekksum Anta at vi har 4 byter som angitt heksadesimalt kan skrives: 25H, 62H, 3FH, og 52H. Disse bytene skal sendes over en overføringslinje og sjekksummen beregnes på sendersiden etter følgende algoritme: - Adder databytene og dropp mente - Ta 2 s komplement til summen. Det vi nå har fått er sjekksummen. Grunnen til at vi tar 2 s komplement til summen er at om vi på mottakersiden - adderer alle bytene inkludert sjekksummen skal vi få 0 som resultat om det ikke er feil i overførte data. Med tallene våre blir dette: addisjon av bytene: 0x25+0x62+0x3F+0x52 = 0x118 om vi dropper mente får vi: 0x18 2 skomplement av resultatet gir sjekksummen: 0xE8 I mottaker - enden adderes alle data inkludert sjekksum slik: 0x25+0x62+0x3F+0x52 + 0xE8 = 0x00 om vi dropper mente Om vi antar at den andre byten har fått en bitfeil under overføringen fra 0x62 til 0x22 får vi følgende feilsjekkresultat i mottakerenden: 0x25+0x22+0x3F+0x52+0xE8 = C0 Resultatet er forskjellig fra null og indikerer at det er feil med de overførte data. 71

72 9.2 CRC - sjekk CRC står for Cyclic Redundancy Check. Denne sjekken er mye brukt både i datakommunikasjon og i forbindelse med lagring av data på disk. For å forklare hvordan dette foregår tenker vi oss følgende eksempel: Innholdet i meldingen som skal overføres (nyttedata) ser slik ut: Datasystemet opererer med et såkalt generatorpolynom: og benytter modulo 2 aritmetikk. Algoritmen er da: - Utvid meldingen med et antall 0 bit tilsvarende lengden på generatorpolynomet minus 1. - Utfør modulo 2 divisjon mellom utvidet melding og generatorpolynomet. - CRC verdien er da resten ved denne modulo 2 divisjonen og denne adderes til meldingen. På sender siden foregår følgende EXOR - operasjoner: : = rest Overført melding blir:

73 På mottakersiden utføres en tilsvarende beregning og hvis resten blir 0 er meldingen riktig mottatt : = rest 73

74 74

75 10 IO bussystemer i en PC 10.1 Universal Serial Bus (USB) Noen toneangivende selskaper innen data- og elektronikkbransjen Compaq, DEC, NEC, IBM, Intel, Microsoft og Nothern Telecom gikk sammen om å løse problemet med tilkobling av langsomme IO enheter. Resultatet ble USB. Noen av målene for selskapene var: Det skal ikke være nødvendig for bruker å stille brytere/jumpers på IO kort. Bruker skal ikke måtte åpne PC'n for å plugge i kort Samme type kabel skal benyttes for sammenkobling av mange IO enheter IO-enhetene skal få strømtilførsel over denne kabelen Inntil 127 enheter kan koples til samme datamaskin Systemet bør støtte sanntidsbehandling av video, lyd og telefon IO enhetene skal kunne installeres mens datamaskinen står på, og uten ny oppstart av maskinen (hot-plug) Bussen og IO enhetene skal ha lav pris USB imøtekommer alle disse kravene. Typiske enheter som er tilkoblet denne er tastatur, mus, stillbilde kamera, videokamera, scannere, digitale telefoner etc. Hele USB båndbredden var i starten 1.5 Mbit/s og 12 Mbit/s (USB 1.0, USB 1.1). Siste kvartal år 2000 ble USB 2.0 lansert med overføringsrater opptil 480 Mbit/s = 60MByte/s. USB 3.0 ble første gang vist i I PC er lanseres 1ste kvartal Hastighetene her 4.8 Gbit/s = 600 Mbyte/s, men vi antar at vi realistisk opplever 400 Mbyte/s etter at overhead er trukket fra. Teknologien her ligner på teknologien fra PCIexpress 1x Figur 10.1 viser et typisk USB IO - buss system. Topologien for et USB - system er en trestruktur med treets rot plassert inne i PC'n (host adapter). Kabelen som forbinder to enheter har to ulike kontakter i hver ende for å unngå feil sammenkobling av utstyr. Kabelen har 4 tråder, 2 til dataoverføring, en til strømforsyning og en jordforbindelse. 75

76 PC USB- skjerm tastatur kontakt hub +12V modem signal GND skrive Figur 10.1 Et typisk USB- buss r system. Signalene over linjen ordnes på følgende måte: en logisk 0 overføres som spenningsendring fra høyt spenningsnivå til lavt eller omvendt. en logisk 1 overføres fravær av spenningsendring. Dette innebærer at en lang rekke 0'er vil overføres som et regelmessig pulsmønster over linjen. Når en ny IO - enhet plugges inn, vil rothuben inne i PC'n detektere denne hendelsen og gi et interrupt til operativsystemet. Operativsystemet vil finne ut hva slags enhet dette er og hvor mye båndbredde denne enheten trenger. Hvis operativsystemet finner ut at dette båndbreddekravet kan tilfredsstilles, vil enheten få tildelt en unik adresse ( ) som lastes ned til enheten sammen med andre data som skal benyttes i enhetens konfigureringsregistre. På denne måten kan nye enheter kobles til 'on-the-fly' uten at bruker trenger å foreta seg noe. For å gjøre kablingen enklere inneholder mange enheter USB hubber. En monitor kan f eks ha to hub - kontakter for å betjene høyre og venstre høyttaler. Rothuben (hostadapter) spiller en hovedrolle (master) og har hele tiden kontrollen. Kommunikasjonen foregår alltid mellom en IO enhet og denne rothuben. Det kan ikke 76

77 foregå kommunikasjon mellom to IO enheter direkte i et USB system. (Det er imidlertid mulig ved SCSI og FireWire bussystem). IO enhetene må dele den totale båndbredden som er tilgjengelig i systemet. Hvert millisekund vil rothuben kringkaste en ny melding (frame) for å holde alle tilkoblede IO - enheter synkronisert i tid. En melding består av pakker, og den første kommer alltid fra rothuben. De pakkene som følger etter kan sendes i samme retning, eller de kan sendes fra IO enheten til rothuben. Figur 10.2 viser en sekvens bestående av fire frames (meldinger). tid (ms) Frame 0 Frame 1 Frame 2 Frame 3 SOF SOF In Data ACK SOF SO OU Data ACK F T SYN Pid Payload ACK SYN Pid Payload ACK Figur 10.2 USB rot hub sender ut 'frames' hvert ms. Figur 10.2 viser at det ikke er noe informasjon knyttet til frame 0 og frame 2, så det eneste som går over den serielle overføringslinjen er en SOF - Start of Frame pakke. Denne pakken kringkastes til alle enheter. Frame 1 er et eksempel på en såkalt 'poll' aktivitet med en forespørsel til f eks en skanner om å returnere data fra et bilde som den er i ferd med å skanne inn. Frame 3 viser oppbygningen av en frame som leverer data til for eksempel en skriver. USB benytter 4 frametyper. Disse er control, isochronous, bulk og interrupt. Control frames brukes til å konfigurere en IO enhet, gi disse en kommando eller forespørre om status i IO enheten. Isochronous frames er for sanntidsenheter, som for eksempel mikrofoner, høytalere, telefoner og kamera (video). Disse framene har ingen form for retransmisjon ved feil og får derfor en forutsigbar forsinkelse (delay) ved overføring. Bulk frames benyttes ved overføring av større datamengder uten sanntidskrav, men der det er viktig med feilfri overføring. Et eksempel her er overføring til skrivere. Interrupt frames 77

78 trengs fordi USB ikke benytter seg av styrt interrupt i vanlig forstand. I stedet for å ha et tastatur som forårsaker interrupt hver gang vi trykker en tast, vil et tastatur på USB - bussen bli forespurt av operativsystemet om å avlevere innkomne tastetrykk f eks hvert 50 ms. En frame består av en eller flere pakker, og disse pakkene kan sendes i begge retninger. Fire ulike pakketyper finnes. Disse er: token, data, handshake og special pakketyper. Token pakker kan f eks være pakker som sendes mellom rothuben og IO - enhet og benyttes til systemkontroll. I figur 10.2 er SOF, IN, OUT - pakkene eksempler på token pakker. SOF - pakkene er de som innleder en frame (11 bits heltall som inkrementeres pluss en 5 bits CRC-sjekk). Hvis det ikke skal foregå noe dataoverføring, vil dette være det eneste som skjer innen 1 ms. IN - token - pakken er en polling som går ut på å forespørre om en enhet har noe data å overføre. Feltene i IN pakken forteller hvilke data denne IO - enheten skal returnere. OUT token pakker forteller IO enheten at data til denne enheten vil følge. En fjerde type token pakke kalles SETUP pakke. Dette er en pakke som brukes til konfigurering. I tillegg til pakker av typen token, har vi 3 andre pakketyper. Disse er DATA, HAND- SHAKE og SPECIAL. Formatet for en datapakke er vist i figur Den består av et 8 bits synkroniseringsfelt, en 8 bits pakketype ID, nyttedata og CRC sjekk (Cyclic Redundancy Check). Handshake pakketyper kan forekomme i 3 utgaver: ACK, NAK, STALL. ACK er en kvittering på riktig mottatte data, NAK er en kvittering på feil ved data (CRC feil) og STALL betyr 'vent - jeg er opptatt. Hvert ms vil operativsystemet sende en frame fra rothuben selv om det ikke er noe overføring som skal foregå for øvrig. I figur 10.2 er frame 0 og 2 kun SOF pakker som indikerer at det ikke er noe å gjøre. Frame 1 er en poll frame og derfor starter den med en SOF og en IN pakke fra datamaskin til IO enhet. Denne etterfølges av en DATA pakke fra enheten til datamaskinen. ACK pakken forteller enheten at datamaskinen har mottatt data korrekt. Hvis det hadde vært feil ved mottaket, ville en NAK pakke bli sendt tilbake til enheten og pakken ville bli sendt om igjen hvis det var bulk enhet (ikke hvis det var en isochronous enhet). Frame 3 er lik frame 1 bortsett fra at datastrømmen er fra en datamaskin til en IO - enhet. 78

79 Litteraturreferanser [1] [2] [3] [4] [5] J L Antonakos: An introduction to the Intel Familiy of Microprocessors. [6] Douglas Hall: Microprocessors and interfacing, 2 nd edition. Appendiks 1 - Instruksjonsrepertoaret i Intel x86-familien 79