mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ROM-Auslastung von C++-Programm reduzieren


Autor: Manuel W. (multisync)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

zum Aneignen/Vertiefen von Programmierkenntnissen entwickle ich gerade 
privat an einem Projekt rum. Verwendeter Mikrocontroller: STM32F103C8T6. 
Ich habe einen funktionstüchtigen Versuchsträger der ausschließlich in C 
programmiert ist. Ich will nun das Projekt auf objektorientiertes C++ 
umstellen. Dafür habe ich nun einen Teil der Software nun als Klasse 
programmiert, und sie funktioniert auch wunderbar. Jedoch scheint sich 
die ROM-Auslastung drastisch zu erhöhen. Könnt ihr mir Tipps geben, wie 
ich ROM freischaufeln kann?

Anbei findet ihr:
 - robot-ausschlieszlich-c.map: MAP-File der C-only-Lösung
 - robot-mit-cplusplus-anteilen.map: MAP-File der erweiterten Lösung bei 
der das Modul "Trajectory" als C++-Klasse implementiert wurde.
 - stm32f103c8_flash.ld: Linkerskript.

Ich denke, dass das __etext-Symbol das Ende des benutzten ROMs markiert. 
Wenn das stimmt, sind bei der C++-Lösung 61k der 64k ROM belegt. Bei der 
C-only-Lösung sind nur runde 25k belegt.

Gibt es etwas das ich tun kann, um die ROM-Belegung zu reduzieren?

Folgende Switches habe ich gesetzt:
- isolate each function in a section
- remove unused sections
- don't catch exceptions
- no run-time-type-identification
- newlib nano-branch
- use C++ libraries
- no optimizations (Für die Entwicklungsphase würde ich das gerne 
beibehalten, da optimierter Code angeblich schwerer zu debuggen ist.)


Vielen Dank im Vorraus!
Manuel

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Manuel W. schrieb:
> - no optimizations (Für die Entwicklungsphase würde ich das gerne
> beibehalten, da optimierter Code angeblich schwerer zu debuggen ist.)

Das ist halt schon verkehrt. Optimierungen ausschalten und guten/kleinen 
Code erwarten macht halt keinen Sinn. Schalte mal -Os ein. Wenn du 
tatsächlich Probleme mit Debugging hast, verwende -Og oder doch -O0.
Ansonsten:
https://www.mikrocontroller.net/articles/ARM_GCC#C... 
befolgen

Disassembly posten, dann kann man schauen was da viel frisst

Autor: ягт ден троль раус (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erst mal ueberlegen was C++ denn bringt.

Sie sollte die Dokumentaion wegen der Re-use verbessern, man bringt eine 
Struktur in die Dokumentation die vorher nicht da war.

Und sie sollte den Code dichter machen, wegen der Re-use von Code.

Wenn du also mehr Codespeicher benoetigst ist etwas noch nicht ganz 
optimal. Das bedeutet, dass zB Debugcode dabei ist, oder 
Ueberpruefungen.

Ich setze mal voraus, du verwendest keine dynamischen zur Laufzeit 
verlinkten Objekte, und keine dynamischen Objekte. Die beiden sollte man 
nicht verwenden, denn sie sind fehleranfaellig. Machen den Code viel 
unzuverlaessiger.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-ffunction-sections -fdata-sections mit --gc-sections mal ausprobiert?

Autor: Manuel W. (multisync)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ягт ден троль раус schrieb:
> Ich setze mal voraus, du verwendest keine dynamischen zur Laufzeit
> verlinkten Objekte, und keine dynamischen Objekte. Die beiden sollte man
> nicht verwenden, denn sie sind fehleranfaellig. Machen den Code viel
> unzuverlaessiger.

Ich habe mein Objekt tatsächlich dynamisch zur Laufzeit instanziiert. 
Ich weiß, dass das den Code fehleranfälliger macht, aber ich wollte es 
trotzdem einmal ausprobieren, einfach um es mal gemacht zu haben. Ich 
habe dynamische Speicherallokation noch niemals benutzt.

Ich habe den Zeitpunkt der Instanziierung nun zur Kompilierzeit hin 
verschoben, und voilà, tatsächlich schrumpfte die Codegröße wieder 
beträchtlich! Sie betrug dann nur noch 29kB, 3kB mehr als mit reinem C. 
Das hätte ich mir nicht gedacht. Was ist der Grund dafür? Weil die 
Notwendigkeit für's Heap-Management entfällt?

Etwas übermütig geworden habe mich nach diesem Erfolgserlebnis gleich 
daran gemacht das nächste Modul auf .cpp umzustellen. Und zwar die 
Hauptdatei des Projekts, also jene in der main() definiert wird.

Obwohl da drinnen nichts objektorientiert ist und gar nichts dynamisch 
stattfindet (kein malloc() oder operator new), ging die Codegröße gleich 
wieder auf ~60kB hoch.


Anbei sind die zugehörigen Dateien:
 - robot-mit-cplusplus-anteilen-noheap.map: Codegröße 29kB
 - robot-mit-cplusplus-anteilen-noheap-trotzdem-grosz.map: Codegröße 
~60kB
 - robot-mit-cplusplus-anteilen-noheap-trotzdem-grosz.objdump: Codegröße 
~60kB

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel W. schrieb:
> Was ist der Grund dafür? Weil die Notwendigkeit für's Heap-Management
> entfällt?

Die malloc Funktion und das zugehörige Zeug ist halt groß. Außerdem 
natürlich der Exception Handling Code wenn du new verwendest.

Deine Disassembly enthält jede Menge double Berechnungen. Vielleicht mal 
auf float oder Interesse umstellen. Außerdem Exception Handling Code. 
Der wird trotz -fno-exceptions eingebunden wenn du irgendwas tust, was 
Exceptions generieren kann. Überschreibe mal __cxa_pure_virtual

Autor: Reginald Leonczuk (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann in meiner IDE auf newlibnano umstellen, da sinkt der benötigte 
Speicher im Flash um 50% bei mir.

Autor: Manuel W. (multisync)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Manuel W. schrieb:
>> Was ist der Grund dafür? Weil die Notwendigkeit für's Heap-Management
>> entfällt?
>
> Die malloc Funktion und das zugehörige Zeug ist halt groß. Außerdem
> natürlich der Exception Handling Code wenn du new verwendest.

Hmm... Alles klar. Interessant, was da alles hineingeschwemmt wird.

> Deine Disassembly enthält jede Menge double Berechnungen. Vielleicht mal
> auf float oder Interesse umstellen. Außerdem Exception Handling Code.
> Der wird trotz -fno-exceptions eingebunden wenn du irgendwas tust, was
> Exceptions generieren kann. Überschreibe mal __cxa_pure_virtual

Das alles wundert mich ehrlichgesagt ziemlich.

 - type float verwende ich im Code durchaus, aber type double habe ich 
wirklich nirgendwo verwendet.
 - Den Einfluss meiner Änderung auf's Exception-Handling verstehe ich 
auch nicht ganz. Ich habe wirklich nur mein .c-File in .cpp umbenannt, 
den Targetcompiler geändert (CPP anstatt CC), ein paar Compilerswitches 
gesetzt (zB "don't catch exceptions") und eingebundenen C-Header über 
extern "C" geklammert. Ich instanziiere aber keine Objekte oder 
ähnliches. Da drin ist nur stinknormaler C-Code.

Das mit __cxa_pure_virtual probiere ich mal.

Autor: Dieter Werner (dds5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Vielleicht mal auf float oder Interesse umstellen.

LOL.
Der Korrektur-Automat lässt grüßen!

Autor: Manuel W. (multisync)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun
 - __cxa_pure_virtual definiert
 - und folgenden Artikel gefunden: 
http://www.embedded.com/design/mcus-processors-and...
Grund dafür:

Die Codebeispiele hinter folgenden Absätzen habe ich hinzugefügt.

"Most low-end ARM-based MCUs cannot tolerate 50KB code overhead. To 
eliminate that code you need to define your own, non-throwing versions 
of global new and delete, which is done in the module mini_cpp.cpp 
located in the directory cpp_blinky1."

"Finally, if you don't use the heap, which you shouldn't in robust, 
deterministic applications, you can reduce the C++ overhead even 
further. The module no_heap.cpp provides dummy empty definitions of 
malloc() and free():"
#include <stdlib.h> // for prototypes of malloc() and free()

// ...............................
extern "C" void *malloc(size_t) {
  return (void*)0;
}

// ...............................
extern "C" void free(void *) {
}

// .................................................................
void *operator new(size_t size) throw() { return malloc(size); }
// .................................................................
void operator delete(void *p) throw() { free(p); }
// .................................................................
extern "C" int __aeabi_atexit(
        void *object,
        void (*destructor)(void *),
        void *dso_handle)
{
        return 0;
}

void __cxa_pure_virtual()
{

}

Leider ist die Codegröße nach wie vor bei ~60kB...

Autor: Torsten Robitzki (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht hilft Dir dieser Link: 
https://www.gitbook.com/book/arobenko/bare_metal_cpp/details

Ansonsten, wenn möglich auf den heap verzichten, RTTI und exceptions 
ausschalten. Dann gibt es eigentlichen keinen Grund, warum Deine C++ 
Variante größer sein sollte.

Vielleicht fängst Du mal damit an, Dein C code mit einem C++ compiler 
übersetzbar zu machen. Dann ist offensichtlich, dass sich die 
Code-Größen nicht unterscheiden dürften.

mfg Torsten

Autor: Manuel W. (multisync)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt das Problem gefunden!

Ich musste einfach nur Definitionen für die symbols __cxa_end_cleanup 
und __gxx_personality_v0 hinzufügen.
extern "C" void __cxa_end_cleanup(){};
extern "C" void __gxx_personality_v0(){};

Wie bin ich darauf gekommen?

Wenn man sich die bereits geposteten map files
 - robot-mit-cplusplus-anteilen-noheap.map
 - robot-mit-cplusplus-anteilen-noheap-trotzdem-grosz.map
näher ansieht, springt es einem eigentlich eh gleich in's Auge.

Ganz zu Beginn des Dokuments beschreibt der Linker nämlich, welche 
Objekte er einbindet, und welche Referenzen der Grund dafür sind:
c:/program files (x86)/emblocks/2.30/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/lib/armv7-m\libstdc++_n.a(eh_arm.o)
                              obj\release\src\main.o (__cxa_end_cleanup)

Ein Diff macht klar, dass bei der C++-Lösung deutlich mehr Objekte 
hineingelinkt werden. Object A referenziert ein Symbol aus Object B, 
welches ein Symbol aus Object C referenziert usw. usf. An der Wurzel 
dieser ganzen Abhängigkeiten stehen jedoch nur zwei Referenzierungen: 
Die von __cxa_end_cleanup und __gxx_personality_v0. Wenn ich also für 
diese selbst Definitionen bereitstelle, wird das Reinlinken der tausend 
anderen Objects auch verhindert.

Die Codegröße ist jetzt wieder auf dem Niveau der C-Lösung. :-)

Definitionen für operator new, operator delete, malloc() und delete() 
bereitzustellen war -- in meinem Fall zumindest -- nicht nötig. 
Vielleicht kommt das aber noch.

: Bearbeitet durch User
Autor: Manuel W. (multisync)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten R. schrieb:
> Vielleicht hilft Dir dieser Link:
> https://www.gitbook.com/book/arobenko/bare_metal_cpp/details

Danke für den Link, das Buch ist sehr interessant!

Torsten R. schrieb:
> Ansonsten, wenn möglich auf den heap verzichten, RTTI und exceptions
> ausschalten. Dann gibt es eigentlichen keinen Grund, warum Deine C++
> Variante größer sein sollte.
>
> Vielleicht fängst Du mal damit an, Dein C code mit einem C++ compiler
> übersetzbar zu machen. Dann ist offensichtlich, dass sich die
> Code-Größen nicht unterscheiden dürften.

Genau das mache ich doch gerade...

: Bearbeitet durch User
Autor: ./. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  - type float verwende ich im Code durchaus, aber type double habe ich
> wirklich nirgendwo verwendet.

Da reicht schon ein:

3.1415926

wo eigentlich ein:

3.1415926F

hinmuesste.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.