arm-elf-g++ und c++

[mthomas (Gast)]

Hallo,

habe erfolglos versucht, mit der "gnu-toolchain" (arm-elf-gcc et al,
hier: GNUARM und WinARM 4/2005) ein Programm fuer einen Philips LPC2106
(ARM7TDMI) in C++ zu erstellen ("reines C" bereitet keine Probleme).
Der kaputte Versuch findet sich im Anhang - hoffentlich auf ein Minimum
gekuerzt. Der Compiler selbst meckert nicht, aber das "Disassembly"
enhaelt scheinbar keinen Code fuer die Member-Funktionen. Bin mir
zumindest ziemlich sicher, dass im Linker-Skript und Startup-Code
einiges anzupassen ist (z.B. ctors). Etwas Code fuer einen ST ARM7 aus
einer kommerziellen IDE laesst darauf schliessen. Aber habe das noch
nicht weit genug verstanden, um herauszufinden was genau zu tun ist.
Jeder Hinweis willkommen, was zu aendern/zu tun ist, "damit's mit C++
klappt". Komplette Beispiele inkl. Linker-Script und Startup-Code für
LPC2xxx unter "arm-elf-g++"  würden ebenfalls sehr weiterhelfen.


Martin Thomas

[OldBug (Gast)]

Hallo Martin!

Das scheint in irgend einer Weise mit der Optimierung des Compilers
zusammen zu hängen. Wenn ich -O0 einstellen (also Optimierung
abschalte), dann erhalte ich den Code...

[OldBug (Gast)]

Hm, es könnte auch daran liegen, wie Du die Klasse implementierst.

Folgender Code (nach den ersten 5 Kapiteln aus "Thinking in C++"
erzeugt auch brauchbaren Code:

class LED_Handler
{
public:
    void init();
    void off();
    void on();
}

void LED_Handler::init(void)
{
    IODIR |= (1 << LEDPIN);
    IOSET = (1 << LEDPIN);
}

void LED_Handler::off(void)
{
    IOCLR = (1 << LEDPIN);
}

void LED_Hander::on(void)
{
    IOSET = (1 << LEDPIN);
}

...im main dann:

[..]
    LED_Handler lh;

    lh.init();

    lh.on();

    lh.off();
[..]

[mthomas (Gast)]

Erstmal Danke Patrick, das bringt doch schon ein Stück weiter.
Vielleicht liegt es tatsaechlich an den "inline-Member-Funktionen"
und einer "übertriebenen" Optimierung, da im Beispiel innerhalb der
Funktionen nur auf I/O-Register zurueckgegriffen wird. Koennte sein,
dass das volatile bei den "Registermakros" bei der
"C++-Optimierung" noch ignoriert wird. Die Implementierung ausserhalb
der Klassendeklaration (wie in Deinem Codefragment) ist wenn recht
erinnert nicht implizit inline. Unpraktisch waer's schon, wenn grade
das ("inline"+volatile) nicht funktionieren wuerde, aber mglw. muss
"nur" eine Compiler/Linker-Option richtig gesetzt werden. Eigentlich
sollte das "Problem" dann in der Form auch auf anderen Plattformen
(nicht nur arm-elf "Targets") auftreten.

[OldBug (Gast)]

Es ist aber schon so, daß der Code gar nicht funktioniert, also auf dem
Target die LED nicht an/ausschaltet, oder hast Du das gar nicht
getestet?

[mthomas (Gast)]

Danke nochmal.
Partielle Blindheit und zu wenig Ahnung von ARM-Assembler, um das
Disassembly richtig zu interpretieren, waren die Hauptursache.
Tatsaechlich sind wohl alle Teile des "Beispiel-Codes" umgesetzt,
d.h. "es blinkt". So man ein Objekt der Klasse im "global-scope"
anlegt, gab es Probleme mit dem Konstruktor, wurden aber behoben.
Kleines Beispiel mit makefile/startup/linker-script f. LPC2106 mit
"g++" auf:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/