Macros en ASM inline - Page 2

" (offset), "a" (a)); \ } \ else \ asm(" bset.b %0,0(%2,%1.w)" : : "g" (n), "d" (offset), "a" (a)); \ })

J'ai réécrit la macro de façon à ce qu'elle génère le meilleur code possible dans tous les cas, et ça donne ça : #define EXT_SETPIX_AN(a,offset,n) ({if(__builtin_constant_p(offset)) \
	{	\
		if(__builtin_constant_p(a))	\
			asm(" bset.b %0,%c1" : : "g" (n), "i" ((offset)+(a)));	\
		else	\
			asm(" bset.b %0,%c1(%2)" : : "g" (n), "i

Ce code est assez moche, mais il permet de générer le meilleur code possible dans tous les cas (enfin, le meilleur code que j'ai trouvé).
En fait, il y a d'autres macros qui sont utilisées pour donner l'offset en fonction des coordonnées du point et le numéro du bit.
Voilà, donc je m'adresse surtout à XDanger pour lui demander s'il est prêt à mettre ça dans ExtGraph ou bien on garde l'autre macro moins agressive à l'oeil quand on la lit (mais légèrement plus lente dans certains cas).

Je suis parfaitement prêt à mettre ça, aucun problème. GCC sait très bien faire, donc autant exploiter à fond toutes ses possibilités !

Comment est définie EXT_PIXOFFSET ? La plus optimisée est à ma connaissance
#define EXT_PIXOFFSET ((((y)+(y))<<4)-((y)+(y))+((x)>>3))
qui génère un code qui est exactement celui qu'on génère habituellement à la main en assembleur.
On pourrait aussi définir en plus une macro du même style qu'EXT_PIXOFFSET, qui donnerait toujours une adresse paire (ce qu'on utilise dans toutes nos routines). Il est probablement possible de faire comprendre à GCC l'optimisation de Ximoon...
Quel nom (pas trop long) lui donner ?

((y)<<4)-(y))*2+((x)>>3))Voilà mon EXT_PIXOFFSET :#define EXT_PIXOFFSET(x,y) ((
Il génère sûrement un code comparable au tien. J'espère que TIGCC optimise dans tous les cas (quelle que soit l'optimisation demandée, exceptée -o0) le *2 par un add.

Pourquoi utiliser une adresse paire ?
Enfin, ça peux toujours servir. Et oui, on peut se débrouiller pour que TIGCC produise l'optimisation de Ximoon.

> Pourquoi utiliser une adresse paire ? Enfin, ça peux toujours servir.
Pour faire une fonction bien particulière qui écrive sur des words ou des longs. Rien ne dit que ça sera utilisé, mais ça sera utilisable.

> J'espère que TIGCC optimise dans tous les cas (quelle que soit l'optimisation demandée, exceptée -o0) le *2 par un add.
En effet, je pense aussi. Par contre, ma solution génère probablement un add en -O0 aussi.

Pour le *2 en add, je crois que oui (je l'ai jamais vu faire autrement)
(y))<<4)-((y)+(y))+((x)>>3))Par contre pour votre macro #define EXT_PIXOFFSET ((((y)+, c'est sur qu'il fera ce qu'on veut, mais c'est illisible.
Pourquoi pas (vous y avez surement pas pensé8)) ((y)*30+(x)/ en laissant GCC optimiser à sa guise prennant en compte -Os ou -O3 ou autre, normalement il devrait bien optimiser (s'il n'optimise pas bien, rajouter des casts en (unsigned) évite souvent des abomination, par exemple x/8==x>>3 n'est vrai que pour les positifs, et ne sera utilisé que si c'est de type unsigned)

C Bien: la macro d'ExtGraph 1.02 est moins performante, plus lisible que celles qu'on a postées. Elle reste moins lisible que la tienne, certes. Mais à peu près n'importe quel débutant comprend bien ce que la routine fait...

Le mulu #30 et la séquence de 4 instructions n'ont que quatre octets de différence, mais le mulu est plus lent. Je pense qu'on laissera comme ça. Il ne faut pas toujours chercher ce genre d'optimisations taille à tout prix, notamment lorsque d'autres optimisations qui font gagner plus de place ne sont pas faites (optimisation des valeurs immédiates redondantes, optimisations des tableaux de strings, etc.)

> s'il n'optimise pas bien, rajouter des casts en (unsigned) évite souvent des abomination, par exemple x/8==x>>3 n'est vrai que pour les positifs, et ne sera utilisé que si c'est de type unsigned)
Oui, mais ici on a une macro. Si on veut transformer du short en unsigned short dans une macro, c'est possible, mais ça devient moins lisible.
La lisibilité au détriment de la performance, je n'en veux pas trop. tthdex comporte beaucoup d'assembleur, de même qu'ExtGraph maintenant, alors que c'est moins lisible.

A mon avis, le mulu.s est certes à éviter, mais ce choix devrait être fait en fonction des options d'optimisations (comme -Os), et donc laissé à GCC.
Le but de ma macro n'est pas la lisibilté (qui ne serait que peu réduite par un cast), mais c'est de déleguer à GCC le choix de l'optimisation, selon les options en -Ox. Il sait éviter le mulu!

jackiechan
: Il génère sûrement un code comparable au tien. J'espère que TIGCC optimise dans tous les cas (quelle que soit l'optimisation demandée, exceptée -o0) le *2 par un add.

Oui.

Et je confirme aussi que les shifts/additions/soustractions sont maintenus tels quels (et non pas transformés en muls ou mulu) même avec mes modifications pour utiliser de préférence muls/mulu en mode -Os (cf. http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=86.topic).

C bien :
Pour le *2 en add, je crois que oui (je l'ai jamais vu faire autrement)
(y))<<4)-((y)+(y))+((x)>>3))Par contre pour votre macro #define EXT_PIXOFFSET ((((y)+, c'est sur qu'il fera ce qu'on veut, mais c'est illisible.
...] ((y)*30+(x)/8)Pourquoi pas [ en laissant GCC optimiser à sa guise prennant en compte -Os ou -O3 ou autre, normalement il devrait bien optimiser

Non, il considère la séquence pour multiplier par 30 trop longue et utilise muls pour multiplier par 30 même en -O2 ou -O3 (et je n'y suis pour rien, je n'ai changé les valeurs que pour optimize_size, je n'ai pas touché aux autres options).
La division pose aussi problème à être optimisée, et puis >>3 est mieux que /8 même en -Os.