Atmega objdump: Speicherfresser finden

Bei über 1500 Byte an globalen Variablen sucht man nach großen Arrays. 
Diese Menge bekommt man mit vielen kleinen Variablen nicht mal annähernd 
zusammen.

Oliver

chris schrieb:
> Was mich ein wenig wundert ist, dass Objekte die noch nicht instantiiert
> sind und in einer Liste später gesammelt werden, schon ca. 10 Byte .data
> zu verbrauchen scheinen.

Was meinst du mit "noch nicht instantiiert"? Globale Variablen sind 
immer da und brauchen immer Speicher. Es gibt kein "noch nicht 
instantiiert".

chris schrieb:
> Warum verbrauchen die Klassen 16Bytes an initialiertem .data-RAM, ohne
> ein einziges Objekt?

Das liegt bei AVR an der vtable, die der gcc blöderweise ins RAM packt. 
Jede virtuelle Elementfunktion benötigt darin dann 2 Byte zzgl. der bei 
Null-Einträge am Anfang sowie dem virtuellen dtor.

chris schrieb:
> Es scheint mir,
> das wäre der bessere Weg gewesen.

Die Frage ist, ob Du überhaupt Laufzeitpolymorphie benötigst. Meistens 
ist das nämlich gar nicht der Fall und man kann das durch statische 
Polymorphie ersetzen.

chris schrieb:
> Ich habe 30 Klassen a 16Bytes was mich ca. ein viertel des Speichers
> kostet.

Was allerdings bedeutet, daß nichtmal eine Instanz von jeder Klasse ins 
RAM passt. Das Konzept erscheint nicht ganz durchdacht.

Oliver

Folgendes Tool könnte vielleicht nützlich sein:
http://www.sikorskiy.net/prj/amap/

"amap : A tool to analyze .MAP files produced by 32/64-bit Visual Studio 
compiler and report the amount of memory being used by data and code.
This app can also read and analyze MAP files produced by the GCC, 
Xbox360, Wii, PS3 (gcc and SNC), and PS4 compilers."

Das erleichtert zumindest das Suchen etwas...

avr-size ist Dein Freund.

Andreas B. schrieb:
> avr-size ist Dein Freund.

Besser:

1

avr-nm -CS --size-sort test.elf

Aaaaahhhhhh ... Objekte auf einem AVR ... aaaaahhh.
Man kann auchb wirklich alles falsch machen.

Was sollen die denn bringen ? Eine linked list ?
Sollte man immer alles statisch allozieren.

Joggel E. schrieb:
> Aaaaahhhhhh ... Objekte auf einem AVR ... aaaaahhh.
> Man kann auchb wirklich alles falsch machen.

Was hast Du gegen Objekte?

Du meinst virtuelle Elementfunktionen und Laufzeitpolymorphie.

Hi

https://github.com/ARMmbed/mbed-os-linker-report

Ganz toll um sich einen Überblick zu verschaffen.

Matthias

chris schrieb:
> Wie finde ich mit avr-objdump die großen Speicherfresser?

Ist das Projekt geheim, oder kannst du das hier mal hochladen?

Oliver

>> Joggel E. schrieb:
>> Aaaaahhhhhh ... Objekte auf einem AVR ... aaaaahhh.
>> Man kann auchb wirklich alles falsch machen.

>Was hast Du gegen Objekte?
>
>Du meinst virtuelle Elementfunktionen und Laufzeitpolymorphie.


Ja, ich habe etwas gegen Objekte auf Controllern.

Was sollen die bringen ?

Joggel E. schrieb:
> Ja, ich habe etwas gegen Objekte auf Controllern.

1

int x{};

2

3

A y{};

Hier hast Du ZWEI Objekte. Und jetzt erkläre, was daran verwerflich sein 
soll.

Vincent H. schrieb:
> Folgendes Tool könnte vielleicht nützlich sein:
> http://www.sikorskiy.net/prj/amap/

Stimmt. Gerade ausprobiert und jetzt in meine Werkzeugsammung 
aufgenommen. Danke für den Tipp!

Textest Du die Leute voll?
Bei Textvariablen wird diese in's RAM kopiert, was mal schnell ein paar 
Bytes verbraucht.
Also: Texte explizit im Flash ablegen.

Ansonsten fällt mir nur noch ein:
So viele Variablen, wie möglich, lokal, in den Funktionen anlegen. Da 
brauchst Du kein malloc und so'n Kram und das Recycling passiert beim 
Rücksprung.

Sebastian S. schrieb:
> Ansonsten fällt mir nur noch ein:
> So viele Variablen, wie möglich, lokal, in den Funktionen anlegen. Da
> brauchst Du kein malloc und so'n Kram und das Recycling passiert beim
> Rücksprung.

Es hat aber auch einen großen Nachteil: Es ist zur Compilezeit nicht 
überschaubar, wie viel RAM man tatsächlich braucht. Und wenn die Daten 
zu groß für den Speicher sind, gibt's einfach nur fehlerhaftes 
Verhalten.

@Rolf M.

>Es hat aber auch einen großen Nachteil: Es ist zur Compilezeit nicht
>überschaubar, wie viel RAM man tatsächlich braucht. Und wenn die Daten
>zu groß für den Speicher sind, gibt's einfach nur fehlerhaftes
>Verhalten.
Stimmt, aber nur so kommt man auf ein "Minimum" zur Laufzeit und kann 
nicht vergessen zu "putzen".

Compiler schrieb:
>> Vor allem, ...
>
> Compiler denken nicht mit. Es gibt auch keine Optimierung die
> "so viel wie möglich ohne RAM-Nutzung in den Registern zu erledigen."

Doch, natürlich gibt es die. Das dürfte sogar zu den ältesten 
Optimierungen überhaupt zählen.

> Und ob ich die Variablen statisch deklariere oder in der main
> vom Stack hole, macht keinen Unterschied.

Es macht einen Unterschied. Darum ging es ja gerade. Bei statischen 
Variablen sehe ich bereits zur Linkzeit, wie viel Platz sie brauchen. 
Dafür brauchen sie den Platz über die gesamte Laufzeit des Programms. 
Automatische Variablen dagegen existieren nur während der Laufzeit der 
Funktion, in der sie definiert sind. Davor und danach existieren sie 
nicht. Dafür sieht man nicht, wieviel am Ende wirklich an Platz 
gebraucht wird. Allerdings werden sie wenn möglich rein in Registern 
gehalten, wodurch sie zum Teil gar keinen Speicher brauchen.

vn nn schrieb:
> Sebastian S. schrieb:
>>>Es hat aber auch einen großen Nachteil: Es ist zur Compilezeit nicht
>>>überschaubar, wie viel RAM man tatsächlich braucht. Und wenn die Daten
>>>zu groß für den Speicher sind, gibt's einfach nur fehlerhaftes
>>>Verhalten.
>> Stimmt, aber nur so kommt man auf ein "Minimum" zur Laufzeit und kann
>> nicht vergessen zu "putzen".
>
> Vor allem, da der Compiler dann versuchen wird, so viel wie möglich ohne
> RAM-Nutzung in den Registern zu erledigen.

Das macht der eh, wenn man nicht gerade Code hat, der nur mit -O0 
richtig läuft. Was der AVR auch macht: Globale Variablen immer mit 
kompletter Adresse ansprechen (also 2-Wort-LDS-STS, statt via 
Frameptr+ofs). Wenn man viele Funktionen mit kleinem lokalem 
Speicherbedarf hat, dann kann die "Stack-Variante" günstiger sein als 
die "Globals-Variante". BTW, "static type var;" ist auch "global".
Ich vermute die "static"-"Idee" stammt aus der 8051-Zeit. Dort sind 
Pointer-Zugriffe ein Horror.

Wenn man dann vom AVR Richtung ARM schaut, der hat so viele breite 
Index-Register zur Verfügung, daß lokal praktisch immer besser ist als 
(viele) globale Variablen. Wenn schon "global/static", dann wenigstens 
keine einzelnen Variablen, sondern Strukturen aus zusammen verwendeten 
Variablen. Dann kennt der Compiler für jede Variable den Offset 
innerhalb der Struktur und braucht (innerhalb gewisser Grenzen, ARM:4k) 
nur eine Basisadresse. Andernfalls: Mem-Adresse relative zum PC aus 
Flash holen und auf genau eine Variable zugreifen. Für jede einzelne 
Variable ein anderes Adressregister, bis diese ausgehen und dann 
eventuell eben mehrfach Adressen laden. Mit bis zu 4K-struct: einmal 
Basisadresse laden und dann Zugriff über Offset.
Selbst wenn man die 32bit nicht zum Rechnen braucht, die 
Adressierungsarten dieser CPU möchten man nicht mehr missen, hat man sie 
mal entdeckt.

Den Speicherverbrauch in den Funktionen kann man auch selbst 
heruasfinden. Wie viele Funktionen tief springt man, und welche 
Kombination hat am meisten Platz in lokalen Variablen deklariert. 
Rekursionen sollten vermieden werden.