Portning och utökning av processor för ASIC och FPGA

(1)

Portning och ut¨

okning av processor

f¨

or ASIC och FPGA

Martin Olsson

LiTH-ISY-EX--09/4249--SE

(2)

(3)

f¨

or ASIC och FPGA

ISY, Link¨opings Universitet

Martin Olsson LiTH-ISY-EX--09/4249--SE

Examensarbete: 20 p Level: D

Supervisor: Anders Forslund,

Signal Processing Devices Sweden AB Examiner: Oscar Gustafsson,

ISY, Link¨opings Universitet Link¨oping, april 2009

(4)

(5)

Elektroniksystem, ISY 581 83 LINK ¨OPING SWEDEN april 2009 x x http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-18250 LiTH-ISY-EX--09/4249--SE

Portning och ut¨okning av processor f¨or ASIC och FPGA Port and extension of processor for ASIC and FPGA

Martin Olsson

In this master thesis, the possibilities of customizing a low-cost micropro-cessor with the purpose of replacing an existing micropromicropro-cessor solution are investigated. A brief survey of suitable processors is carried out whe-rein a replacement is chosen. The replacement processor is then analyzed and extended with accelerators in order to match set requirements. The result is a port of the processor Lattice Mico32 for the FPGA circuit Xilinx Virtex-5 which replaces an earlier solution using Xilinx MicroBla-ze. To reach the set requirements, accelerators for floating point arith-metics and FIR filtering have been developed. The toolchain for the pro-cessor has been modified to support the addition of accelerated floating point arithmetics.

A final evaluation of the presented solution shows that it fulfills the set requirements and constitutes a functional replacement for the previous solution.

CPU, Mico32, FPU, FPGA, FIR, accelerators, GDB Nyckelord Keyword Sammanfattning Abstract F¨orfattare Author Titel Title

URL f¨or elektronisk version

Serietitel och serienummer Title of series, numbering

ISSN ISRN ISBN Spr˚ak Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats ¨ Ovrig rapport

(6)

(7)

In this master thesis, the possibilities of customizing a low-cost micropro-cessor with the purpose of replacing an existing micropromicropro-cessor solution are investigated. A brief survey of suitable processors is carried out wherein a replacement is chosen. The replacement processor is then analyzed and ex-tended with accelerators in order to match set requirements.

The result is a port of the processor Lattice Mico32 for the FPGA circuit Xilinx Virtex-5 which replaces an earlier solution using Xilinx MicroBlaze. To reach the set requirements, accelerators for floating point arithmetics and FIR filtering have been developed. The toolchain for the processor has been modified to support the addition of accelerated floating point arithmetics.

A final evaluation of the presented solution shows that it fulfills the set requirements and constitutes a functional replacement for the previous solu-tion.

Keywords: CPU, Mico32, FPU, FPGA, FIR, accelerators, GDB

Sammanfattning

I det här examensarbetet undersöks möjligheterna att anpassa en mikro-processor med l˚ag kostnad i syfte att ersätta en existerande mikroproces-sorlösning. En kort kartläggning över lämpliga processorer görs, i vilken en ersättare väljs ut. Ersättningsprocessorn analyseras sedan och kompletteras med acceleratorer för att motsvara ställda krav.

Resultatet är en portning av processorn Lattice Mico32 till FPGA-kretsen Xilinx Virtex-5 som ersätter en tidigare lösning med Xilinx MicroBlaze. För att n˚a upp till de krav som ställts upp har acceleratorer för flyttalsaritmetik och FIR-filtrering utvecklats. Verktygskedjan för processorn har modifierats för att stödja den tillagda accelererade flyttalsaritmetiken.

En slutlig utvärdering av lösningen som presenteras visar att den uppfyller de krav som ställts upp och utgör en funktionell ersättning för den tidigare lösningen.

(8)

(9)

Jag vill tacka min handledare Anders Forslund och alla andra p˚a SP Devices för möjligheten att f˚a genomföra det här examensarbetet samt för all hjälp och vägledning ni erbjudit under arbetet.

Tack ocks˚a till min opponent Victoria Dahl som grundligt g˚att igenom arbetet och kommit med m˚anga bra insikter och synpunkter.

(10)

(11)

ASIC Application Specific Integrated Circuit 1

BSD Berkley Software Distribution, BSD-liknande

licenser är ett samlingsnamn för en typ av li-censer för öppen källkod

8

DDD Data Display Debugger, ett grafiskt gr¨anssnitt f¨or debugverktyg

24

FIR Finite Impulse Response, en filtertyp med im-pulssvar av begr¨ansad l¨angd

2

Flyttalsaccelerator Se FPU 2

FPGA Field-Programmable Grid Array, en form av

programmerbar logik

1

FPU En accelerator f¨or hantering flyttal och

ber¨akning av flyttalsaritmetik

9

GAS GNU Assembler, en assemblator 41

GCC GNU Compiler Collection, en kompilator 7

GDB GNU Debugger, ett debugverktyg 24

GPIO General Purpose Input/Output, en enhet f¨or

digital I/O

63

GPL GNU General Public License, en licens f¨or

¨oppen k¨allkod

8

IDE Intergrated Development Environment,

verk-tyg f¨or mjukvaruutveckling

7 IP-block Kodmoduler som utgör immateriell egendom 7 JTAG En standard för testportar för integrerade

kretsar

20

(12)

LGPL GNU Lesser General Public License, en licens för öppen källkod

8 LSB Least Significant Bit, biten med l¨agst

signifi-kans i ett dataord

30

MAC Multiply-Accumulate, en funktion d¨ar tv˚a tal multipliceras och produkten adderas till ett ackumulerat resultat, en MAC-enhet ¨ar en en-het som implementerar den funktionen

8

MMU Memory Management Unit, enhet f¨or

minnes-hantering

2

MSB Mico System Builder, konfigurationsverktyg

f¨or Mico32, alt. Most Significant Bit, biten med h¨ogst signifikans i ett dataord

24

OS Operativsystem 2

RISC Reduced Instruction Set Computer, en

de-signstrategi f¨or instruktionsarkitekturer

9

Slice LUT Ett logikblock i FPGA-kretsar best˚aende av ett visst antal LUT:ar och register, anv¨ands som ungef¨arligt m˚att p˚a fyllnadsgraden hos FPGA-kretsen

63

Strukturerad ASIC En kretstyp d¨ar programmerbara logikblock anv¨ands men routinglager tillverkas fixt

1

UART En standard för seriell överföring av data 20 Verilog Ett spr˚ak för h˚ardvarubeskrivande kod 9 Verktygskedja Den samling verktyg som behövs för

mjukva-ruutveckling

8

(13)

1 Introduktion 1

1.1 Bakgrund och syfte . . . 1

1.2 Kravspecifikation . . . 2

1.3 Disposition . . . 3

I

Val och portning av processor

5

2 Processor 7 2.1 Existerande l¨osning . . . 7

2.2 Val av ny processor . . . 8

2.2.1 Licenser . . . 8

2.2.2 Urval . . . 8

2.3 Introduktion till Mico32 . . . 9

2.3.1 Registerarkitektur . . . 10

2.3.2 Undantagshantering . . . 10

2.3.3 Pipelinearkitektur . . . 12

2.3.4 Hopp och anrop . . . 15

2.3.5 Utvecklingsverktyg . . . 15 2.4 Portning . . . 17 2.4.1 Minnen . . . 18 2.4.2 Debugsystem . . . 20 2.4.3 Utvecklingsverktyg . . . 24

II

Utveckling av acceleratorer

27

3 Flyttalsacceleration 29 3.1 Flyttalsaritmetik . . . 29 3.1.1 Flyttal . . . 29 3.1.2 Flyttalsoperationer . . . 31 Olsson, 2009. xiii

(14)

3.2 Val av flyttalsenhet . . . 31

3.3 Minnesmappad flyttalsacceleration . . . 32

3.4 Instruktionsgr¨anssnitt . . . 37

3.5 Kompilatorst¨od . . . 40

3.6 Ny flyttalsaccelerator . . . 42

3.6.1 Bakgrund och begr¨ansningar . . . 42

3.6.2 Design . . . 43 3.6.3 Testning . . . 45 3.6.4 Resultat . . . 46 4 Filteracceleration 47 4.1 Specifikation . . . 47 4.2 Design . . . 49 4.2.1 Beräkning av FIR-filter . . . 49 4.2.2 Adressering . . . 51 4.3 Implementation . . . 54 4.3.1 Gränssnitt . . . 57 4.3.2 Programmeringsgränssnitt . . . 59 4.4 Testning . . . 61 4.5 Resultat . . . 61

5 Resultat och vidareutveckling 63 5.1 Resultat . . . 63 5.2 Vidareutveckling . . . 66 5.2.1 Mico32 . . . 66 5.2.2 Debugenhet . . . 67 5.2.3 Flyttalsacceleration . . . 67 5.2.4 Filteracceleration . . . 69 A Exjobbsf¨orslag 73 B RTL-schema MicoFPU 75 B.1 Pipelinesteg P0 . . . 76 B.2 Pipelinesteg P1 . . . 77 B.3 Pipelinesteg P2 . . . 78 B.4 Pipelinesteg P3 . . . 79 B.5 Specialtal, multiplikation . . . 80 B.6 Specialtal, addition/subtraktion . . . 81 B.7 Submoduler MicoFPU . . . 82 C Debugserver 83

(15)

Introduktion

I f¨orsta kapitlet presenteras bakgrunden och syftet till arbetet tillsammans med en genomg˚ang av rapportens inneh˚all.

1.1 Bakgrund och syfte

Den här rapporten dokumenterar ett examensarbete som har genomförts av Martin Olsson som en del av utbildningen Civilingenjör i datateknik 180p vid Linköpings Universitet. Arbetet utfördes för Signal Processing Devices Sweden AB i Linköping under 2008–2009.

SP Devices är ett företag baserat i Linköping som inriktar sig p˚a högprestrerande signalbehandlingssystem. Fokus ligger p˚a system för multiplexad A/D-omvandling och efterbehandling av A/D-konverterad data. Företagets produkter innefat-tar stora digitala system som byggs med hjälp av FPGA-teknik. Som en kom-ponent i SP Devices digitala system används en integrerad mikroprocessor, Xilinx MicroBlaze.

Processorn MicroBlaze licensieras som en del av utvecklingsverktygen för de FPGA-kretsar som används. En av nackdelarna med MicroBlaze, tillika den största anledningen att det här examensarbetet kom till är att proces-sorn enbart licensieras för implementation i Xilinx FPGA:er. Den framtida utvecklingen av SP Devices system leder mot implementation i strukture-rad ASIC och ASIC. För det behövs en ersättare till MicroBlaze som kan implementeras i valfri teknologi. I avsnitt 2.1 beskrivs MicroBlaze lite nog-grannare.

Syftet med det här arbetet har allts˚a varit att utvärdera potentiella ersättare till MicroBlaze, välja ut en processor och anpassa den för SP De-vices syften. Exjobbsförslaget som l˚ag till grund för arbetet finns ˚atergivet i

(16)

bilaga A.

1.2 Kravspecifikation

Eftersom den nya processorn ersätter en existerande lösning blir den tidigare lösningen en naturlig baslinje för de krav som ställs p˚a den nya implementa-tionen. Följande krav och begränsningar sattes upp innan arbetet p˚abörjades:

K1.1 Processorn ska ha en flyttalsaccelerator.

K1.2 Processorn ska ha en l˚ag eng˚angskostnad och ingen styckekost-nad.

K1.3 Processorn ska ha en minimal konfiguration f¨or inbyggt system. K1.4 Inget OS ska k¨oras p˚a processorn, den ska programmeras i ren C

och Assembler.

K1.5 Det ska g˚a att exekvera FIR-filter med en 16 bitars multiplikation och 48 bitars ackumulation per klockcykel. Detta behöver dock inte ske i processorkärnan utan kan lösas m.h.a. delade minnen och en extern beräkningsenhet.

K1.6 Till processorn ska finnas en utvecklingsmilj¨o med C-kompilator, debugger och simulator.

K1.7 Processorn ska ha en debug-port med anslutning till standardde-bugger.

K1.8 Processorn ska inte ha en MMU.

K1.9 Processorn ska inte anv¨anda sig av cacheminne.

K1.10 Processorn ska kunna exekvera med en klockfrekvens p˚a minst 100 MHz i Xilinx FPGA.

Kraven är löst definierade eftersom det initialt fanns en oklar bild över urvalet av processorer och deras prestanda. Gemensamt för alla krav är en strävan att beh˚alla den funktionalitet och prestanda som den nuvarande lösningen erbjuder.

(17)

1.3 Disposition

Rapporten är indelad i fem kapitel, där det första kapitlet utgör en introduk-tion. Resten av rapporten utgörs av tv˚a övergripande delar enligt nedan. Kapitel 1

I kapitel ett ges en introduktion till arbetets bakgrund och m˚alen med arbetet fastst¨alls.

DEL I

F¨orsta delen av arbetet utg¨ors av kapitel tv˚a och handlar om arbetet som gjorts med processorn.

Kapitel 2

I kapitel tv˚a ges en beskrivning av valet av processor. D¨arefter beskrivs funk-tionaliteten hos den valda processorn. Kapitlet avslutas med en beskrivning av vad som gjordes f¨or att anpassa processorn.

DEL II

Den andra delen av arbetet handlar om utvecklingen av acceleratorer f¨or den nya processorn, dels en flyttalsaccelerator och dels en filteraccelerator. Kapitel 3

I kapitel tre redogörs arbetet med acceleration av flyttalsaritmetik. Först ges en kort introduktion till flyttalsformatet och flyttalsaritmetik. Därefter beskrivs hur processorn i steg kompletterades med en flyttalsaccelerator. Kapitel 4

I kapitel fyra ges f¨orst en kort bakgrund till teorin bakom FIR-filtrering, d¨arefter beskrivs hur en filteraccelerator designades och implementerades. Kapitel 5

I femte och sista kapitlet ges en sammanfattning av resultaten fr˚an arbe-tet med ˚aterkoppling till m˚alen ifr˚an kapitel ett. Därefter ges förslag p˚a förbättringar och vidareutveckling av olika delar i arbetet.

(18)

(19)

Val och portning av processor

(20)

(21)

Processor

I det här kapitlet ges en kort beskrivning av den processor som har ersatts. Vidare beskrivs hur valet av en ersättande processor gick till. En introduktion till den nya processorn ges tillsammans med en beskrivning av de ändringar och kompletteringar som har gjorts för att anpassa den till systemet.

2.1 Existerande l¨

osning

För Xilinx FPGA-kretsar finns en rad med licensierbara IP-block som kan användas för att snabba upp utvecklingen. Till dessa hör processorkärnan MicroBlaze tillsammans med en flyttalsaccelerator och en rad andra kring-enheter. För utveckling med MicroBlaze finns en samling verktyg som un-derlättar konfigurering av processorn med kringenheter samt utveckling av mjukvara för MicroBlaze. Verktygsuppsättningen g˚ar under namnet Xilinx EDK och inneh˚aller bland annat kompilatorn GCC och ett grafiskt IDE. [5] Xilinx EDK inneh˚aller ett grafiskt gränssnitt, Xilinx Platform Studio (XPS) för att konfigurera processorns valbara delar samt tillgängliga kring-enheter. Med hjälp av XPS kan man definiera minnesstorlekar, adressutrym-men, klockfrekvens med mera för ett processorsystem. [5]

MicroBlaze i sig är en 32-bitars processor av RISC-typ. Den har en femstegs pipeline och kan i den aktuella h˚ardvaran (Xilinx Virtex-5) klockas i upp till 200MHz. Processorn har utvecklats internt hos Xilinx och bygger p˚a en tidigare, enklare variant med trestegs pipeline som utvecklades 2001 (den här varianten finns fortfarande tillgänglig som ett utrymmessn˚alare al-ternativ). Debuggning av programkod i h˚ardvaran g˚ar att göra över JTAG med hjälp av GDB och verktyg i Xilinx EDK. MicroBlaze distribueras utan källkod. [10]

Den flyttalsaccelerator som MicroBlaze anv¨ander sig av har en fyrastegs

(22)

pipeline och kan vid fullt utnyttjande utföra en flyttalsberäkning var fjärde klockcykel. Acceleratorn g˚ar att klocka i samma hastighet som processorn. [10]

2.2 Val av ny processor

2.2.1 Licenser

Krav K1.2 sl˚ar fast att lösningen som väljs inte f˚ar ha n˚agon styckekost-nad och m˚aste ha en l˚ag eng˚angskostnad. En styckekostnad är en kostnad som läggs p˚a varje producerad produkt. En eng˚angskostnad är en kostnad som läggs t.ex. under utvecklingen men inte växer med antalet producera-de produkter. Det här kravet leproducera-der till att i huvudsak lösningar som bygger p˚a öppen källkod har beaktats. Det finns ett antal varianter av licenser för öppen källkod men gemensamt är att koden licensieras utan kostnad. Öppen källkod är ett väl etablerat förfarande inom mjukvaruutveckling men licenser för öppen källkod som är speciellt anpassade för h˚ardvarubeskrivningar är ovanliga. [6] Under förstudien till projektet konstaterades ocks˚a att m˚anga av de licenser som används för h˚ardvarubeskrivande öppen källkod är s˚adana som tidigare använts för mjukvara, till exempel GPL eller LGPL.

För källkod som licensieras med GPL gäller att modifikationer av koden m˚aste vidaredistribueras under samma licens. [9] För det här projektet är ett s˚adant villkor inte godtagbart eftersom integrering med IP som licensieras under andra villkor behöver kunna göras i ett senare skede. Kod som enbart kan licensieras under GPL har därför valts bort. Källkod som licenseras under t.ex. LGPL eller BSD har inte s˚adana begränsningar.

2.2.2 Urval

I förstudien till projektet togs ett antal processorer i beaktning. Bland des-sa valdes visdes-sa bort direkt p˚a grund av olika faktorer s˚asom pris, prestanda och licenskrav. Bland de som valdes bort i förstudien fanns bland andra Opensparc S1, LEON3, ZPU och AEMB. Utifr˚an förstudien valdes tre pro-cessorer ut och presenterades i detalj för handledaren och representanter fr˚an SP Devices. Processorerna beskrivs i korthet nedan.

• LEON2

En 32-bitars LGPL-licensierad RISC-arkitektur skriven i VHDL. Pro-cessorn ¨ar utvecklad av Gaisler Research Institute och har en femstegs

(23)

pipeline. Instruktionsupsättningen implementerar SPARCv8. En 16x16-bitars MAC-instruktion med ett 40-16x16-bitars ackumulatorregister som ex-ekverar en operation per klockcykel finns. Till processorn finns en FPU som m˚aste licensieras separat. Ett verktygskedja baserat p˚a GCC finns tillgängligt, men för att debugga programkod i processorn krävs ett verktyg som licensieras separat till en extra kostnad. För att konfigure-ra processorn och ansluta kringenheter finns ett gkonfigure-rafiskt hjälpverktyg. [11]

• Mico32

En 32-bitars RISC-arkitektur med en sexstegs pipeline skriven i Veri-log. Processorn är utvecklad av Lattice Semiconductor för företagets egentillverkade FPGA-kretsar. Licensen som används g˚ar under nam-net Lattice Open IP Core License och är speciellt utformad för öppen h˚ardvarubeskrivande källkod. Instruktionsuppsättningen saknar MAC-instruktion och FPU-MAC-instruktioner. En GCC-baserad toolchain och ut-vecklingsmiljö i Eclipse finns. I samma Eclipsemiljö finns ett verktyg för att konfigurera processorn och ansluta kringenheter. Debuggning av programkod p˚a processorn är möjligt, men bara p˚a Lattice h˚ardvara. [1]

• Openrisc 1200

En 32-bitars LGPL-licensierad RISC-arkitektur med en femstegs pi-peline skriven i Verilog. Processorn saknar FPU, men instruktions-uppsättningen stödjer FPU-instruktioner. En 32x32-bitars MAC-instruktion med 48-bitars ackumulatorregister och en cykels exekveringstid finns. En toolchain baserad p˚a GCC finns till processorn. Debuggning av pro-gramkod p˚a processorn är möjligt. Processorn konfigureras med hjälp av konfigurationsfiler i källkoden. Kringenheter kan manuellt anslutas till processorns Wishbone-buss. [12]

Utifr˚an diskussioner kring kraven och de egenskaper som processorerna har valdes genom konsensus att projektet skulle g˚a vidare med en utveckling av Mico32.

2.3 Introduktion till Mico32

Mico32 best˚ar av en 32-bitars processorkärna med ett egenutvecklat RISC-instruktionsset. Processorn har en registerfil med 32 register och tv˚a bussar enligt Wishboneprotokollet för data respektive instruktioner. Minnesmappa-de WishbonebaseraMinnesmappa-de kringenheter kan anslutas till databussen. Förutom

(24)

da-tabussen kan kringenheter ocks˚a kommunicera med processorn via 32 exter-na interruptsigexter-naler. Processorn kan konfigureras med valbar minnesmängd samt med eller utan data- och instruktionscache. Debugmöjligheter för pro-gram i processorn finns via debugport. Processorn kan ocks˚a via ett existe-rande gränssnitt förlängas med användardefinierade instruktioner som im-plementeras i extern logik. [1]

I f¨oljande avsnitt ges en mer ing˚aende beskrivning av de olika delarna i Mico32.

2.3.1 Registerarkitektur

Mico32 har 32 register varav R1-R29 är generella register1_{. Register R0 är} reserverat och alltid satt till noll2_{. Register R29 (ra) används av} instruktio-nen call för att lagra returadressen, register R30 (ea) används för att lagra programräknaren när ett undantag sker och register R31 (ba) används för att lagra programräknaren när ett breakpoint eller watchpoint utförs. [1]

Ut¨over de generella registrena finns ¨aven ett antal Control and Status

Re-gisters (CSR) som kan läsas och skrivas med instruktionerna rcsr respektive wcsr. Tabell 2.1 visar alla ˚atkomliga CSR. EBA kan användas för att peka om basadressen för undantag fr˚an debugminnet till programminnet och p˚a s˚a sätt utnyttja egna undantagshanterare. IE, IM och IP används för att hantera interrupts. ICC och DCC används för att tömma cacharna d˚a de är aktiverade. CC används för att räkna instruktionscykler om funktionen för cykelräkning är aktiv. I CSR CFG finns processorns konfiguration lagrad s˚a att exekverande program kan utläsa vilka funktioner som konfigurerats in i processorn. [1]

2.3.2 Undantagshantering

Det finns ˚atta typer av undantag i Mico32. När ett undantag inträffar i Mico32 sker ett hopp till hanterande rutin. Beroende p˚a om undantaget är ett debugundantag eller ett normalt undantag sker hoppet relativt antingen basadressen DEBA eller EBA. Basadressen EBA för normala undantag är ställbar via CSR. De värden som EBA och DEBA antar efter reset ställs i konfigurationen av processorn. I tabell 2.2 finns samtliga undantag med respektive adresser listade. Källkoden till undantagshantering för normala undantag˚aterfinns i filen crt0ram.S. Hantering av debugundantag behandlas mer ing˚aende i avsnitt 2.4.2. [1]

1

Vid C-programmering är även R26-R28 reserverade för speciella funktioner.

2

Med vissa restriktioner kan även R0 användas som generellt register, s˚a görs exem-pelvis i debugkoden i avsnitt 2.4.2.

(25)

Namn ˚Atkomst Beskrivning

IE R/W Interrupt enable

IM R/W Interrupt mask

IP R Interrupt pending

ICC W Instruction cache control

DCC W Data cache control

CC R Cycle counter

CFG R Configuration

EBA R/W Exception base address

Tabell 2.1: F¨orteckning ¨over CSR

Undantag Adress f¨or hanterare

Reset DEBA + 0

Breakpoint DEBA + 32

Instruction bus error EBA + 64

Watchpoint DEBA + 96

Data bus error EBA + 128

Divide by zero EBA + 160

Interrupt EBA + 192

System call EBA + 224

(26)

2.3.3 Pipelinearkitektur

Instruktionspipelinen i Mico32 har sex steg: Address (A), Fetch (F), Decode (D), Execute (X), Memory (M) och Write (W). I figur 2.1 visas en skiss över pipelinen i Mico32 i förh˚allande till minnen, register och kringenheter. En detaljerad beskrivning av funktionen hos stegen i pipelinen följer.

Pipelinesteg A

I steg A sker generering av nästa värde för programräknaren. Beräkning av adressen till nästa instruktion sker i signalen pc a, som är ett 30-bitars adressregister. I figur 2.2 ˚ask˚adliggörs beslutsdiagrammet för beräkning av pc a.

Om ett hopp sker i M-steget sätts adressen till branch target m. Sker ett hopp i X-steget s˚a sätts adressen istället till branch target x.

För korta villkorliga hopp görs en enkel förutsägning om utg˚angen. I de

fall hopp förutsägs sker det i D-steget och pc a tilldelas branch predict address d. Visar det sig i M-steget att en förutsägning i D-steget var fel s˚a rättas det till genom att pc a tilldelas pc x.

En närmare beskrivning av systemet för förutsägning av hopp finns i 2.3.4. I normaltillst˚andet, allts˚a när inga hopp sker och pipelinen inte är stoppad, tilldelas pc a adressen över den instruktionen som hämtades i förra instruktionscykeln.

Initiellt efter ˚aterställning av processorn tilldelas pc f värdet av EBA mi-nus ett vilket medför att pc a i nästa cykel kommer att anta värdet av EBA (registret EBA beskrivs närmare i avsnitt 2.3.1).

Pipelinesteg F

I pipelinesteg F h¨amtas instruktionen fr˚an adress pc f i programminnet. Pipelinesteg D

I steg D avkodas instruktionsordet som hämtats fr˚an minnet. Instruktionsty-pen avgörs utifr˚an de sex mest signifikanta bitarna i instruktionsordet. För varje avkodad instruktion genereras kontrollsignaler till instruktionsenheter-na i steg X. Vilka enheter som finns i processorn beror p˚a hur den konfigure-rats. Tillgängliga enheter är Load-Store (LSU), Adder (AU), Logic-Operation (LOU), Shifter (SU), Multiplier (MU) samt Division (DU). Efter operations-koden i instruktionsordet följer parametrar som beror p˚a instruktionstypen, tabell 2.3 visar bitfördelningen i de instruktionsformat som processorn han-terar.

(27)

(28)

p c _ a p c _ x b r a n c h _ t a r g e t _ m b r a n c h _ t a r g e t _ x b r a n c h _ p r e d i c t _ a d d r e s s _ d p c _ f p c _ f + 1 b r a n c h _ m i s p r e d i c t _ t a k e n _ m & & ! e x c e p t i o n _ m b r a n c h _ t a k e n _ x b r a n c h _ p r e d i c t _ t a k e n _ d & & v a l i d _ d s t a l l _ f b r a n c h _ t a k e n _ m 1 0 1 0 1 0 1 0 1 0

Figur 2.2: Ber¨akning av n¨asta instruktionsadress, pc a

Register Immediate Format (RI)

Op.kod Reg. 0 Reg. 1 Immediatev¨arde

6 5 5 16

Register Register Format (RR)

Op.kod Reg. 0 Reg. 1 Reg. 2

-6 5 5 5 11

Control Register Format (CR)

Op.kod CSR Reg.

-6 5 5 16

Immediate Format (I)

Op.kod Immediatev¨arde

6 26

(29)

Pipelinesteg X och M

Utifr˚an avkodningen i steg D väljs indata till instruktionen fr˚an registerfilen eller avkodat immediatevärde. I de fall som register bypass valts i steg D används data direkt ifr˚an föreg˚aende steg X eller M. I de fall instruktionen utnyttjar Wishbonebussen uppeh˚alls pipelinen tills ˚atkomsten genomförts. Pipelinesteg W

Utifr˚an avkodningen i steg D v¨aljs utdataregister f¨or instruktionen och re-sultatet ifr˚an steg X eller steg M skrivs till registerfilen.

2.3.4 Hopp och anrop

Instruktionsuppsättningen i Mico32 har funktionsanrop samt villkorliga och ovillkorliga hopp. För villkorliga hopp relativt programräknaren sker en enkel förutsägning av utg˚angen: hopp med positiv offset förutsägs inte tas och de med negativ offset förutsägs tas. Förutsägningen sker i pipelinesteg D, felaktiga förutsägningar korrigeras i steg M. I övriga fall tas villkorliga hopp i steg M. [1] Ovillkorliga hopp tas i steg X3_.

2.3.5 Utvecklingsverktyg

Mico32 levereras tillsammans med en uppsättning verktyg som inneh˚aller de delar som behövs b˚ade för konfigurering av h˚ardvarusystem med Mico32 och kringkomponenter samt mjukvaruutveckling för s˚adana system. Alla verktyg som används sammanförs i ett Eclipse-baserat grafiskt IDE.

Konstruktion av system med Mico32 och kringkomponenter sker i mjuk-varan MSB (Mico System Builder). MSB är ett grafiskt verktyg som körs i samma Eclipsebaserade miljö som övriga utvecklingsvektyg. Figur 2.3 visar en skärmbild fr˚an programmet. I MSB kan man bygga ett system genom att ange parametrar för systemet som helhet och sedan lägga till kompo-nenter som ansluts till processorns Wishbonebuss. I rutan uppe till vänster i skärmbilden (figur 2.3) finns en lista som inneh˚aller Mico32 samt andra kom-ponenter som finns tillgängliga att ansluta till processorn. För varje kompo-nent finns ett antal parametrar som t.ex. basadress för minnesmappningen.

Efter att ha definerat upp systemet i MSB s˚a genererar programmet dels de Verilogfiler som behövs för att bygga systemet och dels stödfiler för mjuk-varuutveckling till det genererade systemet.

3

(30)

Figur 2.3: Konfigurationsverktyget MSB

Verilogfilerna best˚ar av system conf.v som inneh˚aller definitioner av de parametrar man valt i MSB samt en toppniv˚afil för systemet som ocks˚a inneh˚aller en arbitrerare för de komponenter som anslutits till Wishbonebus-sen. De här filerna kopieras tillsammans med koden till de komponenter som ing˚ar i systemet till en valbar plats i filsystemet.

Eftersom processorn i det här projektet portats till en alternativ FPGA-krets och dessutom har utökats med funktionalitet krävdes mer ing˚aende kon-troll över konfigurationen. Konfigurationen som skrivs ut till system conf.v och toppniv˚afilen har därför modifierats allt eftersom det behövts.

För mjukvaruutvecklingen skapar MSB länkscript anpassade till den min-neskonfiguration som specificerats. En headerfil system conf.h som inneh˚aller basadresser och andra parametrar för de komponenter som ing˚ar i syste-met skapas. För varje komponent som lagts till i systesyste-met kopieras ocks˚a tillhörande drivrutiner in i systemet. Tillsammans kan de här filerna sedan användas för att kompilera C- och C++-kod för systemet i utvecklingsmiljön. I utvecklingsmiljön finns även verktyg för att debugga koden i en mjuk-varusimulator samt direkt p˚a processorn via JTAG. För det sistnämnda al-ternativet krävs att Lattices h˚ardvara används.

Utvecklingsverktygen för Mico32 utgörs till stor del av beprövade verktyg med öppen källkod. Den C-kompilator som används i utvecklingsverktygen

(31)

Figur 2.4: Utvecklingsplattform f¨or projektet

är GCC v3.4.4. För delar av det här projektet har ocks˚a utvecklingsversionen GCC v4.4.0 använts med framg˚ang. Förutom GCC är de delar som används för programvaruutveckling: Binutils (assemblerare, länkare, m.m), GDB (de-bugger, simulator) och Newlib (standardbibliotek för C). För de tre senare finns stöd för Mico32 för senaste versionen i respektive projekts kodbas. Till GCC krävs fortfarande en extern patch.

2.4 Portning

M˚alet med portningen av Mico32 har varit att göra designen tillräckligt allmän för att kunna användas i ASIC eller strukturerad ASIC. Som ett steg p˚a vägen gjordes portningen först mot en existerande h˚ardvaruplattform ba-serad kring FPGA-kretsen Virtex-5, se figur 2.4. Resultatet av det här arbetet är allts˚a en lösning för den här h˚ardvaruplattformen. Oundvikligen kommer vissa delar av portningen att bli specifika för m˚alplattformen. Implementa-tionen har gjorts modulär för att s˚adana delar enkelt ska kunna bytas ut mot motsvarande delar för en annan m˚alplattform. En av fördelarna med att använda Virtex-5 som m˚al för portningen är att det blir enklare att jämföra den nya lösningen med den tidigare eftersom h˚ardvaran är densamma.

I avsnittet som följer redogörs för de ändringar som gjorts i Mico32 i syfte att göra processorn portabel enligt projektm˚alen.

(32)

2.4.1 Minnen

I konfigurationsprogrammet MSB läggs program- och dataminne av valbar storlek till som komponenter p˚a processorns Wishbonebussar för instruktio-ner respektive data. S˚a som systemets Wishbonestöd är implementerat tar det fyra klockcykler att hämta ett dataord fr˚an ett minne p˚a Wishbonebus-sen. Det innebär att varje g˚ang F-steget hämtar ett instruktionsord stoppas pipelinen i tre cykler.

För att snabba upp hämtningen av instruktionsord finns ett system med instruktions- och datacache implementerat i Mico32. Ett av önskem˚alen för projektet var att systemet inte skulle använda sig av cacheminne. De min-nen som finns tillgängliga för implementatiomin-nen av Mico32 p˚a m˚alplattformen best˚ar av h˚art implementerade minnesblock i FPGA-kretsen. ˚Atkomsttiden för s˚adana minnen är kort nog för att processorn ska kunna hämta en in-struktion per cykel. Av den här anledningen finns det ingen anledning att ha ett cachesystem med flera niv˚aer. Samma resonemang gäller för nästa m˚alplattform.

I Verilogkoden för Mico32 finns ett system för att koppla minne direkt till instruktionspipelinen utan att g˚a vägen över Wishbonebussen. Gränssnittet är en enklare variant av det gränssnitt som används för cacheminne. Möjligheten att koppla minne direkt till instruktionspipelinen g˚ar inte att aktivera i MSB4 och är odokumenterad utanför källkoden till processorn.

Eftersom instruktionscache inte var aktuellt för projektet och ett instruk-tionsminne p˚a Wishbonebussen medför en prestandasänkning med en faktor fyra s˚a valdes istället varianten med minne direkt mot instruktionspipelinen. Eftersom funktionen inte stöds av Lattices system ställer en s˚adan modifika-tion först˚as krav p˚a försiktighet och ytterligare testning.

Processorn har en separat Wishbonebuss för instruktionsminne och en för dataminne. I systemet som MSB bygger kopplas däremot alla minnen och kringenheter in p˚a samma buss. Det här ˚aterspeglas inte i konfigurations-verktyget MSB där användaren lätt f˚ar intrycket av att bussarna är helt separata, se skärmbild 2.6. I dokumentationen sägs det dessutom att Mico32 är av Harvard-arkitektur, vilket inte stämmer med den Wishboneimplemen-tation som MSB genererar. Däremot stämmer det efter modifikationen av minnena. Figur 2.5 visar hur data- och instruktionsminnen ansluts i pipeli-nen efter modifikatiopipeli-nen.

Efter att ha infört separata instruktions- och dataminne g˚ar de C-program som kompilerats i Lattices utvecklingsmiljö inte längre att exekvera. An-ledningen till detta är att länkskripten lagrar hopptabeller för

konstrukto-4

I MSB:s egna konfigurationsfiler finner man att stöd för funktionen är p˚abörjad men utkommenterad.

(33)

R e g i s t e r f i l F e t c h D e c o d e I n s t r . -m i n n e D e b u g -m i n n e E x e c u t e M e m o r y W r i t e b a c k D a t a W B I n s t r . W B R e g i s t e r b y p a s s D a t a -m i n n e B y p a s s , m i n n e U a r t G P I O

Figur 2.5: Mico32:s pipeline efter modifikation av minneskonfigurationen.

(34)

rer5 _{och destruktorer i instruktionsminnet (kodexempel 2.1, rad 17-26) som} nu längre inte är läsbart. Länkskriptet genereras av ett perlskript i MSB, mdk msb subs.pm, som kan modifieras s˚a att det genererar länkskript där hopptabellerna läggs i dataminnet (kodexempel 2.2, rad 25-34). Med den modifikationen genererar länkaren kod som g˚ar att exekvera även med den nya minneskonfigurationen.

2.4.2 Debugsystem

För att underlätta debuggning vid mjukvaruutveckling mot Mico32 finns en portning av debugverktyget GDB tillgänglig. Debugverktyget kan antingen användas med en mjukvarusimulator eller kopplas mot processorn för de-buggning i h˚ardvara. Debuggning mot Mico32 i h˚ardvara sker genom att ett debugundantag genereras i processorn. Den mjukvarurutin som hante-rar debugundantaget agehante-rar sedan server mot en GDB-klient som körs p˚a användarens dator. Debugservern i Mico32 till˚ater sedan att minnesinneh˚all och registerinneh˚all undersöks och modifieras via GDB.

I den ursprungliga konfigurationen av Mico32 finns en implementation av hanterare för debugundantag. Programkoden distribueras enbart i binär form och˚aterfinns som specifikation av inneh˚allet i debugminnet i lm32 monitor ram.v. Debugservern implementerar ett enkelt protokoll för debuggning av kod p˚a processorn och kommunicerar via JTAG. Protokollet som används är likt det som GDB använder för debuggning över serieport men inte kompatibelt. För att kunna kommunicera med processorn krävs därför att man använder ett program som översätter fr˚an Lattices protokoll till GDB:s protokoll. Ett s˚adant program ing˚ar i MSB men kan bara kommunicera med processorn via den JTAG-lösning som Lattice använder sig av.

I det här projektet har debugkommunikationen via JTAG ersatts av kom-munikation via UART. För att ˚astadkomma det här har programkoden i debugminnet ersatts. Tv˚a m˚al ställdes upp för den nya debugkoden. Min-nesutrymmet ska vara detsamma som för den tidigare lösningen. GDB ska kunna användas direkt för att debugga utan mellanliggande program.

Det ursprungliga debugminnet är 2048 bytes stort och rymmer därmed 512 32-bitars ord. Av dessa är 256 ord reserverade för hantering av undan-tag. Vid debugundantag m˚aste en komplett kopia av processorns register- och CSR-tillst˚and skapas, till det reserveras 37 ord i debugminnet. Det lämnar 219 ord kvar för programkod. Av dessa har tolv ord använts som stackut-rymme. Kvar blir 207 ord som kan användas fritt för att implementera

kom-5

Hopptabellen f¨or konstruktorer inneh˚aller ett antal funktionspekare som anropas i ordning f¨ore main() i C-program.

(35)

1 . boot : { ∗ ( . boot ) } > irom 2 . t e x t : 3 { 4 . = ALIGN ( 4 ) ; 5 f t e x t = . ; 6 ∗ ( . t e x t . stub . t e x t . ∗ . gnu . l i n k o n c e . t . ∗ ) 7 ∗ ( . gnu . warning ) 8 KEEP ( ∗ ( . i n i t ) ) 9 KEEP ( ∗ ( . f i n i ) ) 10 11 12 /∗ E xcep t ion h a n d l e r s ∗/ 13 ∗ ( . e h f r a m e h d r ) 14 KEEP ( ∗ ( . e h f r a m e ) ) 15 ∗ ( . g c c e x c e p t t a b l e ) 16 17 /∗ C o n s t r u c t o r s and d e s t r u c t o r s ∗/ 18 KEEP (∗ c r t b e g i n ∗ . o ( . c t o r s ) )

19 KEEP ( ∗ (EXCLUDE FILE (∗ c r t e n d ∗ . o ) . c t o r s ) ) 20 KEEP ( ∗ (SORT( . c t o r s . ∗ ) ) )

21 KEEP ( ∗ ( . c t o r s ) )

22 KEEP (∗ c r t b e g i n ∗ . o ( . d t o r s ) )

23 KEEP ( ∗ (EXCLUDE FILE (∗ c r t e n d ∗ . o ) . d t o r s ) ) 24 KEEP ( ∗ (SORT( . d t o r s . ∗ ) ) ) 25 KEEP ( ∗ ( . d t o r s ) ) 26 KEEP ( ∗ ( . j c r ) ) 27 e t e x t = . ; 28 } > irom =0 29 30 /∗ read−o n l y data ∗/ 31 . r o d a t a : 32 { 33 . = ALIGN ( 4 ) ; 34 f r o d a t a = . ; 35 f r o d a t a r o m = LOADADDR( . r o d a t a ) ; 36 ∗ ( . r o d a t a . r o d a t a . ∗ . gnu . l i n k o n c e . r . ∗ ) 37 ∗ ( . r o d a t a 1 ) 38 e r o d a t a = . ; 39 } > dram 40 } 41 }

(36)

1 . boot : { ∗ ( . boot ) } > irom 2 . t e x t : 3 { 4 . = ALIGN ( 4 ) ; 5 f t e x t = . ; 6 ∗ ( . t e x t . stub . t e x t . ∗ . gnu . l i n k o n c e . t . ∗ ) 7 ∗ ( . gnu . warning ) 8 KEEP ( ∗ ( . i n i t ) ) 9 KEEP ( ∗ ( . f i n i ) ) 10 11 12 /∗ E xcep t ion h a n d l e r s ∗/ 13 ∗ ( . e h f r a m e h d r ) 14 KEEP ( ∗ ( . e h f r a m e ) ) 15 ∗ ( . g c c e x c e p t t a b l e ) 16 17 18 e t e x t = . ; 19 } > irom =0 20 21 /∗ read−o n l y data ∗/ 22 . r o d a t a : 23 { 24 . = ALIGN ( 4 ) ; 25 /∗ C o n s t r u c t o r s and d e s t r u c t o r s ∗/ 26 KEEP (∗ c r t b e g i n ∗ . o ( . c t o r s ) )

27 KEEP ( ∗ (EXCLUDE FILE (∗ c r t e n d ∗ . o ) . c t o r s ) ) 28 KEEP ( ∗ (SORT( . c t o r s . ∗ ) ) )

29 KEEP ( ∗ ( . c t o r s ) )

30 KEEP (∗ c r t b e g i n ∗ . o ( . d t o r s ) )

31 KEEP ( ∗ (EXCLUDE FILE (∗ c r t e n d ∗ . o ) . d t o r s ) ) 32 KEEP ( ∗ (SORT( . d t o r s . ∗ ) ) ) 33 KEEP ( ∗ ( . d t o r s ) ) 34 KEEP ( ∗ ( . j c r ) ) 35 36 f r o d a t a = . ; 37 f r o d a t a r o m = LOADADDR( . r o d a t a ) ; 38 ∗ ( . r o d a t a . r o d a t a . ∗ . gnu . l i n k o n c e . r . ∗ ) 39 ∗ ( . r o d a t a 1 ) 40 e r o d a t a = . ; 41 } > dram 42 }

(37)

Kommando Funktion

g L¨as fr˚an register

G Skriv till register

m L¨as fr˚an minnesposition

M Skriv till minnesposition

c ˚Ateruppta programk¨orning

s Stega fram en instruktion

? L¨as senaste signal

Tabell 2.4: Implementerat subset av GDB:s remote serial protocol munikationsprotokollet mot GDB.

Protokollet för debuggning över serieport med hjälp av GDB specifice-ras i GDB:s manual. [15] I protokollet definespecifice-ras ett kommandoformat och en rad kommandon till debugservern samt hur de ska besvaras. En full im-plementation av hela protokollet i den minnesmängd som finns tillgänglig är inte möjlig, därför har bara den delmängd av protokollet som krävs för full funktionalitet implementerats.

För de kommandon som inte implementerats svarar debugservern enligt specifikation med ett tomt meddelande. Genom att prova sig fram avgör kli-enten vilka kommandon som stöds av servern och sluter sig till ett gemensamt subset av protokollet som stöds av b˚ada ändpunkter. Enligt [15] m˚aste kom-mandona g, G, m, M, c och s implementeras. Utöver de här komkom-mandona har även kommandot ? implementerats6_{. I tabell 2.4 beskrivs funktionen för} respektive kommando.

N˚agot som komplicerar debugfunktionaliteten är att klienten under en debugsession kan ge kommandon som försöker komma ˚at programminnet. I själva verket är det ett vanligt beteende fr˚an GDB-klienten. Ger användaren exempelvis ett kommando för att disassemblera nuvarande frame s˚a kommer klienten att försöka läsa in programdata fr˚an servern och sedan disassem-blera denna. Det sker även om en lokal binär specificerats som referensdata. Likas˚a implementeras breakpoints genom att injicera en break-instruktion i programminnet och spara undan den instruktion som lagrades där innan.

En ˚atkomst till programminnet fr˚an debugservern kommer att generera ett nytt debugundantag med debugminnet som källa och i samband med det skriva över registertillst˚anden fr˚an den ursprungliga källan.

Ett sätt att hantera problemet skulle vara att i debugservern före varje minnes˚atkomst kontrollera om minnesadressen är giltig. En s˚adan kontroll

6

I den version av GDB (v6.5) som anv¨andes gick det inte att koppla upp mot debug-servern om den inte svarade p˚a kommandot ?.

(38)

skulle kräva information om vilka adresser som är läsbara, n˚agot som skiljer sig mellan olika konfigurationer av processorn. Ett annat alternativ skulle vara att modifiera GDB s˚a att inga försök att komma ˚at programminnet görs.

Istället för att försöka arbeta runt de här problemen i GDB eller debug-servern implementerades en Wishbonebrygga mot programminnet. Bryggan till˚ater processorn att skriva och läsa mot programminnet vid exekvering av programkod fr˚an debugminnet.

Resultatet fr˚an implementationen är en fullt fungerande debugserver som kan användas direkt fr˚an GDB via serieporten p˚a h˚ardvaran. Programkoden för debugservern finns ˚atergiven i bilaga C. Precis som tidigare kan debug-funktionaliteten i processorn väljas bort vid konfigurering för att spara re-surser.

2.4.3 Utvecklingsverktyg

De förändringar som gjorts i minneskonfigurationen och debugfunktionalite-ten för med sig vissa problem när det kommer till utvecklingsverktygen. Verk-tygen är skrivna som insticksapplikationer till systemet Eclipse. Eftersom källkoden till insticksapplikationerna inte distribueras med utvecklingsverk-tygen g˚ar det inte att anpassa alla delar av dem i takt med att ändringar görs i Mico32.

MSB till˚ater bara att minnen ansluts via Wishbonebussarna. Efter modifi-kationen av minneskonfigurationen är det därför inte längre möjligt att ändra minnesstorlekar i MSB. Tillvägag˚angssättet för att generera system med pro-cessorn fr˚an MSB har istället varit att skapa en konfiguration helt utan min-nen och sedan justera minnestorleken i den genererade Verilog-koden. Till det är det nödvändigt att definera ett nytt identiskt system i MSB med mot-svarande minnen anslutna till Wishbonebussen. Konfigurationsfilerna fr˚an systemdefinitionen kan sedan användas i mjukvaruutvecklingsverktygen.

Förändringen av debugporten medför att det grafiska debugverktyg som Lattice distribuerar inte längre g˚ar att använda. Anledningen är att gränssnittet mot GDB är fast inställt för att kopplas upp mot den JTAG-lösning som används. Den kommandoradsversion av GDB som distribueras med verk-tygskedjan g˚ar däremot att använda. Vidare har debugfunktionaliteten ocks˚a med framg˚ang testats med version 6.8 av GDB tillsammans med det grafiska gränssnittet DDD.

I en aspekt har integrationen av nya funktioner i utvecklingsverktygen givit bättre resultat. MSB till˚ater att nya Wishbonebaserade komponenter läggs till i systemet genom att gränssnitt, drivrutiner och dokumentation placeras i en speciell katalogstruktur och specificeras i en XML-fil. P˚a s˚a

(39)

sätt kan egenutvecklade kringenheter presenteras p˚a ett enhetligt sätt till-sammans med de som levereras av Lattice i MSB. Det innebär ocks˚a att egenutvecklade enheter enkelt kan läggas till och tas bort fr˚an ett system i verktyget. För de Wishbone-enheter som utvecklats under arbetets g˚ang har motsvarande MSB-komponenter skapats.

Som ett alternativ till de utvecklingsverktyg som distribueras av Lattice har en egenkompilerad verktygskedja best˚aende av Binutils, Newlib, GCC och GDB satts samman. Den motsvarar verktygskedjan som distribueras, men använder nyare versioner av respektive programvara. För verktygskedjan har Make-filer och länkscript skrivits s˚a att mjukvara kan kompileras utan behov av de program som Lattice distribuerar. Genom att använda sig av den här verktygskedjan i kombination med en egen toppniv˚amodul för Mico32 är det möjligt att utveckla system och programvara helt utan de distribuerade verktygen.

(40)

(41)

Utveckling av acceleratorer

(42)

(43)

Flyttalsacceleration

I det h¨ar kapitlet beskrivs hur processorn har kompletterats med en flyttalsac-celerator. En kort introduktion till flyttalsaritmetik ges, d¨arefter beskrivs hur en befintlig flyttalsenhet integrerats med processorn. Slutligen beskrivs hur en ny flyttalsenhet utvecklats och integrerats med processorn och verktygskedjan.

3.1 Flyttalsaritmetik

3.1.1 Flyttal

Flyttal är ett sätt att med en begränsad bitlängd kombinera ett stort dyna-miskt omr˚ade och en hög precision. Ledande standard för flyttal definieras av

IEEE 754, med IEEE 754-2008 som senaste utg˚ava. [3] Flyttal enligt IEEE

754 ¨ar av sign-magnitude-format och delas in i tre delar.

Teckenbit Exponent Signifikand

Teckenbiten S avgör talets tecken, där en etta innebär ett negativt tal. Talets magnitud bestäms av exponenten, E och signifikanden, F . Exponenten lagras i ett viktat format s˚a att t.ex. en sjubitars exponent kan anta ett värde fr˚an 2−62_{till 2}63_{. Sammantaget innebär det är att ett tal med en exponentvikt} p˚a -62 har ett värde motsvarande uttrycket i 3.1. [3]

(−1)S

· F · 2E−62 _(3.1)

Beroende p˚a vilka krav som finns p˚a precision och dynamiskt omr˚ade v¨aljs olika bredd p˚a E och F , nedan listas de precisioner som definieras av IEEE 754-standarden. [3]

(44)

1 8 23

Enkel precision, 32 bitar 1 ≥11 ≥31

Ut¨okad enkel precision, ≥43 bitar 1 11 52

Dubbel precision, 64 bitar 1 ≥15 ≥63

Ut¨okad dubbel precision, ≥79 bitar

Specifikationen för flyttalsaccelereringen i det här arbetet begränsar sig till enkel precision. Vidare är det underförst˚att att flyttal av enkel precision enligt IEEE 754-standarden avses när flyttal nämns.

Signifikanden lagras p˚a normaliserad form vilket inneb¨ar att exponenten justeras s˚a att den mest signifikanta ettan i signifikanden alltid placeras i den mest signifikanta biten. Eftersom denna bit d˚a alltid ¨ar nollskild lagras den inte utan tolkas implicit till ett. [3]

Subnormala tal

För att kunna hantera tal mellan noll och det minsta representerbara norma-liserade talet finns en alternativ representation, s˚a kallade subnormala1 _tal. När subnormala tal representeras sätts exponenten till noll. Signifikanden ska d˚a tolkas som om mest signifikanta biten är noll och exponenten ska tolkas p˚a samma sätt som om den vore satt till ett. [3]

Specialtal

Standarden definierar även ett antal tal med speciell funktion. Inf som repre-senterar ett oändligt tal har bitarna i exponenten satta till ett och bitarna i signifikanden till satta noll. NaN som är resultatet av en operation som inte g˚ar att utföra, t.ex. division med noll. NaN finns i tv˚a varianter, om högsta biten i signifikanden är satt s˚a är talet ett signalling NaN (sNaN) och ska ge ett undantag, om den inte är satt är talet ett quiet NaN (qNaN) och ska pro-pagera genom operationer utan att ge ett undantag. Hantering av undantag vid flyttalsberäkningar ligger utanför omr˚adet i det här arbetet s˚a qNaN och

sNaN kommer vidare behandlas som ekvivalenta. Specialtalen, liksom talet

noll finns i b˚ade positiv och negativ variant. [3]

1

(45)

Avrundningsalgoritmer

IEEE 754-2008 definerar fem olika typer av avrundningar för flyttalsarit-metik. Tre av dessa är s˚a kallade riktade avrundningar och avrundar mot +∞, −∞ respektive noll. De andra tv˚a avrundar mot närmsta representer-bara flyttal med skillnaden att den ena avrundar mot talet med en nolla i LSB om avst˚andet är lika l˚angt och den andra avrundningen mot talet med en etta i LSB. [3]

3.1.2 Flyttalsoperationer

Acceleratorn ska hantera addition, subtraktion och multiplikation. För att utföra aritmetiska operationer p˚a flyttal m˚aste talen först delas upp i tecken-bit, exponent och signifikand. Därefter kan beräkningar, utförda p˚a varje del separat, sammanställas i ett resulterande flyttal. En förteckning över vilka beräkningar som behöver göras för att utföra flyttalsoperationerna finns i avsnitt 3.6.2.

3.2 Val av flyttalsenhet

För acceleration av flyttalsberäkningar p˚a Mico32 togs följande flyttalsenhe-ter i beaktning.

• “FPU100” Implementation av en enkelprecisions pipelinad FPU i VHDL enligt IEEE 754. Licensieras under BSD-liknande licens. Ex-ekverar addition/subtraktion p˚a sju klockcykler, multiplikation p˚a tolv klockcykler. [16]

• “Floating Point Unit” Implementation av en enkelprecisions pipe-linad FPU i Verilog enligt IEEE 754. Licensieras under BSD-liknande licens. Alla operationer exekverar p˚a fyra klockcykler. [17]

Utöver de här tv˚a s˚a togs även flyttalsenheten fr˚an ett projekt vid namn

Opensparc i beaktning, men valdes bort eftersom licensen g¨or att den inte

kan integreras i ett system med förövrigt stängd källkod.

För att f˚a en uppfattning om hur mycket resurser varje enhet tar i an-spr˚ak samt i vilken hastighet den g˚ar att klocka implementerades varje enhet p˚a m˚alplattformen. Eftersom kravet p˚a flyttalsenheten är att den ska kunna utföra addition, subtraktion och multiplikation togs funktionalitet för divi-sion bort innan syntiseringen. I tabell 3.2 redovisas resultatet av implemen-tationen.

(46)

Enhet Slice LUTs Maxfrekvens

FPU100 6399 45MHz

Floating Point Unit 2238 37MHz

Tabell 3.1: Initiell syntisering av flyttalsenheter.

Utifr˚an de här resultaten valdes till att börja med “Floating Point Unit” p˚a grund av att den tar mindre resurser i anspr˚ak och har en högre prestan-da. Eftersom gränssnitten till respektive flyttalsenhet är snarlika designades gränssnittet mellan processorn och flyttalsenheten allmänt nog för att enkelt kunna byta mellan flyttalsenheterna i ett senare skede.

3.3 Minnesmappad flyttalsacceleration

För att kunna utnyttja flyttalsfunktionerna i flyttalsenheten fr˚an program som körs p˚a processorn behövs n˚agot sätt att flytta data fr˚an processorns pipeline till flyttalsenheten och tillbaks. Ett enkelt sätt att ˚astadkomma det här är att skapa en slavenhet p˚a Wishbonebussen som kan flytta data mellan bussen och flyttalsenheten. P˚a s˚a vis kan man komma ˚at flyttalsfunktionerna genom att skriva och läsa till och fr˚an speciella positioner i processorns min-nesrymd. Varje ing˚ang p˚a flyttalsenheten representeras av en adress i minnet till vilken program kan skriva värden. P˚a samma sätt representeras utg˚angen fr˚an flyttalsenheten av en minnesposition där program kan läsa ut resultatet av en flyttalsberäkning.

I figur 3.1 visas ett diagram över hur tillst˚andsmaskinen för Wishbone-interfacet fungerar. Eftersom den aktuella flyttalsenheten inte gick att klocka högre än ungefär en tredjedel av den klockhastighet som processorn klockats med s˚a ägnas en del av kontrollogiken ˚at en handskakningsmekanism.

Skrivningar till de register som driver ing˚angarna p˚a flyttalsenheten be-kräftas i samma klockcykel som förfr˚agningen görs. Läsningar fr˚an utg˚angen p˚a flyttalsenheten fördröjs tills den senaste skrivningen g˚att genom pipeli-nen. En utläsning av resultatet fr˚an flyttalsenheten kan allts˚a ta upp till tolv klockcykler.

I kodexempel 3.1 demonstreras med assemblerkod hur man använder flyt-talsenheten i den minnesmappade modellen. Kodexempel 3.2 visar C-kod som motsvarar assemblerkoden i exempel 3.1. Anropsmetoden i exemplet är om-ständig och tar fokus fr˚an uppgiften som programmet utför. Istället är det önskvärt att kunna göra flyttalsberäkningar med hjälp av de inbyggda flyt-talstyper som finns i C. Exempel 3.3 motsvarar programkoden i kodexempel 3.2, men nu med C:s inbyggda flyttalstyper.

(47)

I N I T P I P E L I N E 1 P I P E L I N E 2 P I P E L I N E 3 R E A D Y C o u n t e r r e s e t r e q / C o u n t e r r e s e t a c k K l o c k d o m ä n , F P U K l o c k d o m ä n , C P U W A I T W R I T E R E A D W B w r i t e r e q / C o u n t e r r e s e t r e q , R e g i s t e r w r i t e , W B a c k W B r e a d r e q & F P U i n s t a t e R E A D Y / W B d a t a o u t , W B a c k C o u n t e r r e s e t r e q , C o u n t e r r e s e t a c k , F P U s t a t e

Figur 3.1: FSM f¨or kontroll av flyttalsenhet p˚a Wishbonebussen.

1 mvhi r1 , 0 x8000 2 o r i r1 , r1 , 0 x0100 3 sw ( r 1 +12) , r 0 4 sw ( r 1 +16) , r 3 5 sw ( r 1 +20) , r 4 6 lw r2 , ( r 1 +0)

(48)

1 f l o a t a , b , c ;

2 unsigned int ∗ fpu = ∗(0 x80000100 ) ; 3

4 /∗ . . . ∗/ 5

6 fpu [ 3 ] = 0 ;

7 fpu [ 4 ] = ∗ ( ( unsigned int ∗) &a ) ; 8 fpu [ 5 ] = ∗ ( ( unsigned int ∗) &b ) ; 9 c = ∗ ( ( f l o a t ∗) fpu [ 0 ] ) ;

Kodexempel 3.2: C-kod f¨or flyttalsoperation utan C-spr˚akets inbyggda typer. 1 f l o a t a , b , c ;

2

3 /∗ . . . ∗/ 4

5 c = a + b ;

Kodexempel 3.3: C-kod f¨or flyttalsoperation med hj¨alp av C-spr˚akets inbygg-da typer.

För att kunna använda flyttalstyperna i C behöver kompilatorn instrueras att översätta beräkningar med flyttalstyper till assemblerkod motsvarande den i de tidigare exemplen. P˚a samma sätt fungerar hantering av flyttals-beräkningar d˚a processorn inte har n˚agon flyttalsaccelerator. När kompila-torn exempelvis stöter p˚a uttrycket c = a + b i exempel 3.3 ersätts det med programkod motsvarande c = addsf(a, b);. Funktionen addsf implemen-terar en addition mellan tv˚a flyttal med enkel precision i mjukvara. Mot-svarande anrop finns för andra kombinationer av operationer och operand-precisioner. I den version av GCC som används för Mico32 implementeras funktionerna för flyttalsberäkningar i ett bibliotek vid namn SoftFloat.

En enkel metod för att översätta flyttalsberäkningar med inbyggda flyt-talstyper till beräkningar i den minnesmappade flyttalsacceleratorn är att bara ersätta anropen till SoftFloats rutiner med anrop till rutiner liknan-de exempel 3.2. För att slippa modifiera GCC eller SoftFloat görs liknan-detta genom att deklarera om de berörda funktionerna vid kompileringstillfället. Omdeklareringen gjordes genom att införa nya funktioner med samma an-ropssignatur2 _{som de hos SoftFloat. För att de nya funktionerna ska ersätta}

2

Samma anropssignatur inneb¨ar att den nya funktionen har samma namn, samma antal anropsparametrar och samma typer p˚a alla anrops- och returparametrar som den tidigare

(49)

SoftFloats rutiner finns tv˚a kriterier vid kompileringen. Dels m˚aste växeln --allow-multiple-definitionges till kompilatorn, dels m˚aste de nya funk-tionerna länkas in före funkfunk-tionerna i SoftFloat.

I kodexempel 3.5 visas de funktioner som används för att ersätta Soft-Floats rutiner med accelererade varianter. När C-kod som använder pro-gramspr˚akets inbyggda flyttalstyper länkas tillsammans med de här funk-tionerna blir resultatet att beräkningarna utförs av flyttalsenheten istället för att beräknas i mjukvara. I kodexempel 3.4 har resulterande objektkod fr˚an kompileringen av exempel 3.3 disassemblerats. Den beräkning med flyt-tal som gjordes har här ersatts med ett anrop till funktionen addsf3. I listningen syns ocks˚a funktionen som ersätter den tidigare mjukvaruflyttals-beräkningen.

En analys av kodexempel 3.4 visar nackdelar med metoden. Vid flyt-talsberäkningar enligt den här modellen sker alltid ett funktionsanrop. För normala funktionsanrop i C kan man med hjälp av attributet inline f˚a ope-rationerna i funktionen att kopieras in p˚a funktionsanropets plats istället för att ett anrop utförs. P˚a s˚a sätt kan operationen utföras utan det overhead som funktionsanropet utgör. Eftersom de ursprungliga flyttalsfunktionerna i Soft-Float inte är deklarerade med det här attributet g˚ar det inte att ˚astadkomma utan att modifiera verktygskedjan.

Fr˚an exemplet 3.4 framg˚ar att för varje flyttalsoperation m˚aste ˚atta in-struktioner utföras. I tabell 3.2 redovisas tids˚atg˚angen för varje instruktion. Speciellt intressant för den här rutinen är tids˚atg˚angen för minnes˚atkomsterna. I figur 3.1 kan man se att bekräftelsen för en skrivning ges p˚a b˚agen mellan WAIT och WRITE direkt vid skrivförfr˚agningen. Bekräftelsen för läsning p˚a b˚agen mellan WAIT och READ ges däremot inte förrän flyttalsaccelera-torn st˚ar i läge READY eftersom resultatet fr˚an beräkningen m˚aste väntas in. Som mest tar det tolv cykler fr˚an det att sista skrivningen till ett av flyttalsacceleratorns register gjorts. Eftersom instruktionen för utläsning av resultatet sker direkt efter sista skrivningen fördröjs den tolv cykler. Det gör att den totala tids˚atg˚angen för en flyttalsoperation är 20 cykler, varav tolv ägnas ˚at själva flyttalsberäkningen i flyttalsenheten. Det motsvarar en overhead p˚a ungefär 67%.

Viss del av denna overhead kommer fr˚an integrationen med flyttalstyper-na i C. För att undersöka om det är lönt att göra om kompilatorn s˚a att beräkningarna sker med lägre overhead kan man titta p˚a vad som kan skalas bort. Uppenbarligen kan funktionsanropet skippas. Kvar blir 17 cykler, ett overhead p˚a ungefär 29%. Utför man m˚anga instruktioner p˚a en g˚ang eller om man dedikerar ett register till flyttalsenhetens basadress s˚a g˚ar overhead mot

(50)

Instruktion Tids˚atg˚ang [cykler] calli 1 mvhi 1 ori 1 sw 1 sw 1 sw 1 lw 12 mv 1 ret 1

Tabell 3.2: Tids˚atg˚ang f¨or minnesmappad flyttalsaddition.

25% och en tids˚atg˚ang p˚a 15 cykler för en flyttalsoperation. För flyttalsopera-tioner av samma typ eller med samma indata sjunker tids˚atg˚angen ytterliga-re, men förutsätter man godtyckliga operationer blir minimala tids˚atg˚angen 15 cykler. I jämförelse med flyttalsberäkningar i MicroBlaze som exekverar en flyttalsoperation var fjärde cykel är tids˚atg˚angen allts˚a i bästa fall nästan fyra g˚anger s˚a hög.

1 f l o a t a d d s f 3 ( f l o a t A, f l o a t B) 2 { 3 f l o a t r e t ; 4 asm v o l a t i l e ( 5 ”mvhi r3 , 0 x8000 \n\ t ” 6 ” o r i r3 , r3 , 0 x0100 \n\ t ” 7 ”sw ( r 3 +12) , r 0 \n\ t ” 8 ”sw ( r 3 +16) ,%1\n\ t ” 9 ”sw ( r 3 +20) ,%2\n\ t ” 10 ” lw %0 ,( r 3 +0)” 11 : ”=r ” ( ∗ ( ( f l o a t ∗) &r e t ) )

12 : ” r ” ( ∗ ( ( unsigned int ∗) &A) ) , 13 ” r ” ( ∗ ( ( unsigned int ∗) &B) ) 14 : ” r 3 ” ) ;

15 return r e t ; 16 }

(51)

1 00010244 < a d d s f 3 >: 2 1 0 2 4 4 : 78 03 80 00 mvhi r3 , 0 x8000 3 1 0 2 4 8 : 38 63 01 00 o r i r3 , r3 , 0 x100 4 1024 c : 58 60 00 0 c sw ( r 3 +12) , r 0 5 1 0 2 5 0 : 58 61 00 10 sw ( r 3 +16) , r 1 6 1 0 2 5 4 : 58 62 00 14 sw ( r 3 +20) , r 2 7 1 0 2 5 8 : 28 64 00 00 lw r4 , ( r 3 +0) 8 1025 c : b8 80 08 00 mv r1 , r 4 9 1 0 2 6 0 : c3 a0 00 00 r e t 10 . . . 11 1049 c : 2b 62 f f f 8 lw r2 , ( f p +−8) 12 104 a0 : 2b 61 f f f c lw r1 , ( f p +−4) 13 104 a4 : f b f f f f 68 c a l l i 10244 < a d d s f 3 > 14 104 a8 : 5b 61 00 00 sw ( f p +0) , r 1

Kodexempel 3.4: Disassemblering av kodexempel 3.3 efter inf¨orandet av funk-tionerna i kodexempel 3.5.

3.4 Instruktionsgr¨

anssnitt

Den största anledningen till att den minnesmappade implementationen av flyttalsaccelerering presterar d˚aligt är att all in- och utdata m˚aste flyttas mellan processorns register och flyttalsacceleratorn för varje beräkning. En bättre lösning skulle vara att flyttalsacceleratorn läser och skriver indata direkt mot processorns register. Det g˚ar att ˚astadkomma genom att använda

user-gr¨anssnittet hos processorn.

Instruktionsarkitekturen hos Mico32 definierar instruktionen user med ett register som utargument, tv˚a register och en elvabitars operationskod som inargument, ett exempel ges i kodexempel 3.6. När userinstruktionen ex-ekverar läggs data fr˚an inargumenten ut p˚a en port hos processorn samtidigt som utsignalen user valid g˚ar hög. Pipelinen i processorn stoppas sedan tills insignalen user ready detekteras. Därefter flyttas data fr˚an inporten user resultin i det register som angavs som utargument för instruktionen. Genom att implementera ett gränsnitt mellan flyttalsacceleratorn och user-funktionaliteten i processorn kan flyttalsacceleratorn användas utan att flytta flyttalsdata fram och tillbaks. I figur 3.2 visas var user-gränssnittet för flyttalsenheten passar in i processorns pipeline. Det gränssnittet gör är att synkronisera in- och utdata mellan flyttalsenheten och processorns klock-domäner samt generera user ready-signalen när beräkningen är klar.

(52)

R e g i s t e r f i l F e t c h D e c o d e I n s t r . -m i n n e D e b u g -m i n n e E x e c u t e M e m o r y W r i t e b a c k D a t a W B I n s t r . W B R e g i s t e r b y p a s s D a t a -m i n n e B y p a s s , m i n n e U a r t G P I O F P U

Figur 3.2: Mico32:s pipeline efter inf¨orandet av flyttalsacceleratorn via user-gr¨anssnit.

(53)

1 u s e r r3 , r1 , r2 , 0

Kodexempel 3.6: Assemblerkod f¨or addition med flyttalsinstruktion.

1 00010244 < a d d s f 3 >: 2 1 0 2 4 4 : c c 22 18 00 u s e r r3 , r1 , r2 , 0 x0 3 1 0 2 4 8 : b8 60 08 00 mv r1 , r 3 4 1024 c : c3 a0 00 00 r e t 5 . . . 6 1049 c : 2b 62 f f f 8 lw r2 , ( f p +−8) 7 104 a0 : 2b 61 f f f c lw r1 , ( f p +−4) 8 104 a4 : f b f f f f 68 c a l l i 10244 < a d d s f 3 > 9 104 a8 : 5b 61 00 00 sw ( f p +0) , r 1

Kodexempel 3.7: Disassemblering av kodexempel 3.3 efter kompilering med accelererade funktioner enligt exempel 3.8.

ser ut i assembler. Nu behöver operanderna inte flyttas till flyttalsenhetens register innan operationen utförs. P˚a samma sätt som tidigare kan man in-tegrera den här lösningen med C-spr˚akets flyttalstyper genom att byta ut anropen till mjukvaruberäkningarna. I listningen 3.7 har resulterande ma-skinkod disassemblerats. Utöver instruktionen som utför flyttalsberäkningen är det nu bara själva funktionsanropet som utgör overhead.

1 f l o a t a d d s f 3 ( f l o a t A, f l o a t B) 2 {

3 f l o a t r e t ;

4 asm v o l a t i l e ( ” u s e r %0,%1,%2,0”

5 : ”=r ” ( ∗ ( ( f l o a t ∗) &r e t ) )

6 : ” r ” ( ∗ ( ( unsigned int ∗) &A) ) ,

7 ” r ” ( ∗ ( ( unsigned int ∗) &B) ) ) ;

8 return r e t ; 9 }

(54)

3.5 Kompilatorst¨

od

Genom introduktionen av usergränssnittet i avsnitt 3.4 kan accelererade talsberäkningar utföras med en enda assemblerinstruktion. Hittills har flyt-talsberäkningar i C implementerats genom att ersätta anropen till SoftFloats rutiner. Det innebär ocks˚a att för varje flyttalsberäkning finns ett onödigt overhead i form av ett funktionsanrop. En bättre lösning är istället att l˚ata kompilatorn översätta aritmetik med inbyggda flyttalstyper i C till motsva-rande user-instruktioner. Det innebär att kompilatorn behöver kompletteras med stöd för flyttalsinstruktioner i form av user-instruktionerna. För att först˚a hur det g˚ar till ges här först en kort översikt över hur kompilatorn genererar maskinkod fr˚an C-kod. GCC behandlar programkod i följande tre övergripande steg:

• Parsning av k¨allkod i front end • Optimering i middle end

• Generering av maskinkod i back end

F¨or varje programmeringsspr˚ak som kompilatorn st¨odjer finns ett front

end och f¨or varje instruktionsarkitektur ett back end. Delarna i GCC som h¨or

till Mico32-porten ˚aterfinns t.ex. i ett back end ben¨amnt lm32.

Parsning av källkod sker med hjälp av ett antal olika front ends som översätter respektive programspr˚ak till AST-format (abstract syntax tree), det här formatet översätts sedan till generic-formatet som är det gemensam-ma representationsforgemensam-mat som alla front end genererar.

Efter att en generic-representation har genererats sker optimering av pro-gramkoden, först via den interna representationen GIMPLE och sedan via ännu en intern representation vid namn SSA. Efter att optimeringar p˚a SSA-niv˚a genomförts s˚a konverteras koden ˚ater igen till GIMPLE.

Efter det genereras fr˚an den slutgiltiga GIMPLE-representationen med hjälp av back end en RTL-representation. RTL är sedan det representations-formatet som används av back end för att generera assemblerkod för den aktuella processortypen. Det är i det här steget; översättningen fr˚an RTL till assemblerkod, som komplettering krävs för att generera flyttalsinstruktioner. I GCC finns ett speciellt spr˚ak för beskrivning av processorns instruk-tionsuppsättning, olika delenheter och pipelinestruktur. S˚adana här beskriv-ningar ges för respektive plattform i MD-filer (machine description) som utgör en del av back end för en port av GCC.

RTL-representationen har redan information om när en flyttalsoperation utförs s˚a det som behöver läggas till är en definition av hur en flyttalsopera-tion fr˚an RTL-representationen ska matchas mot en flyttalsinstruktion. Finns

(55)

det ingen s˚adan mappning kommer flyttalsoperationen att ers¨attas med ett anrop till l¨amplig mjukvarurutin fr˚an biblioteket SoftFloat.

I kodexempel 3.9 finns ett exempel p˚a en tillagd definition som genererar en user-instruktion. Här definieras en flyttalsaddition med enkel precision där b˚ada operanderna samt resultatet är av enkel precision. Bivillkoren är att m˚aloperanden ska vara ett generellt register (rad 2), källoperanderna skall vara antingen tv˚a generella register eller ett generellt register och värdet noll (rad 3-6). Om en operand har värdet noll kommer den att bytas ut mot registret r0 som alltid inneh˚aller värdet noll. Assemblerinstruktionen som matas ut f˚ar en user-operationskod som motsvarar operationskoden för addition i flyttalsenheten (rad 8).

1 ( d e f i n e i n s n ” a d d s f 3 ” 2 [ ( s e t ( match operand : SF 0 ” r e g i s t e r o p e r a n d ” ”=r ” ) 3 ( p l u s : SF ( match operand : SF 1 4 ” r e g i s t e r o r z e r o o p e r a n d ” ”%rJ ” ) 5 ( match operand : SF 2 6 ” r e g i s t e r o p e r a n d ” ” r ” ) ) ) ]

7 ”TARGET HARD FLOAT”

8 ” u s e r %0, %z1 , %2, 0” 9 [ ( s e t a t t r ” type ” ” f l o a t ” ) ] 10 )

Kodexempel 3.9: Definition av flyttalsinstruktion i MD-fil.

I kodexempel 3.9 finns ytterligare ett bivillkor (rad 7), nämligen att TARGET HARD FLOATskall vara satt för att instruktionen ska genereras. Detta gör att man vid kompileringstillfället kan sl˚a av och p˚a generering av flyttals-instruktioner med ett argument till kompilatorn (-mhard-float). För att f˚a den funktionaliteten krävdes ocks˚a ett par triviala ändringar i övriga delar av back end samt i assembleraren GAS i Binutils.

I kodexempel 3.10 finns ett exempel p˚a resulterande assemblerkod när kodexempel 3.3 kompilerats med den modifierade versionen av GCC. Själva flyttalsberäkningen utförs nu p˚a rad 4 utan overhead fr˚an funktionsanrop. Tids˚atg˚angen för flyttalsoperationen utgörs nu enbart av den tid det tar för acceleratorn att utföra beräkningen.