Compilateur croisé - Cross compiler

Exécution du programme
Concepts généraux
Types de codes
Stratégies de compilation
Temps d'exécution notables
Compilateurs et chaînes d'outils notables

Un compilateur croisé est un compilateur capable de créer du code exécutable pour une plate - forme autre que celle sur laquelle le compilateur s'exécute. Par exemple, un compilateur qui s'exécute sur un PC mais génère du code qui s'exécute sur un smartphone Android est un compilateur croisé.

Un compilateur croisé est nécessaire pour compiler du code pour plusieurs plates-formes à partir d'un hôte de développement. La compilation directe sur la plate-forme cible peut être impossible, par exemple sur des systèmes embarqués avec des ressources informatiques limitées.

Les compilateurs croisés sont distincts des compilateurs source à source . Un compilateur croisé est destiné à la génération logicielle multiplateforme de code machine, tandis qu'un compilateur source à source traduit d'un langage de programmation à un autre en code texte. Les deux sont des outils de programmation .

Utilisation

L'utilisation fondamentale d'un compilateur croisé est de séparer l'environnement de construction de l'environnement cible. Ceci est utile dans plusieurs situations :

  • Ordinateurs embarqués où un périphérique a des ressources extrêmement limitées. Par exemple, un four à micro-ondes aura un ordinateur extrêmement petit pour lire son clavier et son capteur de porte, fournir une sortie à un affichage numérique et un haut-parleur, et pour contrôler les machines de cuisson des aliments. Cet ordinateur n'est généralement pas assez puissant pour exécuter un compilateur, un système de fichiers ou un environnement de développement.
  • Compilation pour plusieurs machines. Par exemple, une entreprise peut souhaiter prendre en charge plusieurs versions différentes d'un système d'exploitation ou prendre en charge plusieurs systèmes d'exploitation différents. En utilisant un compilateur croisé, un seul environnement de construction peut être configuré pour compiler pour chacune de ces cibles.
  • Compilation sur une batterie de serveurs . Semblable à la compilation pour plusieurs machines, une construction compliquée qui implique de nombreuses opérations de compilation peut être exécutée sur n'importe quelle machine gratuite, quel que soit son matériel sous-jacent ou la version du système d'exploitation qu'elle exécute.
  • Amorçage vers une nouvelle plate-forme. Lors du développement d'un logiciel pour une nouvelle plate-forme, ou l'émulateur d'une future plate-forme, on utilise un compilateur croisé pour compiler les outils nécessaires tels que le système d'exploitation et un compilateur natif.
  • Compilation de code natif pour les émulateurs pour les anciennes plates-formes désormais obsolètes comme le Commodore 64 ou Apple II par des passionnés qui utilisent des compilateurs croisés qui s'exécutent sur une plate-forme actuelle (comme les compilateurs croisés MS-DOS 6502 d' Aztec C fonctionnant sous Windows XP ).

L'utilisation de machines virtuelles (telles que la JVM de Java ) résout certaines des raisons pour lesquelles les compilateurs croisés ont été développés. Le paradigme de la machine virtuelle permet d'utiliser la même sortie de compilateur sur plusieurs systèmes cibles, bien que ce ne soit pas toujours idéal car les machines virtuelles sont souvent plus lentes et le programme compilé ne peut être exécuté que sur des ordinateurs avec cette machine virtuelle.

En règle générale, l' architecture matérielle diffère (par exemple, la compilation d'un programme destiné à l' architecture MIPS sur un ordinateur x86 ) mais la compilation croisée est également applicable lorsque seul l' environnement du système d'exploitation diffère, comme lors de la compilation d'un programme FreeBSD sous Linux , ou même simplement la bibliothèque système , comme lors de la compilation de programmes avec uClibc sur un hôte glibc .

Croix canadienne

La croix canadienne est une technique de construction de compilateurs croisés pour d'autres machines. Étant donné trois machines A, B et C, on utilise la machine A (ex. exécutant Windows XP sur un processeur IA-32 ) pour construire un compilateur croisé qui s'exécute sur la machine B (ex. exécutant Mac OS X sur un processeur x86-64 ) pour créer des exécutables pour la machine C (ex. exécuter Android sur un processeur ARM ). Lors de l'utilisation de la Croix canadienne avec GCC, quatre compilateurs peuvent être impliqués

  • Le compilateur natif propriétaire pour la machine A (1) (par exemple le compilateur de Microsoft Visual Studio ) est utilisé pour construire le compilateur natif gcc pour la machine A (2) .
  • Le compilateur natif gcc pour la machine A (2) est utilisé pour construire le compilateur croisé gcc de la machine A à la machine B (3)
  • Le compilateur croisé gcc de la machine A à la machine B (3) est utilisé pour construire le compilateur croisé gcc de la machine B à la machine C (4)

Exemple de croix canadienne, schéma

Le compilateur croisé des résultats finaux (4) ne pourra pas s'exécuter sur la machine de construction A ; à la place, il s'exécuterait sur la machine B pour compiler une application en code exécutable qui serait ensuite copié sur la machine C et exécuté sur la machine C.

Par exemple, NetBSD fournit un script shell POSIX Unix nommé build.shqui construira d'abord sa propre chaîne d' outils avec le compilateur de l'hôte ; ceci, à son tour, sera utilisé pour construire le compilateur croisé qui sera utilisé pour construire l'ensemble du système.

Le terme Croix canadienne est apparu parce qu'au moment où ces questions étaient en discussion, le Canada comptait trois partis politiques nationaux.

Chronologie des premiers compilateurs croisés

  • 1979 – ALGOL 68C a généré le ZCODE ; cela a aidé à porter le compilateur et d'autres applications ALGOL 68 vers d'autres plates-formes. Pour compiler le compilateur ALGOL 68C, il fallait environ 120 Ko de mémoire. Avec le Z80, sa mémoire de 64 Ko est trop petite pour réellement compiler le compilateur. Ainsi, pour le Z80, le compilateur lui-même a dû être compilé à partir d'un ordinateur à capacité CAP plus grande ou d'un ordinateur central IBM System/370 .

GCC et compilation croisée

GCC , une collection de logiciels libres de compilateurs, peut être configuré pour une compilation croisée. Il prend en charge de nombreuses plates-formes et langues.

GCC exige qu'une copie compilée de binutils soit disponible pour chaque plate-forme ciblée. L' assembleur GNU est particulièrement important . Par conséquent, binutils doit d'abord être compilé correctement avec le commutateur --target=some-targetenvoyé au script configure . GCC doit également être configuré avec la même --targetoption. GCC peut ensuite être exécuté normalement à condition que les outils créés par binutils soient disponibles dans le chemin , ce qui peut être fait en utilisant ce qui suit (sur les systèmes d'exploitation de type UNIX avec bash): 

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

GCC compilation croisée exige qu'une partie de la plate - forme cible » de la bibliothèque standard C sera disponible sur la plate - forme hôte . Le programmeur peut choisir de compiler la bibliothèque C complète, mais ce choix pourrait ne pas être fiable. L'alternative consiste à utiliser newlib , qui est une petite bibliothèque C contenant uniquement les composants les plus essentiels requis pour compiler le code source C.

Les GNU autotools paquets ( par exemple autoconf , automake et libtool ) utilisent la notion d'une plate - forme de construction , une plate - forme hôte , et une plate - forme cible . La plate - forme de construction est l'endroit où le compilateur est réellement compilé. Dans la plupart des cas, la construction doit être laissée non définie (elle sera par défaut de l'hôte). La plate - forme hôte est toujours l'endroit où les artefacts de sortie du compilateur seront exécutés, que la sortie soit un autre compilateur ou non. La plate - forme cible est utilisée lors de la compilation croisée de compilateurs croisés, elle représente le type de code objet que le package lui-même produira ; sinon, le paramètre de la plate-forme cible n'est pas pertinent. Par exemple, envisagez la compilation croisée d'un jeu vidéo qui fonctionnera sur une Dreamcast . La machine sur laquelle le jeu est compilé est la plate-forme de construction tandis que la Dreamcast est la plate-forme hôte . Les noms hôte et cible sont relatifs au compilateur utilisé et déplacés comme fils et petit - fils .

Une autre méthode couramment utilisée par les développeurs Linux embarqués implique la combinaison de compilateurs GCC avec des bacs à sable spécialisés comme Scratchbox , scratchbox2 ou PRoot . Ces outils créent un bac à sable « chrooté » où le programmeur peut créer les outils, libc et bibliothèques nécessaires sans avoir à définir des chemins supplémentaires. Des fonctionnalités sont également fournies pour « tromper » le moteur d'exécution afin qu'il « croie » qu'il s'exécute réellement sur le processeur cible prévu (comme une architecture ARM) ; cela permet aux scripts de configuration et autres de s'exécuter sans erreur. Scratchbox s'exécute plus lentement par rapport aux méthodes "non chrootées", et la plupart des outils qui se trouvent sur l'hôte doivent être déplacés dans Scratchbox pour fonctionner.

Compilateurs croisés Manx Aztec C

Manx Software Systems , de Shrewsbury , New Jersey , a produit des compilateurs C à partir des années 1980 destinés aux développeurs professionnels pour une variété de plates - formes jusqu'aux PC et Mac inclus .

Le langage de programmation Aztec C de Manx était disponible pour une variété de plates - formes, notamment MS-DOS , Apple II , DOS 3.3 et ProDOS , Commodore 64 , Macintosh 68XXX et Amiga .

Depuis les années 1980 et tout au long des années 1990 jusqu'à la disparition de Manx Software Systems, la version MS-DOS d'Aztec C a été proposée à la fois comme compilateur en mode natif ou comme compilateur croisé pour d'autres plates-formes avec différents processeurs, notamment le Commodore 64 et Apple II. Des distributions Internet existent toujours pour Aztec C, y compris leurs compilateurs croisés basés sur MS-DOS. Ils sont encore en usage aujourd'hui.

Aztec C86 de Manx, leur compilateur MS-DOS 8086 en mode natif , était également un compilateur croisé. Bien qu'il n'ait pas compilé de code pour un processeur différent comme leurs compilateurs croisés Aztec C65 6502 pour le Commodore 64 et Apple II, il a créé des exécutables binaires pour les systèmes d'exploitation hérités de la famille de processeurs 8086 16 bits.

Lorsque l'IBM PC a été introduit pour la première fois, il était disponible avec un choix de systèmes d'exploitation, CP/M-86 et PC DOS étant deux d'entre eux. Aztec C86 a été fourni avec des bibliothèques de liens pour générer du code pour les deux systèmes d'exploitation IBM PC . Tout au long des années 1980, les versions ultérieures d'Aztec C86 (3.xx, 4.xx et 5.xx) ont ajouté la prise en charge des versions "transitoires" MS-DOS 1 et 2 et qui étaient moins robustes que les versions MS-DOS "de base" 3 et plus tard que l'Aztec C86 a ciblé jusqu'à sa disparition.

Enfin, Aztec C86 fourni aux développeurs de langage C avec la capacité de produire une ROM « HEX » le code qui pourrait ensuite être transféré à l' aide d' un graveur de ROM directement à un processeur à base de 8086. La paravirtualisation est peut-être plus courante aujourd'hui, mais la pratique consistant à créer du code ROM de bas niveau était plus courante par habitant pendant ces années où le développement de pilotes de périphériques était souvent effectué par des programmeurs d'applications pour des applications individuelles, et les nouveaux périphériques constituaient une industrie artisanale . Il n'était pas rare que les programmeurs d'applications s'interfacent directement avec le matériel sans l'assistance du fabricant. Cette pratique était similaire au développement de systèmes embarqués aujourd'hui.

Thomas Fenwick et James Goodnow II étaient les deux principaux développeurs d'Aztec-C. Fenwick est devenu plus tard notable en tant qu'auteur du noyau Microsoft Windows CE ou NK ("Nouveau noyau") comme on l'appelait alors.

Compilateurs croisés Microsoft C

Histoire ancienne – années 1980

Microsoft C (MSC) a une histoire plus courte que d'autres, remontant aux années 1980. Les premiers compilateurs Microsoft C ont été fabriqués par la même société qui a fabriqué Lattice C et ont été rebaptisés par Microsoft, jusqu'à la sortie de MSC 4, qui était la première version produite par Microsoft.

En 1987, de nombreux développeurs ont commencé à passer à Microsoft C, et bien d'autres suivront tout au long du développement de Microsoft Windows jusqu'à son état actuel. Des produits comme Clipper et plus tard Clarion ont émergé qui offraient un développement facile d'applications de base de données en utilisant des techniques multi-langages, permettant à une partie de leurs programmes d'être compilés avec Microsoft C.

Borland C (société californienne) était disponible à l'achat des années avant que Microsoft ne publie son premier produit C.

Bien avant Borland, BSD Unix (Berkeley University) avait obtenu le C des auteurs du langage C : Kernighan et Ritchie qui l'ont écrit à l'unisson tout en travaillant pour AT&T (laboratoires). Les besoins initiaux de K&R n'étaient pas seulement une élégante syntaxe analysée de 2ème niveau pour remplacer la syntaxe analysée de 1er niveau asm : elle a été conçue pour qu'une quantité minimale d'asm soit écrite pour prendre en charge chaque plate-forme (la conception originale de C était la possibilité de compiler en utilisant C avec le moins de code de support par plate-forme, dont ils avaient besoin.). Hier également, le C directement lié au code ASM partout où il ne dépend pas de la plate-forme. Le C d'aujourd'hui (plus c++) n'est plus compatible avec le C et le code asm sous-jacent peut être extrêmement différent de celui écrit sur une plate-forme donnée (sous Linux : il remplace et détourne parfois les appels de bibliothèques par des choix de distributeurs). Le C d'aujourd'hui est un langage de 3e ou 4e niveau qui est utilisé à l'ancienne comme un langage de 2e niveau.

1987

Les programmes C étaient depuis longtemps liés à des modules écrits en langage assembleur . La plupart des compilateurs C (même les compilateurs actuels) offrent un pass en langage assembleur (qui peut être modifié pour plus d'efficacité puis lié au reste du programme après l'assemblage).

Des compilateurs comme Aztec-C ont tout converti en langage assembleur en tant que passe distincte, puis ont assemblé le code en une passe distincte, et ont été connus pour leur code très efficace et petit, mais en 1987, l'optimiseur intégré à Microsoft C était très bon, et seulement Les parties « critiques à la mission » d'un programme étaient généralement envisagées pour une réécriture. En fait, la programmation en langage C était devenue le langage de "niveau le plus bas", la programmation devenant une industrie de croissance multidisciplinaire et les projets devenant de plus en plus importants, les programmeurs écrivant des interfaces utilisateur et des interfaces de base de données dans des langages de niveau supérieur, et un besoin s'était fait sentir. a émergé pour le développement de la langue qui se poursuit à ce jour.

En 1987, avec la sortie de MSC 5.1, Microsoft proposait un environnement de développement multilingue pour MS-DOS. Le code objet binaire 16 bits écrit en langage assembleur ( MASM ) et les autres langages de Microsoft, notamment QuickBASIC , Pascal et Fortran, pourraient être liés ensemble dans un seul programme, dans un processus qu'ils ont appelé "Programmation en langage mixte" et maintenant "Appel interlangue". Si BASIC était utilisé dans ce mélange, le programme principal devait être en BASIC pour prendre en charge le système d'exécution interne qui a compilé BASIC requis pour le ramasse-miettes et ses autres opérations gérées qui simulaient un interpréteur BASIC comme QBasic dans MS-DOS.

La convention d'appel pour le code C, en particulier, consistait à passer les paramètres dans "l'ordre inverse" sur la pile et à renvoyer les valeurs sur la pile plutôt que dans un registre de processeur . Il y avait d'autres règles de programmation pour faire fonctionner tous les langages ensemble, mais cette règle particulière a persisté à travers le développement multilingue qui s'est poursuivi dans les versions Windows 16 et 32 ​​bits et dans le développement de programmes pour OS/2 , et qui persiste jusqu'à présent journée. Elle est connue sous le nom de convention d'appel Pascal .

Un autre type de compilation croisée pour lequel Microsoft C a été utilisé à cette époque était dans les applications de vente au détail nécessitant des appareils portables tels que le Symbol Technologies PDT3100 (utilisé pour faire l' inventaire ), qui fournissait une bibliothèque de liens destinée à un lecteur de codes à barres basé sur 8088 . L'application a été construite sur l'ordinateur hôte puis transférée vers l'appareil portable (via un câble série ) où elle a été exécutée, similaire à ce qui est fait aujourd'hui pour ce même marché en utilisant Windows Mobile par des sociétés comme Motorola , qui a acheté Symbol.

Début des années 90

Tout au long des années 1990 et en commençant par MSC 6 (leur premier compilateur conforme ANSI C ), Microsoft a recentré ses compilateurs C sur le marché émergent de Windows, ainsi que sur OS/2 et le développement de programmes GUI . La compatibilité des langues mixtes est restée via MSC 6 du côté MS-DOS, mais l' API pour Microsoft Windows 3.0 et 3.1 a été écrite en MSC 6. MSC 6 a également été étendu pour fournir la prise en charge des assemblys 32 bits et la prise en charge de l'émergence de Windows pour les groupes de travail. et Windows NT qui constituerait la base de Windows XP . Une pratique de programmation appelée thunk a été introduite pour permettre le passage entre des programmes 16 et 32 ​​bits qui tiraient parti de la liaison d'exécution (liaison dynamique ) plutôt que de la liaison statique qui était favorisée dans les applications MS-DOS 16 bits monolithiques . La liaison statique est toujours privilégiée par certains développeurs de code natif, mais ne fournit généralement pas le degré de réutilisation du code requis par les meilleures pratiques plus récentes telles que le modèle de maturité des capacités (CMM).

La prise en charge de MS-DOS était toujours fournie avec la sortie du premier compilateur C++ de Microsoft, MSC 7, qui était rétrocompatible avec le langage de programmation C et MS-DOS et prenait en charge la génération de code 16 et 32 ​​bits.

MSC a repris là où l' Aztec C86 s'était arrêté. La part de marché des compilateurs C s'était tournée vers les compilateurs croisés qui tiraient parti des fonctionnalités les plus récentes et les plus performantes de Windows, offraient C et C++ dans un seul ensemble, et prenaient toujours en charge les systèmes MS-DOS qui avaient déjà dix ans, et les petites entreprises qui les compilateurs produits comme Aztec C ne pouvaient plus rivaliser et se sont tournés vers des marchés de niche comme les systèmes embarqués ou ont disparu.

La prise en charge de la génération de code MS-DOS et 16 bits s'est poursuivie jusqu'à MSC 8.00c, qui était fourni avec Microsoft C++ et Microsoft Application Studio 1.5, le précurseur de Microsoft Visual Studio qui est l'environnement de développement croisé que Microsoft fournit aujourd'hui.

Fin des années 90

MSC 12 a été publié avec Microsoft Visual Studio 6 et ne prenait plus en charge les binaires MS-DOS 16 bits, mais prenait plutôt en charge les applications console 32 bits, mais prenait en charge la génération de code Windows 95 et Windows 98 ainsi que Windows NT . Les bibliothèques de liens étaient disponibles pour d'autres processeurs exécutant Microsoft Windows ; une pratique que Microsoft continue à ce jour.

MSC 13 a été publié avec Visual Studio 2003 et MSC 14 a été publié avec Visual Studio 2005 , qui produisent toujours du code pour des systèmes plus anciens comme Windows 95, mais qui produiront du code pour plusieurs plates-formes cibles, notamment le marché mobile et l' architecture ARM .

.NET et au-delà

En 2001, Microsoft a développé le Common Language Runtime (CLR), qui a constitué le noyau de leur compilateur .NET Framework dans l'IDE Visual Studio. Cette couche sur le système d'exploitation qui se trouve dans l' API permet le mélange de langages de développement compilés sur des plates-formes qui exécutent le système d'exploitation Windows.

Le runtime .NET Framework et le CLR fournissent une couche de mappage aux routines principales pour le processeur et les périphériques sur l'ordinateur cible. Le compilateur C de ligne de commande dans Visual Studio compilera le code natif pour une variété de processeurs et peut être utilisé pour créer les routines de base elles-mêmes.

Les applications Microsoft .NET pour les plates-formes cibles telles que Windows Mobile sur l' architecture ARM se compilent sur des machines Windows avec une variété de processeurs et Microsoft propose également des émulateurs et des environnements de déploiement à distance qui nécessitent très peu de configuration, contrairement aux compilateurs croisés d'autrefois ou d'aujourd'hui. autres plateformes.

Les bibliothèques d'exécution, telles que Mono , assurent la compatibilité des programmes .NET compilés de manière croisée avec d'autres systèmes d'exploitation, tels que Linux .

Des bibliothèques comme Qt et ses prédécesseurs, y compris XVT, offrent une capacité de développement croisé au niveau du code source avec d'autres plates-formes, tout en utilisant Microsoft C pour créer les versions de Windows. D'autres compilateurs comme MinGW sont également devenus populaires dans ce domaine car ils sont plus directement compatibles avec les Unix qui constituent le côté non Windows du développement logiciel, permettant à ces développeurs de cibler toutes les plates-formes à l'aide d'un environnement de construction familier.

Pascal libre

Free Pascal a été développé dès le début en tant que compilateur croisé. L'exécutable du compilateur (ppcXXX où XXX est une architecture cible) est capable de produire des exécutables (ou simplement des fichiers objets si aucun éditeur de liens interne n'existe, ou même simplement des fichiers d'assemblage si aucun assembleur interne n'existe) pour tous les OS de la même architecture. Par exemple, ppc386 est capable de produire des exécutables pour i386-linux, i386-win32, i386-go32v2 (DOS) et tous les autres systèmes d'exploitation (voir ). Pour compiler vers une autre architecture, cependant, une version inter-architecture du compilateur doit être construite en premier. L'exécutable du compilateur résultant aurait un 'ross' supplémentaire avant l'architecture cible dans son nom. c'est-à-dire que si le compilateur est conçu pour cibler x64, alors l'exécutable serait ppcrossx64.

Pour compiler pour une architecture-OS choisie, les commutateurs de compilateur (pour le pilote de compilateur fpc) -P et -T peuvent être utilisés. Ceci est également effectué lors de la compilation croisée du compilateur lui-même, mais est défini via l'option make CPU_TARGET et OS_TARGET. L'assembleur et l'éditeur de liens GNU pour la plate-forme cible sont requis si Free Pascal n'a pas encore de version interne des outils pour la plate-forme cible.

Bruit

Clang est nativement un compilateur croisé, au moment de la construction, vous pouvez sélectionner les architectures que vous souhaitez que Clang puisse cibler.

Voir également

Les références

Liens externes