Question de newbie - Page 1

Pourquoi quand j'écris move.b Label(pc,d0.w),-(a7), a7 est décrémenté de 2 au lieu de l'être de 1 comme je le voudrais ?
OK, ça fait que je me retrouve sur une adresse impaire, mais c'est mon problème, puisque juste après, j'empile un deuxième octet, donc je retombe finalement sur une adresse paire.
Et puis dans ma doc sur le 68k, il est dit que a7 ne devrait être décrémenté que de 1

C'est impossible car a7 doit toujours être pair! Imagine qu'une interruption survienne après

move.b Label(pc,d0.w),-(a7)

et que cette interruption utilise MOVE %usp,%a6 (par exemple), puis move.w (%a6),%d0, et ben là, comme %a6 est impair la calto crashe!

Ta doc se trompe T'es obligé de faire :

  move.b  Label(pc,d0.w),-1(a7)
  move.b  <deuxième octet>,-(a7)

Je vois pas plus rapide. Et encore, il faut s'assurer que le processeur ne force pas à zéro l'octet de poids fort au deuxième move, sinon ça marche pas.

Au fait, pourquoi cette instruction s'appelle move sur plein (tous ?) de processeurs alors qu'il s'agit plutôt d'un copy

Parce que MOVE x, y = MOVE data from x to y
ou encore MOVE contents of x to y
etc...

Bah non, tu fais une copie, pas un déplacement !

Ben movei.w #0xFFFF, %d0 ça ne fait pas une copie...

D'ailleurs, lorsqu'on essaye d'empiler un octet sur la pile, à quoi correspond l'octet supplémentaire? Sa valeur est significative? Dans mes essais, il n'est jamais à 0, mais vaut $39

L'octet suivant contient un bout de long ou de short empilé auparavant.

tu veux dire quoi ?
si tu as
sp-2 0xb09a
sp 0x0001
sp+2 0x5466
et que tu fais move.b #0x18,%-(%sp)
tu devrais avoir
sp 0xb018
sp+2 0x0001
non ?
edit: post croisé

Moi je vois la pile comme ça, zone mémoire réservée de taille plus ou moins fixe. Elle ce comporte comme a0-a6 mais dans une zone précise. Il faut juste empiler des shorts ou long pour éviter tout autre empilement d'être fait sur une adsresse impaire car lors d'un saut avec rts ou autre, l'adresse empilé sera erronné et donc fausse.
Mias dans le cas ou tu empile que des octets, du temps que tu n'effectue pas de saut et qu'aucune interruption ou programme utilise la pile a7 tu est tranquil. Tu peux même changer la zone mémoire de la pile comme le fait pedrom.

GoldenCrystal
: Imagine qu'une interruption survienne

J'avoue que je n'avais pas pensé à ça
Bon, bah merci d'avoir répondu.

GoldenCrystal #5 : Ca fait quoi alors ?

Au fait move USP fait quoi au juste?

move usp,ancopie la valeur du pointeur de la pile utilisateur dans anp. move an,usfait l'inverse.

Euh pour info a7 a forcément une valeur paire. (quoique je sais pas ce qu'il arrive si on se contente de faire des move
Donc quand on fait move.b d0,-(a7), ça revient à faire subq.w #2,a7;move.b d0,(a7).
(idem pour move.b (a7)+,d0 : move.b (a7),d0;addq.w #2,a7).

a7 doit avoir une valeur paire (pour ne pas tout planter) ou a réellement une valeur paire? genre addq #1,a7 ne marche pas ?

Ximoon-> avec un add/sub, tu peux régler A7 à une valeur impaire. Ca m'est malencontreusement arrivé lorsque je développait un de mes premiers progs assembleur-> Addresse error peu après, et il ne me semble pas que c'était lors du add, mais bien lors d'un move ensuite

Et qu'est-ce qui se passe si on fait un move.b d0,-(a7) avec a7 qui a une valeur impaire?

a7 redevient paire?

Excellente question, Pollux

geogeo> pas sûr du tout, peut-être que ça fait un subq.w #2,a7;move.b d0,(a7), ou peut-être encore que ça crashe avec une Address error, ou...

Bon j'essaye

L'histoire des interruptions ne tient pas debout: c'est SSP qui est utilise.

C'est en fait pour eviter de faire:
move.b d0,-(a7)
bsr Toto

Voila

> L'histoire des interruptions ne tient pas debout: c'est SSP qui est utilise
Relis la dernière ligne du post #1, ça tient debout

Ben je vois pas pkoi une int ferait ca. Elle doit assumer que USP peut etre impair, sinon c'est un bug de l'int

En effet PpHd a raison, il faut assumer dans une interruptions tous les cas possible et donc être capable de retourner les anciennes valeurs des registres correctement.... Mais généralement le paramètre que a7 soit à une adresse impaire n'est jamais pris en compte.
Pour moi l'interruption doit ce mettre à genoux devant tout ce quelle modifie et donc doit être capable dans tous les cas de ne pas planter.

PpHd : N'importe quoi
Tu joues le Kevin ?

.23>dans 68kguide.txt:

A special case is when you use A7 and transfer a byte, because A7
will be increased with 2 instead of 1, because A7, as stack pointer, must be an even number.

Donc ça serait plutôt un bug du programme qui met a7 impair...

because A7, as stack pointer, must be an even number.

'as stack pointer', ok, mais on peut tres bien se servir d'a7 pour autre chose que pour le pointeur de pile, il suffit de le sauvegarder.
donc je suis d'accord avec PpHd.

Et d'ailleurs je le fais Donc ca sera incompatible avec mes programmes.

parce que tu mets a7 imapir dans un de tes programmes ?