Bascom: HWSTACK - SWSTACK - FRAMESIZE

Mal eine Frage an die Bascom-Spezialisten:
Wofür sind eigentlich diese verschiedenen Frames bzw. Stacks gut?

Hintergrund der Frage ist, dass ich momentan an einem Projekt stricke, das rekursive Funktionen verwendet.
Als tiefste Schachtelung habe ich 20 ermittelt, ein Unterprogramm wird also maximal 20-mal von "sich selbst" aufgerufen.
Bei jedem Unterprogrammaufruf schiebt Bascom bekanntlich alle 32 Register auf den Stack, so dass alleine dafür 640 byte RAM erforderlich sind.

Welche der Stack-Angaben (HWSTACK, SWSTACK, FRAMESIZE) muss ich jetzt entsprechend erhöhen, damit die Geschichte überhaupt eine Chance hat, zu funktionieren?
Das Ganze soll auf einem Mega8 laufen, der mit 1024 byte RAM eigentlich genug Speicher zur Verfügung haben sollte...

Kappler schrieb:

Bei jedem Unterprogrammaufruf schiebt Bascom bekanntlich alle 32 Register auf den Stack

Zum Vergrößern anklicken....

Macht das Bascom wirklich so - wäre relativ ineffektiv. Normalerweise werden nur die Register gerettet, die in der Unterroutine genutzt werden - und ich möchte die Routine sehen, die alle 32 Register nutzt. Allerdings kommt (zumindest bei C) noch die Funktionsparameter hinzu, die auch auf dem Stack landen und dann natürlich noch die lokalen Variablen. ... aber alle 32 Register retten ...

Kappler schrieb:

Welche der Stack-Angaben (HWSTACK, SWSTACK, FRAMESIZE) muss ich jetzt entsprechend erhöhen, damit die Geschichte überhaupt eine Chance hat, zu funktionieren?

Zum Vergrößern anklicken....

Kann ich Dir jetzt zwar nicht beantworten, aber vor (geschätzt) einem 1/4 bis 1/2 Jahr gab es einen Thread dazu ...

Viele Grüße,
Thomas(_st)

So, inzwischen sehe ich etwas klarer...

Das mit dem Sichern aller Register beim Unterprogramm-Aufruf war ein Irrtum - das trifft nur für den Sprung in eine Interrupt-Routine zu...

Und für die verschiedenen Stackbereiche habe ich ganz schlüssige Erklärungen gefunden, die das Ganze schön darstellen:

http://halvar.at/elektronik/kleiner_bascom_avr_kurs/speicher_hwstack_swstack_frame/
und
http://www.rn-wissen.de/index.php/Bascom_Inside

(falls es sonst noch jemanden interessiert)

Kappler schrieb:

Das mit dem Sichern aller Register beim Unterprogramm-Aufruf war ein Irrtum - das trifft nur für den Sprung in eine Interrupt-Routine zu...

Zum Vergrößern anklicken....

Auch auf die Gefahr hin, nörglerisch zu erscheinen: dies trifft (sofern Bascom hier keine Extrawurst brät) auch nicht auf die Interruptroutinen zu. Nach einem IRQ wird der Programcounter (PC) auf dem Stack gerettet und dann direkt der Code an der entsprechenden Speicherstelle des INT-Vectors ausgeführt. Dort steht normalerweise ein Sprungbefehl in die ISR. Da wird bis auf den PC nirgendwo was auf den Stack gerettet; dies ist Aufgabe des Compilers so etwas in den Programmcode der ISR zu integrieren

HTH,
Thomas(_st)

Und genau das macht der Bascom-Compiler: Alle 32 Register auf den Stack schieben...

Das kann hier:
http://www.rn-wissen.de/index.php/Codevergleich_AVR-Compiler#Interrupt-Routinen
im Codevergleich avr-gcc gegen Bascom schön gesehen werden...

Kappler schrieb:

Und genau das macht der Bascom-Compiler: Alle 32 Register auf den Stack schieben...

Zum Vergrößern anklicken....

Sorry, aber dafür gibt es ein:

Kappler schrieb:

Das kann hier:
http://www.rn-wissen.de/index.php/Codevergleich_AVR-Compiler#Interrupt-Routinen
im Codevergleich avr-gcc gegen Bascom schön gesehen werden...

Zum Vergrößern anklicken....

Was ich interessant finde: da wird das Status-Register (SREG) mit gesichert - muss gleich mal nachsehen, ob das immer so ist; das habe ich nämlich bei Bedarf immer selbst gemacht ...

Viele Grüße,
Thomas(_st)

Ergänzung: die Register R6, R8, R9 und R12 bis R15 scheinen nicht mit gerettet zu werden

thomas_st schrieb:

...Ergänzung: die Register R6, R8, R9 und R12 bis R15 scheinen nicht mit gerettet zu werden

Zum Vergrößern anklicken....

Tatsächlich -

Das ist aber mehr als seltsam...
Vielleicht verwendet Bascom diese Register selbst nicht und hält sie daher nicht für sichernswert? Oder da ist ein Fehler bei den Roboterfreunden...

Na, wie auch immer - Hauptsache, es funktioniert
Auch wenn Bascom wohl einiges an unnötigem Overhead erzeugt.