Obligement - L'Amiga au maximum

Samedi 18 novembre 2017 - 05:44  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

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

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


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


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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


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

C
C
C

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

C
C
C

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

C
C

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

C
C
C

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.

C
C
C

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 !

A 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.


[Retour en haut] / [Retour aux articles]