Vor Umstellung auf Squeeze

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.

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

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)

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