De manière généralement admise, la compilation consiste à traduire un programme écrit dans un langage de haut niveau (ie. compréhensible par humain, comme le C), en instructions interprétables par le CPU (ie. une suite d'octets, du 'code binaire').
Je vais chipoter. :) Un compilateur traduit un langage (quel que soit le niveau) vers un autre langage. Généralement oui, on part d'un langage qui a un plus haut niveau d'abstraction vers un langage qui propose un niveau d'abstraction plus bas1. Mais ce n'est pas obligatoire.
Traduire d'un langage à un autre (eg. prendre un programme écrit en Go, et émttre du code C) n'est généralement pas considéré comme de la compilation.
Autant la phrase précédente j'estime que je chipotais, autant là je ne chipote pas : traduire du Go en C est de la compilation, définitivement.
Une chaîne de compilation (vue de très très loin), ça ressemble à ça :
Langage source -> Front-End -> IR de haut niveau -> Middle-End -> IR de bas niveau -> Back-End
Très souvent tout un tas d'optimisations de bas-niveau sont opérées aussi au niveau du back-end.
C'est « tout ». Il n'est dit nulle part qu'on ne pourrait pas compiler (par exemple) d'un langage assembleur x86 vers un langage assembleur Itanium (si ce n'est que ce serait quand même 'achement difficile d'un point de vue technique, mais c'est faisable).
[1] Par exemple, OCaml a pendant un certain temps compilé d'abord vers C, puis utilisé gcc comme « backend » vers du code natif.
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par lasher . En réponse au journal Chaine(s) de compilation ARM. Évalué à 3.
Je vais chipoter. :) Un compilateur traduit un langage (quel que soit le niveau) vers un autre langage. Généralement oui, on part d'un langage qui a un plus haut niveau d'abstraction vers un langage qui propose un niveau d'abstraction plus bas1. Mais ce n'est pas obligatoire.
Autant la phrase précédente j'estime que je chipotais, autant là je ne chipote pas : traduire du Go en C est de la compilation, définitivement.
Une chaîne de compilation (vue de très très loin), ça ressemble à ça :
Langage source -> Front-End -> IR de haut niveau -> Middle-End -> IR de bas niveau -> Back-End
En détails, ça donne :
Langage source -> Front-End (Analyse lexicale -> analyse syntaxique -> analyse sémantique) -> génération de représentation intermédiaire, appelée IR (par exemple sous forme de représentation « graphique » comme un arbre de syntaxe abstrait)
IR -> middle-end (qui transforme l'IR avec des passes successives, pour optimiser certains accès, transformer les boucles, etc.) -> IR de bas niveau
IR de bas niveau (généralement on est passé d'un AST à une représentation proche d'une sorte d'assembleur de très bas niveau — contenant souvent plus d'infos que ce que la cible peut représenter) -> Back-End (sélection d'instruction -> ordonnancement d'instruction -> allocation de registres)
Très souvent tout un tas d'optimisations de bas-niveau sont opérées aussi au niveau du back-end.
C'est « tout ». Il n'est dit nulle part qu'on ne pourrait pas compiler (par exemple) d'un langage assembleur x86 vers un langage assembleur Itanium (si ce n'est que ce serait quand même 'achement difficile d'un point de vue technique, mais c'est faisable).
[1] Par exemple, OCaml a pendant un certain temps compilé d'abord vers C, puis utilisé gcc comme « backend » vers du code natif.