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 : Draco - introduction
(Article écrit par Cédric Beust et extrait d'A-News (Amiga News) - avril 1990)
|
|
Disons-le tout net : l'étude du langage Draco a balayé chez moi toutes les idées, pourtant bien ancrées,
relatives au C et à sa supériorité sur tous les autres langages en matière d'efficacité. Draco le bat
sur presque tous les points. Le compilateur Draco est rapide, produit des exécutables petits, un code
très bon et qui plus est, est partagiciel, donc accessible à tous. Quatre bonnes raisons pour passer ce langage
à la loupe.
Présentation
Draco a été inventé en 1983 par un Canadien, Chris Gray. Celui-ci, constatant chez Pascal et C un certain nombre
de lacunes, décida de ne garder que les meilleurs aspects de chacun d'eux en y ajoutant un brin d'Algol 68.
Le compilateur, jusqu'à l'année dernière, n'existait que sous CP/M. Il est désormais implémenté sur notre Amiga,
et d'une manière remarquable comme je vais tâcher de vous en convaincre. Commençons par résumer les reproches
faits par Chris Gray à C et Pascal :
Pascal
- Pas de compilation séparée ni conditionnelle.
- Manipulation de pointeurs et de chaînes peu souples.
- Pas de manipulation de bits, ni de variables signées/non signées.
- Limitations sur les fonctions et les types de leurs arguments.
C
- Trop de {} !
- Syntaxe de déclaration horrible.
- Peut devenir très illisible.
- Peu ou pas de vérification de types.
- Éditeurs de liens stupides ajoutant du code qu'on n'a pas écrit.
- Pas d'E/S intégrées, ce qui produit de gros codes, même pour des programmes courts.
Tous ces problèmes ont été résolus en Draco.
La syntaxe de Draco
Déclarations
Celles-ci se font de manière inverse par rapport aux langages usuels. Elles commencent par
une dimension éventuelle, suivie par le type et enfin la variable :
Il est également possible de se définir des types, de la même façon qu'en Pascal. Signalons parmi les
types prédéfinis la présence des énumérés, des pointeurs (leur sémantique est identique à celle de Pascal,
mais c'est le symbole de C "*" qui est utilisé), des structures et unions, des procédures et enfin des
opérateurs (celui-ci est une particularité du langage Draco).
Procédures
Une procédure est encadrée par les deux mots-clés "proc" et "corp". Elle peut retourner une valeur
d'un certain type. Les instructions à l'intérieur y sont séparées par un ";". Le retour de résultat
se fait simplement en donnant l'expression avant la fin de la procédure, non suivie d'un ";"
(la présence d'un ";" indique que l'unité précédente est une instruction, et non une expression).
Cette méthode permet de simuler l'expression conditionnelle avec "?" et ":" du C.
D'autre part, les arguments peuvent être des tableaux dont la taille n'est pas connue,
celle-ci pouvant être récupérée à l'intérieur de la procédure par la fonction "dim".
Une taille inconnue se signale par l'utilisation de "*" entre les crochets.
Il semblerait cependant y avoir un problème à ce niveau dans le compilateur.
Instructions
Celles-ci sont séparées par un ";" (qui est, je le rappelle, un séparateur et pas un terminateur).
Draco respecte les conventions chères à Pascal et C dans ce domaine. En vrac, on trouvera :
- Des affectations (utilisation de ":=").
- Des appels de procédures (vérification du type et du nombre d'arguments). Comme en C,
les parenthèses doivent être présentes, même si la procédure appelée n'a pas de paramètres.
- Des instructions conditionnelles :
- Le "while" de Draco se rapproche davantage du "for" de C que de son homologue Pascal.
Il permet, en effet, d'inclure des instructions avant l'expression à tester.
Ceci permet une plus grande souplesse mais ne remplace pas le "repeat-until", étonnamment absent de Draco.
- Les boucles "for" permettent juste de préciser le pas et acceptent comme index des variables numériques
(signée ou non), une valeur d'énumération ou un pointeur.
Le compilateur apporte un soin particulier pour la production de code des boucles "for", qui sont toujours très
présentes dans les programmes. Je vais y revenir plus bas.
- Instructions d'aiguillages : case.
Pas grand-chose à ajouter sur "case", si ce n'est que le compilateur produira du code différent en
fonction du nombre et des intervalles des alternatives.
- Les entrées/sorties sont incluses dans le langage, et utilisent notamment "write" et "writeln",
fidèles compagnons des programmeurs Pascal. Elles autorisent également une sortie formatée, et
leur utilisation peut s'étendre à la gestion des fichiers, et plus généralement à des "channels",
qui sont une autre particularité de Draco par rapport aux autres langages.
- Les instructions "new" et "free" peuvent être utilisées, ou remplacées par "Malloc" et "Mfree",
qui font partie d'une bibliothèque à part.
- La coercition ("coercion" ou "to force" en anglais) est également disponible, en la présence
de "pretend". Elle permet d'effectuer une conversion de type sur un résultat. Elle ne sera considérée
comme instruction que dans le cas où cette coercition produit comme résultat un "void"
(dans le cas contraire, un résultat est rendu et il s'agit d'une expression).
Le premier "pretend" est une instruction alors que le deuxième, en tant qu'expression, ne peut être
utilisé tel quel.
- L'instruction "error" permet d'afficher un message d'erreur lors de la compilation. C'est un
autre aspect du compilateur qui met cette instruction en valeur. En effet, toute valeur constante
est calculée lors de la compilation, et si un "if" agit sur une expression booléenne qui est
connue dès la compilation et se révèle comme fausse, le code du "then" n'est pas produit. Ceci
permet de faire de la compilation conditionnelle.
Si "DEBUG" est déclaré comme constante et initialisé à "false", le code du "writeln"
ne sera jamais produit. Ces deux aspects sont présents pour simplifier les problèmes éventuels
de portabilité et, plus généralement, afin de s'assurer de la cohérence d'un code.
Aspects spécifiques
Deux constructions ont été ajoutées dans le langage afin de permettre une programmation plus
spécifique à l'Amiga. La première est l'instruction "code" qui permet, lors de la compilation,
d'insérer un code machine spécifié dans les arguments. Par exemple, sachant que le code du RTS
en 68000 est 0x4e75, on le produirait avec code (0x4e750000). La deuxième est le "@"
qui permet d'imposer une adresse absolue à un pointeur ou à une procédure. L'avantage est double :
d'abord de pouvoir faire coexister deux variables au même emplacement mémoire (exercice très
dangereux) et d'autre part de pouvoir déclarer des procédures à des endroits absolus en mémoire,
ce qui permet d'appeler des routines systèmes en Draco.
Utilisation sous AmigaDOS
Le compilateur est réparti en deux disquettes, l'une contenant toutes les docs
et quelques sources, l'autre les includes et les binaires (avec un éditeur de source et deux
jeux écrits en Draco dont l'un, Empire, fait beaucoup parler de lui).
Les sources Draco se terminent par ".d", les includes par ".g" et les objets par ".r"
(drôle d'idée, probablement héritée de l'implémentation CP/M). Le compilateur s'appelle
Draco et l'éditeur de liens utilisé est le classique Blink. Il existe plusieurs bibliothèques
(les ".lib") et trois modules de démarrages (équivalents aux "c.o" du C) : l'un dédié aux
réels (drstartf.r), l'autre au démarrage standard (drstart.r) et le dernier aux programmes
sans startup (drstart0.r). Ce dernier ne consiste qu'en deux instructions : la sauvegarde des
paramètres de la ligne de commande, puis la main vous est rendue. Ceci permet une constatation
immédiate : il est très possible de produire des programmes très petits !
Ce programme produit un exécutable de 108 octets ! Autrement dit, il est possible virtuellement
d'écrire de l'assembleur dans un langage structuré. Et vous n'êtes pas au bout de vos surprises :
le code produit est optimal ! Autrement dit, je n'aurais pas (ou presque) fait plus court si
je l'avais écrit à la main. En comparaison, le code produit par le Lattice est beaucoup plus lourd.
Sans compter les innombrables modules qu'il ajoute sans vous prévenir.
Du point de vue vitesse de compilation, sur tous les programmes où j'ai fait la comparaison,
Draco allait toujours plus vite que lc (v5.04, je serais curieux de connaître le résultat de
la comparaison avec l'Aztec. Quelqu'un a-t-il déjà fait les tests ?). Sans toutefois généraliser
ces comparaisons (faites sur des programmes courts), il est indéniable que les deux compilateurs
sont sur un pied d'égalité.
Bien évidemment, Draco est fait pour pouvoir entièrement utiliser l'Amiga. Rien de plus facile que
d'appeler les fonctions des bibliothèques comme la dos.library (ce qui aura pour effet de diminuer
encore la taille des exécutables qui font des E/S), graphics.library, etc. Toutefois, la technique
utilisée pour ouvrir ces bibliothèques diffère de celles utilisées jusqu'à présent. Il suffit
d'appeler des fonctions spécifiques (par exemple OpenDosLibrary(version)) et de tester si le résultat
est non nul. Ceci ne restreint en rien l'utilisation qu'on peut en faire par la suite, les prototypes
des fonctions étant déclarés dans les includes correspondants.
Pour finir, un include spécial "util.g" contient les prototypes de fonctions utiles pour analyser
les arguments de la ligne de commande, gérer les fichiers, faire des manipulations sur les chaînes,
sur les recopies de mémoire, etc.
Je passe sous silence de nombreux autres aspects intéressants de Draco (notamment le type opérateur
et l'utilisation des "channels", qui généralisent la notion d'E/S en les rattachant indifféremment
à des fichiers ou encore des chaînes de caractères). Il est malheureusement impossible de décrire
le langage dans son ensemble.
Conclusion
Chris Gray reconnaît fort honnêtement que la version actuelle du compilateur (1.2) présente encore
certaines lacunes, qu'il énumère dans sa documentation. Une nouvelle version est en cours de test
et devrait voir le jour d'ici trois ou quatre mois. Le compilateur sur Amiga est malgré tout un
petit bijou et commence à être beaucoup utilisé dans le domaine public. Il pourrait fort bien
devenir dans les mois à venir un concurrent très sérieux pour le C car il surpasse les compilateurs
existants dans bien des domaines.
|