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 : C - choix du compilateur, efficacité du code généré
(Article écrit par Gilles Soulet et extrait d'Amiga News - juillet 1992)
|
|
Ça y est ! Vous vous êtes enfin décidé à programmer sérieusement sur votre Amiga.
Vous voulez créer vos propres exécutables, sans utiliser d'interpréteur. Vous voulez que
vos programmes soient courts, rapides et indépendants, mais l'assembleur ne vous inspire
pas du tout. Bref, il vous faut un langage compilé.
Le bon choix
Parmi les langages compilés existant, le C est le plus connu et représente certainement le meilleur
choix. Même si c'est un langage assez difficile à apprendre et à maîtriser, c'est un langage universel,
que tous les ordinateurs du monde connaissent. De plus, il est relativement portable, et il reste de
loin le langage évolué le plus rapide. Apprendre à travailler en C, c'est un investissement qui ne sera
pas perdu. Tôt ou tard, sur une autre machine, vous rencontrerez C à nouveau.
Il existe cependant d'autres langages susceptibles d'être compilés, comme le Pascal (KickPascal ou Oxford Pascal),
le Modula-2, les BASIC GFA, HiSoft et AMOS, le TurboDEX ou encode EzASM. Même si ces langages sont souvent
bien adaptés à l'Amiga, ils ont l'inconvénient d'être soit difficilement transportables sur une autre machine
(pour EzASM et TurboDEX, qui ne sont d'ailleurs que des macro-assembleurs évolués), soit pas toujours très
efficaces et très rapides à l'exécution, notamment pour Oxford Pascal.
Il commence à y avoir de plus en plus de compilateurs C sur l'Amiga. Outre les désormais célèbres
Aztec et SAS/Lattice, il existe également des compilateurs du domaine public, comme le DICE C
ou le Sozobon HCC. Le problème du choix se pose. Les critères sont nombreux, et dépendent beaucoup
de l'utilisateur. Citons par exemple le prix (gratuit pour les compilateurs DICE et Sozobon !),
la place mémoire nécessaire, l'espace disque nécessaire, l'ergonomie de l'environnement, la rapidité
de compilation, l'efficacité du code généré, etc.
C'est ce dernier critère que je vous propose d'examiner aujourd'hui. C'est un critère essentiel, qui
va décider à la fois de la taille de vos futurs programmes, ainsi que de leur vitesse d'exécution.
La compilation et l'optimisation
Il faut savoir que deux compilateurs C peuvent très bien générer des codes machine différents pour
le même programme source. Ceci est très dû souvent à l'optimisateur. En effet, lorsqu'un compilateur
analyse votre programme, il procède pas à pas, ligne après ligne, instruction après instruction.
Pour chaque instruction, le compilateur génère un équivalent dans un langage intermédiaire (source
assembleur pour Aztec, langage de quadruplets pour le Lattice) avant de créer le fichier objet correspondant.
Cette façon de procéder peut entraîner des répétitions et des opérations inutiles au niveau du code machine.
D'autre part, le source lui-même n'est pas toujours très efficace ! C'est pourquoi, avant de créer
le code machine, le compilateur procède presque toujours à une phase d'optimisation de ce code.
Dans cette phase, le code est analysé dans son ensemble : des registres machine sont attribués à
certaines variables, des boucles sont modifiées, les opérations inutiles sont éliminées, etc.
On peut parfois préciser au compilateur s'il doit plutôt améliorer la vitesse d'exécution ou la taille
du code, bien que souvent, ceci revienne au même. Nous allons particulièrement nous intéresser à
l'efficacité des optimisateurs, en termes de vitesse d'exécution et d'amélioration du code.
Tous les compilateurs ne sont pas comparables au niveau de l'optimisation. Pour évaluer la qualité
du code généré, et établir un classement de nos différents protagonistes, je vous propose un petit
source C très simple, que nous allons successivement compiler avec HCC, Aztec C et SAS C.
Ce source a été conçu pour mettre en valeur les qualités des optimisateurs. Il est abondamment commenté,
et très simple à comprendre. Ensuite, nous nous pencherons ensemble sur le code machine généré par
les compilateurs, et tirerons les conclusions qui s'imposent...
Le code source
Comme vous l'avez constaté, ce source C ne fait rien de bien extraordinaire, à part un certain
nombre de choses plus ou moins utiles et plus ou moins compliquées ! Ce source a été volontairement
non optimisé (pas de décalages, pas de variables Register, etc.) afin de laisser les compilateurs
effectuer tout le travail !
Voyons comment le Sozobon C (HCC) se débrouille
Pour un compilateur du domaine public, HCC ne se débrouille pas trop mal. On peut lui reprocher de
ne pas assez utiliser les registres du 68000, et quelques grosses fautes d'inattention !
Voyons à présent le comportement d'un célèbre compilateur sur Amiga : Aztec
Le bilan est globalement positif. A part une énorme erreur, sur le "if (0) puts..." Aztec s'en
sort pas trop mal. Mais la différence avec HCC n'est pas énorme, et en déclarant les variables Register,
on aurait sans doute obtenu un code similaire.
Voici à présent la crème des compilateurs sur Amiga : SAS C 5.10
Que dire ? On est tout simplement ébahi de voir à quel point le code est efficace, à quel point
l'optimisateur modifie les choses ! Prudence cependant ! Lorsqu'on en arrive à ce point de l'optimisation,
il devient très difficile de "tracer" un programme. N'utilisez l'optimisateur que lorsque vous êtes
sûr que le programme fonctionne correctement !
Et le Turbo C Atari
Pour en finir avec le langage C, je n'ai pas pu résister à la tentation de compiler mon petit source
sur un compilateur ultra-célèbre, longtemps considéré comme le meilleur sur 68000 :
Turbo C Atari. Les appels systèmes typiques de l'Amiga ont été remplacés par un appel à la fonction Vsync()
du BIOS de l'Atari.
Peut-on peut affirmer à présent, preuves à l'appui, que SAS C est le meilleur compilateur sur 68000 ?
Certes, TC se montre nettement moins bon que SAS C pour traiter les index
dans les boucles, pour les mises au carré, et sur beaucoup d'autres choses. Mais il a quand même
de beaux restes. SAS C peut encore progresser, en s'inspirant par exemple de TC pour
les multiplications par des constantes.
De plus, la qualité du code compilé ne fait pas tout : la qualité des bibliothèques
fournies est au moins aussi importante. Un autre critère très important est la vitesse
de compilation, domaine dans lequel Turbo C est intraitable ! En attendant la version 6.0
du SAS C, et afin de ne pas raviver certaines veilles querelles, je déclare le match nul !
À propos du GFA Basic
Je serai impitoyable, n'en déplaise à certains fanatiques qui ne jurent plus que par ce langage. Au départ,
je voulais opposer le compilateur du GFA Basic aux autres compilateurs de cet article, pensant qu'il serait
"au niveau" ! Certes, le source devait être adapté sur GFA, le langage ayant ses particularités. Ne connaissant
pas du tout le compilateur du GFA Basic, j'ai commencé tout doucement à compiler un tout petit programme, afin de
voir simplement si le code assembleur était optimisé.
Disons-le tout net, j'ai été scandalisé par la piètre qualité du résultat. Après de longues recherches
dans le code machine, j'ai pu apercevoir ce qui ressemblait vaguement à ce que j'avais demandé de faire
au compilateur. C'était l'horreur. Non content de ne procéder à aucune optimisation décente, ne serait-ce
que d'utiliser les registres, ce compilateur génère presque systématiquement un sous-programme pour chaque
opération arithmétique, et ce malgré les options sensées optimiser les calculs sur les nombres entiers.
Il faudrait au moins trois pages d'Amiga News pour vous montrer ce qu'a généré ce compilateur pour notre petit test !
Comment a-t-on pu laisser dire que ce langage était plus rapide que le C ? Certes, le GFA est un excellent
BASIC, et il s'avère très rapide en interprété. Facile à utiliser, les programmes sont vite écrits et
vite testés. Mais au niveau du compilateur, c'est une horreur. Le GFA s'avère presque toujours incapable
d'utiliser les registres machine ou d'effectuer simplement une addition 68000 quand on lui demande une addition
entre variables entières. Il utilise toujours des cases mémoires pour ces variables (y compris les variables locales)
et des sous-programmes (genre FADD, FSUB...) pour les opérations arithmétiques élémentaires. Il semble
en fait que le GFA Basic ne puisse pas réellement effectuer des calculs entiers sur des registres machines.
Ceci peut expliquer la taille des exécutables (5 ko minimum !) et le peu de différence (au niveau vitesse d'exécution)
qu'il y a parfois entre un programme en mode interprété et le même programme en mode compilé.
Il est vrai que les bibliothèques du GFA Basic sont très efficaces, notamment au niveau des fonctions
d'entrées-sorties ou des fonctions graphiques (et ceci peut expliquer la réputation de rapidité du langage)
mais au niveau du code créé par le programmeur, le GFA Basic est tout simplement lamentable !
Je mets au défi quiconque de me montrer un code assembleur généré par le GFA, meilleur que l'équivalent
généré par un bon compilateur C...
Conclusion
J'entends déjà des grincheux au fond de la salle : à quoi ça sert, tout ça ?
Est-ce que c'est si important d'avoir un code optimisé au maximum ?
Eh bien, oui ! Vous avez tous, un jour ou l'autre, pesté devant un programme qui
se traînait lamentablement. Vous avez souvent "craqué" à force d'attendre. Certains ont
critiqué les programmeurs qui ne travaillent pas en langage machine...
Tout ceci est bien fini maintenant. Car la preuve est faite que nous disposons sur Amiga d'un excellent
compilateur, un véritable pur-sang. Et ceci prouve qu'il n'est plus besoin désormais de
travailler en assembleur pour aller vraiment vite. Voyez comme SAS C optimise le code :
dans certains cas, même un humain ne ferait pas mieux !
Ce compilateur va changer bien des habitudes de programmation, et les amoureux du langage machine
(dont je fais toujours partie) vont devoir se mettre à la page.
|
