🚀 go-pugleaf

"Antoine Leca" <root@localhost.invalid> wrote in message
news:dg3hhd$kuf$1@shakotay.alphanet.ch...
> En <news:mn.52367d59df2fc1aa.31483@laposte.net>, Pierre Maurette va
> escriure:
> > Je pense qu'il n'y a qu'une seule alternative: soit respecter les
> > conventions d'appel, soit d�velopper la fonction inline.
>
> Non. Les conventions d'appel ne sont pas forc�ment uniques, tu peux (et
> g�n�ralement tu as, pour des raisons de march� et de diff�renciations
> marketing) des extensions ou des options (#pragma) permettant de les
> modifier.
> De plus, si les conventions de passage sont par pile, en g�n�ral cela va
> cr�er une contrainte d'ordre partiel. Mais si les conventions utilisent les
> registres, cette contrainte dispara�t ; et les compilateurs actuels vont
> magouiller l'expression pour espacer le plus possible les interactions avec
> chaque espace de m�moire (y compris les registres), histoire de remplir tous
> les pipelines parall�les.

Ne m�lange pas les conventions d'appel et l'ordre d'�valuation des param�tres,
ceux-ci peuvent �tre �valu�s dans n'importe quel ordre, voire de facon
concommitante et les r�sultats sont ensuite mis sur la pile dans le bon ordre
pour respecter la convention d'appel.

Voici deux techniques possibles : les parametres peuvent etre evalu�s dans des
registres et ensuite les registres sont pouss�s sur la pile dans l'ordre
ad�quat.  Ou encore le pointeur de pile est ajust� et les parametres sont
evalu�s et mis sur la pile avec un mov dans l'ordre que le compilateur choisit
avec des crit�res hors du controle du programmeur.

Par exemple, l'excellent compilateur en une passe de Fabrice Bellard TinyCC (
http://tinycc.org ) genere le code des expressions arguments de fonction au vol
directement dans la phase de parse.  Ce code s'�x�cute donc en g�n�ral dans le
m�me ordre quelle que soit la convention d'appel, et la technique d�crite
ci-dessus est utilis�e pour que les param�tres soient dans le bon ordre, non
sans mal dans certains cas (listes d'arguments variables).

Se reposer sur une telle connaissance du compilateur pour �crire un code non
portable n'a d'int�r�t que pour le concepteur de compilateur ou de suites de
test, c'est une pratique � bannir pour le reste des programmeurs, qui seront
forc�ment punis un jour ou l'autre d'avoir pris de telles habitudes risqu�es.

De plus des cas simples comme fun(i++, i++) devraient �tre refus�s par le
compilateur qui devrait d�tecter le comportement ind�fini facilement
identifiable.

-- 
Chqrlie.