addq avec les registres Ax - Page 1

j'ai remarqué que peu de programmeur font l'optimisation addq.l #x,Ax en addq.w #x,Ax qui est absolument équivalent (même dans Preos ce n'est pas fait)
d'après la doc de motorola le .l prend 8 cycles et le .w en prend 4

Meuh non c'est pô équivalent dans tous les cas ! Si Xlib contient cette "optimisation" bonjour les plantages...

J'explique : addq.w n'affecte que les 2 premiers octets du registre. Imaginons que an pointe vers $0001FFFB. Alors addq.w #5,an donnera $00000000, au lieu de $00020000 quand la totalité du registre est prise en compte avec addq.l

[edit]Edité par Thibaut le 09-04-2002 à 15:16:59[/edit]

addq.w / addq.l avec an comme registre, c' est la meme chsoe. Meme taille, meme cycle, meme effets.

Je réfute, CF post 2 !

d'après le PDF de motorola addq.w #x,Ax prend 4 cycles et addq.l 8 cycles

La réponse de PpHd qu'il m'a faite en mini message :
>> "Essayes. Et tu verras. Toute operation sur un registre de adresse implique tout le registre d' adresse."


Alors je réfute encore !

En effet, en écrivant la bibliothèque Azur, Kevin et moi-même avons mis du temps avant de trouver d'où venait le fait que la valeur renvoyée était différente de NULL lorsque l'ouverture d'un fichier avec fopen échouait...
Et bien je faisais sub.w a0,a0 en croyant que tout le registre serait affecté


Que faut-il conclure des affirmations de PpHd, de celle de JS, et de la mienne
[edit]Edité par Thibaut le 09-04-2002 à 15:42:32[/edit]

Et bien refute.

d'où vient l'idée que hwti=JS ? Je n'ai rien à voir avec lui.
addq.w est bien identique à addq.l. J'ai vérifié avec DB92.

Thibaut : oui, mais pour le suba.w, ça n'est pas tout à fait pareil. Le suba.w utilise les 16 bits de la source, et les 32 bits du résultat. Donc forcément, le mot du registre est généralement le seul à être nettoyé.
Mais pour addq.w et addq.l, les effets sont exactement les mêmes, comme le dit PpHd. Et ça a l'air d'être la même chose en nombre de cycles.

Mais j'ai été l'un des seuls à avoir toujours utilisé addq.w, laissez moi mon addq.w !

PpHd : tu aurais mieux fait d'argumenter, bravo pour ton aide...

ExtendeD : merci

addq.w #n,an et addq.l #n,an font exactement la même chose, et selon nos tables de cycles, prennent le même nombre de cycles. (À vérifier.) Si effectivement, il y a une différence de vitesse comme le dit hwti (la meilleure manière de vérifier est de le mesurer), je peux faire automatiquement optimiser ça à A68k.

Il n'y en a pas. Il y a une difference entre addq.w #,dn et addq.l #,dn. Mais pas avec an.

Kevin Kofler>a68k met quoi quand on met addq tout court?

word je crois.

addq.l prend plus de cycle que addq.w parceque le processeur est un "faux" 32bits.
Je m'explique: c'est un processeur 32 bits mais avec un bus 16 bits donc il faut 2 fois plus de temps d'horloge pour acheminer des donnees sur 4 octets que sur 2 octets.
Si c'est possible il vaut mieux utiliser des operations sur des words que sur des long words.
(Regardez le black book:c'est la section des "mangeurs de cycles")

Bah c'est pas ce que disent les tables de nombre de cycles.

id>teste en pratique et regarde...

JE te signale qu' on incremente un registre 32 bits interne au proc.
Il n' y a aucun transfert sur le bus.

En tout cas un truc est sûr: a68k assemble comme ça:
addq #1,a0 -> $5248
addq.w #1,a0 -> $5248
addq.l #1,a0 -> $5288
Donc, il y a une différence dans le codage de ces instructions (conformément à la doc de Motorola)...
Par contre au niveau du résultat, reste à savoir s'il affecte tout le registre dans le cas .w et s'il existe une différence de temps d'execution!

Je repete : aucune difference au niveau du resultat / aucune difference en temps.

Et sur un registre dn alors?

Pour les registres dn, ca change,ok.
Pour les an, non.

et au niveau des temps sur un dn?

un addq.w #1,dn est plus rapide qu' un addq.l #1,dn.

un addq.l #1,dn est moins rapide qu'un addq.l #1,an???

C'est pareil.
C'est le addq.w #1,dn qui est plus rapide.