	GNU: un compilateur qui rflechit!
	**********************************


	Sans penser  mal, rien de tel qu'un dsassemblage pour comprendre
comment fonctionne un programme. Il m'a souvent t donn de regarder 
l'intrieur de programmes sortis d'un compilateur "C": c'est l qu'on
comprend toute la difficult d'un tel outil, c'est  dire comment
optimiser...

GNU et Pure C
-------------

	Je me suis intress  ces deux compilateurs en mode 68030 avec
une unit de calcul flottant, le FPU 68882. Je suis parti de ce petit bout
de programme:

double pourcent(a,b)
	{ return((b-a)*100.0/a); }

	Que j'appelais ainsi aprs avoir rempli mes deux variables x et y
avec deux nombres rels:

	z=pourcent(x,y);

	Cette fonction renvoit le pourcentage d'augmentation de y par
rapport  x. Exemple, si x=50 et y=52, il y a 4% d'augmentation.

	Je passe le programme  la moulinette des deux compilateurs et l,
surprises....

Format DOUBLE
-------------

	Premire constatation, chez Pure C un nombre DOUBLE tient sur 10
octets et chez le GNU il n'en occupe que 8. D'aprs les informations que
j'ai pu rcolter sur le FPU, les 10 octets du format tendu ne sont
utiliss qu'en interne par le coprocesseur afin de limiter les erreurs.
Par contre, ds qu'il dialogue avec l'extrieur, il n'a que 8 octets
significatifs!
	Pure C s'encombre donc de deux octets inutiles pour chaque nombre
rel qu'il utilise. Ceci occasionne une dpense de RAM dans les
applications traitant une grande quantit de donnes et une perte de
vitesse: transfrer 10 octets prends plus de temps que 8.
	Et puis, en informatique, 8 est un nombre rond alors que 10 est
batard: accder au 100eme lment d'un tableau de rels sur 8 octets
revient  faire un dcalage sur 100, alors qu'avec 10...
	Un point pour le GNU.

Les sous-programmes
-------------------

	Deuxime constatation: si le Pure C contient un saut vers la
fonction pourcent, le GNU n'en a pas, et pour cause... Il a simplement
remplace l'appel  une fonction par le code de cette fonction elle-meme.
	Ceci est des plus malin: il a intelligement estim que cette
fonction tait assez courte et que lui ajouter un saut (instruction jsr)
et un retour (instruction rts) alourdit de manire consquente le code. En
effet, ajouter deux instructions  une dizaine revient  +20% de code.
Sans compter la dsoptimisation qu'occasionne une rupture d'instructions
lors d'un saut.
	Deux points pour le GNU.

Plus fut que le programmeur
----------------------------

	J'avais ensuite envie de faire des tests de temps, je transforme
mon appel en:

	for(i=0;i<LIMITE;i++)
		{ z=pourcent(x,y);}

	Ceci afin d'utiliser suffisament le code pour en estimer la dure,
un seul passage tant non mesurable avec le Timer au 1/200eme. Je fus
alors sidr en voyant les temps: le Pure C se trainait lamentablement
alors que le GNU ne semblait pas decoller de la seconde quelque
soit la LIMITE fixe.
	La encore, le dsassemblage fut la solution. Mon bout de programme
est un non-sens de programmation. Le calcul de Z ne dpend que de X et Y.
Et comme ces deux derniers ne varient pas, calculer Z une fois donne le
meme resultat que calculer Z mille fois.
	Le GNU s'en est rendu compte et ne fais effectivement le calcul
qu'une seule fois: le reste de la boucle tourne a vide.
	Trois points pour le GNU.

Encore plus que plus
--------------------

	Au sortir de ma boucle, mon programme affichait Z. J'ai retir
cette instruction. De ce fait, Z lui meme devient inutile. Le GNU s'en
rend aussitot compte et travaille alors dans une boucle vide sans jamais
calculer la fonction pourcent! Le Pure C lui, mouline comme il peut...
	Quatre points pour le GNU.

Et meme plus
------------

	Un coup d'oeil au reste de la boucle montre que le GNU met un soin
particulier  utiliser au maximum les registres du CPU et du FPU. Par
exemple, mon compteur i et la valeur LIMITE sont des registres CPU. Dans
le Pure C, ce n'est pas systmatiquement le cas, d'autant plus que j'avais
declar i en LONG (4 octets) et non en INT (2 octets) ce qui semble le
perturber au niveau de l'optimisation.
	Autre optimisation, la valeur 100.0 utilise dans la fonction
pourcent, comme toutes les puissances de 10, est une constante incluse
dans le FPU. Le GNU utilise cette constante alors que le Pure C a mis la
valeur 100 en RAM sur 10 octets qu'il faut  chaque fois charger vers le
FPU.
	Cinq points pour le GNU.

Les utilisateurs
----------------

	J'ai recueilli les avis de deux utilisateurs. L'un d'entre eux,
Olivier Landemarre, souligne les qualits du Pure C: rapidit de
compilation, programmes plus compacts en sortie, besoin de moins de RAM,
passage de paramtres par registres et non sur la pile. Mais il n'enscence
pas moins le GNU: nombre impressionnant de paramtres permettant d'affiner
la compilation et de tirer le meilleur parti de chaque processeur, grande
portabilit, bugs corrigs car c'est un kit qui volue encore.
	Le second, Franois le Coat, partage sensiblement le meme avis: le
Pure C est parfait lorsque le source a t conu en fonction de ses
limitations. En revanche, pour un programme comme POV, l'adapter au Pure C
est un travail de titan: dans ce cas le GNU se revle bien plus  son
aise, fournit un excutable plus rapide et moins bugg.

Ou peut-on le trouver?
----------------------

	Sur ce site FTP allemand par exemple:

ftp.tu-harburg.de/pub/software/systems/atari/gnu/gcc/2.8.1/gcc-281c.lzh

	C'est donc la version 2.8.1 la dernire en date ou moment ou
j'cris ces quelques lignes.


En Bref
-------
	Sur Atari la puissance des machines ne change pas tous les 4 mois.
Il nous faut trouver des solutions logicielles pour compenser. Le Pure C a
sans doute fait son temps, meme si il est extremement convivial et facile
d'accs.
	Le GNU tire bien mieux parti de nos processeurs, l'optimisation
est de bien meilleure qualit, la rflexion autour du source prend
vraiment en compte l'etat prcdent et l'utilisation  venir des calculs
en cours. Il reste que cet outil de dveloppement est plus obscur, mais
faire l'effort de s'en servir vaut certainement le coup.

	Et puis, le GNU C n'est pas limit au monde Atari, il permet de
rcuprer les sources d'autres programmes dvelopps sur d'autres
plateformes avec un minimum d'adaptation surtout depuis que des cartes
VGA/SVGA standard sont connectables sur un Atari (NOVA sur TT, cartes sur
Hades, Milan). C'est d'ailleurs avec "la bible du PC" que je sais o taper
dans les registres Hardware de ma carte NOVA.
	N'avez vous pas entendu parler de jeux sur PC dont les sources
sont disponibles? C'est tentant, non?

	Guillaume Tello
	gtello@wanadoo.fr
