Obligement - L'Amiga au maximum

Jeudi 14 décembre 2017 - 18:01  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Articles divers

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


Jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


Comparatif : Lattice C contre Aztec C
(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 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.


[Retour en haut] / [Retour aux articles]