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
|
|
|
|
Comparatif : Lattice C contre Aztec C (version 1989)
(Article écrit par Roméo Rapido et extrait d'A-News (Amiga News) - janvier 1989)
|
|
Voici enfin le test comparatif tant attendu Lattice contre Aztec, que le match commence.
Compilateurs C
Maintenant que vous vous êtes remis de votre crise de foie et que vos économies se sont regonflées grâce aux étrennes,
vous avez peut-être envie d'acheter un compilateur (à moins que vous préfériez un jeu, dans ce cas passez directement aux
pages pleines d'images). Soit que vous ayez l'idée du programme du siècle (ou de l'année si vous êtes plus modeste),
soit que vous désiriez tirer parti du maximum des possibilités de votre Amiga pour programmer vos applications
personnelles ou bien que tout simplement vous en ayez marre de la lenteur du BASIC. Dans tous les cas, il vous faut
acheter un compilateur C et un macro assembleur compatible avec le compilo. Nous allons donc passer en revue les
deux principaux du marché : Aztec C et Lattice C. Je ne parlerai pas ici des compilateurs du domaine public qui feront
peut-être l'objet d'un test ultérieur. Le principal intérêt de ces derniers est qu'ils sont quelquefois fournis avec les sources.
Entrons de suite dans le vif du sujet. Le Lattice c'est le langage de référence des précieux manuels Addison & Wesley (ROM
Kernel, Intuition, etc.) mais comme nous parlons de C et pas d'une vulgaire recette de mamie Vano, pas de problèmes. En effet,
il s'agit d'un langage portable par définition (standard ANSI) et donc un programme en C pur (sans appels directs aux fonctions
de la ROM) tournera aussi bien sur Amiga que sur Atari ST ou PC et c'est beau, ce qui fait tout l'intérêt dc programmer en C.
Différences
La première grosse différence vient du type entier par défaut (int) qui est long sur le Lattice et short sur l'Aztec.
Cette particularité permet à l'Aztec d'aller plus vite en boucles puisque les indices sont sur 16 bits au lieu de 32
(le type short int désigne des entiers sur 16 bits, valeur comprise entre 0 et 65535 (unsigned short int) ou -32768 et
+32767 s'il s'agit d'entiers signés (signed short int), alors que type long int désigne les entiers sur 32 bits, valeur
comprise entre 0 et 4294987295 (unsigned long int) ou -2147483648 et +2147483647 s'il s'agit d'entiers signés (signed long int)
mais le problème peut être contourné par le Lattice en déclarant les indices de boucle en short int
(voir article de décembre).
Attention tout de même car les fonctions
de la ROM réclament des long int, gare aux méditations du Guru si vous leur passez un short comme argument. D'où la nécessité
en Aztec de rajouter un "L" après toutes les constantes qui sont passées aux fonctions de la ROM et de bien vérifier les
types. Exemple : OpenLibrary ("intuition.library", 0L). De toute façon, il existe une option de compilation qui force les
entiers à être sur 32 bits dans le compilateur Aztec et vous pouvez l'utiliser si vous n'êtes pas sûr de vous (il
suffit de lié avez l'option -lc32 au lieu de -lc, c'est cool non ?).
La deuxième grosse différence vient des assembleurs. Si leur principe est le même (production d'un fichier .o utilisable par
l'éditeur de liens (ou "linker" pour les anglophones), l'Aztec offre en plus la possibilité de faire de l'assembleur in line.
C'est-à-dire que vous pouvez écrire une fonction en assembleur dans votre "texte" en C, pratique non ? Quant au principe,
tous deux compilent en deux passes, le Lattice LC1 produit un fichier intermédiaire .q puis un .o par application de
LC2 à ce dentier, alors que l'Aztec produit (avec cc) un fichier en assembleur puis appelle automatiquement l'assembleur.
Intérêt : vous pouvez générer votre code en C puis faire des optimisations en assembleur (alors là, je me marre car qui
optimise un code produit par un compilateur C ? Autant écrire directement en assembleur !). Dernier détail, les fichiers .o
produits ne sont pas compatibles entre eux.
Le reste en vrac : l'Aztec génère un code plus court et plus rapide ce qui n'est pas pour déplaire aux utilisateurs. Quant aux
manuels, celui du Lattice se présente comme un gros carnet à spirale alors que celui de l'Aztec est constitué d'un petit classeur
qui se range dans l'emballage d'origine. Là encore le manuel de l'Aztec se révèle légèrement plus complet que celui du Lattice.
Bien entendu tous deux sont en grand breton. Côté prix comptez entre 1500 et 1700 FF pour l'un ou l'autre des compilateurs
(suivant les versions : attention, la version commerciale de l'Aztec coûte près de 4000 FF alors que la version de base est
disponible chez CIS à Talence pour moins de 1600 FF). Dernière chose, l'Aztec possède un "makefil"" bien connu des amateurs
de système Unix.
Compilation automatisée
Pour les autres j'explique : quand vous développez un très gros programme en utilisant la technique de la compilation
séparée (voir cet article) chaque fois que vous faites une modification,
il faut recompiler le morceau et refaire une édition de lien. Si vous faites plusieurs modifications de fichiers il
faudra les recompiler chacun à leur tour sans en oublier. Le "make" peut s'en charger, pour tous les fichiers qui sont dans
un petit script il teste si la date du code source est plus ancienne que la date du fichier .o correspondant : si oui,
il passe au suivant, si non, il le compile, quand il a passé tous les fichiers il lance l'édition de lien comme indiqué.
La compilation est donc automatisée et plus de risque de se tromper ou d'oublier de compiler un bout : il suffit de taper "make".
Si votre choix n'est pas déjà fait, voici le coup de grâce. Il existe pour le Lattice des utilitaires de mise au point et de
débogage (du moins sur le dépliant donné par Lattice avec le compilateur) mais où sont-ils et que valent-ils ? (qui suis-je ?
où vais-je ?). Alors que pour l'Aztec il existe saint SDB (priez pour nous pauvres programmeurs) qui, pour moins de 600 FF,
vous permet d'exécuter votre code ligne à ligne (en voyant le texte source dans une fenêtre), de mettre des points d'arrêt,
de vérifier le contenu des registres et des variables, enfin un véritable débogueur et même interpréteur puisque vous pouvez
lancer des commandes directement en C depuis SDB. Décidément, merci monsieur Manx.
Bon maintenant que vous avez choisi et acheté votre compilateur, vous le chargez et vous commencez à programmer. Stop !
Commencez donc par lire la documentation, cela vous épargnera bien des désagrements et des crises de nerfs. Bien maintenant
vous êtes fin prêt à programmer mais avant d'entamer cette ultime épreuve réfléchissez bien à ce que vous voulez faire
écrivez noir sur blanc (ou le contraire si vous ne pouvez pas porter votre copain africain) le cahier des charges,
c'est-à-dire tout ce que doit réaliser le programme et comment il doit le faire. N'hésitez pas non plus à crobarder
quelques écrans avec les positions des menus, gadgets et fenêtres.
Réfléchissez bien à ce que vous pouvez faire avant d'attaquer la programmation que ce soit sur papier avec une gomme et
un crayon (outils indispensables au véritable informaticien) ou sur machine et écrivez si possible un organigramme
global du déroulement du programme, il vous aidera plus tard à vous y retrouver.
Il ne vous reste plus qu'à réaliser le logiciel de vos rêves. Là aussi de la méthode : respectez bien l'indentation
et mettez un maximum de commentaires même s'ils vous paraissent inutiles sur le moment, ils vous serviront dans six
mois ou si vous passez les sources à un copain ou (dernier maillon de la chaîne) à un éditeur si vous désirez être
édité (et bien sûr gagner quelques brouzoufs avec votre logiciel). En effet, ce dernier ne se contentera pas d'une seule
version sur Amiga et il faudra adapter le programme sur Atari (beurk quelle horreur !), PC, etc. Donc si vous avez une idée
de programme que vous trouvez géniale pensez aux possibilités (souvent réduites) des autres machines en vue d'une éventuelle
adaptation. Sur ce, bon courage et programmez bien.
|
