 |
Vendredi 23 mai 2025 - 14:16 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Les compilateurs C de Lattice Incorporated et de Manx Software Systems sont disponibles pour le Commodore Amiga. Les deux compilateurs ont leurs forces et leurs faiblesses, et tous deux conviennent au développement de logiciels professionnels.
Les deux rivaux
Manx Aztec C68K
- Type : paquetage de développement et débogueur C.
- Société : Manx Software Systems, P.O. Box 55 Shrewsbury, NJ 07701. Tél : (201) 542-2121.
- Matériel nécessaire : Amiga 1000 avec AmigaDOS, 256 ko de mémoire, un lecteur de disquette.
- Protection contre la copie : non.
- Prix : 499 $ (Aztec C68K version commerciale), 299 $ (Aztec C68K version développeur).
- Type : paquetage de développement et débogueur C.
- Société : Lattice Incorporated, P.O. Box 3072, Glen Ellyn, IL 60138. Tél : (312) 858-7950.
- Matériel nécessaire : Amiga 1000 avec AmigaDOS, 512 ko de mémoire, un lecteur de disquette.
- Protection contre la copie : non.
- Prix : 149,95 $ (compilateur C Amiga), 250 $ (compilateur croisé Amiga IBM PC).
Lattice a travaillé en collaboration avec Commodore pour développer son compilateur C pour les premiers développeurs de logiciels. L'un des problèmes les plus importants de la programmation de l'Amiga est d'avoir accès à tous les appels de la bibliothèque système et aux structures de données que l'Amiga utilise pour accéder à ses ressources graphiques et multitâches. Heureusement, Lattice a abordé cette question dès le début ; le résultat est un ensemble complet de routines, de liens et de fichiers d'inclusion qui définissent toutes les structures de données de l'Amiga.
Manx Aztec C68K
Le compilateur Manx Aztec C68K est arrivé plus tard sur la scène Amiga, et sa première révision a été rendue disponible ce printemps 1986. Cependant, Manx Software Systems n'était pas un nouveau venu dans le monde des compilateurs C 68000 ; il avait déjà un compilateur C disponible pour le Macintosh. Le compilateur Manx Aztec C68K pour l'Amiga génère un code rapide et compact et le fait rapidement.
Résultats des tests
Les résultats du test de performances favorisent fortement Aztec C68K. Pour une comparaison des tailles du compilateur et de l'éditeur de liens, voir le tableau 1. Pour les résultats des temps, voir le tableau 2.
Tableau 1
Tailles des fichiers nécessaires sur disquette pour compiler et lier. Toutes les tailles sont en octets.
Résultats des temps des tests et de la taille des fichiers. Tous les temps sont exprimés en secondes et toutes les tailles de fichiers sont en octets. Un tiret indique que les temps ne sont pas disponibles. Les programmes d'évaluation sont disponibles auprès de BYTEnet Listings au (617) 861-9764.
Il est nécessaire d'augmenter la taille de la pile pour exécuter ce test avec l'un ou l'autre des compilateurs. J'ai utilisé "stack 40000".
Un test mathématique à virgule flottante sur Amiga peut être plus lent lors de la première exécution car les bibliothèques doivent être chargées depuis la disquette. Le différentiel de taille du Lattice C est en partie dû à la bibliothèque Mathtrans ; Aztec C68K utilise la bibliothèque d'exécution du système Amiga, qui fait environ 4,5 ko. Lattice C utilise ses propres routines IEEE en double précision dans le code objet. Le test "Savage" provient de Dr. Dobb's Journal, septembre 1983, page 120.
Il est important d'examiner les raisons pour lesquelles les résultats sont tels qu'ils apparaissent. L'écart le plus important dans les résultats du test se produit dans deux domaines : les mathématiques en virgule flottante et la taille du code objet.
En ce qui concerne la taille du code objet, le compilateur C68K d'Aztec produit systématiquement des résultats de référence inférieurs à la moitié de la taille des programmes compilés sous Lattice C. Dans les tests de référence Byte, les programmes Lattice C ont une taille moyenne près de trois fois supérieure à celle des programmes C d'Aztec. Comme je m'intéresse beaucoup à l'optimisation du code, j'ai examiné de près les résultats des deux compilateurs. Ma conclusion est que le compilateur Aztec devrait généralement produire un code de 20 à 33% plus petit que le code équivalent du compilateur Lattice.
En pratique, la taille du code produit par ces tests est largement déterminée par la taille de la fonction de la bibliothèque "printf". Manx Software Systems a fait un bon travail en créant une fonction printf très efficace, mais si vous voulez mesurer l'efficacité du code que le compilateur Aztec C68K génère, vous devez prendre en compte cette différence, en particulier si vous n'utilisez pas printf dans votre code. La taille du code d'un programme contenant la seule instruction "Hello, world" est de 4720 octets avec Aztec C et de 14 508 octets avec Lattice C. Cette différence n'a pas grand-chose à voir avec le compilateur utilisé, sauf peut-être pour mesurer l'efficacité du compilateur à construire les bibliothèques de liens. Si Lattice Incorporated voulait améliorer les repères de son compilateur C, il pourrait optimiser la fonction printf du compilateur.
L'autre différence majeure dans la taille des fichiers exécutables produits est due à l'utilisation par le compilateur Aztec C68K de décalages de 16 bits pour l'adressage des données et des fonctions. La taille des "int" fait très peu de différence dans la taille du fichier exécutable (bien qu'elle fasse une grande différence dans les tests pour la vitesse). La différence de taille du fichier exécutable provient du mode d'adressage utilisé pour référencer les variables et les fonctions.
Le compilateur Aztec C68K réserve le registre A4 comme pointeur d'adresse de base, qui est utilisé pour indexer une région de données de 64 ko. Cela permet d'utiliser un adressage par décalage de 16 bits plutôt que des adresses absolues de 32 bits. Le résultat est un code qui est environ 25% plus rapide et 33% plus petit pour chaque instruction de référence mémoire. La même méthode est utilisée pour les adresses de fonction : plutôt que d'utiliser une adresse absolue de 32 bits, un décalage de 16 bits du compteur de programme est généré pour les appels de fonction.
Cette méthode d'adressage constitue la différence la plus importante entre Aztec C et Lattice C en termes de taille du code généré. Un fait négligé dans cette évaluation est que le compilateur C de Lattice gère l'adressage relatif à la base en tant que commutateur de compilateur. Cependant, avec la version actuelle d'ALink, il n'est pas possible d'utiliser cette fonctionnalité car MetaComCo, l'auteur d'ALink, n'a pas inclus la gestion de l'adressage base-relative dans la spécification du code objet.
L'utilisation de l'adressage par décalage sur 16 bits présente quelques limitations. La première est une limitation générique similaire à l'espace d'adressage segmenté de processeurs comme le 8086 ; la seconde est un problème spécifique à l'Amiga basé sur la philosophie de la gestion de la mémoire Amiga.
La première limitation est que lorsque vous utilisez seulement 16 bits d'adresse, vous limitez effectivement la taille de l'objet adressé à 64 ko. Ceci doit être considéré séparément pour le code et les données, puisque les données sont adressées comme un décalage d'un registre de base, alors que le code est référencé comme un décalage du compteur de programme. Le compilateur et l'éditeur de liens Aztec C68K résolvent le problème d'adressage du code en plaçant des vecteurs de saut dans le segment de données lorsque vous essayez d'accéder à une fonction qui est en dehors de la plage du compteur de programme actuel. Si le code est dans la plage (32 ko en avant ou en arrière), il est directement accessible. Dans le cas contraire, une instruction de référence de données équivalente est générée, qui saute à un vecteur dans le segment de données. Le problème de la référence aux données est plus difficile à résoudre si vous avez un grand segment de données. Le compilateur Aztec C68K vous permet de combiner des modules compilés avec des segments de données petits (relatifs aux compteurs de programme) et grands (absolus), il est donc possible de séparer le code en modules qui ne font référence qu'à des données courtes et en modules qui peuvent faire référence à n'importe quelle partie du segment de données.
Je ne suis pas sûr que vous puissiez faire la même chose avec le compilateur C de Lattice, en supposant qu'il soit possible d'utiliser son mode d'adressage 16 bits. En effet, Lattice C utilise le registre A5 comme registre de base lorsque vous utilisez l'adressage court et le registre A5 comme variable de registre si vous compilez sans le commutateur d'adresse 16 bits. Étant donné que l'adressage de données relatif à la base repose sur un registre d'adresse à base fixe, je m'attends à ce qu'il y ait des problèmes pour combiner l'adressage relatif et absolu avec Lattice C.
La deuxième limitation à l'utilisation de l'adressage de décalage 16 bits avec l'Amiga est la philosophie de base du gestionnaire de mémoire. Le noyau Exec de l'Amiga n'a aucune disposition pour rendre la mémoire disponible contiguë une fois qu'elle a été allouée, et le résultat est que souvent la carte mémoire a beaucoup de petites régions de mémoire libre. La philosophie de chargement de l'Amiga stipule que le programme doit gérer cette fragmentation en chargeant dans un ensemble de petites régions non contiguës plutôt que dans une seule grande région. Cependant, sans mémoire contiguë, vous ne pouvez pas utiliser l'adressage avec un décalage de 16 bits ; vous devez vous rabattre sur une adresse absolue de 32 bits. L'éditeur de liens doit produire du code et des données avec de nombreux petits morceaux (c'est-à-dire des blocs de code ou de données avec des informations de relocalisation) plutôt qu'un seul gros morceau.
Ce problème se pose avec le compilateur et l'éditeur de liens Aztec C68K, bien que Manx Software Systems ait assuré aux développeurs qu'il traitera ce problème dans la prochaine révision. La révision actuelle de l'éditeur de liens Aztec C68K ne produit qu'un seul segment de code et un seul segment de données. Cela signifie que si votre programme contient 180 ko de code, tout est mis dans un seul morceau qui doit être chargé dans une zone contiguë de la mémoire. S'il n'y a pas assez de mémoire contiguë, le programme ne se chargera probablement pas ; s'il se charge, il pourrait avoir des difficultés à allouer une grande zone de mémoire contiguë pour l'affichage de l'Amiga.
La taille optimale que devraient avoir les segments est subjective. Les bibliothèques C de Lattice ont trop de segments : dans la version actuelle. Lattice C possède de nombreux segments qui ne chargent que 4 ou 8 octets de code ou de données. Par exemple, le test "Sieve" est divisé en environ 40 segments. Chaque segment nécessite environ 32 octets de stockage sur disquette et environ 16 octets au moment de l'exécution pour identifier chaque segment ; ainsi, les tests de Lattice C ont environ 1200 octets de surcharge juste pour gérer les différents segments.
J'ai hâte d'obtenir la révision de l'Aztec C68K qui vous permet de séparer les programmes en segments, mais les utilisateurs d'Aztec doivent faire attention : vos programmes deviendront un peu plus gros lorsque vous les séparerez en segments.
Dans les résultats mathématiques à virgule flottante, le compilateur Aztec C68K produit des résultats 10 à 20 fois plus rapides que ceux du Lattice C. La différence, cependant, est simple : Lattice C utilise des routines mathématiques IEEE en double précision, qui sont très précises mais aussi très lentes, par rapport aux routines mathématiques FFP en simple précision de Motorola que le compilateur Aztec C68K utilise (voir les résultats du test "Savage" dans le tableau 2). Si vos exigences en matière de mathématiques à virgule flottante sont orientées vers la vitesse, l'utilisation des routines FFP par Aztec C68K est exactement ce dont vous avez besoin. Cependant, si vous avez besoin de la précision IEEE, vous aurez besoin du compilateur C de Lattice.
Quelles sont les autres grandes différences dans les tests ? J'ai peu parlé de la vitesse, mais le compilateur Aztec C68K est très performant dans ce domaine. Les deux compilateurs sont à peu près à égalité, sauf en ce qui concerne les avantages de l'adressage relatif, lorsqu'on utilise des entiers 32 bits. En fait, le compilateur C de Lattice fait un meilleur travail d'optimisation en termes de mémorisation des résultats intermédiaires plutôt que de les recalculer dans deux instructions adjacentes au niveau de la source. Un exemple de ceci serait l'affectation de valeurs à un tableau de structures de données. Le compilateur C de Lattice calculait une fois l'adresse de l'élément de structure référencé et l'utilisait comme adresse de base pour chacune des affectations ; le compilateur C68K d'Aztec recalculait l'adresse de base chaque fois qu'elle était utilisée, même si la même adresse de base était utilisée 10 fois de suite.
Aztec C68K atteint une vitesse de référence exceptionnelle lorsque vous utilisez des entiers de 6 bits, en particulier si vous faites un usage approprié des variables de registre. Cette vitesse est parfaitement démontrée dans le test "Sieve", dans lequel Aztec C68K a terminé en 2,6 secondes contre 3,8 secondes en utilisant des entiers de 32 bits, ce qui est identique au temps affiché par Lattice C.
Le seul test dans lequel aucun des deux compilateurs n'a réussi à s'imposer est "Fileio". Il y a deux problèmes dans ce domaine. Le premier est qu'AmigaDOS ne gère tout simplement pas très bien les entrées/sorties de disquettes aléatoires. Le second est que les routines multitâches ne gèrent pas bien les entrées/sorties à caractère unique.
Je vais d'abord expliquer le second problème. Dans l'environnement multitâche, toute demande d'entrées/sorties de disquette doit passer un message au pilote de périphérique de disquette, qui va ensuite traiter la demande. Ensuite, le pilote renvoie un message à la tâche qui a fait la demande. Cette même surcharge se produit que votre demande porte sur un seul octet ou sur 100 000 octets. Dans un environnement multitâche, cette surcharge permet à de nombreuses tâches différentes d'accéder simultanément à la même disquette et aux mêmes fichiers sans problème. Le test "Fileio" fait beaucoup d'opérations d'entrées/sorties à un seul caractère, ce qui est la pire catégorie de performance pour l'Amiga. Une solution simple pour les programmeurs est de faire des requêtes pour le plus gros morceau de données possible à la fois. La disquette de l'Amiga peut pomper des données à environ 8 ko par seconde si vous faites des demandes pour de grands blocs.
Le premier problème, l'entrée/sortie aléatoire de disquette sous AmigaDOS, est en fait deux problèmes : AmigaDOS est lent, et l'Amiga est une machine utilisant des tampons de piste. Je ne peux pas expliquer AmigaDOS, mais je peux expliquer la mise en mémoire tampon des pistes : toute lecture ou écriture d'entrées/sorties apporte en fait une piste entière (environ 15 ko) de données dans la machine. L'Amiga est très efficace pour cela, avec une vitesse de données brutes d'environ 20 ko par seconde, mais lors d'entrées/sorties de disquette aléatoire, ce schéma va à l'encontre de la productivité.
Une solution partielle au problème d'entrées/sorties de disquette aléatoire sera probablement corrigée bientôt : Amiga se prépare à sortir la version 1.2 d'AmigaDOS. J'ai effectué le test "Fileio" avec cette version, et les résultats étaient plus de deux fois plus rapides que ceux obtenus avec la version 1.1.
Le paquetage Manx Aztec C68K
Le compilateur Aztec C68K dispose d'une version pour développeurs et d'une version commerciale. Les deux versions comprennent le compilateur et l'assembleur, l'éditeur de liens de Manx, les fichiers d'inclusion Amiga, un ensemble de programmes d'exemple provenant de disquettes du domaine public, ainsi que les bibliothèques de l'éditeur de liens de Manx.
La version pour développeurs possède les mêmes compilateur, assembleur, éditeur de liens et routines de bibliothèque que la version commerciale. Son prix suggéré est de 299 $.
La version commerciale comporte un ensemble de programmes utilitaires et inclut le code source des bibliothèques et un ensemble de fonctions de bibliothèque étendues. Parmi les utilitaires, on trouve une fonction "Make", un débogueur et un éditeur de texte de style vi, ainsi que des programmes Diff Grep, de bibliothèque et d'archivage. La version commerciale comprend également un an de mises à jour gratuites. Le prix suggéré est de 499 $.
J'ai trouvé la fonction Make très utile, bien qu'il lui manque certaines fonctions disponibles dans d'autres programmes Make. De plus, je considère qu'avoir les sources des bibliothèques est indispensable pour les développeurs professionnels, à la fois comme un moyen de vérifier que les bibliothèques font exactement ce que vous pensez qu'elles font et comme une source d'exemples.
Le paquetage Lattice C
Lattice Incorporated propose un compilateur C natif pour Amiga dont le prix est de 149,95 dollars et un compilateur croisé pour IBM PC dont le prix catalogue est de 250 dollars.
Les deux paquets de compilateur C de Lattice comprennent les deux passes du compilateur, LC1 et LC2 ; l'éditeur de liens ALink ; les fichiers d'inclusion Amiga ; les bibliothèques de l'éditeur de liens Lattice et les fichiers de démarrage, ainsi que quelques exemples ; et le désassembleur de modules d'objets Lattice. Lattice propose également un ensemble de programmes utilitaires similaires à ceux disponibles dans la version commerciale d'Aztec C68K, mais Lattice les vend individuellement plutôt que sous forme de paquetage.
ALink
ALink est l'éditeur de liens standard pour l'Amiga développé par MetaComCo (qui a également développé AmigaDOS). Il utilise le code objet et le format de bibliothèque standard de MetaComCo.
ALink a quelques problèmes majeurs : premièrement, il est extrêmement lent. Deuxièmement, il a des limitations basées sur la mémoire disponible qui déterminent la taille du fichier qui peut être lié. En soi, ce n'est pas si mal, sauf qu'il amène tous les modules d'entrée, y compris les bibliothèques, dans la mémoire pour les lier.
ALink crée l'une des plus grandes différences entre Lattice C et Aztec C68K en termes de temps de développement. Comme Manx Software Systems possède son propre format interne d'objets et de bibliothèques, il ne souffre pas de ce problème. Le résultat est un avantage clair et net pour le compilateur Aztec C68K jusqu'à ce que quelqu'un fasse quelque chose pour résoudre les problèmes d'ALink.
Dale Luck, chez Amiga, a mis en oeuvre une solution partielle pour ALink ; il a découvert qu'ALink passait la plupart de son temps d'exécution à allouer et à désallouer de la mémoire. Il a trouvé une solution rapide (qui est incluse dans la version 2.3) que vous pouvez invoquer en ajoutant le mot clé "faster" à la fin de votre ligne de commande ALink. Cela double la vitesse du processus de liens. Le seul inconvénient est qu'ALink peut ne pas être capable de fonctionner à ce moment-là parce qu'il saisit un seul gros morceau de mémoire au début de l'exécution.
Même avec l'option la plus rapide, l'éditeur de liens de l'Aztec C68K est environ deux fois plus rapide qu'ALink, et les liens sont la partie la plus lente du processus de développement. Mais c'est un début.
Documentation
La documentation fournie avec les deux compilateurs ressemble plus à des manuels d'utilisation qu'à autre chose. Les deux comprennent des instructions raisonnables pour l'utilisation des divers programmes inclus dans les paquetages et des instructions pour les diverses options de commutation du compilateur.
Vous aurez besoin d'informations spécifiques à l'Amiga si vous envisagez d'écrire des programmes qui vont au-delà des fonctions d'entrées/sorties de la bibliothèque C standard. Les manuels techniques de l'Amiga constituent le meilleur ensemble de références disponibles pour l'Amiga.
Fiabilité
Une autre question à considérer est la fiabilité de ces compilateurs. Heureusement, les deux obtiennent de bonnes notes, mais vous devez prendre la précaution d'allouer suffisamment d'espace de pile lorsque vous compilez avec Lattice C en utilisant la commande "Stack" d'AmigaDOS. Le compilateur Aztec C68K est livré sur une disquette qui contient une instruction "Stack" intégrée dans le script Startup-Sequence qui devrait régler tous les problèmes.
Divers
Un problème supplémentaire est l'utilisation d'entiers 16 bits par l'Aztec C68K. Il est difficile de développer pour l'Amiga en utilisant des entiers de 16 bits parce que les bibliothèques résidentes attendent des valeurs de 32 bits comme arguments d'entrée ; ainsi, presque tous les appels de fonctions Amiga doivent avoir des conversions ("casts") en (long) lors de la compilation en utilisant des entiers de 16 bits.
D'un autre côté, Aztec C68K a un mode de compilation 32 bits qui est très proche du Lattice C en termes de fichiers sources qu'il accepte en entrée. Pour la plupart des programmes du domaine public qui sont disponibles, il est possible de les compiler sans modification en utilisant l'option de compilation 32 bits d'Aztec C68K et les bibliothèques de liens 32 bits fournies.
Un autre problème est lié à l'éditeur de liens d'Aztec C68K. Les pilotes de périphériques et les bibliothèques Amiga nécessitent une table vectorielle décalée de 4 octets par rapport au début du fichier objet exécutable. Normalement, le premier code dans les fichiers de bibliothèque et de périphérique est un filet de sécurité, MOVEQ #0, D0; RTS, qui vous protège contre l'exécution accidentelle du périphérique ou de la bibliothèque. L'éditeur de liens de l'Aztec C68K, cependant, utilise un JSR .BEGIN comme toute première instruction dans sa sortie. Ceci a pour but de s'assurer que le programme est lancé à la bonne adresse.
Pour cette raison, il n'est pas possible de construire des bibliothèques et des périphériques avec la version actuelle du compilateur Aztec C68K. Manx Software Systems a assuré aux développeurs que ce problème sera résolu dans une mise à jour.
Conclusions
Le Lattice C et le compilateur Manx Aztec C68K fournissent tous deux des outils aux développeurs professionnels et aux bidouilleurs.
L'Aztec C68K obtient des scores élevés dans les tests de performances, notamment en termes de taille de code et de temps de compilation/liens. Nous remercions également Manx Software Systems d'avoir fourni le code source des fonctions de bibliothèque, que je considère comme essentielles pour les développeurs professionnels. Un autre grand avantage de l'utilisation du compilateur C68K d'Aztec est que les programmes nécessaires à la compilation nécessitent environ la moitié de l'espace disque que ceux du compilateur C de Lattice (cela inclut l'assembleur, qui ne fait pas partie du paquetage C de Lattice).
Le compilateur C de Lattice obtient un score élevé en matière de compatibilité avec les programmes Amiga du domaine public car la plupart des premiers programmes pour Amiga ont été développés sous C de Lattice. La plupart de ces programmes peuvent être compilés avec Aztec C68K si vous utilisez l'option 32 bits, mais à partir de maintenant, s'il y a un problème de compilation, il s'agit plus probablement d'un problème de compatibilité avec Aztec C68K. Lattice obtient également un bon score pour avoir déjà géré le format de code objet des pilotes de périphériques Amiga et pour avoir géré la philosophie du chargement fractionné ("scatter-loading"), qui est importante pour les gros programmes nécessitant beaucoup de mémoire graphique. Lattice devrait également continuer à bénéficier de sa relation étroite avec Commodore.
Les deux compilateurs peuvent être améliorés. Lattice doit réduire la taille de son compilateur et doit trouver une solution aux problèmes de liens hérités d'ALink. Lattice doit également gérer l'adressage relatif afin que son compilateur puisse générer du code de petite taille. Le plus gros problème de Manx Software Systems est d'adapter son éditeur de liens pour qu'il fonctionne mieux avec les besoins spécifiques de l'Amiga pour le chargement fractionné du code objet. Aztec C68K doit également gérer les formats de code objet des périphériques et des bibliothèques. Je me réjouis à l'idée de voir un meilleur optimiseur de code pour l'Aztec C68K, ce qui devrait améliorer ses résultats des tests déjà impressionnants.
|
