Obligement - L'Amiga au maximum

Mercredi 24 avril 2024 - 10:00  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

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

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des 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,
ALL


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


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


Test de DICE 2.06.40
(Article écrit par Gilles Soulet et extrait d'Amiga News - décembre 1992)


Il existe actuellement deux versions du compilateur C DICE : une version "librement distribuable", donc disponible dans le domaine public, et une version "enregistrée", donc commerciale, et distribuée en Europe francophone par Someware.

Historiquement, c'est la version du domaine public qui est apparue la première. Celle-ci n'est plus mise à jour depuis décembre 1990. Quant à la version enregistrée, elle fait l'objet d'améliorations permanentes, et c'est dans sa version 2.06.40 que je vous propose de la découvrir aujourd'hui.

Présentation

On peut dire que la société Someware a bien fait les choses puisque DICE est livré dans un beau classeur blanc contenant une documentation en français et les trois disquettes d'installation. Cette documentation se limite à décrire le principe et l'utilisation de l'environnement de programmation DICE, et ne pourra en aucun cas servir d'introduction au langage C. Si vous êtes débutants, il faudra donc vous munir d'un livre de référence du langage. Cela dit, cette documentation est claire et précise, et elle a le mérite d'être en français.

Dans le classeur, on trouve donc trois disquettes contenant toutes les archives nécessaires au fonctionnement de DICE : compilateur, éditeur, assembleur, éditeur de liens, fichiers includes, fichiers objets, bibliothèques, exemples, docs, etc. Le tout est archivé sous forme de trois fichiers au format "lzh" et représente pas loin de 7 Mo de données !

Installation

Le désarchivage et l'installation sur disque dur ne posent aucun problème puisque un programme d'installation est fourni. Les accès aux fichiers includes, aux bibliothèques et aux fichiers temporaires se font grâce à des assignations logiques (DINCLUDE:, DLIB:, DTMP:...).

Donc, un disque dur n'est pas absolument nécessaire pour utiliser DICE. Il est quand même fortement recommandé pour travailler confortablement. Quant à la mémoire, un minimum de 1,5 Mo est conseillé. Vous devez absolument avoir installé les bibliothèques mathématiques système dans votre tiroir Libs:.

L'environnement

DICE est un compilateur C. Il contient par conséquent tous les fichiers includes et toutes les bibliothèques nécessaires pour faire du développement. Tous ces fichiers sont fournis en deux versions, selon qu'on désire développer pour le système 1.3 ou pour le système 2.0. Mais DICE est plus qu'un simple compilateur C. C'est un véritable environnement de programmation. A ce titre, il contient une multitude d'utilitaires qui facilitent la vie du programmeur en C : assembleur, éditeur, profileur, désassembleur d'objets, prototypeur, etc. Malheureusement, aucun débogueur n'est livré avec DICE. Il vous faudra donc vous procurer un débogueur (il en existe plusieurs en DP), car cet outil est absolument indispensable pour développer de grosses applications.

Le compilateur C

Le compilateur C est invoqué via la commande "dcc". Celle-ci est suivie typiquement d'une liste d'options et du nom du fichier source à compiler. Vous pouvez aussi mettre vos options de compilation dans la variable d'environnement DCCOPTS. Cette commande peut être rendue résidente, ce qui améliore la vitesse de la compilation. De toute façon, ne vous attendez pas à des merveilles : DICE est aussi lent pour compiler que SAS C...

On peut dire qu'aujourd'hui, le compilateur DICE est arrivé à maturité. Il possède à présent des caractéristiques très intéressantes. La norme ANSI est maintenant gérée à 99%, et le compilateur procède à diverses optimisations pour améliorer la vitesse d'exécution de vos programmes. De même, les variables automatiques (en quelque sorte les variables "auxiliaires" des fonctions) sont placées dans les registres d0,d1,a0,a1. Les paramètres des fonctions peuvent être transmis par la pile (classiquement) ou par registres. On peut même préciser quels registres on préfère utiliser pour un passage de paramètres. Cette option facilite beaucoup l'interfaçage entre C et assembleur.

Une caractéristique intéressante est de pouvoir définir deux fonctions d'entrées différentes selon que le programme sera lancé depuis le CLI ou depuis le Workbench. Lorsque le programme est lancé depuis le CLI, c'est votre fonction "main()" qui est appelée de façon classique, juste après quelques initialisations.

Mais si le programme est lancé depuis le Workbench, c'est alors la fonction "WBMain()" qui est utilisée pour le démarrage. Ceci vous permet de traiter facilement les deux cas de figure, afin d'éviter par exemple que votre programme ne fasse un "printf()" alors qu'aucune fenêtre d'entrées/sorties n'est ouverte (lancement depuis le Workbench). Si votre programme ne définit pas un "WBMain()" c'est celui par défaut qui sera utilisé : il sort directement, en retournant -1.

Autre caractéristique intéressante : la gestion intelligente de la pile. DICE peut générer du code qui vérifie en temps réel la taille de la pile, et qui permet aussi d'agrandir la pile (via allocation mémoire) si elle diminue de façon trop dangereuse ! C'est, à ma connaissance, le seul compilateur C qui propose une telle option.

DICE permet de générer des programmes "purs" ou "réentrants". Un programme est pur lorsqu'il ne se modifie pas lui-même et qu'il n'utilise aucune variable "statique" ou "globale", c'est-à-dire aucune variable représentée par une case mémoire dans un segment du programme. L'intérêt des programmes purs est qu'ils peuvent être rendus résidents en mémoire. Une fois qu'un programme est résident, on peut le lancer autant de fois qu'on le veut sans le dupliquer (et donc sans consommer inutilement de la mémoire), car c'est toujours la même partie du code qui est utilisée par tous les processus. Les bibliothèques de l'Amiga sont un parfait exemple de code pur.

Dernier avantage de DICE, si une base de bibliothèque est non déclarée, ou déclarée externe, il y aura ouverture automatique de la bibliothèque correspondante.

On peut regretter que M. Dillon n'ait pas prévu un principe permettant d'appeler directement les fonctions des bibliothèques, en évitant de passer par une "glue". Les glues sont ces petits bouts de code qui dépilent les paramètres et les placent dans les registres adéquats avant l'appel d'une fonction d'une bibliothèque. Ils ne sont pas nécessaires si le compilateur est capable d'appeler directement une telle fonction, par un "JSR offset(a6)", après avoir chargé les bons registres. Les glues ralentissent la vitesse d'exécution d'un programme et rallongent inutilement sa taille. Il est donc bien dommage qu'on ne puisse pas y échapper, d'autant plus que DICE gère les passages de paramètre par registres.

Autre défaut du DICE : les bibliothèques ont été écrites en C ! M. Dillon a beau nous assurer que cela ne ralentit pas trop les programmes, il devrait plutôt s'inspirer du Turbo C sur Atari ST qui rivalise de vitesse avec SAS C simplement grâce aux routines des bibliothèques qui ont été écrites entièrement en assembleur et optimisées au maximum...

DICE fonctionne assez mal avec ARP, notamment au niveau des commandes "path" et "ares". Ceci peut s'avérer gênant pour les utilisateurs du système 1.3 car ARP est souvent utilisé sous ce système. Sous 2.0, pas de problèmes car ARP n'est pratiquement plus utilisé, à cause de quelques problèmes d'incompatibilité.

Les utilitaires

On trouve dans l'environnement DICE plusieurs utilitaires accompagnant le compilateur :

DAS, est un assembleur 68000, qui est avant tout destiné à assembler les fichiers sources créés par le compilateur. On a de gros problèmes pour l'utiliser sur des fichiers personnels, car sa syntaxe est limitée (il ne reconnaît pas certaines directives standard, comme EVEN, ODD...) et il n'autorise pas la présence de commentaires. C'est bien dommage, car cet assembleur aurait été intéressant à utiliser, dans la mesure où il procède à quelques bienvenues optimisations.

DLINK, est l'éditeur de liens. Associé aux diverses bibliothèques fournies et à plusieurs options de dcc, il permet de générer tous les types de codes : small (relatif à pc), large (absolu), données relatives à A4, données en adressage absolu. On peut même générer du code destiné à être mis en ROM (sans aucune référence statique). La bibliothèque nécessaire pour le modèle "large data" n'est pas directement fournie (mais on peut la créer avec un petit utilitaire). Les "overlays" ne sont pas gérés pour l'instant.

DMAKE est un "make", c'est-à-dire un mini-gestionnaire de projets. Il gère les dépendances, ce qui permet de ne compiler que certains sources après une modification. Il facilite beaucoup le développement de gros projets.

DME est un éditeur "spécialement conçu pour les programmeurs". Comprenez qu'il est entièrement configurable et paramétrable aussi bien au niveau des menus qu'au niveau des touches de fonction. En ce sens, DME se rapproche beaucoup d'une certaine version d'Emacs, écrite en LISP, et qui permet de modifier "en temps réel" l'éditeur ou de lui rajouter des fonctions. En outre, cet éditeur permet, grâce aux "autorefs", de retrouver rapidement des informations sur les fonctions, un peu comme l'aide intégrée de l'éditeur du Turbo C.

DPROF est un "profiler", c'est-à-dire un utilitaire qui permet d'afficher des informations sur le temps d'exécution d'un programme. Un tel outil est très utile si l'on désire optimiser un gros programme. Comme DPROF permet de connaître le détail du temps machine (absolu et relatif) pris par chaque fonction, on peut diriger son travail d'optimisation directement sur les fonctions qui "tournent" le plus souvent. C'est une très bonne idée d'avoir inclus un tel outil dans l'environnement de DICE. Cependant, Laurent Faillie nous a signalé quelques problèmes lorsqu'on utilise le profiteur sous 1.3. A suivre...

LIBMAKE est un utilitaire qui permet de créer des bibliothèques. Attention, il s'agit ici de bibliothèques C, qui seront utilisées par DLINK, et non de bibliothèques partagées, comme celles présentes dans votre tiroir "Libs:".

Efficacité du code

L'optimisation du code n'a pas été considérée comme une priorité majeure du compilateur DICE. M. Dillon s'en expliquera disant qu'il a préféré consacrer son énergie à concevoir un compilateur fiable, quitte à sacrifier la qualité du code obtenu. On le comprend, car l'optimisation du code est une partie très délicate de la conception d'un compilateur. On peut perdre beaucoup de temps à essayer d'optimiser telle ou telle séquence, sans s'apercevoir des effets de bord que cela peut entraîner.

Pour preuve, même l'optimiseur du SAS C se plante dans certains cas très particulier. Ne parlons même pas des optimiseurs de certains compilateurs C sur PC, qu'on est carrément obligé de désactiver, car ils plantent tout le temps ! Le plus grave, me semble-t-il, c'est que les bibliothèques elles-mêmes n'ont pas du tout été optimisées. Or, l'expérience montre que l'optimisation des bibliothèques de fonctions joue un rôle important pour la vitesse d'exécution finale d'un programme. Voici, par exemple, comment est implémentée sur DICE la fonction strcpy() qui réalise une recopie d'une chaîne dans une autre :

DICE
DICE

Voici, par comparaison, comment le SAS C procède :

DICE

En plus, ce diable de SAS C considère la fonction strcpy() comme une "macro", c'est-à-dire qu'il incorpore directement cette séquence de code dans le programme, sans utiliser un sous-programme ! Cela dit, le code produit par DICE n'est pas si mauvais que ça. Il se situe globalement juste en dessous du compilateur Aztec 5.0 : il est moins efficace dans la plupart des opérations arithmétiques, mais il se rattrape grâce au passage des paramètres par registres.

Quant à la taille moyenne des exécutables, elle est comparable à ce qu'on obtient habituellement sur Aztec ou SAS. En particulier, un exécutable utilisant les entrées/sorties (stdio) aura une taille minimale de 5492 octets. Espérons en tout cas que M. Dillon fera tout pour améliorer la qualité du code produit portes prochaines versions de son compilateur.

Conclusion

Au final, DICE s'en sort avec les honneurs. C'est un produit qui souffre encore de quelques erreurs de jeunesse, mais qui semble plein de promesses. Il n'a pas vraiment de gros défauts, et surtout il présente deux grosses qualités : primo, il peut fonctionner efficacement sans disque dur et ne consomme pas trop de mémoire. Comprenez qu'on peut l'utiliser sur des configurations où d'autres compilateurs C sont inutilisables. Ensuite, il ne coûte vraiment pas cher, surtout par rapport à ses concurrents. Et cette qualité n'est pas une des moindres de nos jours...

Nom : DICE 2.06.40.
Auteur : Matt Dillon.
Genre : programmation C.
Date : 1992.
Configuration minimale : Amiga OCS, 68000, 1,5 Mo de mémoire, bibliothèques mathématiques.
Licence : commercial.
Prix : 590 FF.


[Retour en haut] / [Retour aux articles]