Présentation
Auteur(s)
-
Bernard LORHO : Professeur à l’Université d’Évry Val d’Essonne - Département d’informatique
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleINTRODUCTION
La compilation, c’est‐à‐dire la traduction automatisée d’un texte écrit dans un langage de programmation en un texte équivalent dans un autre langage de programmation, est née avec l’informatique. En effet, il est très vite apparu qu’il n’était pas raisonnable de programmer des applications d’une certaine taille et d’une certaine complexité dans les langages rudimentaires que sont les langages machines ou les langages d’assemblage. La raison de base de cette difficulté est simple : ces langages sont modelés sur la structure des machines et sur leur organisation, alors que les utilisateurs ont besoin de mécanismes d’expression qui soient du plus haut niveau possible et adaptés à la formulation de leurs problèmes.
De plus, la nécessité est vite apparue de viser une certaine portabilité qui permette d’écrire des programmes qui soient indépendants d’une machine donnée pour pouvoir les transporter facilement sur une autre machine. La portabilité est devenue une réalité économique forte condamnant la programmation de bas niveau. Celle‐ci n’a pas complètement disparu mais se cantonne à des domaines tout à fait spécialisés où il est indispensable de maîtriser le fonctionnement intime d’une machine.
On peut en fait dire qu’il y a nécessairement compilation dès qu’un programme est écrit. Cela implique que tout utilisateur de l’informatique compile, sans en être conscient dans la plupart des cas, comme M. Jourdain faisait de la prose...
Les langages de programmation ont commencé à se multiplier dès les débuts de l’informatique, certains se spécialisant dans des domaines d’application particuliers, d’autres essayant d’atteindre une certaine universalité. Tous ces langages « de haut niveau » constituent les langages que les compilateurs doivent être capables de traiter. Subsistent bien entendu les langages « de bas niveau » évoqués précédemment, qui sont incontournables car ce sont les seuls langages « natifs » des machines.
Le rôle des compilateurs est, en fait, à partir de programmes écrits dans un langage source, de les transformer en des programmes écrits dans un langage cible, qui peut être un langage de bas niveau ou un autre langage de haut niveau.
Ce processus de traduction doit satisfaire une contrainte très légitime qui est que les programmes cibles résultats de la compilation soient sémantiquement équivalents aux programmes sources, c’est‐à‐dire que leurs exécutions fournissent les mêmes résultats.
Arrêtons-nous un instant sur le fait qu’il peut paraître étrange de traduire un langage de haut niveau en un autre langage de haut niveau. Il y a d’excellentes raisons à une telle démarche : par exemple si, sur une machine donnée, on dispose d’un compilateur du langage C mais pas d’un compilateur d’un langage L et si l’on souhaite malgré tout prendre en compte des programmes écrits en L, il peut être plus facile d’écrire un compilateur de L vers C plutôt que d’écrire complètement un compilateur pour L.
On constate cette tendance croissante à considérer que le langage C (dont un compilateur est présent sur quasiment toutes les machines) constitue un langage cible privilégié pour de nombreux compilateurs car l’universalité de C permet de simplifier la compilation de nombreux langages. Cette démarche a l’avantage supplémentaire d’être indépendante de la machine support et donc de permettre la portabilité d’un compilateur sur plusieurs machines.
VERSIONS
- Version courante de août 2017 par Henri-Pierre CHARLES, Christian FABRE
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(238 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
5. Modèle d’exécution
5.1 Principe
Avant d’aborder la génération de code, il nous faut encore parler de ce que sera l’exécution du programme actuellement en cours de compilation. En effet, nous venons de voir l’adressage des objets locaux lors de l’activation d’une fonction mais les choses sont plus complexes car il peut y avoir à un instant donné plus d’une activation de fonctions en cours.
Les fonctions peuvent s’appeler mutuellement et on peut même avoir des appels récursifs de fonctions. Il faut donc prévoir un mécanisme qui permette de lancer une activation, de l’abandonner provisoirement pour en lancer une autre mais avec l’obligation de pouvoir retrouver, lorsque l’activation plus récente sera achevée, l’activation suspendue dans le même état où on l’a laissée. Nous avons déjà vu une organisation de l’information qui réalise cette contrainte, la notion de pile. On doit donc organiser en pile la mémoire des différentes fonctions actives.
HAUT DE PAGE5.2 Exemple
Considérons l’exemple suivant en simili C :
variables globales A, B, C
main()
{ variables locales D, E
/ *1*/
¼
@1 D=f()
}
int f{}
{variables locales H, I
/ *2*/
¼
@2 H=g()
}
int g()
{variables locales X, Y
/ *3*/
¼
}
Trois points (/ *i*/ ) ont été notés dans ce programme car il est intéressant d’y visualiser l’état de la mémoire.
Le point /*1*/ correspond au début de l’exécution. Les données valides sont les variables globales et les variables locales au programme principal, main. On aura en pile les variables globales qui resteront toujours en mémoire par définition même. On aura aussi le bloc d’activation de main. L’appel de f a lieu et il faut donc activer f c’est‐à‐dire mettre en pile son bloc d’activation. Au point / *2 */, l’appel de g a lieu et il faut donc activer g, c’est‐à‐dire mettre en pile son bloc d’activation. Au point / *3*/, on peut constater qu’on a en mémoire les variables globales, un bloc d’activation de main même si les variables de main ne sont plus accessibles, un bloc d’activation de f même si les variables de f ne sont pas non plus accessibles, un bloc d’activation de g dont les variables sont accessibles.
La...
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(238 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Modèle d’exécution
BIBLIOGRAPHIE
-
(1) - AHO (A.), SETHI (R.), ULLMAN (J.) - Compilateurs : Principe, techniques et outils. - InterEditions (1989).
-
(2) - FOSTER (J.M.) - A syntax improving program, - Computer Journal, 11 : 1, 31-34 (1968).
-
(3) - JOHNSON (S.C.) - Yacc – yet another compiler compiler. - ATT Report 32, Murray Hill (1975).
-
(4) - KNUTH (D.E.) - On the translation of languages from left to right. - Information and Control, 8 : 6, 607-639 (1965).
-
(5) - KNUTH (D.E.) - Semantics of context-free languages. - Math. Systems Theory, 2 : 2, 127-145 (1968).
-
(6) - KNUTH (D.E.) - Top-down syntax analysis. - Acta Informatica, 1 : 2, 79-110 (1971).
-
...
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(238 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive