Macros en ASM inline - Page 1

En voulant faire les macros d'ExtGraph 2 pour les pixels, je me suis heurté à un petit problème : je n'arrive pas à dire à TIGCC quels registres il doit [fr]clobber[/fr].
] "d" (temp));})

Voici ma macro :EXT_PIXOFFSET(x,y) ({register short temp; \
asm("move.w %[y],%[temp]; lsl.w #4,%[y]; sub.w %[temp],%[y]; add.w %[y],%[y]; lsr.w #3,%[x]; add.w %[x],%[y]" \
: [y] "=d" (y) : [x] "d" (x), [temp

Le problème, c'est que cette macro modifie les valeurs de x et de y, donc j'aimerais pouvoir demander à TIGCC de sauver ces valeurs.
Bien sûr, je pourrais le faire moi même, mais j'ai envie que ce ne soit fait que si nécessaire, donc en demandant à TIGCC de le faire automatiquement, je pense qu'il saura ne pas la faire lorsque ce ne sera pas nécessaire.

[edit] au fait, je ne suis même pas sûr que ce que j'ai posté soit correct (en dehors du fait que je ne [fr]clobber[/fr] pas les registres que je détruit), enfin, je veux dire que je ne suis pas sûr que ma macro retourne vraiment une valeur. Mais ça, ça n'est pas important, je sais y remédier, ce n'est pas ça l'actuel problème

Il faut les déclarer aussi en sortie. Déclare des variables short dummy1, dummy2 (pas la peine de mettre register, GCC ignore complètement ce mot-clé) et passe-les en output. Dans ton cas, ça donnera:

EXT_PIXOFFSET(x,y) ({short temp, result, dummy; \
asm("move.w %[y],%[temp]; lsl.w #4,%[y]; sub.w %[temp],%[y]; add.w %[y],%[y]; lsr.w #3,%[x]; add.w %[x],%[y]" \
: "=d" (dummy), "=d" (result), [temp] "=d" (temp): [x] "0" (x), [y] "1" (y)); result;})

D'ailleurs, cette macro devrait être laissée en C! C'est idiot de la mettre en assembleur parce que ça n'optimise rien du tout (GCC sait donner ce code-là de lui-même) et ça empêche aux optimiseurs de GCC de travailler sur cette expression (par exemple si un des paramètres est constant - ta macro en assembleur inline en fera du code affreux)!

Merci Kevin.

Je n'avais pas pensé au cas où on passerait des valeurs constantes à la macro, tu as raison, ce serait mieux de la laisser en C...
move.w %[x],%[temp] lsr.w #3,%[temp] add.w %[temp],%[y] not.w %[x] bset.b %[x],(%[dest],%[y].w)

Mais pour les macros d'affichage de pixel, je ne pense pas que TIGCC puisse produire un code du genre : move.w %[y],%[temp]
 lsl.w #4,%[y]
 sub.w %[temp],%[y]
 add.w %[y],%[y]
 

Enfin, c'est surtout pour la fin, que je m'inquiète...

En revanche, ta macro assembleur donnera une horreur avec EXT_SETPIX(10,20).
Utilise __builtin_constant_p. http://tigcc.ticalc.org/doc/gnuexts.html#SEC104___builtin_constant_p

Je vais voir ce que je peux faire.
Il est évident que si je ne peux pas arranger les choses avec les paramètres constants on gardera les macros C qui sont déjà très rapides.
Sinon, je peux mettre de l'asm juste pour le bset, non ?

Probablement oui.

Je galère depuis près d'une heure pour trouver mon problème
ETPIX_AN(EXT_PIXADDR(p,x,y),~(x))

Voici les macros que j'ai écrites :#define EXT_PIXOFFSET(x,y) ((((y)<<4)-(y))*2+((x)>>3))
#define EXT_PIXADDR(p,x,y) (((char *)(p))+EXT_PIXOFFSET(x,y))
#define EXT_SETPIX_AN(a,n) asm(" bset.b %[n],(%[dest])" : : [n] "g" (n), [dest] "a" (a))
#define EXT_SETPIX(p,x,y) EXT_S

Et quand je compile un EXT_SETPIX(LCD_MEM,x,y);, je me retrouve avec un Parse error before '~' token. Je ne vois vraiment pas d'où ça vient, ça fait une
heure que je cherche...

tigcc -E ?

Un petit tigcc -Os --save-temps test7.c et voilà l'erreur:
__asm__(" bset.b %[n],(%[dest])" : : [~(x)] "g" (~(x)), [dest] "a" ((((char *)(((void*)0x4C00)))+((((y)<<4)-(y))*2+((x)>>3)))));

Donne un autre identifiant que n à ta variable, ou alors utilise un identifiant numérique. (De toute façon, je ne comprends pas pourquoi tu mets des identifiants littéraux pour des asm d'une ligne, ça ne sert à rien. Ça crée juste des problèmes comme celui-ci.)

Merci.
Si par exemple, quelqu'un utilise une variable var et que je choisis d'utiliser ce même nom comme identifiant littéral dans un asm(); ça créera une incompatibilité ?
Si je mets des identifiants littéraux, c'est simplement pour que le code soit plus lisible. C'est vrai que pour une ligne, ça n'est vraiment pas indispensable.

jackiechan a écrit :
Si par exemple, quelqu'un utilise une variable var et que je choisis d'utiliser ce même nom comme identifiant littéral dans un asm(); ça créera une incompatibilité ?

Non. Seulement si c'est utilisé pour une macro (ou pour un paramètre de ta macro comme c'était le cas ici, mais ça, c'est à toi de le résoudre).

.w %d3,%d1 asr.w #3,%d1 add.w %d1,%d0 bset.b %d2,(%a2,%d0.w)

Bon, le code généra pour EXT_SETPIX est très optimisé, je trouve :#$001C4	EXT_SETPIX(dest,x,y);
	move.w %d3,%d2
	not.w %d2
	move.w %d4,%d0
	lsl.w #4,%d0
	sub.w %d4,%d0
	add.w %d0,%d0
	move

est,x,y)) printf("PixelOn"); move.w %d3,%d2 not.w %d2 move.w %d4,%d0 lsl.w #4,%d0 sub.w %d4,%d0 add.w %d0,%d0 move.w %d3,%d1 asr.w #3,%d1 add.w %d1,%d0 lea (%a2,%d0.w),%a0 #APP btst.b %d2,(%a0); sne.b %d2; neg.b %d2 | Ça, c'est ma macro #NO_APP tst.b %d2 jbne .L23Par contre, je peine pour que EXT_GETPIX génère un code aussi performant... Parce que l'instruction btst permet de tester un bit et positionne les indicateurs en fonction de cela, mais je n'arrive pas à trouver un moyen pour TIGCC se serve de ça. Ça m'éviterait de sortir une horreur du genre :#$001CC if(EXT_GETPIX(d

As-tu essayé ce que donne peek_bit (dans TIGCCLIB) comme code?

Si vraiment il n'y a pas moyen d'avoir du code correct autrement, je peux peut-être rajouter un __builtin_m68k_btst à GCC. Mais je préfèrerais ne pas avoir à faire ça.

move.w #19456,%a0
clr.w %d0
move.b (%a0),%d0
asr.w %d3,%d0

pour
short x,y;
[...]
x = peek_bit (0x4C00, y);

mais il faut encore tester d0 à la sortie, c'est pas une solution...

Ce n'est pas x=peek_bit(0x4c00,y) qui nous intéresse vraiment, mais if(peek_bit(0x4c00,y)) puts("toto");.

clr.w %d0
move.b 19456.w,%d0
asr.w %d3,%d0
and.w #1,%d0
lea (20,%sp),%sp
jbne .L20

Et je sens que, plutôt de rajouter un builtin, je ferais mieux de faire en sorte que le code C de peek_bit donne un btst, parce que ça serait utile dans pas mal de cas.

D'après m68k.md, GCC est censé reconnaître un btst dans cette situation. Je n'ai aucune idée pourquoi ça ne marche pas.

Merci Kevin, si tu rajoutes une extension

C'est dommage, j'ai l'impression qu'on ne peut pas utiliser condition?instr1:instr2; si on met des asm("") pour les instr.

tantes est proche de ça : move.w #1800,%d0 bset.b #-7,0(%a0,%d0.w)Sinon, le code généré pour des valeurs cons'est pas hyper optimisé, on pourrait faire : bset.b #-7,1800(%a0)C'est bien, mais ce nelle on veut afficher notre pixel est connue, ce serait mieux de faire : bset.b #-7,1800+$4C00Et si l'adresse à laqu(en supposant qu'on affiche sur LCD_MEM).
Mais ça fait beaucoup de cas à gérer. Et puis je n'arrive pas à générer de l'adressage indirect, à chaque fois, je me retrouve avec bset.b #-7,#1800(%a0).

ce n'est pas de l'addressage indiret, ça?

Non, il y a le '#' en trop

jackiechan a écrit :
Mais ça fait beaucoup de cas à gérer. Et puis je n'arrive pas à générer de l'adressage indirect, à chaque fois, je me retrouve avec bset.b #-7,#1800(%a0).

%c1

Merci, c'est indiqué où, dans la doc ?

Merci Kevin.
(C'est aussi dans le .chm ou pas ? parce que je n'ai pas trouvé)

jackiechan
a écrit : C'est aussi dans le .chm ou pas ?

Non. C'est caché sous "GCC Internals", c'est pour ça qu'on ne l'a pas dans notre CHM. Il faudra qu'on rajoute ça.