Optimale Stacksize bestimmen

Christian J. schrieb:

> Fragt sich nur: Wie gut liegt man mit seiner Schätzung? Egal wie ich den
> Wert verändere, der Compiler und auchn Linker meckert nicht.

Wundert mich wenig.
Wenn der Stack zu klein ist, merkst du das erst zur Laufzeit. Und das 
auch nur wenn in deinem Programm plötzlich seltsame Dinge passieren bzw. 
dein Compiler bei jedem Funktionsaufruf Code einbaut, der die Stackgröße 
überwacht und Alarm schlägt.

> Wie kann man denn die Größe so bestimmen, dass sie eben optimal passt

Gegen das Wort 'optimal' hab ich ein Aversion entwickelt.

> und man keinen wertvollen RAM verschenkt? Beim PIC Compiler rechnet der
> es aus der maximalen Verschachtelungstiefe aus, beim GCC weiss ich nicht
> wie das geht.

Die benötigte Stacksize ist im Allgemeinen nicht per Programm 
bestimmbar. Das wäre eine Variation des Turingschen Halteproblems und 
ist daher prinzipiell nicht möglich. Was nicht heißt, das es für 
einzelne Programme nicht gehen mag. Nur ist es eben nicht für jedes 
beliebige Programm möglich die benötigte Stacksize durch Betrachten des 
Source Codes zu bestimmen.

Hallo,

aber irgendwie muss man doch die optimale Size bestimmen können. Wenn 
das der CCS Compiler kann, dann können das doch auch andere. Sobald die 
Abhängigkeiten bekannt sich lässt sich das ausrechnen.

Christian J. schrieb:
> Hallo,
>
> aber irgendwie muss man doch die optimale Size bestimmen können.

1

#include <stdio.h>

2

3

unsigned int foo( unsigned int j )

4

{

5

  if( j == 0 )

6

    return 1;

7

8

  return foo( j - 1 );

9

}

10

11

int main()

12

{

13

  unsigned int k;

14

15

  scanf( "%u", &k );

16

  printf( "%u\n", foo( k ) );

17

}

Wie soll ein Linker daraus die "optimiale" Stacksize bestimmen können, 
wenn er nicht weiß, was der Benutzer eingeben wird?
(Der Compiler kann sowas prinzipbedingt nicht bestimmen, da er im 
Regelfall das komplette Programm nie zu Gesicht bekommt)

Christian J. schrieb:
> Wie kann man denn die Größe so bestimmen, dass sie eben optimal passt
> und man keinen wertvollen RAM verschenkt?

Dazu muß man in die Internas des Compilers gehen.

Es gibt Compiler, die brauchen keinerlei Einstellungen. Z.B. beim 
AVR-GCC kommen unten die globalen Variablen, danach dann Malloc und der 
Stack wächst vom Ende des SRAM nach unten.
Wenn es dann kracht, hilft keine Einstellung, dann wurde zuviel Speicher 
belegt und das Malloc rennt in den Stack rein bzw. umgekehrt.

Das manche Compiler aber mehrere Stacks benötigen, dient wohl der 
Vorbereitung von Multitasking.

Da hilft wohl nur eine Analyse zur Laufzeit. Man füllt allen unbenutzten 
SRAM mit einem Muster, z.B. 0x77 und testet nach ner Weile, wieviel 
davon in den einzelnen Stacks noch übrig ist.


Peter

Peter Dannegger schrieb:

> Das manche Compiler aber mehrere Stacks benötigen, dient wohl der
> Vorbereitung von Multitasking.

Und an der Architektur der AVRs. Da AVR keinen atomaren Update von SP 
ermöglicht, tut sich ein Compiler etwas leichter, wenn der Stack für die 
lokalen Variablen vom Return-Stack getrennt wird. Einer dieser beiden 
Stacks ist dann fix.

A. K wrote

> Und an der Architektur der AVRs. Da AVR keinen atomaren Update von SP
> ermöglicht, tut sich ein Compiler etwas leichter, wenn der Stack für die
> lokalen Variablen vom Return-Stack getrennt wird. Einer dieser beiden
> Stacks ist dann fix.

Auch beim AVR ist ein atomarer Zugriff auf SP möglich, indem man die 
Interrupts sperrt und danach wieder freigibt. Genau das macht auch der 
avr-gcc, wenn er Platz für lokale Variablen auf dem Stack reserviert. 
Einen weiteren (Software-)Stack benutzt avr-gcc nicht.

MfG Mark