Bei rcall unverständliche Rücksprungadresse auf Stack

[Stack_Simulator (Gast)]

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:

.include "m8def.inc"

.def temp = r16


         ldi temp, HIGH(RAMEND)            ; HIGH-Byte der obersten RAM-Adresse
         out SPH, temp
         ldi temp, LOW(RAMEND)             ; LOW-Byte der obersten RAM-Adresse
         out SPL, temp

         rcall sub1                        ; sub1 aufrufen

loop:    rjmp loop


sub1:
                                           ; hier könnten ein paar Befehle stehen
         rcall sub2                        ; sub2 aufrufen
                                           ; hier könnten auch Befehle stehen
         ret                               ; wieder zurück

sub2:
                                           ; hier stehen normalerweise die Befehle,
                                           ; die in sub2 ausgeführt werden sollen
         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

[Stefan E. (sternst)]

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.

[Yalu X. (yalu) (Moderator)]

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.

[Stack_Simulator (Gast)]

Hallo Yalu X.,
vielen Dank für den Link zu den avrfreaks und Deinen Erklärungen!