Bei rcall unverständliche Rücksprungadresse auf Stack

Stack_Simulator Gast #5208955
Lesenswert?
• ▲
▼ 
Hallo,

eben habe ich wie im Artikel
https://www.mikrocontroller.net/articles/AVR-Tutorial:_Stack
vorgeschlagen, die Funktion des Stacks im Simulator beobachtet.
Hierzu habe ich das Beispiel-Programm für den ATmega8 im Simulator des 
Atmel Studio 7 laufen lassen:

1
.include "m8def.inc"

2


3
.def temp = r16

4


5


6
         ldi temp, HIGH(RAMEND)            ; HIGH-Byte der obersten RAM-Adresse

7
         out SPH, temp

8
         ldi temp, LOW(RAMEND)             ; LOW-Byte der obersten RAM-Adresse

9
         out SPL, temp

10


11
         rcall sub1                        ; sub1 aufrufen

12


13
loop:    rjmp loop

14


15


16
sub1:

17
                                           ; hier könnten ein paar Befehle stehen

18
         rcall sub2                        ; sub2 aufrufen

19
                                           ; hier könnten auch Befehle stehen

20
         ret                               ; wieder zurück

21


22
sub2:

23
                                           ; hier stehen normalerweise die Befehle,

24
                                           ; die in sub2 ausgeführt werden sollen

25
         ret                               ; wieder zurück


Alles funktioniert wunderbar:
Bei rcall sub1 steht der PC auf 04.
Nach rcall sub1 erscheint im Memory Fenster auf dem Stack die 
Rücksprungadresse 00 05.

Wenn man das Beispiel-Programm aber für den ATmega16 simuliert (Device 
im Projekt und .include geändert), ist das Verhalten nicht 
nachvollziehbar. Obwohl an gleicher Stelle der PC auf 04 steht, 
erscheint nach Abarbeitung von rcall sub1 auf dem Stack 20 05 (s. 
Screenshot).

Woher kommt die 20?
Habe ich hier etwas nicht verstanden? Bediene ich den Simulator falsch? 
Es würde mich freuen, wenn mir jemand weiterhelfen könnte.

Weiter Beobachtungen:
Mit Device ATmega128 schreibt der Simulator wie erwartet 00 05 auf den 
Stack. Selbiges gilt für den ATmega16, wenn man die Simulation im 
AVRStudio 4 verwendet.

Vielen Dank für Eure Unterstützung
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Stefan E. #5208980
Lesenswert?
• ▲
▼ 
Stack_Simulator schrieb:
> Wenn man das Beispiel-Programm aber für den ATmega16 simuliert (Device
> im Projekt und .include geändert), ist das Verhalten nicht
> nachvollziehbar. Obwohl an gleicher Stelle der PC auf 04 steht,
> erscheint nach Abarbeitung von rcall sub1 auf dem Stack 20 05 (s.
> Screenshot).
>
> Woher kommt die 20?

Der PC ist 13 Bit groß. Ist doch egal, wenn in den irrelevanten obersten 
3 Bit irgendwelcher Müll steht.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Yalu X. Moderator #5209442
Lesenswert?
• ▲
▼ 
Stack_Simulator schrieb:
> Woher kommt die 20?

Das scheint eine spezielle Eigenart des Atmega16 zu sein, die bei den
meisten (oder sogar allen?) anderen AVR-Controllern nicht auftritt. Hier
wurde der Effekt auch in realer Hardware beobachtet und ein indirekter
Hinweis darauf aus dem Datenblatt zitiert:

  http://www.avrfreaks.net/forum/address-stack-has-always-bit

Generell gibt es ja mehrere Möglichkeiten, die ungenutzten oberen Bits
(beim ATmega16 die Bits 13-15) des Program-Counters hardwaremäßig zu
implementieren:

1. Sie sind wie die Bits 0-12 als Flipflops implementiert und können
   damit geschrieben und gelesen werden.

2. Sie sind so verschaltet, dass sie beim Lesen einen sinnvollen Wert,
   nämlich 0 liefern.

3. Sie so verschaltet, wie es implementierungstechnisch am einfachsten
   ist, so dass jedes Bit beim Lesen zwar immer denselben Wert liefert,
   der aber implementierungsabhängig 0 oder 1 sein kann.

4. Sie sind überhaupt nicht verschaltet, so dass beim Lesen die
   entsprechenden Datenleitungen floaten und der gelesene Wert zufällig
   ist.

Alternative 4 halte ich für unwahrscheinlich. Für den ATmega16 trifft
wohl die Alternative 3 zu, für die meisten anderen AVRs wohl 1 oder 2
(welche davon, müsste man testen).

Das aktuelle AVR-Studio scheint den Effekt im Gegensatz zu älteren
Versionen realitätsgetreu zu simulieren.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren