Par «code source», on entend en réalité le(s) fichier(s) "texte" que vous créez avec l'ensemble des instructions qu'ils contiennent.
Comme le "texte" que vous avez écrit est compréhensible par l'humain sans *trop* de difficultés (ou du moins, qu'il devrait l'être, à condition d'être suffisemment commenté, structuré et d'utiliser des noms de variables explicites), il semble "logique" de penser que le processeur, qui, rappelons le ne connait que des 0 et des 1, ne comprendra pas de lui même les instructions.
Il est donc nécessaire de faire passer ce code source par une "moulinette", appelée compilateur, qui se chargera de transformer ces instructions en une succession de 0 et de 1 compréhensible par quelque chose d'aussi bête qu'un processeur.
Entre le code source et le programme exécutable proprement dit, deux grandes étapes sont nécessaires avec les langages compilés.
Le shéma ci-dessous en fait le synapsis:
La compilation proprement dite a pour but de transformer toutes les instructions du code sources en autant d'instructions processeur codées en binaire.
Au niveau du C (et du C++), elle se fera d'ailleurs en deux étapes:
Le préprocesseur commencera le travail: toutes les instructions préprocesseurs seront physiquement remplacées dans le(s) fichier(s). Ainsi, les fichiers d'entete seront physiquement inclus dans le code sources, et les les définitions seront physiquement remplacées partout où elles sont utilisées.
Le compilateur prendra alors le relais pour transposer effectivement le tout en instructions utilisables par le processeur.
Le fichier obtenu est appelé "fichier objet" (bien souvent, il s'agira d'un fichier ayant une extension .o ou .obj) mais n'est pas encore utilisable par le processeur.
Pour comprendre pourquoi l'édition des liens est nécessaire,il s'agit de comprendre comment réagit généralement un processeur.
Une fois compilé, un programme aura généralement une structure ressemblant fortement à ceci:
Si vous utilisez une chaine constante (pour un affichage, par exemple) du type de "Je m'appelle Machin", vous retrouverez, pour cet exemple précis, une succession de 19 octets (en fait, souvent même 20: un caractère null (de valeur binaire 0) devrait clotûrer la chaine) dans la zone que j'ai indiquée "données constantes" et qui contiendront les valeurs ASCII de chacun des caractères de la chaine.
Ce ne sera qu'une fois que toutes les données constantes auront été indiquées que le programme en lui-même pourra débuter (mais rien n'empêche, par contre, de laisser une certaine quantité de mémoire inutilisée
) .
Il ne faut pas être grand clerc pour comprendre qu'il est donc impossible de dire que "la première instruction du programme se trouvera systématiquement à l'adresse untel" par rapport au début du fichier…
Peut être vous demanderez vous pourquoi, si les données constantes sont indiquées au début du programme, on voit systématiquement apparaître une donnée après une instruction?
Hé bien, "tout simplement" parce que le processeur doit disposer de certaines données pour pouvoir effectuer une instruction…
Si vous travailliez dans un entrepôt, et que l'on vous demandait "veuillez remplir la camionnette", vous demanderiez fatalement "d'accord, mais avec quoi?"… Le processeur ne travaille pas autrement…
Ainsi, si vous demandiez "affiche le résultat de 10+6", le compilateur transformerait cette instruction, pourtant "relativement simple" à nos yeux en une série d'instruction compréhensibles par le processeur qui ressemblerait (en en ommettant ici quelques unes non indispensables à la compréhension)
Maintenant que vous savez, dans l'ensemble, comment se comportera le processeur, vous comprendrez beaucoup plus facilement que l''édition de lien aura pour but de signaler que "la première instruction du programme se trouve à telle adresse dans le fichier".
Elle aura aussi pour but de rassembler les différents fichiers objets créés dans le cadre d'un projet plus important utilisant plusieurs fichiers de codes sources et de faire correspondre les appels aux différentes fonctions avec leur adresse définitives.
Je vous rassure tout de suite: ces différentes étapes se font généralement de manière quasi transparente pour la personne qui utilise un compilateur: La seule preuve visible de ces différentes étape sera (généralement) la présence de fichiers objets.
Toute modification du code source induira la nécessité de recompiler l'application.
C'est là l'un des inconvéniants des langages compilés…
C'est aussi la raison pour laquelle les différents fichiers objets ne sont généralement pas effacés en fin de compilation: si un projet utilise 10 fichiers différents (et c'est parfois beaucoup plus), mais qu'un seul fichier est modifié, il n'est pas *forcément* nécessaire de recompiler les 9 autres…
Certains projets importants peuvent demander plusieurs minutes (parfois même des heures) pour être compilés entièrement. Vous comprendrez donc que le fait de ne recompiler qu'un ou deux fichiers et de rééditer les liens représentera un gain de temps des plus appréciables .
C'est là l'unique raison qui fait que les fichiers objets ne soient généralement pas effacés en fin de compilation.
Copyright (©) 2005 (Philippe Dunski)
Ce cours est libre, vous pouvez le redistribuer et/ou le modifier selon les termes de la Licence Publique Générale GNU publiée par la Free Software Foundation (version 2 ou bien toute autre version ultérieure choisie par vous).
Ce cours est distribué car potentiellement utile, mais SANS AUCUNE GARANTIE, ni explicite ni implicite, y compris les garanties de commercialisation ou d'adaptation dans un but spécifique. Reportez-vous à la Licence Publique Générale GNU pour plus de détails.
Cependant, l'auteur apprécierait grandement que vous lui fassiez part de toute modification apportée à son contnu
Vous pouvez le contacter par mail à l'adresse koala01@free.fr
Vous pouvez trouver une adaptation française de la licence GNU/GPL à l'URL http://www.linux-france.org/article/these/gpl.html
