Alternative Speicheraufteilung bei µC

Rick schrieb:

Einen (wirklich kleinen) Nachteil sehe ich: Man muß vorher schon wissen, wieviel Platz man dem Stack einräumen möchte.

Genau das ist aber bei Architekturen, wo der Speicherplatz knapp ist, der eigentliche Knackpunkt. Und ausserdem kann natürlich auch bei deiner Speicherkonfiguration der Heap einfach in den Stack (oder vice versa) reinlaufen, denn beim Überlauf von xff...ff geht es mit 0 weiter und beim Unterlauf von 0 geht es nach xff...ff. Du kannst also mental einfach das "obere Ende2 des Speicherbereichs an das "untere Ende" anfügen.

Und dann siehst du: beide Speicheranordnungen im Bild sind bis aufs i-Tüpfelchen gleich. Lediglich die Startadressen sind anders.

Lothar M. schrieb:

Und ausserdem kann natürlich auch bei deiner Speicherkonfiguration der Heap einfach in den Stack (oder vice versa) reinlaufen,

Für einen AVR o.ä. simmt das, zumindest wenn der Speicher den Adressraum 2^n komplett füllt. Ich habe aktuell einen STM32 vor mir, der hat noch Lücken in der Speicheraufteilung...

Ich lege den Stack schon immer auf die niedrigste Adresse, quasi instinktiv. Es scheint zu funktionieren ;)

Allerdings kann man mit der MPU auch die klassische Anordnung sicherer machen: .data, .bss, Heap, NICHTS, Stack. Man muss ein wenig RAM für eine verbotene Zone zwischen Heap und Stack opfern, je nach RAM-Größe zwischen 64 Byte und wenigen kByte.

Damit könnte man sogar auf einen Überlauf reagieren, die Grenze zur Laufzeit verschieben und das Programm weiter laufen lassen.

Mit der MPU kann man auf die gleiche Art auch einen zweiten Stack anlegen, wir haben ja 2 Stackpointer. Und man kann ein XN Bit setzen (aka NX, Execute Never).

Rick schrieb:

Einen (wirklich kleinen) Nachteil sehe ich: Man muß vorher schon wissen, wieviel Platz man dem Stack einräumen möchte.

Musst Du doch eh wenn Du nicht nach Prinzip Hoffnung verfahren willst. Sobald du mit einem RTOS arbeitest geht es gar nicht anders, der verlangt beim starten der Task nach einer Angabe für die Stack-Größe msit sogar direkt nach Vor-Allokation des Stacks.

Rick schrieb:

Nun meine Frage: Hat das schon mal jemand längerfristig ausprobiert und kann über seine Erfahrungen berichten?

Wir arbeiten hier ausschließlich so. Man kann so auch die Performance optimieren indem man z.B. den Stack auf einen Adressbereich legt auf den die ARM parallel zum "normalen" Hauptspeicher zugreifen kann. Z.b. ins DTCM. Manchmal ist ein und derselbe physikalischen Speicher auch über unterschiedliche Busports via unterschiedlichen logischen Adressen erreichbar. Das bietet ebenfalls Optimierungspotential.

Rick schrieb:

einen STM32 vor mir, der hat noch Lücken in der Speicheraufteilung...

Hilft dann auch nur, wenn diese Lücken im Adressraum tatsächlich auch mit pyhsikalischem Speicher gefüllt sind.

Rick schrieb:

Speicheraufteilung.pdf

Warum diese Transportverpackung?

"Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen"

Rainer W. schrieb:

Warum diese Transportverpackung?

Warum machst du aus der immer perfekt scharfen Vektorgrafik im PDF eine verpixelte und größere (!) PNG-Datei?

Rick schrieb:

Beim AVR hilft das wahrscheinlich nicht so viel,

Neu AVRs (AVR-Sx, AVR-Lx) haben rudimentären hardwarebasierten Stackschutz. Siehe CPU_SPLIM.

Rick schrieb:

Heap und Stack (Bild links).

Das Ganze hat den Nachteil, das der Stack in den Heap oder gar bis in die Daten reinlaufen kann.

Ich finde diese Aufteilung genau richtig, da der Speicher für Stack und Heap verwendet werden kann. Wenn sich beide Bereiche in die Quere kommen, dann ist der Speicher eben zu klein. Im Prinzip ist es auch egal, ob ich temporären Speicher im Heap reserviere und wieder freigebe oder lokale Arrays im Stack landen. Stack ist wohl einfacher, sodaß (hier) viele Kollegen mit dem Heap sowieso nichts anfangen können.

Mi N. schrieb:

Im Prinzip ist es auch egal, ob ich temporären Speicher im Heap reserviere und wieder freigebe oder lokale Arrays im Stack landen.

Nicht ganz egal. Im Heap führt es u. U. zu Fragmentierung, im Stack nicht. Ist der Heap fragmentiert, dann kann man u. U. nicht mehr allen vorhandenen Speicher nutzen.

Stack ist wohl einfacher, sodaß (hier) viele Kollegen mit dem Heap sowieso nichts anfangen können.

Ja, Stack ist viel einfacher, aber beschränkt auf lokale Variablen.

Viele schreiben im C-Stil und nutzen/kennen die C++-Möglichkeiten nicht. Und in C ist die Heap-Speicherverwaltung bekanntlich problematisch (Buffer overflow, dangling pointer, fehlendes Destruct() nach Exceptions und anderes), sodass mancher vorsichtshalber die Finger davon lässt. In C++ ist das alles einfacher.

Niklas G. schrieb:

Warum machst du aus der immer perfekt scharfen Vektorgrafik im PDF eine verpixelte und größere (!) PNG-Datei?

Geht es dir um den Inhalt oder um die Eleganz und Universalität der Graphik? Gegen die perfekte Vektorgraphik an sich spricht nicht, ist hier aber eher ein akademischer Vorteil. Dank der Verpackung funktioniert die Voransicht im Forum nicht, weil die Software das anscheinend nicht unterstützt, und macht den Beitrag unnötig schwer lesbar.

Bei der von mir gewählten Größe der Graphik ist von "verpixelt" nichts zu sehen, solange man nicht auf eine akademische, völlig praxisfremde Vergrößerung reinzoom. Da die Information, die die Graphik bietet, genauso gut in 10 Textzeilen passt, ist ein weitere Reinzoomen überflüssig.

An den zusätzlichen 27 kByte wird das Forum nicht ersticken, da gibt es ganz andere, inhaltslosere Anhänge, für die man hunderte von diesen hochladen könnte. Die zehn Textzeilen wären vom Speicherbedarf deutlich sparsamer als die Vektorgraphik ;-)