Korskompilator

Programutförande
Allmänna begrepp
Typer av kod
Sammanställningsstrategier
Anmärkningsvärda körtider
Anmärkningsvärda kompilatorer och verktygskedjor

En korskompilator är en kompilator som kan skapa körbar kod för en annan plattform än den som kompilatorn körs på. Till exempel är en kompilator som körs på en PC men genererar kod som körs på en Android - smarttelefon en korskompilator.

En korskompilator är användbar för att kompilera kod för flera plattformar från en utvecklingsvärd. Direkt kompilering på målplattformen kan vara omöjlig, till exempel på inbyggda system med begränsade datorresurser.

Korskompilatorer skiljer sig från källa-till-källa-kompilatorer . En korskompilator är för plattformsoberoende mjukvarugenerering av maskinkod, medan en källa-till-källa-kompilator översätter från ett kodningsspråk till ett annat i textkod. Båda är programmeringsverktyg .

Använda sig av

Den grundläggande användningen av en korskompilator är att separera byggmiljön från målmiljön. Detta är användbart i flera situationer:

  • Inbäddade datorer där en enhet har mycket begränsade resurser. Till exempel kommer en mikrovågsugn att ha en extremt liten dator för att läsa dess knappsats och dörrsensor, ge utsignal till en digital display och högtalare och för att styra mikrovågsugnen för matlagning. Den här datorn är i allmänhet inte tillräckligt kraftfull för att köra en kompilator, ett filsystem eller en utvecklingsmiljö.
  • Kompilera för flera maskiner. Ett företag kan till exempel vilja stödja flera olika versioner av ett operativsystem eller att stödja flera olika operativsystem. Genom att använda en korskompilator kan en enda byggmiljö ställas in för att kompilera för vart och ett av dessa mål.
  • Kompilera på en serverfarm . På samma sätt som att kompilera för flera maskiner, kan en komplicerad konstruktion som involverar många kompileringsoperationer köras på vilken maskin som helst som är gratis, oavsett dess underliggande hårdvara eller operativsystemversionen som den körs.
  • Bootstrapping till en ny plattform. När man utvecklar mjukvara för en ny plattform, eller emulatorn för en framtida plattform, använder man en korskompilator för att kompilera nödvändiga verktyg som operativsystemet och en inbyggd kompilator.
  • Kompilerar inbyggd kod för emulatorer för äldre nu föråldrade plattformar som Commodore 64 eller Apple II av entusiaster som använder korskompilatorer som körs på en aktuell plattform (som Aztec C:s MS-DOS 6502 korskompilatorer som körs under Windows XP ).

Användning av virtuella maskiner (som Javas JVM ) löser några av orsakerna till att korskompilatorer utvecklades. Paradigmet för virtuella maskiner tillåter att samma kompilatorutdata används över flera målsystem, även om detta inte alltid är idealiskt eftersom virtuella maskiner ofta är långsammare och det kompilerade programmet bara kan köras på datorer med den virtuella maskinen.

Vanligtvis skiljer sig hårdvaruarkitekturen (t.ex. kodning av ett program avsett för MIPS-arkitekturen på en x86 -dator) men korskompilering är också användbar när endast operativsystemsmiljön skiljer sig, som när man kompilerar ett FreeBSD- program under Linux , eller till och med bara systembiblioteket , som när man kompilerar program med uClibc på en glibc- värd.

kanadensiska korset

Canadian Cross är en teknik för att bygga korskompilatorer för andra maskiner, där originalmaskinen är mycket långsammare eller mindre bekväm än målet. Med tanke på tre maskiner A, B och C, använder man maskin A (t.ex. kör Windows XP på en IA-32- processor) för att bygga en korskompilator som körs på maskin B (t.ex. kör Mac OS X på en x86-64 -processor) för att skapa körbara filer för maskin C (t.ex. kör Android på en ARM- processor). Den praktiska fördelen i det här exemplet är att maskin A är långsam men har en proprietär kompilator, medan maskin B är snabb men inte har någon kompilator alls, och maskin C är opraktisk långsam för att användas för kompilering.

När du använder det kanadensiska korset med GCC, och som i detta exempel, kan det vara fyra kompilatorer inblandade

  • Den egenutvecklade inbyggda kompilatorn för maskin A (1) (t.ex. kompilator från Microsoft Visual Studio ) används för att bygga den ursprungliga gcc-kompilatorn för maskin A (2) .
  • Den inbyggda gcc-kompilatorn för maskin A (2) används för att bygga gcc-korskompilatorn från maskin A till maskin B (3)
  • Gcc- korskompilatorn från maskin A till maskin B (3) används för att bygga gcc-korskompilatorn från maskin B till maskin C (4)

Example of Canadian Cross, scheme

Slutresultatkorskompilatorn (4) kommer inte att kunna köras på byggmaskin A; istället skulle den köras på maskin B för att kompilera en applikation till körbar kod som sedan skulle kopieras till maskin C och köras på maskin C.

Till exempel tillhandahåller NetBSD ett POSIX Unix- skalskript som heter build.sh som först kommer att bygga sin egen verktygskedja med värdens kompilator; detta kommer i sin tur att användas för att bygga korskompilatorn som kommer att användas för att bygga hela systemet.

Termen Canadian Cross kom till för att vid den tidpunkt då dessa frågor diskuterades hade Kanada tre nationella politiska partier.

Tidslinje för tidiga korskompilatorer

  • 1979 – ALGOL 68C genererade ZCODE ; detta hjälpte till att porta kompilatorn och andra ALGOL 68-applikationer till alternativa plattformar. För att kompilera ALGOL 68C kompilatorn krävdes cirka 120 KB minne. Med Z80 är dess 64 KB minne för litet för att faktiskt kompilera kompilatorn. Så för Z80 var själva kompilatorn tvungen att korskompileras från den större CAP-kapacitetsdatorn eller en IBM System/370 stordator.

GCC och korskompilering

GCC , en gratis samling av kompilatorer, kan ställas in för att korskompilera. Den stöder många plattformar och språk.

GCC kräver att en kompilerad kopia av binutils är tillgänglig för varje riktad plattform. Särskilt viktig är GNU Assembler . Därför måste binutils först kompileras korrekt med switchen --target=some-target skickad till konfigureringsskriptet . GCC måste också konfigureras med samma --target- alternativ. GCC kan sedan köras normalt förutsatt att verktygen som Binutils skapar är tillgängliga i sökvägen , vilket kan göras med följande (på UNIX-liknande operativsystem med bash): 

PATH=/path/to/binutils/bin:${PATH} fabrikat

Korskompilering av GCC kräver att en del av målplattformens C - standardbibliotek är tillgängligt på värdplattformen . Programmeraren kan välja att kompilera hela C-biblioteket, men detta val kan vara opålitligt. Alternativet är att använda newlib , som är ett litet C-bibliotek som endast innehåller de viktigaste komponenterna som krävs för att kompilera C -källkod.

GNU autotools -paketen (dvs autoconf , automake och libtool ) använder begreppet en byggplattform , en värdplattform och en målplattform . Byggplattformen är där kompilatorn faktiskt kompileras . I de flesta fall bör build lämnas odefinierad (det kommer som standard från värd). Värdplattformen är alltid där utdataartefakterna från kompilatorn kommer att exekveras oavsett om utdatan är en annan kompilator eller inte . Målplattformen används vid korskompilering av korskompilatorer, den representerar vilken typ av objektkod paketet kommer att producera ; annars är målplattformsinställningen irrelevant. Överväg till exempel att korskompilera ett videospel som kommer att köras på en Dreamcast . Maskinen där spelet kompileras är byggplattformen medan Dreamcast är värdplattformen . Namnen värd och mål är relativa till kompilatorn som används och skiftas som son och sonson .

En annan metod som populärt används av inbäddade Linux-utvecklare involverar kombinationen av GCC-kompilatorer med specialiserade sandlådor som Scratchbox, scratchbox2 eller PROot . Dessa verktyg skapar en " chrooted " sandlåda där programmeraren kan bygga upp nödvändiga verktyg, libc och bibliotek utan att behöva ange extra sökvägar. Det finns också faciliteter för att "lura" körtiden så att den "tror" att den faktiskt körs på den avsedda mål-CPU (som en ARM-arkitektur); detta gör att konfigurationsskript och liknande kan köras utan fel. Scratchbox går långsammare jämfört med "icke-chrootade" metoder, och de flesta verktyg som finns på värden måste flyttas till Scratchbox för att fungera.

Manx Aztec C korskompilatorer

Manx Software Systems, Shrewsbury , New Jersey , producerade C-kompilatorer med början på 1980-talet riktade till professionella utvecklare för en mängd olika plattformar upp till och inklusive PC och Mac .

Manx Aztec C - programmeringsspråk var tillgängligt för en mängd olika plattformar inklusive MS-DOS , Apple II , DOS 3.3 och ProDOS , Commodore 64 , Mac 68k och Amiga .

Från 1980-talet och fortsatte under hela 1990-talet tills Manx Software Systems försvann, erbjöds MS-DOS-versionen av Aztec C både som en kompilator för native mode eller som en korskompilator för andra plattformar med olika processorer inklusive Commodore 64 och Apple II. Internetdistributioner finns fortfarande för Aztec C inklusive deras MS-DOS-baserade korskompilatorer. De är fortfarande i bruk idag.

Manx's Aztec C86, deras native mode 8086 MS-DOS kompilator, var också en korskompilator. Även om den inte kompilerade kod för en annan processor som deras Aztec C65 6502 korskompilatorer för Commodore 64 och Apple II, skapade den binära körbara filer för då äldre operativsystem för 16-bitars 8086-familjen av processorer.

När IBM PC introducerades för första gången var den tillgänglig med ett urval av operativsystem, CP/M-86 och PC DOS var två av dem. Aztec C86 försågs med länkbibliotek för att generera kod för båda IBM PC- operativsystemen. Under hela 1980-talet lade senare versioner av Aztec C86 (3.xx, 4.xx och 5.xx) stöd för MS-DOS "övergående" versioner 1 och 2 och som var mindre robusta än "baseline" MS-DOS version 3 och senare som Aztec C86 riktade in sig på fram till dess bortgång.

Slutligen försåg Aztec C86 C-språkutvecklare med möjligheten att producera ROM-kompatibel "HEX" -kod som sedan kunde överföras med en ROM-brännare direkt till en 8086-baserad processor. Paravirtualisering kan vara vanligare idag men bruket att skapa ROM-kod på låg nivå var vanligare per capita under de åren då utveckling av drivrutiner ofta gjordes av applikationsprogrammerare för enskilda applikationer, och nya enheter uppgick till en stugindustri . Det var inte ovanligt att applikationsprogrammerare gränssnitt direkt med hårdvara utan stöd från tillverkaren. Denna praxis liknade inbyggd systemutveckling idag.

Thomas Fenwick och James Goodnow II var de två främsta utvecklarna av Aztec-C. Fenwick blev senare känd som författare till Microsoft Windows CE- kärnan eller NK ("New Kernel") som den då kallades.

Microsoft C korskompilatorer

Tidig historia – 1980-talet

Microsoft C (MSC) har en kortare historia än andra som går tillbaka till 1980-talet. De första Microsoft C-kompilatorerna gjordes av samma företag som gjorde Lattice C och döptes om av Microsoft till sina egna, tills MSC 4 släpptes, vilket var den första versionen som Microsoft producerade själva.

1987 började många utvecklare byta till Microsoft C, och många fler skulle följa under utvecklingen av Microsoft Windows till dess nuvarande tillstånd. Produkter som Clipper och senare Clarion dök upp som erbjöd enkel utveckling av databasapplikationer genom att använda tvärspråkstekniker, vilket gjorde att delar av deras program kunde kompileras med Microsoft C.

Borland C (företag i Kalifornien) var tillgängligt för köp flera år innan Microsoft släppte sin första C-produkt.

Långt innan Borland hade BSD Unix (Berkeley University) fått C från författarna till C-språket: Kernighan och Ritchie som skrev det unisont medan de arbetade för AT&T (labs). K&R:s ursprungliga behov var inte bara elegant tolkad syntax på 2:a nivån för att ersätta asm tolkad syntax på 1:a nivå: den designades så att en minimal mängd asm skrivs för att stödja varje plattform (den ursprungliga designen av C var möjligheten att korskompilera med C med minst stödkod per plattform, som de behövde.). Även gårdagens C är direkt relaterad till ASM-kod där den inte är plattformsberoende. Dagens C (mer-så c++) är inte längre C-kompatibel och den bakomliggande asm-koden kan vara extremt annorlunda än skriven på en given plattform (i Linux: den ersätter och omväger ibland bibliotekssamtal med distributörsval). Dagens C är ett 3:e eller 4:e nivå språk som används på det gamla sättet som ett 2:a nivå språk.

1987

C-program hade länge varit kopplade till moduler skrivna på assemblerspråk . De flesta C-kompilatorer (även nuvarande kompilatorer) erbjuder ett pass för assemblerspråk (som kan justeras för effektivitet och sedan kopplas till resten av programmet efter montering).

Kompilatorer som Aztec-C konverterade allt till assemblerspråk som ett distinkt pass och satte sedan ihop koden i ett distinkt pass, och noterades för sin mycket effektiva och lilla kod, men 1987 var optimeraren inbyggd i Microsoft C mycket bra, och endast "uppdragskritiska" delar av ett program övervägdes vanligtvis för omskrivning. Faktum är att C-språkprogrammering hade tagit över som språket på "lägsta nivån", med programmering som blev en multidisciplinär tillväxtindustri och projekten blev större, med programmerare som skrev användargränssnitt och databasgränssnitt på högre språk, och ett behov hade framkommit för tvärspråksutveckling som fortsätter till denna dag.

År 1987, med lanseringen av MSC 5.1, erbjöd Microsoft en utvecklingsmiljö för flera språk för MS-DOS. 16-bitars binär objektkod skriven i assemblerspråk ( MASM ) och Microsofts andra språk inklusive QuickBASIC , Pascal och Fortran kunde länkas samman till ett program, i en process som de kallade "Mixed Language Programming" och nu "InterLanguage Calling". Om BASIC användes i denna blandning, behövde huvudprogrammet finnas i BASIC för att stödja det interna runtime-systemet som kompilerade BASIC som krävs för sophämtning och dess andra hanterade operationer som simulerade en BASIC- tolk som QBasic i MS-DOS.

Den anropande konventionen för C-kod, i synnerhet, var att skicka parametrar i "omvänd ordning" på stacken och returnera värden på stacken snarare än i ett processorregister . Det fanns andra programmeringsregler för att få alla språk att fungera tillsammans, men just denna regel kvarstod genom den tvärspråksutveckling som fortsatte under hela Windows 16- och 32-bitarsversioner och i utvecklingen av program för OS/2 , och som fortsätter med detta dag. Det är känt som Pascals kallelsekonvention .

En annan typ av korskompilering som Microsoft C användes för under denna tid var i detaljhandelsapplikationer som kräver handhållna enheter som Symbol Technologies PDT3100 (används för att ta inventering ), som gav ett länkbibliotek riktat till en 8088- baserad streckkodsläsare . Applikationen byggdes på värddatorn och överfördes sedan till den handhållna enheten (via en seriell kabel ) där den kördes, liknande det som görs idag för samma marknad med Windows Mobile av företag som Motorola , som köpte Symbol.

Början av 1990-talet

Under hela 1990-talet och med början med MSC 6 (deras första ANSI C- kompatibla kompilator) fokuserade Microsoft om sina C-kompilatorer på den framväxande Windows-marknaden, och även på OS/2 och i utvecklingen av GUI -program. Blandspråkskompatibilitet förblev genom MSC 6 på MS-DOS-sidan, men API: et för Microsoft Windows 3.0 och 3.1 skrevs i MSC 6. MSC 6 utökades också för att ge stöd för 32-bitars sammansättningar och stöd för de framväxande Windows for Workgroups och Windows NT som skulle utgöra grunden för Windows XP . En programmeringspraxis som kallas thunk introducerades för att tillåta överföring mellan 16- och 32-bitarsprogram som utnyttjade runtime-bindning ( dynamisk länkning ) snarare än den statiska bindning som gynnades i monolitiska 16-bitars MS-DOS-applikationer. Statisk bindning gynnas fortfarande av vissa inhemska kodutvecklare men ger i allmänhet inte den grad av kodåteranvändning som krävs av nyare bästa praxis som Capability Maturity Model (CMM).

MS-DOS-stöd gavs fortfarande med lanseringen av Microsofts första C++-kompilator, MSC 7, som var bakåtkompatibel med C-programmeringsspråket och MS-DOS och stödde både 16- och 32-bitars kodgenerering.

MSC tog över där Aztec C86 slutade. Marknadsandelen för C-kompilatorer hade övergått till korskompilatorer som utnyttjade de senaste och bästa Windows-funktionerna, erbjöd C och C++ i ett enda paket och fortfarande stödde MS-DOS-system som redan var ett decennium gamla, och de mindre företagen som producerade kompilatorer som Aztec C kunde inte längre konkurrera och vände sig antingen till nischmarknader som inbyggda system eller försvann.

Stödet för MS-DOS och 16-bitars kodgenerering fortsatte fram till MSC 8.00c som levererades med Microsoft C++ och Microsoft Application Studio 1.5, föregångaren till Microsoft Visual Studio som är den korsutvecklingsmiljö som Microsoft tillhandahåller idag.

Sent 1990-tal

MSC 12 släpptes med Microsoft Visual Studio 6 och gav inte längre stöd för MS-DOS 16-bitars binärer, istället gav stöd för 32-bitars konsolapplikationer, men gav stöd för Windows 95 och Windows 98 kodgenerering samt för Windows NT . Länkbibliotek var tillgängliga för andra processorer som körde Microsoft Windows; en praxis som Microsoft fortsätter till denna dag.

MSC 13 släpptes med Visual Studio 2003 och MSC 14 släpptes med Visual Studio 2005 , som båda fortfarande producerar kod för äldre system som Windows 95, men som kommer att producera kod för flera målplattformar inklusive mobilmarknaden och ARM- arkitekturen .

.NET och vidare

2001 utvecklade Microsoft Common Language Runtime (CLR), som utgjorde kärnan för deras .NET Framework- kompilator i Visual Studio IDE. Detta lager på operativsystemet som finns i API :et tillåter blandning av utvecklingsspråk kompilerade över plattformar som kör Windows operativsystem.

.NET Framework runtime och CLR tillhandahåller ett mappningslager till kärnrutinerna för processorn och enheterna på måldatorn. Kommandoradskompilatorn C i Visual Studio kommer att kompilera inbyggd kod för en mängd olika processorer och kan användas för att bygga själva kärnrutinerna.

Microsoft .NET-applikationer för målplattformar som Windows Mobile på ARM-arkitekturen korskompileras på Windows-datorer med en mängd olika processorer och Microsoft erbjuder även emulatorer och fjärrinstallationsmiljöer som kräver väldigt lite konfiguration, till skillnad från korskompilatorerna förr eller senare andra plattformar.

Runtime-bibliotek, som Mono , tillhandahåller kompatibilitet för korskompilerade .NET-program till andra operativsystem, som Linux .

Bibliotek som Qt och dess föregångare, inklusive XVT , tillhandahåller möjlighet till korsutveckling på källkodsnivå med andra plattformar, medan de fortfarande använder Microsoft C för att bygga Windows-versionerna. Andra kompilatorer som MinGW har också blivit populära inom detta område eftersom de är mer direkt kompatibla med Unixerna som utgör icke-Windows-sidan av mjukvaruutveckling, vilket gör att dessa utvecklare kan rikta in sig på alla plattformar med en välbekant byggmiljö.

Gratis Pascal

Free Pascal utvecklades från början som en korskompilator. Den körbara kompilatorn (ppcXXX där XXX är en målarkitektur) kan producera körbara filer (eller bara objektfiler om ingen intern länk existerar, eller till och med bara assemblerfiler om ingen intern assembler finns) för alla operativsystem med samma arkitektur. Till exempel kan ppc386 producera körbara filer för i386-linux, i386-win32, i386-go32v2 (DOS) och alla andra operativsystem (se ). För att kompilera till en annan arkitektur måste dock en korsarkitekturversion av kompilatorn byggas först. Den resulterande körbara kompilatorn skulle ha ytterligare "ross" före målarkitekturen i dess namn. dvs om kompilatorn är byggd för att rikta x64, så skulle den körbara filen vara ppcrossx64.

För att kompilera för ett valt arkitektur-OS kan kompilatorväxeln (för kompilatordrivrutinen fpc) -P och -T användas. Detta görs även vid korskompilering av själva kompilatorn, men ställs in via make option CPU_TARGET och OS_TARGET. GNU assembler och länkare för målplattformen krävs om Free Pascal ännu inte har en intern version av verktygen för målplattformen.

Klang

Clang är naturligt en korskompilator, vid byggtiden kan du välja vilka arkitekturer du vill att Clang ska kunna rikta in sig på.

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Cross_compiler&oldid=1134768936 "