 |
Samedi 20 avril 2024 - 15:22 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Pierre-Philippe Launay prend la défense du compilateur GFA
L'auteur de l'article sur la comparaison des compilateurs (Amiga News 48) ne connaissait pas le GFA et cette ignorance lui fait raconter des bêtises. Il est vrai que la documentation française nécessite une longue lecture.
Voici un extrait en 67 lignes du code produit à partir du programme test publié dans cet article d'Amiga News 48. Sa longueur est intermédiaire entre celle de l'Aztec et du SAS :
L'erreur la plus courante en GFA consiste à ne pas lire le manuel :
- GFA supposera que toutes les variables par défaut sont des flottants tandis que la majorité de ses
fonctions travaillent avec des entiers longs. L'exécutable deviendra très long si l'on
utilise ces flottants à la place des entiers.
- Le compilateur demande à supprimer les lignes complexes à l'inverse de ce que fait l'interprété :
d=(a+b+c) sera beaucoup moins rapidement calculée que d&=a&+b& d&=d&+c&
car dans le premier cas, GFA panique complètement et s'en sort en appelant des procédures spécifiques.
Dommage tout de même. Il serait bien que Frank Ostrowski se décide à ajouter un autre passage
lors de l'étape de compilation.
- La partie du lien nécessaire pour rendre le code exécutable sous CLI et Workbench est un plus du GFA que l'on peut évidemment enlever. En effet, comme je l'ai écrit dans d'autres revues, on peut obtenir des objets ".O" au format MetaComCo et l'on peut même se réécrire totalement sa propre bibliothèque de fonctions grâce à MakeDP.
L'exécutable a été désassemblé avec l'option P de Devpac depuis StartaDDR jusqu'à BaseA4. Les noms des variables ont été rajoutés pour une meilleure lisibilité du code car, dans un premier temps, GFA assigne toutes les variables du code relativement au registre A5 avant de commencer ses calculs.
GFA ne s'aperçoit pas que 3b%+b%=4b% mais GFA s'en sort avec les honneurs dans sa façon de calculer 3b% puis 3b%+b%.
Multiplication d'un long par une constante multiple de 4, excellent.
L'option de compilation entier court donne bien .W. Parfait.
82 cycles au lieu de 28 cycles = ((8+(2*4))+6)+6. Pas bien car 18*a%=(16+2)*a%=16*a%+2*a% mais c'est aussi bien que le MULU du SAS. Comme beaucoup de compilateur, GFA ne sait pas optimiser des opérations comme #constante FOIS variable où "variable" est un multiple de 4 additionné de "n".
A vrai dire, ce genre d'optimisation doit souvent être réalisé par le programmeur dans la majorité des langages car comment, dans le cas contraire, décider à partir de quelle valeur de constante le compilateur devrait optimiser. Pourquoi par exemple s'arrêter à 18 ou à 25248 ? Chaque nombre doit bien posséder une façon optimale et spécifique de le calculer en tenant compte des cycles d'instructions !
Pris en compte du format court de d&. Pas trop mal.
Excellente prise en compte. Peu de compilateurs savent faire cette distinction :
Le calcul de (d&-a%)^2 est décevant car il y a une double conversion parfaitement inutile ici mais exigée par FSQUARE. Autre version : (d&-a%)*(d&-a%) donne 166 cycles.
Autre version : e&=(d&-a%) puis e&=e&*e&.
Décevant : ces trois dernières lignes devraient être remplacées par MULS D0,D0.
GFA s'est aperçu que e& n'était pas utilisé par la suite et a préféré faire une soustraction rapide plutôt qu'une assignation et ensuite il réalise un saut .s (.b du SAS n'existe pas et est une pseudo-instruction).
Aïe et flûte et tartembique, une répétition.
i& convertie en LONG% pour la multiplication.
Excellent car il s'agissait d'une double erreur volontaire de mon code source (INT(pointeur%+e&) : mauvais calcul du pointeur et, de plus, on veut réaliser une conversion en entier avec INT() de ce qui était déjà un entier alors GFA va supposer que l'on désire éliminer les erreurs d'approximation :
- Traduire l'entier en réel FITOF.
- Extraire la partie entier FINT.
- Transformer le nouveau réel en entier FFTOI.
Autre version, la bonne, quoique :
Il y a des conversions injustifiées qu'il faudra supprimer lors de l'optimisation avec Devpac.
GFA n'utilise pas de façon optimale les registres mais il réalise un adressage relatif à A5 sur toutes ses variables. On peut le regretter dans le sens de la longueur mais à l'inverse, ce parti pris permet une excellente portabilité. Il reste cependant quelques étapes que nous ferons semblant de ne pas remarquer :
Ou bien :
On pourrait utiliser directement les registres en GFA mais cela n'y est malheureusement pas très évident. Personnellement, en C ou en GFA, je retouche toujours le code pour supprimer les assignations inutiles, ô mon Amiga, si la version allemande était disponible en France, que ne ferions-nous pas !
En conclusion
Le travail de comparaison a été réalisé sous Devpac (cela aurait pu être ASM One).
- Devpac (ou ASM One) apparaît donc encore comme le passage obligé des vrais programmeurs. C'est le langage de la passion ou de la nécessité.
- SAS apparaît comme le plus rapide des langages C et même son prix exorbitant ne doit pas vous faire reculer pour l'acheter. A moindre prix, la version commerciale de DICE n'est pas mal non plus. Précisons que sous Amiga, le C est le langage le plus sûr pour les professionnels. Sous PC, une grande majorité des programmes seront écris en... BASIC voire en Fortran ou en Pascal.
- GFA a pris du retard sur SAS et est pour l'instant un peu moins bon pour le code produit sur les opérations simples. Il reste le meilleur pour sa bibliothèque de fonctions utiles. Par exemple, l'affichage des lettres donne un exécutable plus rapide que DICE mais à peine plus rapide que SAS. En fait, GFA tirera surtout avantage de ses nombreuses fonctions dédiées et la version 4.0 lui donne en plus de nombreuses fonctions du Fortran.
- AMOS est de loin le langage le plus parfait pour les débutants car d'emblée il donne l'accès à des fonctions de jeux ou de matériels très puissantes. Les exécutables produits n'y ont pas encore la qualité du SAS sur les autres fonctions classiques. Enfin, le temps de développement est particulièrement court avec AMOS et c'est là son avantage le plus évident.
Gilles Soulet : pas d'accord
Mon article sur la rapidité des compilateurs a suscité quelques remarques (notamment sur Minitel...) et déchaîné (comme prévu !) les foudres de M. Launay, farouche défenseur du GFA Basic !
M. Launay s'est empressé de nous démontrer que le compilateur du GFA Basic pouvait lui aussi se livrer à des optimisations puissantes. Pour ce faire, il a adapté mon source C, comme vous avez pu le constater dans la première partie de l'article.
Hélas ! M. Launay n'a pas voulu respecter la règle de base, pourtant simple, que je m'étais fixée : aucune optimisation dans le source lui-même !
Ainsi, par exemple, la ligne C : c=4*a+(3*3+b) n'a pas été retranscrite en c&=4*a%+(3*b%+b%) mais a été transformée en deux lignes : c&=(3*b%+b%) puis ADD c&,4*a%.
Ceci ne représente rien d'autre qu'une optimisation du source ! M. Launay a dû chercher longtemps la façon de réaliser au mieux ce calcul en GFA, mais encore une fois il s'agit justement d'éviter au programmeur de se casser la tête ! C'est au compilateur d'effectuer la plupart des optimisations, et de se débrouiller avec le source (parfois confus !) du programmeur, afin d'améliorer le résultat. Tout le monde n'a pas connaissance de la façon optimale d'effectuer certains calculs sur tel ou tel compilateur particulier !
La véritable raison de cette optimisation du source est facile à comprendre : sans elle, ce pauvre GFA Basic génère un code extrêmement mauvais dès que l'on fait le moindre calcul dans une affectation ! Pour faire taire définitivement toute polémique, et afin de convaincre les plus réticents, je livre ici, sans commentaire, le code correspondant simplement à la ligne c&=4*a%+(3*b%+b%) obtenu sur la version 3.5 du compilateur GFA...
Non, vous ne rêvez pas ! C'est bien ce gros tas que l'on obtient pour cette simple ligne de programme ! Avouez que ça change pas mal de ce que M. Launay a obtenu avec son source si adroitement bidouillé ! Quand je vous disais qu'il me fallait trois pages dans Amiga News pour vous montrer le résultat total ! GFA Basic, langage de spécialistes...
M. Launay admet d'ailleurs dans sa lettre que lorsqu'il y a une expression un peu trop "compliquée" à calculer, "GFA panique complètement et s'en sort en appelant des procédures spécifiques" (je cite). Pourtant, il me semble que ce calcul était à la porté du premier crétin venu... En tout cas, voilà bien l'explication des fameux sous-programmes (correspondant à chaque ligne de calcul) dont je vous parlais ! Effectivement, comme le suggère fort justement M. Launay, il serait bien que Frank Ostrowski se décide à ajouter un autre passage lors de l'étape de compilation !
Ensuite, M. Launay a également "oublié" de regarder de plus près comment le GFA traite les procédures et passe les paramètres : son source ne contient plus d'appel de fonction, vu que la fonction auxiliaire "bidon" a tout simplement disparue ! Est-ce bien un oubli ? Je soupçonne en fait M. Launay d'avoir voulu cacher ici une des plus grandes faiblesses du compilateur GFA : les appels de fonction. A ce sujet, je vous conseille donc d'aller jeter un coup d'oeil à mon article sur le HighSpeed Pascal où se trouvent les temps de calcul du 27e terme de la suite de Fibonacci obtenus sur GFA, HSPascal et SAS C. Ce test est précisément très révélateur de l'efficacité des appels de fonctions, puisque le calcul se fait de façon doublement récursive. Les chiffres parlent d'eux-mêmes !
Mais le plus grave finalement, c'est que le listing de M. Launay ne fait que confirmer mes propos : malgré toute la mauvaise foi... pardon, toutes les optimisations possibles (tant au niveau des options de compilation qu'au niveau du source lui-même...) le compilateur du GFA est totalement incapable d'attribuer des registres 68000 aux variables locales. Toutes (je dis bien toutes) les variables de ce programme ont été attribuées à des cases mémoires (y compris, donc, la variable de boucle i, ce qui est proprement scandaleux !).
Moralité : GFA n'utilise guère que les registres D0 et D1 pour ses calculs. Que penser d'un tel compilateur dans ces conditions ? Quand on connait le gain de rapidité que représente le fait de travailler sur des registres, quand on sait que des millions d'utilisateurs de PC envient les possesseurs de 68000 car ce microprocesseur possède beaucoup de registres (contrairement au 8086 d'Intel) on s'étonne encore que M. Launay puisse défendre son langage fétiche ! Ceci étant dis, je félicite quand même sportivement M. Launay pour le travail qu'il a accompli sur GFA. Visiblement, il défend toujours bec et ongles un langage qui est pourtant, de l'avis de tous (y compris de son distributeur !) complètement dépassé.
M. Launay, dépensez plutôt votre énergie et vos talents sur d'autres langages plus sérieux et plus d'actualité sur l'Amiga : C, Pascal, ARexx et assembleur 680x0 aujourd'hui, en attendant C++, ADA ou Smalltalk demain ?
|
