Teile der STL benutzen auf arm7 mittels Yagarto

[Thorsten F. (thorstenf)]

Ich weiss dass viele nun versuchen werden mir das auszureden, da die 
Verwendung der STL auf einem uC bestenfalls fragwürdig ist, hoffe jedoch 
dass mir trotzdem jemand helfen kann. Im übrigen besteht mein Prof auf 
der Verwendung der STL

Ich Arbeite derzeit mit einem mcb2300 (nxp lpc2388) und einer Yagarto 
Toolchain. Es ist auch kein Problem C++ Code zu verwenden, Klassen und 
deren Ableitungen habe ich bereits erfolgreich getestet.

Evtl ist es auch eine nur eine Kleinigkeit, aber ich denke es gibt 
derzeit keinen STL support innerhalb Yagarto? Es gibt zwar eine 
libstdc++.a allerdings bin ich mir ehrlich gesagt nicht sicher was diese 
enthält. Einen Header für lists oder maps finde ich innerhalb der 
Toolchain leider nicht :/

Sind diese Header irgendwie in der C++ Lib versteckt und mir fehlt nur 
eine entsprechende linker/compiler option?

Wenn nicht, was würde zu einem brauchbaren Ergebnis führen, ich denke da 
beispielsweise an STL port?

[Klaus W. (mfgkw)]

Die Header heißen nach aktuellem Stand nicht list.h, map.h etc.,
sondern schlicht list und map.
Vielleicht mal danach im Dateisystem suchen?

Zum Kompilieren werden diese benötigt, heraus kommt dabei
eine sogenannte Objektdatei.
Der Linker macht dann daraus (zusammen mit anderen Objektdateien
z.B. aus Bibliotheken) das ausführbare Programm.

Die libstdc++.a ist eine solche Bibliothek und deutet an, daß es
eigentlich möglich sein sollte auf diesem System.

Notfalls gibt es diverse Implementierungen der STL, die man
sich aus dem Internet holen kann.

[Thorsten F. (thorstenf)]

Gut zu wissen, hätte ich mir eigentlich denken müssen. Habe sie die 
ganze Zeit nicht gefunden, da ich explizit nach list.h gesucht habe.

Und da ich vergessen hatte das include dir einzugeben hatte ich bei
#include <list>
auch nur eine unresolved inclusion.

Beim durchstöbern von Yagarto ist mir aufgefallen dass es neben list und 
map, auch stl_list.h und stl_map.h gibt. Sind diese dann die 
Entsprechungen der "alten" list.h und map.h?

[Thorsten F. (thorstenf)]

Erstmal entschuldigt bitte den Doppelpost, es ist mir irgendwie nicht 
möglich meinen eigenen Beitrag zu bearbeiten.

Nach dem Einrichten des passenden Include Directories kann ich nun eine 
Liste im Code erstellen und das ganze auch fehlerfrei kompilieren :)
Die Größe meiner Binary geht allerdings von 3kb auf ~65kb (was 
eigentlich ja nicht sooo schlimm sein sollte bei 512kb flash).
Der wirklich störende Punkt ist, dass das Programm nicht auf dem uC 
läuft. da passiert einfanch gar nichts mehr.
Gdb hängt einfach bei continue, hat jemand eine Idee woran so etwas 
liegen kann?

[Karl H. (kbuchegg)]

Thorsten F. schrieb:

> Beim durchstöbern von Yagarto ist mir aufgefallen dass es neben list und
> map, auch stl_list.h und stl_map.h gibt. Sind diese dann die
> Entsprechungen der "alten" list.h und map.h?

Schwer zu sagen.
Aber das sind ja alles Text-Files. Mach sie auf und sieh nach.

[Karl H. (kbuchegg)]

Thorsten F. schrieb:

> Nach dem Einrichten des passenden Include Directories kann ich nun eine
> Liste im Code erstellen und das ganze auch fehlerfrei kompilieren :)
> Die Größe meiner Binary geht allerdings von 3kb auf ~65kb (was
> eigentlich ja nicht sooo schlimm sein sollte bei 512kb flash).

Eigentlich schon.
Dass das list template ein bischen was mit auf die Waage bringt ist ok. 
Aber 65 kB ist schon ein wenig heftig.

> Der wirklich störende Punkt ist, dass das Programm nicht auf dem
> uC läuft. da passiert einfanch gar nichts mehr.

Programm?

[Thorsten F. (thorstenf)]

Hier mal meine Main.cpp

#include "LPC23xx.h"
#include "LCD.h"
#include "C:\Programme\yagarto\arm-elf\include\c++\4.4.2\list"





int main(){

//    std::list<char> testlist;    //Diese Zeile macht 63kb aus und führt zum hängen des Boards/Debuggers
    lcd_init();
    lcd_clear();
    PINSEL10 = 0;                         /* Disable ETM interface, enable LEDs */
    FIO2DIR  = 0x000000FF;                /* P2.0..7 defined as Outputs         */
    FIO2MASK = 0x00000000;
    FIO2CLR = 0xFF;                       /* Turn off all LEDs                  */
    FIO2SET = (0xFF);                 /* Turn on requested LEDs             */



    lcd_print ("Base Project");                 // Display string on LCD display
    set_cursor (0, 1);                              // Set cursor position on LCD display
    lcd_print ("stl on mcb2300");


  return 0;
}

Ich hänge mal sicherheitshalber noch mein makefile sowie das 
Linkerscript mit an.

[Karl H. (kbuchegg)]

Makfile

# Optimization level, can be [0, 1, 2, 3, s].
# 0 = turn off optimization. s = optimize for size.
# (Note: 3 is not always the best optimization level. See avr-libc FAQ.)
#OPT = s
OPT = 0


ohne Optimierung
OK, dann glaub ich dir, dass da 65kB draus werden. Bei Verwendung der 
STL ist das Einschalten der Optimierung quasi Pflicht. Probiers aus, geh 
auf s, der Speicherverbauch sollte eigentlich drastisch sinken. Wenn ja: 
dann ist das nichts worüber du dir jetzt Gedanken machen müsstest.


Der Hänger ist aber blöder. Da weiß ich jetzt auch nicht weiter. Nur 
dadurch, dass du eine Liste definierst, sollte eigentlich nichts hängen. 
Versuch mal im Konstruktor der Liste herauszufinden, ob da irgendwelche 
Dinge dynamisch allokiert werden und ob du Unterstützung für new/delete 
hast.

[Thorsten F. (thorstenf)]

Ich gehe schwer davon auss das dort dynamisch Speicher angelegt wird, 
jedoch werden new und delete unterstützt.

Der Tipp mit der Opimierung war auf jeden Fall Gold wert. Die Codegröße 
ist von 64kb auf 7kb, und erstaunlicherweise funktioniert das Programm 
nun auch.

Das ist irgendwie verwirrend, aber ich bin erstmal happy. Werd die Liste 
jetzt mal ausgiebiger testen.

[Klaus W. (mfgkw)]

NB: absolute Pfade in einem #include sind nicht Sinn der Sache
und gelten gemeinhin als zumindest unelegant.

[Thorsten F. (thorstenf)]

Der absolute Pfad ist mittlerweile aus dem Projekt verschwunden 
(EXTRAINCDIRS im makefile entsprechend erweitert). Vielen Dank für den 
Hinweis, ich werde das in Zukunft vermeiden.

Mein Vorhaben die Liste zu testen scheiterte bisher leider kläglich, es 
ist mir zwar möglich eine leere Liste anzulegen, jedoch lässt ein 
einfaches .push_back() meine Codegröße auf ~64kb anspringen und das 
Programm hängt wieder (Wieder auch so dass das Debuggen nicht mehr 
funktioniert)

Fehlen mir hier ein paar wichtige Compilerflags?

[Klaus W. (mfgkw)]

64 kB als Speichermenge, die man mit 2 Byte adressieren kann, riecht
ja danach, daß evtl. Zeiger nur 16 Bit haben und gar nicht mehr geht?

[Thorsten F. (thorstenf)]

Nunja irgendwie sollte es ja funktionieren, ansonsten ergibt die 
Implementierung der Liste ja irgendwie keinen Sinn.

Stimmt evtl etwas bei der Speicherallokierung nicht? momentan verwende 
ich vereinfachte Implementierungen von new und delete

Ich glaube bei mir ist irgendwas größeres falsch, ich habe 
beispielsweise das gleiche verhalten (codegröße und debugger) wenn ich 
beispielsweise die
Flag

-fno-execptions

entferne.

[Thorsten F. (thorstenf)]

Gibt es ein Problem wenn mit dem interworking bzw dem Thumb instruction 
set in diesem Zusammenhang?
Verwende ich ausschließlich das ARM instructionset wird mein code noch 
gewaltiger(64kb->~80kb), aber scheint es zu funktionieren.