encore une chtite question - Page 8

Je n'ai pas dit qu'il n'y avait pas de bogue, juste que je ne le vois pas tout de suite. Je vais repasser plus en détail ce soir, quand ma semaine d'exams sera finie.

btst.b d2,d3 va tester dans l'octet de poids faible (donc complètement à droite) de d3

Un btst sur un registre de données est toujours sur 32 bits, un btst en mémoire est toujours sur 8 bits.

btst.b D2,(A0) est un btst en mémoire, donc sur 8 bits. Ça teste l'octet exact pointé par A0. Donc ça devrait marcher comme prévu. Je vais essayer de voir ce qui cloche.

J'ai repéré 2 erreurs:

move.w #6,D2 ;bit à tester au cas où le reste de la division serait nul

Pourquoi 6? C'est 7 qu'il faut mettre à mon avis. (Et au passage, un moveq serait mieux.)

beq crash ;si le pixel est allumé, on crash

Le code ne correspond pas au critère. btst+beq saute si le bit est éteint. Il te faut un bne.

beq = branch if equal, pas branch if true

./219>

par contre, ce que je trouve bizare, c'est qu'un pixel éteint soit considéré comme vrai. Intuitivement, j'aurais fait l'inverse. D'ailleurs c'est comme ça que j'avais écrit

La condition "eq" n'est pas la condition "est vrai". C'est la condition "nul" (pour tst), ou "égal" (pour cmp, parce que ça veut dire "différence nulle") ou "faux" (pour les booléens).

[grmbl, cross-post]

Je crois que tu as la réponse sous les yeux :

C'est la condition "nul
" (pour tst), ou "égal" (pour cmp, parce que ça veut dire "différence nulle") ou "faux" (pour les booléens).

Le 6 est bon, en effet. Mais mets un moveq, ça économise 2 octets et 4 cycles par rapport à ton move.w.

(attention, moveq.w n'existe pas, même si A68k l'accepte : c'est en réalité un moveq.l, i.e. ça modifie le registre entier ; cela dit, tu peux toujours utiliser moveq.w comme convention pour indiquer que tu veux un moveq mais que tu n'as pas besoin que de la valeur sur le word)

Pollux
: (attention, moveq.w n'existe pas, même si A68k l'accepte : c'est en réalité un moveq.l, i.e. ça modifie le registre entier ; cela dit, tu peux toujours utiliser moveq.w comme convention pour indiquer que tu veux un moveq mais que tu n'as pas besoin que de la valeur sur le word)

Non, s'il te plaît, ne continue pas ces abus des instructions! Le fait que A68k accepte ça est un bogue (connu et documenté), n'en dépendez pas!

Martial Demolins :
ok, merci pour ces explications sur les instructions. sinon, je croyais qu'on ne pouvait faire un moveq que sur une valeur immédiate comprise entre 0 et 7.

Déjà, 6 est dans cet intervalle, et puis c'est [-128;127] le vrai intervalle pour moveq (et [1;8] pour addq et subq).

et moveq.b ne modifie que le premier byte, pas tout le registre?

moveq.b n'existe pas.

les subq.s et addq.s permettent de faire un add/sub sur une adresse avec une valeur immédiate entre 1 et 8 (où s vaut .b, .w ou .l)
moveq permet de mettre une valeur immédiate entre -128 et +127 dans un registre de données (sur un long uniquement)
[edit : cross post]

Kevin Kofler
:

Pollux
: (attention, moveq.w n'existe pas, même si A68k l'accepte : c'est en réalité un moveq.l, i.e. ça modifie le registre entier ; cela dit, tu peux toujours utiliser moveq.w comme convention pour indiquer que tu veux un moveq mais que tu n'as pas besoin que de la valeur sur le word)

Non, s'il te plaît, ne continue pas ces abus des instructions! Le fait que A68k accepte ça est un bogue (connu et documenté), n'en dépendez pas!

Je trouve quand même que c'est utile de documenter si on utilise moveq et qu'on veut un long ou un word : si par hasard ce moveq dépend de EQU et qu'on modifie ces EQU de telle sorte que ça fait sortir un moveq de la plage en question, il faut chercher si on veut un move .w ou .l ... (et si on n'est pas l'auteur du code, ce qui n'est pas impossible quand on modifie juste un EQU, c pas forcément évident)

Cela dit c'est vrai que ça peut prêter à confusion; mais je ne vois pas vraiment d'autre solution (à part ne pas faire d'ASM du tout )

moveq.w n'existe pas, donc on n'a pas le droit de l'utiliser, un point, c'est tout.

Moi aussi, je suis d'accord avec Kevin.
Mais à vrai dire, Pollux, je n'ai pas compris ton exemple où tu sembles montrer qu'il peut être utile d'écrire moveq.w.

Sasume>

W equ 8
H equ 4

  moveq #W*H-1,d0
  bsr whatever

Si on transforme le code pour mettre H=8, on ne peut plus utiliser moveq; et comme on ne sait pas si moveq est censé remplacer move.w ou move.l, il y a ambiguïté...

A vrai dire la meilleure solution serait, comme j'avais proposé il y a longtemps, de faire un pseudo-op movef tel que movef.w choisisse le plus efficace entre move.w et moveq.l ...

[EDIT : cross-post, encore ]

<NITPICK>Si, avec H=8, on peut encore l'utiliser (8*8-1=63 est à l'intérieur de [-128;127]).</NITPICK>