WinAVR 20080402

Ich habe zuwenig Kenntnisse in Sachen Compilerbau, als dass ich jetzt 
darüber eine Meinung abgeben könnte, ob jetzt Sch... oder nicht.
Aber als GCC-User sollte es unsere Pflicht sein, sobald als möglich auf 
die neuste Version umzusatteln und über mögliche Fehler zu berichten.

Natürlich gibt's Probleme. Aber wie sollen diese Probleme behoben 
werden, wenn diese nicht gemeldet werden?

Ich sage ja nicht, du sollst in einer laufenden Entwicklung auf die neue 
Version umsteigen. Aber eine abgeschlossene Entwicklung sollte man schon 
zu Testzwecken durch den neuen Compiler jagen.
Und eine Neuentwicklung, die z.Zt. bei mir ansteht, würde ich schon 
gerne mit der neuen Version beginnen.

Ich hatte mir auch den neuen Compiler geholt und das Programm wurde
1. Größer
und
2. Funktionierte es nicht mehr.

Deshalb bin ich wieder auf die ältere Version umgestiegen.

Ich hab hier mal eine Routine rausgepickt, die von 9 auf 21 Words 
angestiegen ist, also nur auf schlappe 233%:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=61771&start=40

Das komplette Programm ist um 20% größer geworden, was ja auch schon 
ganz schön happig ist. Er hat also nicht alle Routinen derartig 
drastisch unoptimiert.

Obs noch läuft habe ich nicht testen können, die 120% passen nicht mehr 
in den Chip.


Peter

Mehmet Kendi wrote:
> Aber als GCC-User sollte es unsere Pflicht sein, sobald als möglich auf
> die neuste Version umzusatteln und über mögliche Fehler zu berichten.

Ich sage in solchen Fällen immer: "Hanemann, geh du voran!"

Ich hab jetzt mal einen grösseren Chip gewaehlt und das Programm damit 
compiliert: die Schaltung funktioniert einwandfrei.

Mehmet Kendi wrote:
> Ich hab jetzt mal einen grösseren Chip gewaehlt

Na dann schmeiß ich mal sofort den ATtiny45 runter und setzt nen 3GHz 
Quadcore drauf :-)
Hauptsache ich kann den neuesten Compiler benutzen, egal was es kostet.


Peter

:D Peter, nicht gleich das Kind mit dem Bad ausschütten.
Wegen dieser Code-Vergrösserung bin ich nolens volens gezwungen, den 
alten Compiler zu benutzen.
Aber bei einem neuen Projekt, da macht es mir nichts aus, einen 
grösseren Chip zu waehlen.
Zumindest gehe ich davon aus, dass dieses Mehr an Code zugunsten von 
mehr Sicherheit erkauft wird. Nur so 'ne Vermutung.

Interessant wäre es, mal zu wissen, was der neue konkret besser können 
soll.

Gibt es denn irgendwelche richtig harten Bugs in dem alten?

Wenn es nur um den ATXmega Support geht, dann brauche ich den neuen 
nicht.

Ulkiger Weise scheint der XMega aber auch keine Hardwaredivision zu 
haben, da ist der Hang zum unnötigen Divisionsaufruf ziemlich 
unverständlich.

Ich denke mal, es ist schon opportun, von nem neuen eine Verbesserung zu 
erwarten und keine Verschlechterung.

Allein nur, weil etwas neu ist, mach ich doch keinen Handstand.



Peter

@Peter
Ich pflichte Dir bei. Aber. Wenn keiner den neuen Compiler testet, wie 
in aller Welt sollen dann die Entwickler auf die möglichen Fehler 
aufmerksam werden? Dann könnte man ja die ganze avr-gcc Entwicklung 
beenden und sagen "der aktuelle Compiler tut's ja".

Mehmet Kendi wrote:
> @Peter
> Ich pflichte Dir bei. Aber. Wenn keiner den neuen Compiler testet, wie
> in aller Welt sollen dann die Entwickler auf die möglichen Fehler
> aufmerksam werden?

Naja, er macht ja keinen Fehler. Er macht es nur umständlicher, mit viel 
mehr Code und Zeitbedarf als nötig.
Solche Sachen, die nicht dem ANSI-C widersprechen haben kaum Chancen.

Auch tue ich mich schwer, in diesem Sourceforke durchzusehen, wie und wo 
man Probleme richtig reinstellt (ein Wiki oder Tutorial dafür wäre nicht 
schlecht).

Wenn ich merke, ein Compiler erzeugt falschen Code, dann würde ich das 
natürlich sagen und versuchen, ne andere Version zu finden, die den 
Fehler nicht mehr bzw. noch nicht macht.

Wenn aber der Code nur langsamer und größer wird, dann kann ich nur 
versuchen die optimale Version zu finden.

Der WINAVR-20071221 macht auch vieles nicht mehr so gut, wie der 
WinAVR-20070122.
Aber er hat kann MOVW bei den ATtinys und damit ist dann in der Summe 
der Code doch kleiner und schneller, da ich fast nur ATTinys einsetze.

Ich hab ein neues Projekt mit dem ATmega168 und da werde ich 
warscheinlich mit dem WinAVR-20070122 am besten fahren.

Ich hab mir extra ein paar Batch-Dateien geschrieben, mit denen ich 
schnell zwischen den Versionen umschalten kann.


Peter

yalu wrote:
>
>   -fno-tree-scev-cprop
>
Staun! Also ich habe mal mit Google gesucht, habe nicht eine Erklärung 
zu der Option gefunden. Nur Funde im Zusammenhang mit einem Linux Kernel 
Bug.
Auch das GCC Handbuch danach durchsucht. Nichts.

Woher wußtest Du von dieser Option und dass sie das bewirkt?

900ss

avr-gcc --help=optimizer

Aber das bringt's nicht wirklich. Oder ist nur ein Problem von mehreren.

Mir hat es von 20070525 zu 20080404 Release den Code von 3424 auf 3614 
Bytes aufgeblasen. Grund dafür ist ein -Os völlig zuwiderlaufendes 
agressives Inlining. Ein häufig auftretender Funktionsaufruf (4 Bytes) 
wurde durch jeweils 16 Bytes ersetzt.

Mit -fno-inline-small-functions (kann auch mal nach hinten losgehen) 
oder -finline-limit=<n> (hier ist ggf. etwas tuning angesagt) hält man 
sich das vom Leib. Ergebnis: 3196 Bytes.

Ähnliches ist mir schon früher in der ARM Version passiert. Die hinter 
diesem Inlining stehende Grössenabschätzung ist wohl "etwas" unpräzise.

Peter Dannegger wrote:

> Interessant wäre es, mal zu wissen, was der neue konkret besser können
> soll.

Die Benutzung von GCC 4.3 war für Eric die einzige Chance, dass er
den Xmega-Support mit reinbekommen konnte, weil dieser nur für diese
Version gezimmert worden ist (und letztlich immer noch wird -- da ist
doch manches anders dabei als bei den alten Cores).  Das Rückportieren
dieses umfangreichen Patchwerkes auf die 4.2-er Linie war schon aus
Gründen fehlender Manpower nicht machbar.

Idealerweise hätte er wohl Installationsoptionen für GCC 4.2.x ohne
Xmega-Support und 4.3-BETA mit Xmega anbieten sollen, aber dafür fehlt
es ihm im WinAVR-Installer an jeglicher Unterstützung für derartige
Optionen.  Das wäre übrigens ein Feld, wo sich ein ambitionierter
Windows-Entwickler ganz sicher in diesem Opensource-Projekt einbringen
könnte: den Installer flexibler zu machen.  Ist ja nicht das erste
Mal, dass man sich sowas gewünscht hätte.  Installationsoptionen
wären beispielsweise auch denkbar, um dem Nutzer wahlweise die
Installation eines Standalone-USB-Treibers oder des Filter-Treibers
(der oberhalb des Jungo-Treibers von AVR Studio sitzt) zu ermöglichen.

> Ulkiger Weise scheint der XMega aber auch keine Hardwaredivision zu
> haben,

Nö, die Änderungen im XMega sind an anderen Stellen.  Na komm, du hast
selbst jahrelang nach priorisierbaren Interrupts gerufen...

Sehr schöne Antworten, hat sich also voll bezahlt gemacht, das konkrete 
Problem zu posten.
Das mit dem unerwünschten Inlining hat mich auch schon immer gestört.
Diese Optimierungsschalter sind aber wohl erst mit GCC 4.3. anwendbar.

Allerdings krieg ich nun Probleme mit der Kommandozeile, die wird zu 
lang.
Weiß da einer vielleicht Abhilfe?

Kann man irgendeine Datei editieren, wo sich der GCC die 
Optimierungseinstellungen rausholt?


Peter

-finline-limit=<n> existiert schon länger.

Peter Dannegger wrote:

> Kann man irgendeine Datei editieren, wo sich der GCC die
> Optimierungseinstellungen rausholt?

Der Klassiker: @file

Steht übrigens im Manual ;-).

So, die beiden Optimierungen haben voll eingeschlagen (14% weniger), ist 
schon fast wieder an den GCC4.2.2 ran.

Ich hab dann mal gesucht, wo der nächste Codefresser sitzt und ihn 
gefunden.

Vielleicht findet ja noch jemand raus, warum darin der GCC4.3.0 
haufenweise unnütz pusht, moved, ored.
Da scheint irgendwas in der 32-Bit Berechnung umständlich zu laufen.
Die Routine steigt damit um 155% an.

Anbei der Quellcode und die beiden Listings.


Peter

-fno-split-wide-types

... und wieder 10 Bytes weniger bei mir.

Andreas Kaiser wrote:
> -fno-split-wide-types
>
> ... und wieder 10 Bytes weniger bei mir.

Bei mir 54 Bytes weniger und damit ist er endlich kleiner als der 4.2.2


Peter

Schreibt bitte bugreports für sowas, mit nachvollziehbaren
Codeschnipseln.  Das ist die einzige Hilfe, wie die GCC-Entwickler
derartige Tuning-Geschichten dauerhaft reparieren können.

die ??? wrote:

> Mal eine blöde Frage: Warum werden solch offensichtlichen Flags nicht
> automatisch mit dem MCU Typ ausgewählt?

Weil sie nicht offensichtlich sind.

Andreas Kaiser wrote:

> Weil sie nicht offensichtlich sind.

Genau darum sollst du auch einen Bugreport schreiben, damit Dinge,
die nun plötzlich offensichtlich zu sein scheinen, künftig einfach
mal schon standardmäßig aktiviert werden können.

Auf einen Tag kommt es dabei nun auch nicht an, also Geduld.

Das war ja meinerseits eine Antwort auf ??? Ich hoffe dass ich Peters 
Code legal dafür verwenden darf, sonst muss er's selber machen.

Andreas Kaiser wrote:
> Das war ja meinerseits eine Antwort auf ??? Ich hoffe dass ich Peters
> Code legal dafür verwenden darf, sonst muss er's selber machen.

Kannste nehmen.


Peter

Also bei mir haben diese Flags nur zu einer 0,3 prozentigen Reduzierung 
geführt.
Mit WinAVR-20071221 98%
mit 20080402 ohne irgendwelche Flags: 108,3%
mit den Flags -fno-tree-scev-cprop und/oder -fno-split-wide-types 108%

Hat keiner behauptet, dass die Suche zu Ende sei. Wirf mal einen Blick 
in die Mapfiles und stelle fest, ob eine bestimmte Funktion besonders 
gross wurde.

Und probier dann besser gleich mit
  avr-gcc -Os -fno-<hier-die-option-reinschreiben> quelle.c
mal aus, ob sich unter den in -O1 oder -Os verwendeten 
Optimierungsoptionen was passendes findet.

PS: Du hast -fno-inline-small-functions vergessen.

mit -fno-inline-small-functions: 107,6%  :)
Das map-file muss ich erst mal analysieren.

Also ich habe das ganze mit den verschiedenen genannten Optionen (auch 
noch andere) mit einem Bootloader probiert, der aus 2 Funktionen besteht 
(main + nochwas, startup-libs u.s.w. fehlt). Ist komplett in C 
geschrieben. Da hat der WinAVR-200705xx (die Version vor 
WinAVR-20071221) etwas unter 1024 Bytes erzeugt. Das Minimum mit dem 
aktuellen WinAVR war 1056 Byte. Ich meine bei 2 Funktionen kann man auch 
nicht viel mit Inlining optimieren :-) -fno-tree-scev-cprop und 
-fwhole-program haben am meisten gebracht. Allerdings komme ich eben 
nicht unter die 1024 Byte. Und das ist für einen Bootloader dann 
schlecht, da dann man gleich weitere 1Kb Flash opfern muß. Vielleicht 
hat ja noch jemand eine Idee.  ????

Habe schon einige Optionen probiert, komme aber nicht unter 1024 Bytes. 
Hier zeigt sich, das man auch keine pauschalen Aussagen machen kann, wie 
gut ein Optimierungsswitch wirkt. Kommt immer noch ein wenig auf den 
Code an.

Viel Spaß noch,
900ss

Also ich hab' mal beide map files durchgesehen. Von dem, was auf meinem 
Mist gewachsen ist, gibt es ein Mehr von nur 82 Bytes.
Der Rest von ca. 150 Bytes geht auf das Konto von GCC 4.3

Besonders sticht ins Auge, dass 4.3.0 _prologue_saves_ und 
_epilog_restores_ hinzugefuegt hat. Diese scheint er beim 
eeprom_read_block() hinzugefügt zu haben.

Wenn diese Funktionen sowieso drin sind, kannst du sie genausogut auch 
benutzen. Es gibt eine AVR-spezifische Option, mit der die 
push/pop-Orgien an Anfang und Ende von Funktionen teilweise per 
Laufzeitfunktion erledigt werden. Hab bloss den Namen grad nicht parat.

naked?

-mcall-prologues

Möglicherweise wurde der eeprom-Kram in der Lib damit übersetzt.

Damit bin ich auf 103,1% runter :)
.... aber die Push&Pop Orgie ist immer noch da. Und zwar wird diese 
innerhalb von __eerd_block aufgerufen, das wiederum von 
eeprom_read_block aufgerufen wird.

Wo genau ist die push/pop-Orgie? In der EEPROM-Lib oder separat in Form 
der prolog/epilog-Funktionen? Letzteres ist klar, denn diese Funktionen 
sind die Grundlage von -mcall-prologues.

Andreas Kaiser wrote:

> Möglicherweise wurde der eeprom-Kram in der Lib damit übersetzt.

Ja, der eeprom-Kram wird nun inline gemacht statt über Bibliotheks-
funktionen (war die einzige Möglichkeit, ohne komplettes Umstruktu-
rieren von AVR-GCC und avr-libc die EEPROM-Routinen für jeden
AVR-Typ customized zu bekommen), und Eric hat sich für die
call-prolog-Variante entschieden.  Warum?  Ich denke, dass das
WinAVR-Template das ohnehin als Default hat, weil es normalerweise
Platz spart (geringfügig auf Kosten der Ausführungszeit).

Ähm... wenn diese Funktionen inlined sind, sollte es doch eigentlich 
dadurch überhaupt keine Lib-induzierten prolog/epilog-Funktionen geben?

Separat in Form der prolog/epilog-Funktionen.
Aber auch ohne -mcall-prologues habe ich diese Funktionen, die meiner 
Meinung nach das ganze so aufblaehen.

Wenn ich das Ganze mit 4.2.2 uebersetze, ist die Lib-Funktion 
eeprom_read_block ganze 13 Bytes.

Mit 4.3.0: 34 Bytes (__eerd_block) + (29 Bytes) prolog_save + (29 Bytes) 
prolog_restore

Ist dieser Zuwachs arg störend? Diese Sorte Wachstum skaliert nicht, 
d.h. das vergössert den Code nicht prozentual. Die Einsparung durch 
-mcall-prologues hingegen erspart prozentual. Unterm Strich bist du also 
bei Tinys gekniffen und beim Mega644 klar im Vorteil.

".... Tinys gekniffen und beim Mega644  klar im Vorteil." :D
z.Zt. bin ich der Gekniffene: Mein Zeilprozessor ist ein 2333.

Naja, nicht so schlimm. Bleibe ich halt bei diesem eh alten Project beim 
4.2.2
Zumindest bin ich dahingehend beruhigt, dass dieses Mehr an Code einen 
Sinn hat.
Danke für die Hilfe.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35861

Der WinAVR-20080407 ist da.


Peter

Danke für die Benachrichtigung.
Aber der Compiler und AVR-LibC sind immer noch dieselben. Keine Ahnung 
was sich geaendert hat.

Der Grund für die Neuauflage scheint hier zu liegen:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=62221

Mehmet Kendi wrote:

> Der Grund für die Neuauflage scheint hier zu liegen:

Ja.

Ich habe jetzt mal

1

#include <avr/eeprom.h>

ausgeklammert und meine eigene eeprom_read_block funktion geschrieben:
Programmgrösse ist wieder wie bei 4.2.2 auf 98% zurück.

So jetzt habe ich mir auch die neue Version geholt und keine Warnings 
(schonmal gut). Aber ein ganz bestimmter Teil meines Programms 
funktioniert nicht mehr.

1

Timer1a = (153 * Timer1) / 1000;

Hat vorher super funktioniert.

Beispiel:
Timer1 = 9968
Timer1a = (153 * 9968) / 1000;
Da kommt bei mir 1525,104 raus.
Er sagt 17.

Kann ich nicht nachvollziehen.

Wie sind die Datentypen definiert (also von Timer1)? Das Verhalten von 
Arithmetik bei Überlauf ist nur für Datentypen ohne Vorzeichen als 
Modulo-Arithmetik definiert. Bei Typen mit Vorzeichen ist es 
ausdrücklich undefiniert.

Robin Tönniges wrote:

> Da kommt bei mir 1525,104 raus.
> Er sagt 17.

Bei mir kommt 17 raus.

153 * 9968 sind 1525104 oder 0x174570.  Da die Rechnung im int-Bereich
gemacht wird (mehr hast du zumindest nicht angegeben), bleiben davon
nur die unteren 16 Bits übrig: 0x4570 = 17776.  17776 / 100 = 17.

Unter der Annahme, dass Timer1 uint16_t ist:
153 * 9968 = 17776.
17776 / 1000 = 17.

Also alle Variablen sind als uint16_t deklariert.

Aber wie mache ich dass er rechnet wie ich?

Hat sich erledigt habs gecheckt^^
Danke

Zu früh gefreut :(
Selbst mit "uint64_t Timer1a" zeigt er noch nicht an was ich will.
Was mich wundert ist, dass es bei dem alten Compiler funktioniert hat.
Aber auf den alten umsteigen möchte ich auch nicht.

Klassischer Irrtum. Bei

1

  int b, c;

2

  a = b * c;

wird unabhängig vom Typ von "a" immer mit "int" gerechnet.

Du musst Timer1 breiter machen, nicht Timer1a. Oder

1

Timer1a = (153L * Timer1) / 1000;

rechnen.

Nachdem ich Timer1 auf uint64_t erhöht habe funktionierts. Ich verstehe 
nur nicht warum?
In Timer1 wird doch nur ein 16 Bit Wert abgespeichert nämlich der von 
Timer1.
???

P.S.: Das mit dem 153L ändert nichts.

153 ist vom Typ "int". Timer1 ist vom vom Typ "uint16_t=unsigned". Das 
Ergebnis der Multiplikation ist folglich vom Type "unsigned", und der 
geht bei AVRs nur bis 65535.

Auf einer 32bit Kiste sähe das anders aus.

Robin Tönniges wrote:

> P.S.: Das mit dem 153L ändert nichts.

Das finde ich jetzt interessanter. Und was ist bei
  Timer1a = (153 * (long)Timer1) / 1000;

Geht net. Also weder wenn ich das mit uint16_t Timer1 noch uint64_t 
Timer1 ausprobiere.

uint64_t ist übrigens weit übers Ziel hinaus geschossen.

(153ul * timer1) / 1000

sollte aber gehen.  Es zwingt den Compiler, timer1 von unsigned auf
unsigned long zu erweitern und entsprechend die Multiplikation für
2 unsinged longs zu generieren (die vermutlich in einer Funktion der
libgcc.a versteckt ist).

Jo, aber ob nun 153L oder 153uL, es sollte in beiden Fällen 
funktionieren, denn das Ergebnis passt sowohl in long als auch in 
unsigned long.

Hab jetzt beides ausprobiert. Und bis jetzt ist uint64_t das einziege 
was funktioniert. 153l und 153ul funktionieren bei nicht.
Vlt. liegts auch ausnahmsweise am Compiler und nicht an mir :)

Das die uint64_t natürlich weit mehr speicher einnimmt ist das Unschöne 
an der Lösung.

Kannst ja mal schauen, ob du dieses Stückchen Code im *.lss File 
findest. Daran liesse sich das evtl. verifizieren.

Ansonsten poste mal einen Testcase, d.h. ein absolut miminales Stück 
Code, das genau diesen Effekt produziert. Also ohne zig KB anderes Zeug 
drumherum was ausser dir sowieso niemand übersetzt kriegt.

Also in dem *.lss File steht viel. Und ich werde wohl voher an 
Altersschwäche sterben als das zu finden.

Mal gucken ob ich nen COde basteln kann der kurz und knackig diesen 
Fehler verursacht.

1

uint32_t A;

2

uint16_t B = 9000;

3

4

//Hauptschleife

5

int main(void)

6

{    

7

  while(1)

8

  {

9

    A = (150 * B) / 100;

10

  //A ist laut µC 392

11

  }

12

  return(0);

13

}

So hier mal ein Code wo das selbe Problem besteht.

Robin Tönniges wrote:
>     A = (150 * B) / 100;
>   //A ist laut µC 392

Aus C-Sicht stimmt das auch.
Du mußt schreiben:

     A = (150UL * B) / 100;



Peter

Schön wärs :)
Funktioniert leider nicht. Komm ne ganz lange komische Zahl bei raus.

Was weiß ich hab nicht mitgezählt. LCD sagt lange Zahl. Und wenn ich was 
anderes nehme funktionierts ja also B nicht 9000 sonder 2 oder sowas.

Jaja. Das ist bei 16MHz nicht so einfach das kann ich dir sagen :)

Ich glaube da hast du einen Volltreffer gelandet.

1

unsigned long A;

2

unsigned int B = 9000;

3

4

int main(void)

5

{    

6

    A = 150 * (long)B;

7

    return(0);

8

}

liefert bei -mmcu=attiny25 korrekterweise:

1

main:

2

        lds r22,B

3

        lds r23,(B)+1

4

        ldi r24,lo8(0)

5

        ldi r25,hi8(0)

6

        ldi r18,lo8(150)

7

        ldi r19,hi8(150)

8

        ldi r20,hlo8(150)

9

        ldi r21,hhi8(150)

10

        rcall __mulsi3

aber bei -mmcu=atmega16 fehlt ein bischen was:

1

main:

2

        lds r22,B

3

        lds r23,(B)+1

4

        ldi r24,lo8(0)

5

        ldi r25,hi8(0)

6

        call __mulsi3

Damit hängt m.E. das Ergebnis davon ab, was vorher in R18..R21 
drinsteht.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35872

Sieht so aus, also ob man diese Version auf AVRs mit Hardware-Multiplier 
besser nicht verwendet.

Ich hab nen Bug gefunden? :)
Darf ich jetzt stolz auf mich sein^^

Das mit dem mega16 kommt hin. Ich verwende einen mega32.

Robin Tönniges wrote:

> Ich hab nen Bug gefunden? :)
> Darf ich jetzt stolz auf mich sein^^

Du darfst ihn behalten. ;-)

Jörg Wunsch wrote:

> Schreibt bitte bugreports für sowas, mit nachvollziehbaren
> Codeschnipseln.

Einen davon hattest du höchstselbst als #30908 bereits vor über einem 
Jahr gemeldet ;-).

Andreas Kaiser wrote:

> Einen davon hattest du höchstselbst als #30908 bereits vor über einem
> Jahr gemeldet ;-).

Ja, war auch aus einer Diskussion hier hervor gegangen -- und hat ja
zumindest zu Diskussionen unter den Entwicklern geführt.