Křížový překladač - Cross compiler

Spuštění programu
Obecné pojmy
Typy kódu
Kompilační strategie
Pozoruhodné doby běhu
Pozoruhodné kompilátory a řetězce nástrojů

Kříž překladač je překladač schopen vytvořit spustitelný kód pro platformu než je ten, na kterém je spuštěna kompilátor. Například kompilátor, který běží na PC, ale generuje kód, který běží na smartphonu Android, je cross compiler.

Pro kompilaci kódu pro více platforem z jednoho vývojového hostitele je nutný křížový kompilátor. Přímá kompilace na cílové platformě může být neproveditelná, například na vestavěných systémech s omezenými výpočetními prostředky.

Křížové překladače se liší od překladačů typu zdroj-zdroj . Cross compiler je pro generování strojového kódu napříč platformami , zatímco překladač source-to-source překládá z jednoho programovacího jazyka do druhého v textovém kódu. Oba jsou programovací nástroje .

Použití

Zásadním využitím křížového kompilátoru je oddělení prostředí buildu od cílového prostředí. To je užitečné v několika situacích:

  • Vestavěné počítače, kde má zařízení extrémně omezené zdroje. Například mikrovlnná trouba bude mít extrémně malý počítač, který bude číst její klávesnici a dveřní senzor, poskytovat výstup na digitální displej a reproduktor a ovládat zařízení pro vaření jídla. Tento počítač obecně není dostatečně výkonný na to, aby spustil kompilátor, souborový systém nebo vývojové prostředí.
  • Kompilace pro více strojů. Společnost může například chtít podporovat několik různých verzí operačního systému nebo podporovat několik různých operačních systémů. Pomocí křížového kompilátoru lze nastavit prostředí pro sestavení pro kompilaci pro každý z těchto cílů.
  • Kompilace na serverové farmě . Podobně jako při kompilaci pro více počítačů lze složité sestavení, které zahrnuje mnoho kompilačních operací, provést na libovolném počítači, který je zdarma, bez ohledu na jeho základní hardware nebo verzi operačního systému, na kterém běží.
  • Bootstrapping na novou platformu. Při vývoji softwaru pro novou platformu nebo emulátor budoucí platformy se používá křížový kompilátor ke kompilaci potřebných nástrojů, jako je operační systém a nativní kompilátor.
  • Kompilace nativního kódu pro emulátory pro starší dnes již zastaralé platformy, jako je Commodore 64 nebo Apple II, nadšenci, kteří používají křížové kompilátory, které běží na aktuální platformě (například křížové kompilátory Az -C MS-DOS 6502 běžící pod Windows XP ).

Použití virtuálních počítačů (například JVM Javy ) řeší některé z důvodů, pro které byly vyvinuty křížové kompilátory. Paradigma virtuálního počítače umožňuje použít stejný výstup kompilátoru na více cílových systémech, i když to není vždy ideální, protože virtuální stroje jsou často pomalejší a kompilovaný program lze spustit pouze na počítačích s tímto virtuálním strojem.

Typicky se hardwarová architektura liší (např. Kompilace programu určeného pro architekturu MIPS na počítači x86 ), ale křížová kompilace je také použitelná, když se liší pouze prostředí operačního systému , jako při kompilaci programu FreeBSD pod Linuxem nebo dokonce jen v systémové knihovně , jako při kompilaci programů s uClibc na hostiteli glibc .

Kanadský kříž

Kanadský Kříž je technika pro vytváření křížových kompilátorů na jiných strojích. Vzhledem ke třem strojům A, B a C jeden používá stroj A (např. Běžící Windows XP na procesoru IA-32 ) k vytvoření křížového kompilátoru, který běží na počítači B (např. Běží Mac OS X na procesoru x86-64 ) k vytvářet spustitelné soubory pro počítač C (např. se systémem Android na procesoru ARM ). Při použití Kanadského kříže s GCC mohou být zapojeny čtyři překladače

  • Proprietární nativní kompilátor pro strojní A (1) (např překladač Microsoft Visual Studio ) se používá k vytvoření gcc nativní kompilátor pro stroje A (2) .
  • Gcc nativní překladač pro přístroje A (2) je použit k vytvoření gcc kompilátor kříže z přístroje A do zařízení B (3)
  • Gcc kříž překladač přístroje A do zařízení B (3) je použit k vytvoření gcc kompilátor kříže ze zařízení B na zařízení C (4)

Příklad Kanadského kříže, schéma

Křížový překladač konečných výsledků (4) nebude moci běžet na sestavovacím stroji A; místo toho by běželo na počítači B, aby zkompilovalo aplikaci do spustitelného kódu, který by pak byl zkopírován do počítače C a spuštěn na počítači C.

NetBSD například poskytuje skript POSIX Unix s názvem, build.shkterý nejprve vytvoří vlastní řetězec nástrojů s kompilátorem hostitele; to zase bude použito k vytvoření křížového kompilátoru, který bude použit k vytvoření celého systému.

Termín Kanadský kříž vznikl proto, že v době, kdy se o těchto problémech diskutovalo, měla Kanada tři národní politické strany.

Časová osa raných křížových kompilátorů

  • 1979 - ALCOL 68C generovaný ZCODE ; to pomohlo portování kompilátoru a dalších aplikací ALGOL 68 na alternativní platformy. Ke kompilaci kompilátoru ALGOL 68C bylo zapotřebí přibližně 120 kB paměti. U Z80 je jeho paměť 64 kB příliš malá na to, aby kompilátor skutečně zkompiloval. Pro Z80 tedy musel být samotný kompilátor křížově kompilován z většího počítače se schopností CAP nebo sálového počítače IBM System/370 .

GCC a křížová kompilace

GCC , bezplatnou softwarovou sbírku kompilátorů, lze nastavit pro křížovou kompilaci. Podporuje mnoho platforem a jazyků.

GCC vyžaduje, aby pro každou cílenou platformu byla k dispozici kompilovaná kopie binutils . Obzvláště důležitý je GNU Assembler . Proto musí být binutils nejprve správně kompilovány pomocí přepínače --target=some-targetodeslaného do konfiguračního skriptu . GCC také musí být nakonfigurován se stejnou --targetmožností. GCC pak lze spustit normálně za předpokladu, že jsou v cestě k dispozici nástroje, které vytváří binutils , což lze provést pomocí následujícího postupu (na operačních systémech podobných UNIX s bash): 

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

Cross-kompilace GCC vyžaduje, aby část cílovou platformu‘ je standardní knihovna C k dispozici na hostitelském nosiči . Programátor se může rozhodnout zkompilovat celou knihovnu C, ale tato volba může být nespolehlivá. Alternativou je použít newlib , což je malá C knihovna obsahující pouze nejnutnější komponenty potřebné ke kompilaci zdrojového kódu C.

Tyto GNU autotools obaly (tj autoconf , automake a libtool ) používají ponětí o sestavení platformy , na hostitele platformu a cílovou platformu . Platforma sestavení je místo, kde je kompilátor skutečně kompilován. Ve většině případů by build měl zůstat nedefinovaný (výchozí bude z hostitele). Hostitelská platforma je vždy tam, kde výstupní artefakty z kompilátor bude provedena, zda výstup je jiný kompilátor, nebo ne. Cílová platforma se používá při sestavování napříč přes kompilátory, to znamená, jaký typ objektového kódu samotném obalu bude vyrábět; jinak je nastavení cílové platformy irelevantní. Zvažte například křížovou kompilaci videohry, která poběží na Dreamcastu . Stroj, kde je hra kompilována, je platforma sestavení, zatímco Dreamcast je hostitelská platforma . Názvy host a target jsou relativní k použitému kompilátoru a posunuty jako syn a vnuk .

Další metodou populárně používají vývojáři embedded Linuxu zahrnuje kombinaci GCC se specializovanými pískovišť jako ScratchBox , scratchbox2 nebo PRoot . Tyto nástroje vytvářejí „ chrootované “ sandboxy, kde si programátor může vytvořit potřebné nástroje, libc a knihovny, aniž by musel nastavovat další cesty. Jsou také poskytována zařízení k „oklamání“ běhu, takže „věří“, že skutečně běží na zamýšleném cílovém CPU (jako je architektura ARM); to umožňuje konfigurační skripty a podobné spustit bez chyby. Scratchbox běží pomaleji ve srovnání s metodami „bez chrootování“ a většinu nástrojů, které jsou na hostiteli, je třeba přesunout do Scratchboxu, aby fungovaly.

Křížové kompilátory Manx Aztec C.

Manx Software Systems , Shrewsbury , New Jersey , vyráběl kompilátory C počínaje 80. léty zaměřené na profesionální vývojáře pro různé platformy až po PC a Mac včetně .

Programovací jazyk Manx Aztec C byl k dispozici pro různé platformy včetně MS-DOS , Apple II , DOS 3.3 a ProDOS , Commodore 64 , Macintosh 68XXX a Amiga .

Od 80. let 20. století až do vymizení Manx Software Systems byla verze Aztec C pro MS-DOS nabízena buď jako překladač nativního režimu, nebo jako křížový překladač pro jiné platformy s různými procesory včetně Commodore 64 a Apple II. Internetové distribuce pro Aztec C stále existují, včetně jejich křížových překladačů založených na systému MS-DOS. Používají se dodnes.

Manx's Aztec C86, jejich kompilátor 8086 MS-DOS v nativním režimu , byl také křížovým kompilátorem. Ačkoli nekompiloval kód pro jiný procesor, jako byly jejich křížové kompilátory Aztec C65 6502 pro Commodore 64 a Apple II, vytvořil binární spustitelné soubory pro tehdejší starší operační systémy pro 16bitovou rodinu procesorů 8086.

Když byl počítač IBM PC poprvé představen, byl k dispozici s výběrem operačních systémů, přičemž CP/M-86 a PC DOS jsou dva z nich. Aztec C86 byl vybaven propojovacími knihovnami pro generování kódu pro oba operační systémy IBM PC . V průběhu osmdesátých let novější verze Aztec C86 (3.xx, 4.xx a 5.xx) přidávaly podporu pro „přechodné“ verze 1 a 2 MS-DOS, které byly méně robustní než „základní“ MS-DOS verze 3 a později se Aztec C86 zaměřil až do svého zániku.

Nakonec Aztec C86 poskytl vývojářům jazyka C možnost vytvářet kód „HEX“ s podporou ROM, který pak mohl být přenesen pomocí vypalovačky ROM přímo do procesoru založeného na 8086. Paravirtualizace může být dnes běžnější, ale praxe vytváření nízkoúrovňového kódu ROM byla běžnější na jednoho obyvatele v těch letech, kdy vývoj ovladačů zařízení často prováděli programátoři aplikací pro jednotlivé aplikace a nová zařízení představovala domácí průmysl . Nebylo neobvyklé, že aplikační programátoři komunikovali přímo s hardwarem bez podpory od výrobce. Tato praxe byla dnes podobná vývoji Embedded Systems .

Thomas Fenwick a James Goodnow II byli dva hlavní vývojáři Aztec-C. Fenwick se později stal pozoruhodným autorem jádra Microsoft Windows CE nebo NK („New Kernel“), jak se mu tehdy říkalo.

Křížové kompilátory Microsoft C.

Raná historie - 80. léta 20. století

Microsoft C (MSC) má kratší historii než ostatní z 80. let minulého století. První kompilátory Microsoft C byly vyrobeny stejnou společností, která vyrobila Lattice C a byly přejmenovány společností Microsoft jako jejich vlastní, dokud nebyl vydán MSC 4, což byla první verze, kterou Microsoft sám vyrobil.

V roce 1987 začalo mnoho vývojářů přecházet na Microsoft C a mnoho dalších by následovalo během vývoje Microsoft Windows do současného stavu. Objevily se produkty jako Clipper a novější Clarion , které nabízely snadný vývoj databázových aplikací pomocí křížových jazykových technik, což umožnilo kompilaci části jejich programů s Microsoft C.

Borland C (kalifornská společnost) byl k dispozici ke koupi roky předtím, než společnost Microsoft vydala svůj první produkt C.

Dlouho před Borlandem získala BSD Unix (Berkeley University) C od autorů jazyka C: Kernighana a Ritchieho, kteří jej napsali souběžně při práci pro AT&T (laboratoře). Původní potřeby K & R nebyly jen elegantní syntaktickou syntaktickou syntézou 2. úrovně, která nahradila asm syntaktickou syntaxi 1. úrovně: byla navržena tak, aby na každou platformu bylo napsáno minimální množství asm (původní design C byl schopnost křížové kompilace pomocí C s nejméně podpůrný kód na platformu, který potřebovali.). Také včerejší C C přímo související s kódem ASM, kdekoli to není závislé na platformě. Dnešní C (více c ++) již není kompatibilní s C a kód ASM, který je podkladem, se může extrémně lišit od toho, co je napsáno na dané platformě (v Linuxu: někdy nahrazuje a obchází volání knihovny pomocí voleb distributora). Dnešní C je jazyk 3. nebo 4. úrovně, který se používá starým způsobem jako jazyk 2. úrovně.

1987

Programy C byly dlouho spojeny s moduly napsanými v jazyce sestavení . Většina kompilátorů C (dokonce i současných) nabízí přístup v jazyce sestavení (který lze efektivně upravit a poté po sestavení propojit se zbytkem programu).

Kompilátory jako Aztec-C převáděly vše na jazyk sestavení jako odlišný průchod a poté sestavily kód v odlišném průchodu a byly známé svým velmi efektivním a malým kódem, ale v roce 1987 byl optimalizátor zabudovaný do Microsoft C velmi dobrý a pouze „Přelomové“ části programu byly obvykle zvažovány k přepsání. Programování v jazyce C se ve skutečnosti ujalo jako jazyk „nejnižší úrovně“, přičemž programování se stalo multidisciplinárním odvětvím růstu a projekty se staly většími, přičemž programátoři psali uživatelská rozhraní a databázová rozhraní ve jazycích vyšší úrovně a bylo potřeba se objevily pro vývoj jazyků, který pokračuje dodnes.

V roce 1987, s vydáním MSC 5.1, Microsoft nabízel vývojové prostředí napříč jazyky pro MS-DOS. 16bitový binární objektový kód napsaný v assembleru ( MASM ) a dalších jazycích Microsoftu, včetně QuickBASIC , Pascal a Fortran, lze propojit dohromady do jednoho programu, v procesu, kterému říkali „Mixed Language Programming“ a nyní „InterLanguage Calling“. Pokud byl v tomto mixu použit BASIC , hlavní program musel být v BASICu, aby podporoval interní runtime systém, který kompiloval BASIC požadovaný pro sběr odpadu a jeho další spravované operace, které simulovaly BASIC interpreta jako QBasic v MS-DOS.

Konvence volání pro kód C, zvláště, byl předat parametry v „obráceném pořadí“ na zásobníku hodnoty a návratu na zásobníku spíše než v registru procesoru . Existovala jiná pravidla programování, aby všechny jazyky spolupracovaly, ale toto konkrétní pravidlo přetrvávalo ve vývoji více jazyků, který pokračoval v 16- a 32bitových verzích Windows a ve vývoji programů pro OS/2 , a který v tomto ohledu přetrvává den. Je známá jako Pascalova konvence volání .

Další typ křížové kompilace, pro který byl v této době použit Microsoft C, byl v maloobchodních aplikacích, které vyžadují ruční zařízení, jako je Symbol Technologies PDT3100 (používá se k inventarizaci ), který poskytoval knihovnu odkazů zaměřenou na čtečku čárových kódů založenou na 8088 . Aplikace byla postavena na hostitelském počítači a poté přenesena do ručního zařízení (pomocí sériového kabelu ), kde byla spuštěna, podobně jako to, co dnes na stejném trhu používají Windows Mobile společnosti jako Motorola , která koupila Symbol.

Brzy 1990

Skrz devadesátá léta a počínaje MSC 6 (jejich první kompilátor kompatibilní s ANSI C ) Microsoft znovu zaměřil své kompilátory C na rozvíjející se trh se systémem Windows a také na OS/2 a ve vývoji programů GUI . Kompatibilita se smíšeným jazykem zůstala přes MSC 6 na straně MS-DOS, ale API pro Microsoft Windows 3.0 a 3.1 bylo napsáno v MSC 6. MSC 6 byl také rozšířen, aby poskytoval podporu pro 32bitová sestavení a podporu pro nově vznikající Windows for Workgroups a Windows NT, které by tvořily základ pro Windows XP . Byla zavedena programovací praxe nazývaná thunk, která umožňovala procházení mezi 16 a 32bitovými programy, které využívaly výhody běhové vazby ( dynamické propojení ), a nikoli statické vazby, která byla upřednostňována v monolitických 16bitových aplikacích MS-DOS. Statická vazba je stále upřednostňována některými vývojáři nativních kódů, ale obecně neposkytuje stupeň opětovného použití kódu vyžadovaný novějšími osvědčenými postupy, jako je Capability Maturity Model (CMM).

Podpora MS-DOS byla stále poskytována s vydáním prvního kompilátoru C ++ společnosti Microsoft, MSC 7, který byl zpětně kompatibilní s programovacím jazykem C a MS-DOS a podporoval generování 16 i 32bitového kódu.

MSC převzal tam, kde Aztec C86 skončil. Tržní podíl kompilátorů C se obrátil na křížové kompilátory, které využívaly výhody nejnovějších a největších funkcí Windows, nabízely C a C ++ v jednom balíčku a stále podporovaly systémy MS-DOS, které byly již deset let staré, a menší společnosti, které vyrobené kompilátory jako Aztec C již nemohly konkurovat a buď se obrátily na specializované trhy jako vestavěné systémy, nebo zmizely.

Podpora generování MS-DOS a 16bitových kódů pokračovala až do MSC 8.00c, který byl dodáván s Microsoft C ++ a Microsoft Application Studio 1.5, předchůdcem Microsoft Visual Studio, což je prostředí pro vývoj napříč vývojy, které dnes Microsoft poskytuje.

Pozdní 1990

MSC 12 byl vydán s Microsoft Visual Studio 6 a již neposkytoval podporu pro 16bitové binární soubory MS-DOS, místo toho poskytoval podporu pro 32bitové konzolové aplikace, ale poskytoval podporu pro generování kódu Windows 95 a Windows 98 a také pro Windows NT . Pro další procesory se systémem Microsoft Windows byly k dispozici propojovací knihovny; praxe, kterou Microsoft pokračuje dodnes.

MSC 13 byl vydán s Visual Studio 2003 a MSC 14 byl vydán s Visual Studio 2005 , z nichž oba stále produkují kód pro starší systémy, jako je Windows 95, ale které budou produkovat kód pro několik cílových platforem včetně mobilního trhu a architektury ARM .

.NET a dále

V roce 2001 vyvinul Microsoft Common Language Runtime (CLR), který tvořil jádro pro jejich kompilátor .NET Framework v Visual Studio IDE. Tato vrstva v operačním systému, který je v API, umožňuje míchání vývojových jazyků kompilovaných napříč platformami, na kterých běží operační systém Windows.

Modul runtime .NET Framework a CLR poskytují mapovací vrstvu na základní rutiny pro procesor a zařízení v cílovém počítači. Kompilátor C příkazového řádku v aplikaci Visual Studio zkompilová nativní kód pro různé procesory a lze jej použít k sestavení základních rutin samotných.

Aplikace Microsoft .NET pro cílové platformy, jako je Windows Mobile, na architektuře ARM cross-compile na počítačích se systémem Windows s řadou procesorů a Microsoft také nabízí emulátory a prostředí vzdáleného nasazení, které vyžadují velmi malou konfiguraci, na rozdíl od křížových kompilátorů v minulých nebo minulých dnech jiné platformy.

Runtime knihovny, jako je Mono , poskytují kompatibilitu pro programy s rozhraním .NET s křížovým překladem do jiných operačních systémů, jako je Linux .

Knihovny jako Qt a jeho předchůdci včetně XVT poskytují možnost křížového vývoje na úrovni zdrojového kódu s jinými platformami, přičemž stále používají Microsoft C k vytváření verzí Windows. Ostatní kompilátory, jako je MinGW, se v této oblasti také staly populární, protože jsou přímo kompatibilní s Unixem, který zahrnuje vývoj softwaru mimo Windows, což umožňuje těmto vývojářům cílit na všechny platformy pomocí známého prostředí sestavení.

Zdarma Pascal

Free Pascal byl od začátku vyvinut jako křížový překladač. Spustitelný soubor kompilátoru (ppcXXX, kde XXX je cílová architektura) je schopen vytvářet spustitelné soubory (nebo pouze objektové soubory, pokud neexistuje žádný interní linker, nebo dokonce jen soubory sestav, pokud neexistuje žádný interní assembler) pro všechny operační systémy stejné architektury. Například ppc386 je schopen produkovat spustitelné soubory pro i386-linux, i386-win32, i386-go32v2 (DOS) a všechny ostatní OS (viz). Pro kompilaci do jiné architektury však musí být nejprve vytvořena verze kompilátoru mezi architekturami. Výsledný spustitelný soubor kompilátoru by měl před názvem cílové architektury další „ross“. tj. pokud je kompilátor sestaven tak, aby cílil na x64, pak by spustitelný soubor byl ppcrossx64.

Ke kompilaci pro zvolenou architekturu -OS lze použít přepínač kompilátoru (pro ovladač kompilátoru fpc) -P a -T. To se také provádí při křížovém kompilaci samotného kompilátoru, ale je nastaveno pomocí možnosti make CPU_TARGET a OS_TARGET. Pokud Free Pascal ještě nemá interní verzi nástrojů pro cílovou platformu, je vyžadován GNU assembler a linker pro cílovou platformu.

Zvonit

Clang je nativně křížový překladač, v době sestavení si můžete vybrat, na které architektury chcete, aby Clang mohl cílit.

Viz také

Reference

externí odkazy