Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : C - la compilation séparée
(Article écrit par Roméo Rapido et extrait d'A-News (Amiga News) - octobre 1988)
|
|
Vous allez me dire pourquoi faire compliqué quand on peut faire simple et compiler en une seule fois ? A ceci je répondrai
d'accord mais à condition d'avoir 2 Mo de mémoire, ce qui est loin d'être le cas de tout le monde. Voyons donc les raisons
principales :
1. Compilation de gros fichiers. Avec 512 ko il est difficile (voire impossible) de compiler 50 ko de source, alors
qu'un bon programme dépasse largement les 200 ko.
2. Pour inclure des routines écrites en assembleur et augmenter la vitesse des portions "critiques".
3. Pour plus de lisibilité, plus le fichier source est court et plus il est facile de savoir ce qu'il contient et
donc de le modifier.
4. Et enfin pour compiler plus vite. En effet, pour une modification vous n'aurez besoin de recompiler qu'un petit
bout de votre programme, ce qui suivant le morceau en question peut être très rapide alors que la compilation entière
peut durer plusieurs dizaines de minutes.
Le principe est donc simple : on compile tous les fichiers dont on a besoin chacun à leur tour puis on lie (link) le tout ensemble,
le "linker" se chargeant de faire l'édition de liens, c'est-à-dire de "recoller" les différents morceaux du programme et de
produire un fichier exécutable.
Pour faire de la compilation séparée en C il n'y a pas de problèmes majeurs. Un des fichiers contient la fonction main()
qui en appelle d'autres situées dans le même fichier source ou dans d'autres fichiers. Si les fonctions sont dans le même
fichier, pas de problèmes, si elles sont dans un autre, il faut, dans la partie des déclarations, déclarer ces fonctions
avec leur type + le type extern (externe au programme). Bien que ceci soit facultatif avec le Lattice, je vous encourage à le
faire pour des raisons de lisibilité. Voyons donc un petit exemple.
Compilez chaque fichier en tapant "LC1 -oRAM:fichier1" puis "LC2 RAM:fichier1", "LC1 -oRAM:fichier2" et enfin "LC2 RAM/fichier2".
Puis liez le tout en tapant :
|
BLINK FROM lib/c.o, ram:fichier1.o, ram:fichier2.o TO ram:fichier3 LIB lib/lc.lib,lib/amiga.lib
|
Vous avez maintenant un exécutable en RAM: qui se nomme "fichier3" et qui écrit un "3". Si vous avez davantage de fichiers
il suffit de les rajouter dans la liste de la directive FROM de l'éditeur de lien :
|
BLINK FROM lib/c.o, fichier1.o,...,fichiern.o TO ...
|
Comme vous avez pu le constater, le passage de paramètres s'effectue sans problèmes. Si maintenant nous voulons utiliser dans
le programme 2 une variable déclarée dans le programme 1 (ou vice-versa) il suffit de la déclarer en externe avec son type et
son nom dans le programme 2. Le compilateur génèrera la place nécessaire et l'éditeur de liens se débrouillera pour que le programme 2
récupère bien la bonne valeur. Voyons un petit exemple :
Même procédure que précédemment et le programme affichera la valeur du paramètre passe et la valeur de la variable initialisée
dans fichier1.c.
Voyons maintenant l'interface C assembleur.
Le premier programme initialise la variable "var" à 10 puis appelle le second qui ajoute 10 à cette dernière. Voyons maintenant
prog2.a, la même chose en assembleur.
Remarquez qu'en assembleur les noms de variable et les labels sont toujours précédés d'un souligné. Il ne reste plus qu'à compiler
ce morceau avec l'assembleur du Lattice puis à le lier avec prog1.c et le tour est joué.
Si vous utilisez le compilateur MetaComCo remplacez "CSECT" par "RORG 0" (code relogeable, option par defaut du Lattice)
et supprimez le "END".
Si vous avez écrit des petites routines vous pouvez nous les envoyer, nous les publierons si elles ne sont pas trop longues.
Alors creusez un peu ce qui vous tient lieu de cervelle, il n'y a pas de raison que ce soit toujours les mêmes qui passent des
nuits blanches sur notre machine préférée.
|
