Schiebebefehl ATmega8 - mov Rd,Rr

[Andreas N. (nabi)]

Hallo,

ich habe mir heute den Simulator für Win herunter geladen um ein paar 
Subroutinen zu testen, es hat einfach nicht geklappt der Code lief 
einfach nicht. Nach dem ich mir ein paar Testzeilen geschrieben habe 
mußte ich feststellen dass der mov Rd,Rr genau umgekehrt ausgeführt 
wird. Jedenfalls bei meiner Installation vom Simulator. Ich habe auch 
ein .jpg gemacht. Kann mir jemand sagen wo ich was einstellen muss dass 
korrekt simuliert wird.

Gruß

[Peter D. (peda)]

Dann hat wohl Dein Simulator einen Bug.

[c-hater (Gast)]

Andreas N. schrieb:
> Hallo,
>
> ich habe mir heute den Simulator für Win herunter geladen um ein paar
> Subroutinen zu testen, es hat einfach nicht geklappt der Code lief
> einfach nicht. Nach dem ich mir ein paar Testzeilen geschrieben habe
> mußte ich feststellen dass der mov Rd,Rr genau umgekehrt ausgeführt
> wird. Jedenfalls bei meiner Installation vom Simulator. Ich habe auch
> ein .jpg gemacht. Kann mir jemand sagen wo ich was einstellen muss dass
> korrekt simuliert wird.

Das geht über Systemsteuerung->Software. Den schrottigen Simulator 
deinstallieren und statt dessen AVR-Studio installieren. Das enthält 
einen Simulator, der zumindest den AVR8-Core vollständig fehlerfrei 
simulieren kann.

Bei der Peripherie hingegen ist auch nach fast zwei Jahrzehnten 
Entwicklungszeit immer noch Vorsicht geboten. Manche Peripherie wird bis 
heute garnicht unterstützt, andere nur mit mehr oder weniger großen Bugs 
und/oder in einer Form, die die Simulation erstmal ziemlich nutzlos 
macht.

Offensichtlich wurde/wird der Simulator nur mit (qualitativ und 
quantitativ) völlig ungenügender Manpower entwickelt, wenn er überhaupt 
weiter entwickelt wird...

[c-hater (Gast)]

c-hater schrieb:

> deinstallieren und statt dessen AVR-Studio installieren. Das enthält

Das sollte natürlich eigentlich "Atmel-Studio" heissen. Sorry.

[Hugo E. (Gast)]

...ganz abgesehen davon, daß "mov" kein Schiebebefehl ist ;-)

[Heinz R. (Gast)]

Und noch abgesehener davon, dass Dein Simulator ganz prima funktioniert.
Deine Vorstellung vom mov - Befehl ist verkehrt:

> mov r16, r0
>  !!! copiert r16 nach r0

ist falsch.

 - mov rd, rr
kopiert rr (2.Parameter) nach rd (1.Parameter), d für Destination : 
Ziel.

Schau nochmal ins AVR-Instruction Manual.

[c-hater (Gast)]

Heinz R. schrieb:

> Und noch abgesehener davon, dass Dein Simulator ganz prima funktioniert.
> Deine Vorstellung vom mov - Befehl ist verkehrt:
>
>> mov r16, r0
>>  !!! copiert r16 nach r0
>
> ist falsch.
>
>  - mov rd, rr
> kopiert rr (2.Parameter) nach rd (1.Parameter), d für Destination :
> Ziel.
>
> Schau nochmal ins AVR-Instruction Manual.

Hmm...

Das war jetzt zumindest ein Hinweis, sich den Kram nochmal genauer 
anzuschauen. Also: aus dem OT ist bei genauer Betrachtung weder 
abzulesen, was der TO erwartet hat, noch ist abzulesen, was tatsächlich 
passiert ist.

Sprich: der TO ist dermaßen inkompetent, dass es ihm nicht einmal 
möglich ist, sein Problem kompetent darzustellen.

Also ist nach Ockham deine Annahme am wahrscheinlichsten: der TO 
erwartete schlicht das Falsche.

Trotzdem ist Atmel-Studio die bessere Wahl. µC-Anwendungen leben davon, 
dass man ihre Peripherie benutzt. Über kurz oder lang muss man also doch 
den Atmel- (heute: MC-) Simulator benutzen. Dann kann man auch gleich 
damit anfangen.

[S. Landolt (Gast)]

Also für mich ist das angehängte Bild eindeutig, wenn ich mir das 
Testprogramm anschaue und daneben die Registerinhalte ...

[Ingo W. (uebrig)]

Andreas N. schrieb:
> ich habe mir heute den Simulator für Win herunter geladen um ein paar
> Subroutinen zu testen

Gemeint ist wohl
Beitrag "AVR Simulator mit grafischer Benutzeroberfläche für Linux"

c-hater schrieb:
> Das geht über Systemsteuerung->Software. Den schrottigen Simulator
> deinstallieren und statt dessen AVR-Studio installieren. Das enthält
> einen Simulator, der zumindest den AVR8-Core vollständig fehlerfrei
> simulieren kann.

Das AVR-Studio 4 hat bei mir, bis Windows 7 prima funktioniert, mein 
letzter Test mit WINE vor 4 Jahren war allerdings noch nicht so perfekt.

Für gelegentliche Tests von Routinen, so wie vom TE hat das ziterte 
Projekt allerdings seinen Zweck erfüllt.

c-hater schrieb:
> Trotzdem ist Atmel-Studio die bessere Wahl. µC-Anwendungen leben davon,
> dass man ihre Peripherie benutzt. Über kurz oder lang muss man also doch
> den Atmel- (heute: MC-) Simulator benutzen. Dann kann man auch gleich
> damit anfangen.

Das ist wohl wahr.
Mangels Resonanz, war aber wohl der Anreiz, das Projekt weiter zu 
entwickeln nicht so hoch.

[Hugo E. (Gast)]

S. Landolt schrieb:
> Also für mich ist das angehängte Bild eindeutig, wenn ich mir das
> Testprogramm anschaue und daneben die Registerinhalte ...

Ja, eindeutig ein Schiebebefehl ;-)

[S. Landolt (Gast)]

... wir sind uns doch darin einig, dass in r16 0xFF stehen müsste?

[Kaj (Gast)]

Siehe Anhang

[Jens G. (jensig)]

Heinz R. (Gast) schrieb:

>Und noch abgesehener davon, dass Dein Simulator ganz prima funktioniert.
>Deine Vorstellung vom mov - Befehl ist verkehrt:

>> mov r16, r0
>>  !!! copiert r16 nach r0

>ist falsch.

> - mov rd, rr
>kopiert rr (2.Parameter) nach rd (1.Parameter), d für Destination :
>Ziel.

>Schau nochmal ins AVR-Instruction Manual.

Nöö, schau Du wie auch  c-hater noch mal die Beschreibung des TO an. Die 
Kopieraktion r16 nach r0 ist ja genau das, was er bemängelt, und das 
sieht man ja auch im Screeenshot, daß da was schief läuft.

[c-hater (Gast)]

S. Landolt schrieb:

> Also für mich ist das angehängte Bild eindeutig, wenn ich mir das
> Testprogramm anschaue und daneben die Registerinhalte ...

Nein.

Um das zu entscheiden, bräuchte man die Registerinhalte von zwei 
Zeitpunkten...

Weil: wenn vermutet wird, dass die Simulation nicht tut, was sie tuen 
soll, dann kann man das natürlich für keine Instruktion annehmen. D.h.: 
man kann sich auch nicht darauf verlassen, dass das Programm sich vorher 
erwartungsgemäß verhalten hat.

Simple Anwendung trivialster Gesetze der Logik...

[S. Landolt (Gast)]

Noch wieviele Jahre bis zur Rente?

[c-hater (Gast)]

S. Landolt schrieb:

> Noch wieviele Jahre bis zur Rente?

Acht und ein paar Tage.

[S. Landolt (Gast)]

Doch schon einige Zeit vergangen seit damals; aber damals hatten Sie 
nicht versucht, mit Gewalt etwas an den Haaren herbeizuziehen, bloß um 
Recht zu behalten. Und, pardon, hier nun stehen Sie mit Heinz doch 
alleine auf weiter Flur.
  Aber nichts für ungut, trotz allem wünsche ich Ihnen noch Frohe 
Ostern.

[c-hater (Gast)]

S. Landolt schrieb:

> Doch schon einige Zeit vergangen seit damals; aber damals hatten Sie
> nicht versucht, mit Gewalt etwas an den Haaren herbeizuziehen, bloß um
> Recht zu behalten. Und, pardon, hier nun stehen Sie mit Heinz doch
> alleine auf weiter Flur.

Dunkel ist der Rede Sinn...

> Aber nichts für ungut, trotz allem wünsche ich Ihnen noch Frohe
> Ostern.

Jo, ebenfalls.

[Jens G. (jensig)]

c-hater (Gast) schrieb:

>S. Landolt schrieb:
>
>> Also für mich ist das angehängte Bild eindeutig, wenn ich mir das
>> Testprogramm anschaue und daneben die Registerinhalte ...
>
>Nein.
>
>Um das zu entscheiden, bräuchte man die Registerinhalte von zwei
>Zeitpunkten...

Wie meinen?
Man vollzieht das kleine Testprogramm einfach mal im Kopf nach, und 
stellt nach Ausführung fest, daß die Registerinhalte rechts als Ergebnis 
nicht so ganz stimmen.

[c-hater (Gast)]

Jens G. schrieb:

> Man vollzieht das kleine Testprogramm einfach mal im Kopf nach, und
> stellt nach Ausführung fest, daß die Registerinhalte rechts als Ergebnis
> nicht so ganz stimmen.

Das ist ein Ansatz. Der allerdings nur zu der Erkenntnis führt, das da 
irgendwo im Simulator ein Bug ist. Um hingegen feststellen zu können, 
wo genau der steckt, braucht man im Minumum zwei Snapshots. Diese zwei 
genügen genau dann, wenn man eigentlich bereits weiss, wo der Bug 
stecken muss und man sie genau vor und nach der fehlerhaft 
implementierten Instruktion macht.

[Ingo W. (uebrig)]

c-hater schrieb:
> Das ist ein Ansatz. Der allerdings nur zu der Erkenntnis führt, das da
> irgendwo im Simulator ein Bug ist.

Hat der TE schon richtig beschrieben, im Simulator waren Quelle und Ziel 
vertauscht, Der Disassembler hat es noch richtig angezeigt. Hab es im 
o.g. Thread korrigiert.

[Andreas N. (nabi)]

c-hater schrieb:
> Das ist ein Ansatz. Der allerdings nur zu der Erkenntnis führt, das da
> irgendwo im Simulator ein Bug ist. Um hingegen feststellen zu können,
> wo genau der steckt, braucht man im Minumum zwei Snapshots. Diese zwei
> genügen genau dann, wenn man eigentlich bereits weiss, wo der Bug
> stecken muss und man sie genau vor und nach der fehlerhaft
> implementierten Instruktion macht.

Hää ?

String formula to komplex error !

------------------------------------------------------------------------ 
--

Was ich noch zum AVR-Handbuch sagen wollte auf meinem jpg ist rechts 
unten ein Ausschnitt aus dem Handbuch zu sehen. Der der das nicht 
erkennt wird's wohl nicht gelesen haben - das Handbuch.

Zur Systemsteuerung/Software wäre zu sagen, dass der 'Schrott-Simulator' 
gar keine Installation braucht. Sondern lediglich vor der Kommandozeile 
gestartet wird. Und das ist das Ideale daran.


@Ingo:
Danke für die super schnelle Korrektur. Funktioniert jetzt prima.

PS.
Mein 'Studio' ist mein Kopf, seit ca. 37 Jahren, an gefangen mit dem 
i8048 als Ur-Ur-Opa der Single-Chipper und es gab nur Assembler zur 
Programmierung. No Studio, No Atmel aber Intel Inside.