ASM avec opérandes C - Page 1

Je ne savais pas trop où poster ce topic, mais comme je pense qu'à peu près tous ceux qui savent coder en ASM connaissent aussi le C, il est mieux ici que dans la rubrique C.
Voilà mon problème : je fais un calcul du style a*b/c mais je ne suis pas satisfait du code assembleur produit. J'aimerais que TIGCC utilise muls puis divs, mais rien à faire, j'ai essayer de transtyper de beaucoup de façons différentes, à chaque fois TIGCC utilise __divsi3 ou bien ne fait une division que de 16 bits / 16 bits alors que moi j'ai besoin de 32 bits / 16 bits.
Je me suis donc mis en tête d'écrire une macro qui écrive le code correct.
(c)); \ resultat;})

J'ai donc essayé ça :#define ProduitCroix(a,b,c) \
	({ unsigned long resultat; \
	asm("muls.w %2,%1; divs.w %3,%1" \
	: "=d"(resultat) \
	: "d" (a), "d"(b), "d"

Mais sauf que parfois d0 est utilisé pour resultat mais a correspond à un autre registre, ce qui crée des erreurs lors de la suite du programme, donc j'ai corrigé en mettant ça :

#define ProduitCroix(a,b,c) \
	({ unsigned long resultat; \
	asm("muls.w %2,%1; divs.w %3,%1; move.w %1,%0" \
	: "=d"(resultat) \
	: "d" (a), "d"(b), "d"(c)); \
	resultat;})

Mais le problème c'est que quand d0 est utilisé pour resultat et qu'il est aussi utilisé à la base pour a ça me sort un move.w %d0,%d0
et puis j'ai l'impression aussi que ça plante parfois, mais je ne suis pas sûr que ce soit à cause de ma macro (même si je la soupçonne très fortement, parce qu'avant ça ne plantait presque pas).
Merci.

jackiechan a écrit :
Je ne savais pas trop où poster ce topic, mais comme je pense qu'à peu près tous ceux qui savent coder en ASM connaissent aussi le C, il est mieux ici que dans la rubrique C.
Voilà mon problème : je fais un calcul du style a*b/c mais je ne suis pas satisfait du code assembleur produit. J'aimerais que TIGCC utilise muls puis divs, mais rien à faire, j'ai essayer de transtyper de beaucoup de façons différentes, à chaque fois TIGCC utilise __divsi3 ou bien ne fait une division que de 16 bits / 16 bits alors que moi j'ai besoin de 32 bits / 16 bits.

En effet, il y a l'air d'y avoir un problème dans les patterns de division 68k.

Je me suis donc mis en tête d'écrire une macro qui écrive le code correct.
(c)); \ resultat;})

J'ai donc essayé ça :#define ProduitCroix(a,b,c) \
	({ unsigned long resultat; \
	asm("muls.w %2,%1; divs.w %3,%1" \
	: "=d"(resultat) \
	: "d" (a), "d"(b), "d"

Mais sauf que parfois d0 est utilisé pour resultat mais a correspond à un autre registre,

#define ProduitCroix(a,b,c) \
	({ unsigned long resultat; \
	asm("muls.w %2,%0; divs.w %3,%0" \
	: "=d"(resultat) \
	: "0" (a), "d"(b), "d"(c)); \
	resultat;})

Aah, merci beaucoup Kevin, tu me sauves la vie

> il y a l'air d'y avoir un problème dans les patterns de division 68k
Ca fait super-longtemps que ce bug est là. Je m'en suis aperçu il y a bien 1 an 1/2. A l'époque, je n'ai jamais réussit à faire générer un mulx par TIGCC.
Je pensais que ce bug avait été corrigé

Est-ce que seulement tu l'avais reporté, depuis tout ce temps ? Si ça n'est pas le cas, tu peux difficilement t'étonner qu'il n'ait pas été corrigé plus tôt...

J'attendais la remarque

Un bug aussi énorme, je me disais que c'était un problème qui serait corrigé dès la version suivante. Je ne pensais pas que vous ne fesiez pas plus attention au code généré par votre compilo

Thibaut a écrit :
> il y a l'air d'y avoir un problème dans les patterns de division 68k
Ca fait super-longtemps que ce bug est là. Je m'en suis aperçu il y a bien 1 an 1/2. A l'époque, je n'ai jamais réussit à faire générer un mulx par TIGCC.
Je pensais que ce bug avait été corrigé

Les mul[su] marchent parfaitement. Ce sont les div[su] qui ne marchent pas.

Et on a autre chose à faire que d'examiner le code produit par GCC. S'il est de mauvaise qualité, reportez-le nous. D'ailleurs, c'est très probablement de la faute des développeurs de GCC, pas de la nôtre.

Même sur PC, GCC produit ce code pourrit pour la division ?

> S'il est de mauvaise qualité, reportez-le nous
Fait attention à ce que tu dis, c'est un coup à voir ta boîte exploser sous les mails tellement il y a d'horreurs avec GCC
Ca reste quand même le meilleur compilo à ce jour => je n'ose pas imaginer le code produit par ceux de Borland ou M$...

Thibaut
a écrit : Même sur PC, GCC produit ce code pourrit pour la division ?

As-tu lu ce que j'ai écrit??? "En effet, il y a l'air d'y avoir un problème dans les patterns de division 68k." Depuis quand il y a un 68k dans ton PC???

> S'il est de mauvaise qualité, reportez-le nous
Fait attention à ce que tu dis, c'est un coup à voir ta boîte exploser sous les mails tellement il y a d'horreurs avec GCC

Pour l'instant, je n'en ai pas reçu un seul.

> As-tu lu ce que j'ai écrit ???
Oui, tu as écrit "c'est très probablement de la faute des développeurs de GCC, pas de la nôtre"

Tu n'as toujours rien compris!!! (Comme d'habitude, d'ailleurs...) Je te signale que le 68k fait partie des processeurs supportés d'origine par GCC, et que j'ai déjà dit plus haut que c'est très probablement un problème spécifique au target 68k de GCC qui ne se retrouvera pas sur les autres architectures. Apprends à lire!

Haaa Je viens bien moins souvent qu'avant, et je constate que tu t'améliores au fils du temps
De plus en plus sympathique, le Kev'

C'est comme le vin, plus c'est vieux et plus on se délecte

rmq faut pas depasser un certain stade tout de meme, sinon c du vinaigre

Après ça moisit carrément, il n'y a plus rien d'autre à faire que de le jeter aux ordures

Great. Et un petit coup de flood pour changer un peu...
Si le truc n'a pas été corrigé, c'est quand même peut-être un peu de ta faute, Thibaut...

UN PEU. C'est autant, sinon plus, de la vôtre.

Bon. J'arrête la discussion, parce que je vais encore, de toute façon, avoir tort...

He oui, Môôôôssieur : tu as tort, autant que moi