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
|
|
|
|
Test : Compilateur GFA Basic
(Article écrit par Mips et extrait d'Amiga News Tech - mai 1991)
|
|
A l'heure où le GFA Basic arrive en fanfare sur le marché PC, la version Amiga est relativement délaissée.
Il aura fallu attendre très longtemps avant que les utilisateurs français ne puissent compiler leurs
programmes, sans recourir à une version allemande ou anglaise de cette arlésienne des compilateurs.
Comme l'a déjà déclaré Franck Ostrowski, il s'est à peu près vendu un
GFA Basic original pour six piratés, ce qui n'a certainement pas joué en la faveur du développement de la
version Amiga. Cela dit, nous allons faire un compte rendu de ce compilateur qui offre une accélération sensible
de la vitesse des programmes, et permet surtout la diffusion de logiciels autonomes, ne nécessitant pas le
moindre "run-time" ni de bibliothèque additionnelle.
L'un des intérêts principaux de l'environnement du compilateur GFA vient de ce que les sources du Shell
(qui permet d'utiliser le compilateur et l'éditeur de liens automatiquement sans passer par le CLI),
sont fournis. Ces sources sont évidemment écrits en GFA, et il est donc possible à tout programmeur de
personnaliser son environnement. Par exemple, cela permet de choisir par défaut les options de compilation que
l'on utilise le plus souvent. Les plus exigeants pourront même complètement réécrire toute cette interface.
La disquette du compilateur comprend plusieurs fichiers : GFA_BCOM, qui est le compilateur proprement dit, GL,
l'éditeur de liens, GFAlib, GFAlibrary et GFAlibrary.index, qui sont les fichiers de bibliothèques
nécessaires à la constitution du programme final, ainsi que MENUX, qui n'est autre que le programme d'environnement
dont nous venons de parler.
Passons maintenant aux options de compilation, souvent très intéressantes pour l'optimisation du code.
Tout en options
La première, %3, contrôle le type de code produit pour la division. Si %3 est activée, le compilateur génère toujours
le code correspondant à une division entière. Cela est très intéressant lorsque le programme ne comporte pas de
calculs en virgule flottante, car le code produit est beaucoup plus rapide et concis. Avec %3 activée, une routine
simple de division sur deux longs mots est appelée. Lorsque deux variables sur deux octets sont divisées, c'est
l'instruction 68000 DIV qui prend le relais.
Une autre directive, *&, agit sur la multiplication de deux variables entières dont l'une au moins est une variable
sur quatre octets. Dans le cas standard, c'est une routine de multiplication de deux variables sur quatre
octets qui est appelée. Cependant, si *& est activée, l'instruction MULS du 68000 sera utilisée à la place. A
utiliser avec précaution donc, car MULS multipliant deux valeurs sur deux octets, cela peut tronquer une valeur
significative sur quatre octets participant au calcul.
L'option $m réserve de la place mémoire pour le programme. D'autre part, il existe aussi des options $&
et S< qui optimisent les blocs SELECT..CASE en fonction de la vitesse ou de la taille du code à générer.
Pour en finir avec l'optimisation, quelques astuces : il est préférable de décomposer en plusieurs lignes des
calculs complexes sur des nombres entiers, ce qu'il est inutile de faire sous l'interpréteur. D'autre part,
tous les types de boucles tournent aussi rapidement une fois compilés, ce qui n'est pas le cas sous l'interpréteur
où FOR..NEXT est nettement plus rapide que WHILE..WEND ou REPEAT..UNTIL. Enfin, les routines utilisant des boucles à
variables globales sont souvent plus rapides que celles employant des variables locales, ce qui est souvent le
contraire de ce qui se passe en C.
Performances
Du côté des performances, je me suis livré à quelques tests sanglants histoire de justifier ma réputation. Voici
tout d'abord une série de petits tests aussi anodins qu'efficaces pour comprendre ce qu'apporte vraiment le
compilateur dans tous les compartiments du jeu... Le listing ne détaille pas l'intégralité du programme, ce qui a
peu d'intérêt, mais présente chacune des procédures de test. Les temps relevés sont exprimés en secondes, pour
l'interpréteur et le compilateur. Les tests ont été effectués dans un premier temps sur un Amiga 2000 standard,
et ensuite sur la configuration la plus rapide que l'on puisse constituer aujourd'hui à base d'Amiga, à savoir
un A2000 équipé d'une GVP 68030 à 50 MHz.
Le gain apporté par le compilateur est également affiché. Comme vous pouvez le voir, tous les domaines ne
sont pas affectés de la même façon.
Tests de performances rapides GFA Basic
1) Machine de test : Amiga 2000. 68000/7 MHz, 3 Mo de mémoire
2) Machine de test : Amiga 2000, 68030/50 MHz, 9 Mo de mémoire
On peut faire quelques constatations à la lumière de ces chiffres. Premièrement, il est assez logique que la vitesse
d'affichage ne soit pas ou très peu modifiée, sachant qu'elle est prise en compte pour une bonne partie par les
circuits graphiques. En revanche, il est plus curieux de constater que les calculs en virgule flottante ne sont
pas accélérés par la compilation. Le principal reproche que l'on peut faire à ce compilateur est d'ailleurs l'absence
de gestion des coprocesseurs arithmétiques 68881 et 68882, ce qui limite ses prétentions dans le domaine du calcul
scientifique. C'est d'autant plus dommage que le GFA offre dans ce domaine des caractéristiques uniques, comme les
opérations de calcul matriciel, une petite merveille pour la CAO, l'analyse des données et autres domaines gros
consommateurs de matrices.
Sur l'ensemble des programmes courants, on peut raisonnablement s'attendre à un gain variant entre 50 et 100%
après compilation. Notons toutefois que des programmes n'utilisant que l'arithmétique entière peuvent bénéficier
des options d'optimisation vues plus haut, et tourner 4 à 5 fois plus vite que leur équivalent interprété.
Bataille d'interprètes
Puisque le GFA Basic est sorti sur PC (le compilateur n'est pas encore disponible), je n'ai pas résisté à
l'idée de faire une comparaison entre l'interpréteur GFA Basic en version 386/387 et l'interpréteur GFA
Basic sur Amiga. Voici les temps en secondes obtenus sur les mêmes tests par un 486/33 MHz, comparés à ceux de la GVP 50 MHz :
Sachant que les deux versions du GFA Basic sont écrites à 100% en assembleur sur les deux architectures, cela
laisse rêveur quant à la soi-disant rapidité des processeurs Motorola, non ? Précisons tout de même que les
écarts effarants en vitesse d'affichage viennent aussi du fait que l'affichage de texte sous MS-DOS utilise
un "vrai" mode texte, alors que l'on est toujours en mode graphique sur Amiga.
Quoiqu'il en soit, le compilateur GFA permet de générer des programmes rapides et autonomes. Allié à la
souplesse de l'interpréteur, il permet de développer efficacement un grand nombre d'applications sans avoir
besoin de recourir au C ou à l'assembleur, et surtout en beaucoup moins de temps. Dernier atout, et non des moindres,
écrire un programme en GFA Basic est maintenant un gage de portabilité vers le monde PC, ce qui pourra tenter un
certain nombre de développeurs soucieux de rentabiliser leurs travaux...
Nom : Compilateur GFA Basic.
Éditeur : GFA Systemtechnik (Micro-Application pour la version française).
Genre : compilateur.
Date : 1991.
Configuration minimale : Amiga OCS, 68000, 512 ko de mémoire.
Licence : commercial.
Prix : 450 FF.
|
|
