Compilateur source à source

Un traducteur source-à-source , un compilateur source-à-source ( compilateur S2S ), un transcompilateur ou un transpileur est un type de traducteur qui prend le code source d'un programme écrit dans un langage de programmation comme entrée et produit un code source équivalent dans le même langage de programmation ou dans un langage différent. Un traducteur source-à-source convertit entre des langages de programmation qui fonctionnent à peu près au même niveau d' abstraction , tandis qu'un compilateur traditionnel traduit d'un langage de programmation de niveau supérieur vers un langage de programmation de niveau inférieur . Par exemple, un traducteur source-à-source peut effectuer une traduction d'un programme de Python vers JavaScript , tandis qu'un compilateur traditionnel traduit d'un langage comme C vers l'assembleur ou Java vers le bytecode . Un compilateur de parallélisation automatique prendra fréquemment un programme en langage de haut niveau comme entrée, puis transformera le code et l'annotera avec des annotations de code parallèles (par exemple, OpenMP ) ou des constructions de langage (par exemple , les instructions de Fortranforall ).

Un autre objectif de la compilation source-à-source est de traduire le code existant pour utiliser la prochaine version du langage de programmation sous-jacent ou une API qui rompt la compatibilité ascendante. Elle effectuera une refactorisation automatique du code , ce qui est utile lorsque les programmes à refactoriser sont hors du contrôle de l'implémenteur d'origine (par exemple, la conversion de programmes de Python 2 à Python 3, ou la conversion de programmes d'une ancienne API à la nouvelle API) ou lorsque la taille du programme rend son refactorisation manuelle peu pratique ou longue.

Les transcompilateurs peuvent soit conserver la structure du code traduit aussi proche que possible du code source pour faciliter le développement et le débogage du code source d'origine, soit modifier la structure du code d'origine à tel point que le code traduit ne ressemble pas au code source. Il existe également des utilitaires de débogage qui mappent le code source transcompilé au code d'origine ; par exemple, la norme JavaScript Source Map permet de mapper le code JavaScript exécuté par un navigateur Web vers la source d'origine lorsque le code JavaScript a été, par exemple, minifié ou produit par un langage transcompilé en JavaScript.

Les exemples incluent Closure Compiler , CoffeeScript , Dart , Haxe , Opal, TypeScript et Emscripten .

Les traducteurs de langage assembleur sont une classe de traducteurs source à source convertissant le code d'un langage assembleur vers un autre, y compris (mais sans s'y limiter) sur différentes familles de processeurs et plates-formes système .

Intel a commercialisé son processeur 16 bits 8086 pour être compatible avec le 8080 , un processeur 8 bits. Pour prendre en charge cela, Intel avait un traducteur basé sur ISIS-II du code source 8080 vers 8086 nommé CONV86 (également appelé CONV-86 et CONVERT 86 ) disponible pour les clients OEM depuis 1978, probablement le premier programme de ce type. Il prenait en charge plusieurs niveaux de traduction et fonctionnait à 2 MHz sur un système de développement de microprocesseur Intel MDS-800 avec des lecteurs de disquettes de 8 pouces . Selon les rapports des utilisateurs, il ne fonctionnait pas de manière très fiable.

Seattle Computer Products (SCP) a proposé TRANS86.COM, écrit par Tim Paterson en 1980 lors du développement de 86-DOS . L'utilitaire pouvait traduire le code source d'assemblage Intel 8080 et Zilog Z80 (avec les mnémoniques Zilog/ Mostek ) en code source .ASM pour l'Intel 8086 (dans un format uniquement compatible avec l' assembleur croisé ASM86 de SCP pour CP/M-80 ), mais ne prenait en charge qu'un sous-ensemble d' opcodes , de registres et de modes, et nécessitait souvent encore des corrections manuelles et des retouches importantes par la suite. De plus, n'effectuant qu'une simple translittération , traducteur à passage unique à force brute n'effectuait aucune optimisation de registre et de saut. Il prenait environ 24 Ko de RAM. La version SCP 1 de TRANS86.COM fonctionnait sur des systèmes basés sur Z80. Une fois que 86-DOS était en cours d'exécution, Paterson, dans une approche inspirée de l'auto-hébergement , a utilisé TRANS86 pour se convertir en un programme fonctionnant sous 86-DOS. Numérotée version 2, elle a été nommée TRANS.COM à la place. Plus tard en 1982, le traducteur était apparemment également disponible auprès de Microsoft .

Également appelé TRANS86, Sorcim proposait également un traducteur 8080 vers 8086 depuis décembre 1980. Comme le programme de SCP, il a été conçu pour porter le code d'application CP/M-80 (au format d'assemblage ASM, MAC, RMAC ou ACT80) vers MS-DOS (dans un format compatible avec ACT86). Au format ACT80, il prenait également en charge quelques mnémoniques Z80. La traduction s'effectuait instruction par instruction avec une certaine optimisation appliquée aux sauts conditionnels. Le programme fonctionnait sous CP/M-80, MP/M-80 et Cromemco DOS avec un minimum de 24 Ko de RAM et n'avait aucune restriction sur la taille du fichier source.

Beaucoup plus sophistiqué et le premier à introduire des technologies de compilation d'optimisation dans le processus de traduction de source était XLT86 1.0 de Digital Research en septembre 1981. XLT86 1.1 était disponible en avril 1982. Le programme a été écrit par Gary Kildall et a traduit le code source .ASM pour le processeur Intel 8080 (dans un format compatible avec les assembleurs ASM, MAC ou RMAC) en code source .A86 pour le 8086 (compatible avec ASM86). Français En utilisant l'analyse globale du flux de données sur l'utilisation du registre 8080, multi-passe à cinq phases optimiserait également la sortie pour la taille du code et prendrait en charge les conventions d'appel ( les appels BDOS CP/M-80 ont été mappés dans les appels BDOS pour CP/M-86 ), de sorte que les programmes CP/M-80 et MP/M-80 pourraient être portés automatiquement sur les plates-formes CP/M-86 et MP/M-86 . XLT86.COM lui-même a été écrit en PL/I-80 pour les plates-formes CP/M-80. Le programme occupait 30 Ko de RAM pour lui-même plus de la mémoire supplémentaire pour le graphique du programme . Sur un système de mémoire de 64 Ko, la taille maximale du fichier source prise en charge était d'environ 6 Ko, de sorte que les fichiers plus volumineux devaient être décomposés en conséquence avant la traduction. Alternativement, XLT86 était également disponible pour DEC VAX/VMS . Bien que l'entrée et la sortie de XLT86 fonctionnaient au niveau du code source, la représentation en mémoire du programme par le traducteur et les technologies d'optimisation de code appliquées ont posé les bases de la recompilation binaire .

2500 AD Software a proposé un traducteur de code source 8080 à 8086 dans le cadre de sa suite XASM pour les machines CP/M-80 avec Z80 ainsi que pour les systèmes Zilog ZEUS et Olivetti PCOS .

Depuis 1979, Zilog a proposé un traducteur Z80 vers Z8000 dans le cadre de son système de développement PDS 8000. Advanced Micro Computers (AMC) et 2500 AD Software ont également proposé des traducteurs Z80 vers Z8000. Ce dernier s'appelait TRANS et était disponible pour Z80 CP/M, CP/M-86, MS-DOS et PCOS.

Le kit de développement Z88DK fournit un convertisseur de code source Z80 vers i486 ciblant nasm nommé « to86.awk », écrit en 2008 par Stefano Bodrato. Il est à son tour basé sur un convertisseur 8080 vers Z80 écrit en 2003 par Douglas Beattie, Jr., nommé « toz80.awk ».

En 2021, Brian Callahan a écrit un traducteur de code source 8080 CP/M 2.2 vers MS-DOS ciblant nasm nommé 8088ify.

Les premières implémentations de certains langages de programmation ont commencé comme des transcompilateurs, et l'implémentation par défaut de certains de ces langages est toujours des transcompilateurs. En plus du tableau ci-dessous, un responsable de CoffeeScript fournit une liste de langages qui compilent en JavaScript.

Lorsque les développeurs souhaitent passer à un autre langage tout en conservant la majeure partie d'une base de code existante, il peut être préférable d'utiliser un transcompilateur plutôt que de réécrire l'intégralité du logiciel à la main. Selon la qualité du transcompilateur, le code peut nécessiter ou non une intervention manuelle pour fonctionner correctement. Cela diffère des « langages transcompilés » où les spécifications exigent que le code source de sortie fonctionne toujours sans modification. Tous les transcompilateurs utilisés pour porter une base de code s'attendent à un ajustement manuel du code source de sortie s'il est nécessaire d'obtenir une qualité de code maximale en termes de lisibilité et de convention de plate-forme.

Un pipeline de transcompilation est le résultat d' une transcompilation récursive . En enchaînant plusieurs couches de technologie, avec une étape de transcompilation entre chaque couche, la technologie peut être transformée à plusieurs reprises, créant ainsi une spécification distribuée indépendante du langage .

XSLT est un outil de transformation à usage général qui peut être utilisé entre de nombreuses technologies différentes, pour créer un tel pipeline de code dérivé .

La transcompilation récursive (ou transpilation récursive ) est le processus d'application de la notion de transcompilation de manière récursive, pour créer un pipeline de transformations (à partir souvent d'une seule source de vérité ) qui transforment à plusieurs reprises une technologie en une autre.

En répétant ce processus, on peut transformer A → B → C → D → E → F puis revenir à A(v2). Certaines informations seront préservées grâce à ce pipeline, de A → A(v2), et ces informations (à un niveau abstrait) démontrent sur quoi chacun des composants A–F s'accorde.

Dans chacune des différentes versions produites par le pipeline de transcompilation, ces informations sont conservées. Elles peuvent prendre de nombreuses formes et tailles différentes, mais au moment où elles reviennent à A (v2), après avoir été transcompilées six fois dans le pipeline ci-dessus, les informations reviennent à leur état d'origine.

Ces informations qui survivent à la transformation à travers chaque format, de A à F à A (v2), sont (par définition) un contenu dérivé ou un code dérivé .

La transcompilation récursive tire parti du fait que les transcompilateurs peuvent soit conserver le code traduit aussi proche que possible du code source pour faciliter le développement et le débogage du code source d'origine, soit modifier la structure du code d'origine à tel point que le code traduit ne ressemble plus au code source. Il existe également des utilitaires de débogage qui mappent le code source transcompilé au code d'origine ; par exemple, les mappages de sources JavaScript permettent de mapper le code JavaScript exécuté par un navigateur Web vers la source d'origine dans un langage transcompilé en JavaScript.