MC68020: Expected result A7 indirect with post increment

[Sven S. (sven_10059)]

Ich bin gerade beim Testen eines eigenen Emulators für den Motorola 
MC68020. Als "Referenz" dient mir der Musashi Emulator. Bei folgendem 
Befehl verhalten sich beide Emulatoren unterschiedlich, aber ich bin mir 
nicht sicher, welches Ergebnis der Realität entspricht.

moves.b a7, (a7)+

In a7 steht testweise 0xFFFF0008. Mein Emulator schreibt auf Adresse 
0xFFFF0008 den Wert 0x08, während Musashi den Wert 0x0A schreibt. Ich 
tendiere ja dazu einem ausgereiften Emulator gegen einem neu 
geschriebenen Recht zu geben, aber eigentlich ist mein Verständnis, daß 
hier der Wert von A7 auf die von A7 adressierte Speicherstelle zu 
schreiben ist und danach der Wert von A7 zu incrementieren ist (und 
nicht der incrementierte Wert zu schreiben).
Aber wie verhält sich der MC68020 tatsächlich? Möglich wäre ja auch, daß 
direkt nach dem Lesen aus A7 incrementiert wird (also post increment 
nach Lesen von A7 und nicht nach Befehlsabarbeitung) und damit dann 
tatsächlich A7+2 geschrieben werden würde. Oder anders ausgedrückt: wann 
wird incrementiert? Nach Lesen von A7 oder nach Abarbeitung des Befehls?
Vielen Dank für die Hilfe schon mal!

[m.n. (Gast)]

Sven S. schrieb:
> Aber wie verhält sich der MC68020 tatsächlich?

Dein Emulator arbeitet richtig.
Aber ist das nicht völlig egal? Wozu sollte denn der gezeigt Befehl 
taugen außer dem Prozessor den Stack zu ruinieren?

[Bernd K. (berndkeck)]

Hallo Sven,
ich habe früher sehr viele Jahre mit dem 68020 in Assembler programmiert 
- VMEbus usw. Leider habe ich keine Maschine mehr zur Verfügung um das 
an einem lebenden Objekt zu verifizieren.
Nach meinem Verständnis ist das eindeutig ein postincrement, d.h. A7 
wird NACH dem byte transfer erhöht.
Gruß
Bernd

[holm (Gast)]

Wenn Ihr mir dem Mschinencode mal aufschreibt und ein 68010 oder ein 
68332 diesen Befehlt auch unterstützt, kann ich evtl mal nachgucken was 
der macht.

Ich habe nur den fbug oder den CPU32Bug auf den ollen Platinen.. (KatCe)

Gruß,

Holm

[Micha (Gast)]

Eigendlich sollte ja Sven recht haben, aber wenn man hier schaut:
http://bitsavers.informatik.uni-stuttgart.de/pdf/motorola/68000/CPU32_Reference_Manual_Rev1_Dec90.pdf
und zwar S.164 (acrobat-reader-zählung)

ich zitiere mal:

                    NOTE:
For either of the two following examples, which use the same address register as both source and destination, the value stored is undefined. The current implementations of the MC68010, CPU32 and MC68020 store the incremented or decremented value od An.

            MOVES.x An,(An)+
            MOVES.x An,-(An)

scheint also doch der Musashi Emulator recht zu haben
Gruss Micha

[Micha (Gast)]

Ach Gott, da ist ja Formatierung vollkommen schief gelaufen. Naja...

[Sven S. (sven_10059)]

Hallo alle zusammen und vielen Dank für die Rückmeldungen. Ihr seid 
super.
Der Maschinencode ist:

0E1F F800

Und der 68010 kennt den Befehl bereits.
Zur Frage, ob der Befehl Sinn macht: Der Code ist bei einem 
automatischen Test rausgepurzelt, der verschiedene Kombinationen 
gegeneinander ausprobiert. Der Befehl ist gültig und ich wäre gern so 
akkurat wie möglich. Und ich denke die Frage, wann jetzt genau 
incrementiert wird, ist noch für andere opCodes relevant. Daher der 
Versuch das zu klären. Vielen Dank für eure Hilfe! Und es wäre super, 
wenn sich das am real target verifizieren ließe :-)

[Arc N. (arc)]

Sven S. schrieb:
> Aber wie verhält sich der MC68020 tatsächlich? Möglich wäre ja auch, daß
> direkt nach dem Lesen aus A7 incrementiert wird (also post increment
> nach Lesen von A7 und nicht nach Befehlsabarbeitung) und damit dann
> tatsächlich A7+2 geschrieben werden würde. Oder anders ausgedrückt: wann
> wird incrementiert? Nach Lesen von A7 oder nach Abarbeitung des Befehls?
> Vielen Dank für die Hilfe schon mal!

Bei movem gibt es einen Unterschied: Bsp.: movem.l a0-a3, -(a0) 68k 
schreibt a0 unverändert, >68020 schreibt den dekrementierten Wert
Beim normalen move wird "After the operand address is used, it is 
incremented by one, two, or four depending on the size of the operand: 
byte, word, or long word, respectively"
Einzige Ausnahme afaik: A7/Stack, wird immer min. um 2 de/inkrementiert.

[Sven S. (sven_10059)]

Micha schrieb:
...
> und zwar S.164 (acrobat-reader-zählung)
...

Hallo Micha und danke. Sehr konkreter Hinweis, dem ich mich wohl beugen 
muß. Sowas in der Art hatte ich "befürchtet". Eigentlich im Recht, aber 
die Wirklichkeit sieht anders aus ;-)

[Sven S. (sven_10059)]

Arc Net schrieb:
...
> Bei movem gibt es einen Unterschied: Bsp.: movem.l a0-a3, -(a0) 68k
...

Hallo Arc Net und danke. Dann muß ich bei movem auch noch aufpassen.

[Holm T. (Gast)]

Möglicherweise stelle ich mich ein wenig prasslig an, aber ich habe es 
mal probiert auf einem 68010 mit Motorola FBUG Monitor:

MOTOROLA> as 1000
$00001000 4E71            nop               ?                              
$00001002 4E71            nop               ?                              
$00001004 0E1F F800       moves.b       A7,(A7)+    ?                      
$00001008 4E71            nop               ?                              
$0000100A 4E71            nop               ?                              
$0000100C 4E71            nop               ?  .
MOTOROLA> br 1002
Break Point:
$00001002:&0

MOTOROLA> br 1008
Break Point:
$00001002:&0
$00001008:&0

MOTOROLA> go 1000
Breakpoint at $00001002

PC   =$00001002   SR   =$00002700   USP  =$00001B00   
SSP  =$00002000   VBR  =$00000000   SFC  =$00000003   DFC  =$00000000   

D0   =$00000000   D1   =$00000000   D2   =$00000000   D3   =$00000000   
D4   =$00000000   D5   =$00000000   D6   =$00000000   D7   =$00000000   

A0   =$00000000   A1   =$00000000   A2   =$00000000   A3   =$00000000   
A4   =$00000000   A5   =$00000000   A6   =$00000000   A7   =$00002000   

$00001002 4E71            nop                   ?  

MOTOROLA> g
Breakpoint at $00001002

PC   =$00001002   SR   =$00002700   USP  =$00001B00   
SSP  =$00002000   VBR  =$00000000   SFC  =$00000003   DFC  =$00000000   

D0   =$00000000   D1   =$00000000   D2   =$00000000   D3   =$00000000   
D4   =$00000000   D5   =$00000000   D6   =$00000000   D7   =$00000000   

A0   =$00000000   A1   =$00000000   A2   =$00000000   A3   =$00000000   
A4   =$00000000   A5   =$00000000   A6   =$00000000   A7   =$00002000   

$00001002 4E71            nop                   ?  

MOTOROLA> go 1004
Breakpoint at $00001008

PC   =$00001008   SR   =$00002700   USP  =$00001B00   
SSP  =$00002002   VBR  =$00000000   SFC  =$00000003   DFC  =$00000000   

D0   =$00000000   D1   =$00000000   D2   =$00000000   D3   =$00000000   
D4   =$00000000   D5   =$00000000   D6   =$00000000   D7   =$00000000   

A0   =$00000000   A1   =$00000000   A2   =$00000000   A3   =$00000000   
A4   =$00000000   A5   =$00000000   A6   =$00000000   A7   =$00002002   

$00001008 4E71            nop                   ?  

MOTOROLA> md 2000
$00002000:  $0010  $6444  $4744  $5544  $5404  $4444 
$0000200C:  $C544  $5444  $4544  $444C  $4045  $4505  
$00002018:  $4544  $4504  $4545  $6441  $5744  $5554
$00002024:  $4554  $5544  $554C  $4554  $4500  $5508  
$00002030:  $4405  $C490  $5505  $C440  $4544  $5D40  
$0000203C:  $5641  $5404  $4547  $4401  $5540  $44C4  
$00002048:  $5DD0  $4505  $4545  $5404  $4504  $5500  
$00002054:  $9554  $5444  $6544  $5DC4  $D554  $5444  


MOTOROLA>

Ich kann mir nicht erklären was die 0010 bei 2000 im Speicher zu suchen 
hat. Eine 2000 hätte ich ja für plausibel gehalten, aber A7 ist doch 
irgendwie auch der Stackpointer? Ich habe über die Dinger so gut wie 
Alles vergessen.

Gruß,

Holm

[(prx) A. K. (prx)]

Der Befehl schreibt mit FC=DFC=000 und dieser Wert ist undefiniert.
Was stand denn vorher drin?