Forum: Compiler & IDEs Vor Umstellung auf Squeeze


von Norbert (Gast)


Lesenswert?

Hallo Gemeinschaft,

da ich gerade (vor der Umstellung auf Squeeze) die für mich kritischen 
Anwendungen überprüfe, hätte ich da gerne mal eine Frage.

Gibt es bereits Erkenntnisse zu der avr-gcc Version 4.3.5?
Die alte in Lenny war 4.3.2. (und arbeitete hervorragend)

avr-objdump und avr-objcopy:
OldLenny:2.18.0  Squeeze:2.20.1

Gleiche Frage auch für den avrdude:
OldLenny:5.5  Squeeze:5.10


Wenn schon jemand Erfahrung (auch während der Testing Phase) gemacht 
hat, würde ich mich freuen.

Besten Dank vorab

von Yalu X. (yalu) (Moderator)


Lesenswert?

Norbert schrieb:
> Gibt es bereits Erkenntnisse zu der avr-gcc Version 4.3.5?
> Die alte in Lenny war 4.3.2. (und arbeitete hervorragend)

Die 4.3-Serie für den AVR hat eigentlich keinen guten Ruf, weil sie in
vielen Fällen deutlich längeren und langsameren Code generiert als die
4.2-Serie. In 4.4 und 4.5 ist das teilweise wieder verbessert worden.
Ich glaube aber nicht, dass du dir Nachteile einhandelst, wenn du 4.3.5
anstelle von 4.3.2 nimmst

Ich benutze abere auch heute noch primär den 4.2.4 (sofern der verwende-
te AVR-Typ unterstützt wird) und lasse gelegentlich mal einen 4.4.x oder
4.5.x über den Code laufen, um zu sehen, was sich getan hat. In manchen
Punkten schneiden die neuen Versionen signifikant besser ab, aber leider
eben nicht in allen.

> avr-objdump und avr-objcopy:
> OldLenny:2.18.0  Squeeze:2.20.1
>
> Gleiche Frage auch für den avrdude:
> OldLenny:5.5  Squeeze:5.10

Mit den Binutils hatte ich noch nie nennenswerte Probleme, so dass ich
dort immer nur eine einzige (relativ aktuelle) Version installiert habe.
Gleiches gilt für den Avrdude und auch die AVR-Libc.

von Norbert (Gast)


Lesenswert?

Yalu X. schrieb:

> Die 4.3-Serie für den AVR hat eigentlich keinen guten Ruf, weil sie in
> vielen Fällen deutlich längeren und langsameren Code generiert als die
> 4.2-Serie. In 4.4 und 4.5 ist das teilweise wieder verbessert worden.
> Ich glaube aber nicht, dass du dir Nachteile einhandelst, wenn du 4.3.5
> anstelle von 4.3.2 nimmst

Ahh, gute Info. Hatte bis jetzt noch keine akuten Platzprobleme, aber 
werde die Info bzgl. 4.2 / 4.4 im Hinterkopf behalten.

Über Geschwindigkeitsprobleme konnte ich mich aber noch nicht 
beschweren, habe zZ einen:
Software-USB plus
115.200bps UART plus
free-running 8Kanal ADC (IRQ alle 111µs) plus
'endlose' float Operationen plus
SPI EEPROM read/write plus
SPI zu zweitem AVR
bei maximaler Belastung absolut stabil laufen :-)

von Peter D. (peda)


Lesenswert?

Yalu X. schrieb:
> Die 4.3-Serie für den AVR hat eigentlich keinen guten Ruf, weil sie in
> vielen Fällen deutlich längeren und langsameren Code generiert als die
> 4.2-Serie.

Das stimmt so nicht.
Es sind nur einige default-Schalter ungünstig eingestellt.
Z.B. werden kleine Funktion geinlined unabhängig von ihrer Größe und 
Aufrufzahl.
Mit "-fno-inline-small-functions" erreicht man ne deutliche 
Verbesserung.

Gegenüber den Vorgängern ist auch der Schalter "--combine 
-fwhole-program" möglich, der nochmal kräftig eindampft.
Er entdeckt auch viele volatile-Sünden, d.h. wenn der Code danach immer 
noch läuft, hat man es richtig gemacht.
Er entfernt auch alle (scheinbar) unbenutzten Funktionen, d.h. 
init-Sektionen und z.B. Signaturen im Flash müssen als used deklariert 
werden.

Die Nachfolger kann ich nicht prüfen, da ich unter Windows arbeite 
(WINAVR).
Bei den Nachfolgern ist aber ein Bug in der "Delay.h".


Peter

von Yalu X. (yalu) (Moderator)


Lesenswert?

Peter Dannegger schrieb:
>> Die 4.3-Serie für den AVR hat eigentlich keinen guten Ruf, weil sie in
>> vielen Fällen deutlich längeren und langsameren Code generiert als die
>> 4.2-Serie.
>
> Das stimmt so nicht.
> Es sind nur einige default-Schalter ungünstig eingestellt.

Die Dinge, die durch Kommandozeilenoptionen beseitigt werden können,
stören mich ja nicht. Wenn ich sehe, dass da zu viele Funktionen
geinlinet werden, dann finde ich auch die zugehörige Option. Oft ist es
aber so, dass arithmetische Ausdrücken manchmal in 16 Bit gerechnet
werden, obwohl 8 Bit erkennbar ausreichend wären. Oft werden auch
unnötige Registertransfers gemacht. Dafür habe ich keine Optionen
gefunden, und die 4.2-Version ist in dieser Hinsicht zwar nicht perfekt,
aber doch deutlich besser.

Und warst nicht du einer von denjenigen, die damals bei Erscheinen der
4.3er wie die Rohrspatzen über die Verschlimmbesserungen gescholten
haben? ;-)  (vielleicht verwechsle ich dich aber auch mit jemandem)

von Peter D. (peda)


Lesenswert?

Yalu X. schrieb:
> Und warst nicht du einer von denjenigen, die damals bei Erscheinen der
> 4.3er wie die Rohrspatzen über die Verschlimmbesserungen gescholten
> haben? ;-)

Das muß 2008 gewesen sein, da gab es in kurzer Folge mehrere Versionen 
des WINAVR.
Die letzte von 2010 scheint aber ganz o.k. zu sein, auch bei der 
Codegröße.

Ich kann mich noch erinnern, ältere AVR-GCC hatten char-Returnwerte 
immer auf 16Bit aufgebläht.
Tote RETs gabs auch (2 RET hintereinander).
Und Switch-Anweisungen waren schlecht implementiert, da waren 
unleserliche if-else-Monster deutlich kürzer. Mit dem 2010-er WINAVR ist 
es genau umgekehrt.


Peter

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.