ATmega32 CALL ohne SP vorher

Denis Meißner schrieb:
> was passiert eigentlich, wenn ich mit CALL in ein Unterprogram
> springe, ohne vorher den Stackpointer gesetzt zu haben?

Er wird korrekt ins Unterprogramm springen, egal, ob du den SP 
initialisiert hast oder nicht.

> Würde er dann in das letzte RET springen, dass ich gesetzt habe?

Die Frage verstehe ich nicht. Du meinst, was passiert, wenn das per CALL 
gestartete Unterprogramm mit RET beendet wird?

Falls der SP vorher nicht initialisiert wurde, wird der Programmablauf 
mit einiger Sicherheit an einer Stelle fortgesetzt, an der du es gar 
nicht haben willst. Anders ausgedrückt: das Programm stürzt 
wahrscheinlich ab.

Es bleibt die Frage, warum du den SP nicht initialisieren magst.
Gerade bei dem technisch schon länger nicht mehr aktuellen ATmega32 ist 
das wichtig, weil der SP sonst den Wert 0 hat. Du könntest natürlich 
auch den Nachfolger des Nachfolgers des ATmega32 verwenden: den 
ATmega324A.
Beim ATmega324A wird der SP nämlich automatisch mit dem richtigen Wert 
initialisiert, so dass du dich im Normalfall nicht darum kümmern musst. 
Zu empfehlen ist die explizite Initialisierung aber trotzdem, weil es ja 
sein kann, dass der Controller per Reset oder Brown-out neu gestartet 
wird.

Grundsätzlich kannst du natürlich auch ganz ohne SP arbeiten. Dann 
solltest du allerdings Assembler als Programmiersprache verwenden und 
ein paar Besonderheiten berücksichtigen...

Hi.

Der SP wird bereits durch die Hardware nach einer RESET-Condition auf 
RAMEND gesetzt. (Ich weis, die glibc macht es danach nocheinmal in 
Software...)

Wenn du also nicht absichtlich den SP vorher verschoben hast, passiert 
absolut nichts (selbst wenn du mittels "naked" in "init0" starten 
wuerdest), weil alles wie gewohnt ablaueft.

MfG

Okay, habe eben nocheinmal nachgelesen. Stimmt!
Beim ATmega32 ist SP initial undefiniert.

In diesem Fall droht ein Unterprogrammaufruf unkontrolliert verwendete 
Variablen (oder sogar Register?) zu ueberschreiben.

MfG

Stephan B. schrieb:
> Beim ATmega32 ist SP initial undefiniert.

Nein, er ist 0.
Ein Call würde also die Returnadresse in R0 und 0xFFFF speichern wollen.
Die Register können zwar als SRAM adressiert werden, nicht jedoch als 
Stack.

Es ist also nicht der Stackpointer undefiniert, sondern der SRAM, auf 
den er zeigt.

Stephan B. schrieb:
> In diesem Fall droht ein Unterprogrammaufruf unkontrolliert verwendete
> Variablen (oder sogar Register?) zu ueberschreiben.

Variablen werden erst nach mehreren verschachtelten Aufrufen 
überschrieben. So schnell schafft es der SP nicht von 0 aus (nach unten) 
ins SRAM.
Register werden nach meiner Erinnerung nicht überschrieben, weil diese 
Adressierungsart (gemappte Register) für den SP HW-technisch nicht 
implementiert wurde.

In Assembler ist es locker möglich, mit Unterprogrammen zu arbeiten 
(z.B. nur eine Ebene), ohne den Stack zu verwenden. Es muss ja nicht das 
klassische RCALL und RET sein. Sogar Interrupts sind dann möglich - 
sofern man eine feste Rücksprungstelle verwendet.
Das ist natürlich nur für spezielle Fälle sinnvoll, wenn man z.B. das 
gesamte SRAM für Variablen oder einen Puffer benötigt. Über seine 
Beweggründe hat Denis Meißner aber leider nichts verraten...

Peter Dannegger schrieb:
> Nein, er ist 0.

Davon steht nichts im Datenblatt (soweit wie ich ueberflogen habe) und 
ich halte das auch fuer ein Geruecht.

Der SP ist vielleicht NULL beim PowerUp, aber nach einem Reset wird der 
letzte Wert darin stehen - also undefiniert im weitem Sinne.

MfG

Unten bei "Initial Value"?

Okay, obwohl ich das wohl nicht glaube g ( ;-) ) ist es wohl nicht 
verkehrt das anzunehmen.

Also Danke fuer die Richtigstellung, ich bin von den XMegas verdorben 
worden ;-)

MfG