SRAM schonende Optimierung beim gcc?

[SRAM ist voll (Gast)]

'-Os' läßt ja der benötigten Flashspeicher schrumpfen.

Welche von den vielen -f... Optionen nimmt man, wenn man noch viel 
Flashspeicher frei hat, aber das SRAM zur Neige geht?

[Hans (Gast)]

Ich bezweifle, dass es da entscheidende Unterschiede gibt. Du musst 
vielmehr dein Programm handoptimieren...

[Hans (Gast)]

Wenn du noch viel Flash über hast, heißt das ja, dass du nicht viel Code 
hast, aber sich anscheinend viele Daten in Arrays etc. häufen. Die 
werden natürlich nicht kleiner. Daten sind Daten. Du musst einfach 
sinnvoll planen, sofern möglich.

[Carl D. (jcw2)]

SRAM ist voll schrieb:
> '-Os' läßt ja der benötigten Flashspeicher schrumpfen.
>
> Welche von den vielen -f... Optionen nimmt man, wenn man noch viel
> Flashspeicher frei hat, aber das SRAM zur Neige geht?

Sind die verwendeten Strings schon im Flash, oder sind die noch im RAM?

const char string[] = "ein String";

sieht dank const nicht so aus, aber belegt 11Byte wertvolles RAM

http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
beschreibt was man dagegen tun kann.

[Wilhelm M. (wimalopaan)]

SRAM ist voll schrieb:
> '-Os' läßt ja der benötigten Flashspeicher schrumpfen.
>
> Welche von den vielen -f... Optionen nimmt man, wenn man noch viel
> Flashspeicher frei hat, aber das SRAM zur Neige geht?

Welche Sprache soll es denn sein?

Um RAM zu sparen, sollte / kann man C++ möglichst viel Information in 
die Datentypen codieren: das hat zur Folge, dass

1) der Compiler viel besser optimieren kann, da er mehr Typinformationen 
zur Verfügung hat

2) man "gezwungen" ist, sich zu überlegen, welche Informationen man zur 
Compilezeit ggf. durch Meta-Funktionen schon berechnen kann.

Datentypen als solche sind ja im Maschinencode nicht mehr präsent und 
belegen keine SRAM.

Meine Beobachtung bei fremden Code ist, dass die meisten Leute sich viel 
zu wenig Gedanken um ihr (domänenspezifisches) Typ-System machen. Aber 
genau das ist das A-und-O.

Natürlich kann(!) (nicht muss) extensive Nutzung der Template-Mechanik 
zur Produktion von mehr Code (im Flash) führen. Allerdings sind 
teilweise die Optimierungen des Clang / gcc bei template-code geradezu 
"atemberaubend", und andererseits tun ein paar (k)Byte mehr 
Flashverbrauch weniger weh als beim SRAM.

[Rolf M. (rmagnus)]

Carl D. schrieb:
> Sind die verwendeten Strings schon im Flash, oder sind die noch im
> RAM?const char string[] = "ein String";sieht dank const nicht so aus,
> aber belegt 11Byte wertvolles RAM

Nicht unbedingt. Das hängt von der (hier unbekannten) Architektur ab.

> http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
> beschreibt was man dagegen tun kann.

Ja, für den AVR hast du recht.

[Carl D. (jcw2)]

Rolf M. schrieb:
> Carl D. schrieb:
>> Sind die verwendeten Strings schon im Flash, oder sind die noch im
>> RAM?const char string[] = "ein String";sieht dank const nicht so aus,
>> aber belegt 11Byte wertvolles RAM
>
> Nicht unbedingt. Das hängt von der (hier unbekannten) Architektur ab.
>
>> http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
>> beschreibt was man dagegen tun kann.
>
> Ja, für den AVR hast du recht.

Stimmt, ich hab dieses Forum als AVR-Forum kennengelernt und so was 
prägt.