... Mit jeder neuen Winavr-Version werden die Kompilate größer :-( Schreibe grade an einem Programm. Das ist mit dem Versionswechsel "mal eben" von 4200 auf 5700 Bytes angewachsen. Gibt es - Ausser auf eine Uralt-Version zurückzugehen - einen Workaround ? Kann man die neue libc auch mit einer alten Winavr-Version problemlos benutzen ? lg, Frank
@ Frank (Gast) >... Mit jeder neuen Winavr-Version werden die Kompilate größer :-( Optimierung eingeschaltet? >Schreibe grade an einem Programm. Das ist mit dem Versionswechsel "mal >eben" von 4200 auf 5700 Bytes angewachsen. Sourcecode? Bitte als Anhang. >Kann man die neue libc auch mit einer alten Winavr-Version problemlos >benutzen ? Solche Stunts würde ich lassen. MFG Falk
Frank wrote:
> von 4200 auf 5700 Bytes angewachsen
Was? Das kann ich ja fast nicht glauben. Quellen wären wirklich
hilfreich.
Frank wrote: > Kann man die neue libc auch mit einer alten Winavr-Version problemlos > benutzen ? Ich wüsste erstmal keinen Grund, warum nicht. Trotzdem sollten deine Probleme natürlich analysiert werden, sonst werden sie einfach nie gelöst.
Optimierung: -s Ne, das Ding kann ich hier nicht anhängen. Das müsste ich erst "für Dritte" lesbar machen :-) Hab mittlerweile ein weiteres, altes Projekt neu Kompiliert. 2230->3304 Bytes :-( Versuchs mal, Falk. lg, Frank
@ Frank (Gast) >Ne, das Ding kann ich hier nicht anhängen. Das müsste ich erst "für >Dritte" lesbar machen :-) Keine Bange, die Leute hier sind einiges gewöhnt. Es geht auch nicht darum das Programm zu verstehen, sondern eher Solperfallen zu finden (z.B. _delay_ms() mit variablen Parametern etc.). >Hab mittlerweile ein weiteres, altes Projekt neu Kompiliert. 2230->3304 >Bytes :-( Quelltext posten! >Versuchs mal, Falk. ??? MFG Falk
Hier das Programm. Ich musste erst noch was ändern,da es in der neuen libc fmin() und fmax() schon gibt. Die hatte ich schon aus diesem Programm entfernt. Aus 4236 Bytes (WINAVR20070525) werden 5764 Bytes. lg, Frank
Mein aktuelles Programm ist ein paar Bytes kleiner geworden: WinAVR-070525: 10440 WinAVR-071221: 10376 Die CFLAGS+LDFLAGS: -mmcu=atmega168 -I. -g3 -DF_CPU=4000000UL -mtiny-stack -mcall-prologues -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wundef -Wa,-adhlns=main.o -I../utils -std=gnu99 -Wundef -MD -MP -gc-sections Vielleicht machen die ja etwas aus. Die Flags sind natürlich bei beiden WinAVR Versionen gleich. - Michael
@let: Hm. Ein Lichtblick :-) Es geht also auch andersherum :-) @alle: Ich habe das selbe Makefile (= identische Flags) benutzt. Frank
Hm.. irgendetwas stimmt da nicht. Mit 071221 gibt "avrsize" den dreifachen RAM-Bedarf aus. Das ist mir grade erst aufgefallen. Es ist was faul im Staate D.. :-) Was läuft falsch ? Aus den Mapfiles werde ich nicht so ganz schlau.
Wenn ich das richtig sehe ist der Floatingpoint-Code größer geworden. Da haben die Codevision-Fans wieder was zu lachen ;)
Hm, das ist ja nicht so schlimm, wenn er dabei auch schneller geworden ist. Dann wäre aber irgendein Switch gut : A) Klein, aber langsamer, b) Groß, aber schneller. Aber ist er das alleine schuld ? Kann ich mir nicht vorstellen. Frank
>Schreibe grade an einem Programm. Das ist mit dem Versionswechsel "mal >eben" von 4200 auf 5700 Bytes angewachsen. DEIN Code und DEIN makefile erzeugen bei mir nur 4236 Bytes. Mit Winavr 4.1.2.
Hmmm, ich sehe erstmal nichts grossartig Verdächtiges. Aber ein paar Anmerkungen. - SIGNAL() ist veraltet, huete macht man das mit ISR(); ob das unterschiedlich Platz braucht? - Du macht recht viel mit Fliesskomma rum. Ist an der Stelle im WINAVR was geändert worden? - Mit dem Makefile kenn ich mich nicht soo sehr aus. Kann es sein, dass duch printf und Fliesskomma viel Code generiert wird? Mal das durcharbeiten. AVR-GCC-Codeoptimierung MFG Falk
Bei den Daten ist offenbar __clz_tab für 256 Bytes gut. Dürfte zur Floating-Point Lib gehören und dort für Tempo sorgen. Auch bei Code ist es die Floating-Point Lib. Schneller mag die ja sein, aber "... It is smaller and faster, ..."?
Falk Brunner wrote: > - Du macht recht viel mit Fliesskomma rum. Ist an der Stelle im WINAVR > was geändert worden? "A completely rewritten floating-point library, contributed by Dmitry Xmelkov. It is smaller and faster, but as it's an almost full rewrite."
Also ob AVRs nun wirklich mit DSPs und ARMs Fliesskomma-Wettrennen veranstalten müssen stelle ich mal in Frage. Platz ist oft wichtiger. Und die 256 Bytes zusätzliches RAM werden in vielen existierenden Projekten tödlich sein.
@Falk: Bin mir schon bewusst, das man noch viel Optimieren kann. Das Programm ist bisher "schnell zusammengeklatscht", teilweise mit Sourcecodes von Dritten. Trotzdem: Es ist ja nur ein anderer Compiler 4.1.2 -> 4.2.2 und eine neue AVR-LIBC (1.6). Hm. Dann versuche ich morgen mal, dem neuen WINAVR die alte libc beizubringen. Frank
Sieht mir nicht danach aus als ob die alte libc da hilft. Der Lowlevel-Kram der Floating-Point-Lib steckt in der libgcc - und die ist von der Version des Compilers abhängig.
>Hm. Dann versuche ich morgen mal, dem neuen WINAVR die alte libc >beizubringen. Wozu ? Bleib doch erst mal beim alten 4.1.2.
Hä? Es sagt doch garkeiner, dass die Lib größer geworden ist. Im Gegenteil: Andreas Kaiser wrote: > "A completely rewritten floating-point library, contributed by > Dmitry Xmelkov. It is smaller and faster, but as it's an almost full > rewrite."
Yep. So steht es geschrieben. Aber stimmt es auch? In den Mapfiles endet Franks Code bei 0xDB6/0xDA4, ist also geringfügig kleiner geworden. Fast alles dahinter gehört zur Floating-Point-Runtime. Und endet bei 0x1086/0x1588.
Wo wird diese __clz_tab denn benutzt ? Ich finde nichts diesbezügliches. lg, Frank
__clz_tab sollte aber eigentlich durch die libm.a gar nicht nötig sein. Linkst du denn auch mit -lm?
Ja, -lm ist drin. Siehe unten. -------- begin -------- avr-gcc (GCC) 4.2.2 (WinAVR 20071221) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiling C: main.c avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./main.lst -std=gnu99 -Wundef -MMD -MP -MF .dep/main.o.d main.c -o main.o Linking: main.elf avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o -std=gnu99 -Wundef -MMD -MP -MF .dep/main.elf.d main.o --output main.elf -Wl,-Map=main.map,--cref -lm Creating load file for Flash: main.hex avr-objcopy -O ihex -R .eeprom main.elf main.hex Creating load file for EEPROM: main.eep avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \ --change-section-lma .eeprom=0 --no-change-warnings -O ihex main.elf main.eep || exit 0 Creating Extended Listing: main.lss avr-objdump -h -S main.elf > main.lss Creating Symbol Table: main.sym avr-nm -n main.elf > main.sym Size after: AVR Memory Usage ---------------- Device: atmega16 Program: 5774 bytes (35.2% Full) (.text + .data + .bootloader) Data: 369 bytes (36.0% Full) (.data + .bss + .noinit) lg, Frank
Habe ein Problem gefunden:
1 | #include <avr/io.h> |
2 | #include <math.h> |
3 | |
4 | volatile float a; |
5 | |
6 | |
7 | int main (void) |
8 | {
|
9 | |
10 | a=ADCH; |
11 | |
12 | }
|
Program: 1380 bytes (8.4% Full) (.text + .data + .bootloader) Data: 260 bytes (25.4% Full) (.data + .bss + .noinit)
Oh, Du hast den Bug schon gemeldet :-) Allerdings scheint er ja recht alt zu sein. Der GCC aus dem WINAVR-20070525 macht aus dem Programm allerdings nur : Program: 576 bytes (3.5% Full) (.text + .data + .bootloader) Data: 4 bytes (0.4% Full) (.data + .bss + .noinit) Ist das wirklich der selbe Bug ? lg, Frank
Ist schon der gleiche Bug. Nur verwendet GCC 4.2.2 ein paar FP-Lib Funktionen, die in der libm nicht enthalten sind und so greift irgendeine GCC Standardkram, der eigentlich garnicht zum Zuge kommen sollte. Was ich dazu bislang gefunden habe: float __floatunsisf (unsigned long); fehlt komplett und float __floatundisf (unsigned long long); findet sich nur als __floatunsdisf. Als (untested) Hotfix käme folglich in Frage:
1 | extern float __floatunsdisf(unsigned long long); |
2 | |
3 | float __floatunsisf(unsigned long x) |
4 | {
|
5 | return __floatunsdisf(x); |
6 | }
|
7 | |
8 | float __floatundisf(unsigned long long x) |
9 | {
|
10 | return __floatunsdisf(x); |
11 | }
|
Update, uint32_t=>float gibt es, ist aber auch falsch geschrieben:
1 | extern float __floatunssisf(unsigned long); |
2 | float __floatunsisf(unsigned long x) |
3 | {
|
4 | return __floatunssisf(x); |
5 | }
|
6 | |
7 | extern float __floatunsdisf(unsigned long long); |
8 | float __floatundisf(unsigned long long x) |
9 | {
|
10 | return __floatunsdisf(x); |
11 | }
|
Klasse... ich bastle grade die gcc Toolchain zusammen. Bin gespannt ob es dann funktioniert :-)
Wenn du sowieso dabei bist den Kram neu zu generieren, kannst du die Funktionen auch gleich dort korrigieren, wo der Fehler steckt: avr-libc-1.6.x/libm/fplib/float*isf.S
Könnt ihr das bitte als Bugreport bei avr-libc einkippen? Schade, um solche Fehler frühzeitig berichtet zu bekommen, hatten wir extra einen avr-libc-1.5.1-Prärelease gemacht. Darauf gab's keine negativen Reaktionen (das Ding mit der __clz_tab war bekannt).
Bin noch am testen. Mein Build ist durch, aber mit dem Mapfile kenne ich mich nicht aus, und avr-size gibt mir eine Fehlermeldung aus:
1 | c:\avrgcc\bin\avr-size.exe: unrecognized option `--mcu=atmega16' |
2 | Usage: c:\avrgcc\bin\avr-size.exe [option(s)] [file(s)] |
3 | Displays the sizes of sections inside binary files |
4 | If no input file(s) are specified, a.out is assumed |
5 | The options are: |
6 | -A|-B --format={sysv|berkeley} Select output style (default is berkeley) |
7 | -o|-d|-x --radix={8|10|16} Display numbers in octal, decimal or hex |
8 | -t --totals Display the total sizes (Berkeley only) |
9 | --common Display total size for *COM* syms |
10 | --target=<bfdname> Set the binary file format |
11 | @<file> Read options from <file> |
12 | -h --help Display this information |
13 | -v --version Display the program's version |
14 | |
15 | c:\avrgcc\bin\avr-size.exe: supported targets: elf32-avr elf32-little elf32-big |
16 | srec symbolsrec tekhex binary ihex |
Das Mapfile habe ich mal angehängt. Es geht um das Miniprogramm ( a=ADCH ) von oben. 1) Ist der Fehler weg ? 2) Wie bekomme ich avr-size zum laufen, bzw wie muss ich es aufrufen ?
So..avr-size habe ich nun auch zum laufen bekommen. Habe mal meine geänderten Dateien angehängt. Habe nur die Schreibweisen geändert (Oder war noch mehr zu machen ?) Frank
Jörg Wunsch wrote:
> Könnt ihr das bitte als Bugreport bei avr-libc einkippen?
OK. Ich hatte da vorhin mal reingesehen, aber die Bugliste sah nicht
wirklich ernsthaft aus (querdurch Status:none, veraltete Top-News).
> (Oder war noch mehr zu machen ?)
Bischen. Bei __floatunsisf nicht die richtige sondern die falsche
Version auskommentieren ;-).
Wow..klappt.
text data bss dec hex filename
314 0 4 318 13e main.elf
@Andreas:Super :-)
Die neue libc kommt bestimmt bald, oder soll ich sie hier anhängen ? Ist
aber vermutlich groß.
Frank
@Andreas: wg.falsch auskommentiert : Jo.. ich sollte mal meine Brille aufsetzen.. :-)
Jörg Wunsch wrote: > Schade, um solche Fehler frühzeitig berichtet zu bekommen, hatten > wir extra einen avr-libc-1.5.1-Prärelease gemacht. Konnte keiner merken. Der 4.1 Compiler arbeitet an dieser Stelle völlig anders und verwendet auch ohne Vorzeichen die __floatsisf Funktionen, mit etwas Zirkus drumherum.
Andreas Kaiser wrote: >> Könnt ihr das bitte als Bugreport bei avr-libc einkippen? > > OK. Ich hatte da vorhin mal reingesehen, aber die Bugliste sah nicht > wirklich ernsthaft aus (querdurch Status:none, veraltete Top-News). Naja, diese blöden News dort kann ich eigentlich nicht leiden, und mehr als eine Announcement (liest das jemals einer?) über neue Releases passiert da nicht. Eigentlich sollte man das Feature wahrscheinlich besser abschalten. Der Status der Bugs geht in aller Regel sofort von "None" nach "Fixed" über, sowie sich jemand gekümmert hat und das repariert hat. Ansonsten ist das so ungepflegt nicht. Wenn du's nicht glaubst, dann klapp dir mal ganz oben die Suchkriterien auf und selektiere "Closed" statt "Open". ;-) In der Regel gehe ich die Bugliste jeweils vor einem Release durch und entscheide, was mit vertretbarem Aufwand zu machen ist.
Andreas Kaiser wrote: >> Schade, um solche Fehler frühzeitig berichtet zu bekommen, hatten >> wir extra einen avr-libc-1.5.1-Prärelease gemacht. > > Konnte keiner merken. Der 4.1 Compiler arbeitet an dieser Stelle völlig > anders und verwendet auch ohne Vorzeichen die __floatsisf Funktionen, > mit etwas Zirkus drumherum. Ja, hast Recht, das ist ja eher ein Problem des 4.2er Compilers als der Bibliothek selbst.
Jörg Wunsch wrote: > Ansonsten ist das so ungepflegt nicht. Wenn du's nicht glaubst, dann > klapp dir mal ganz oben die Suchkriterien auf und selektiere "Closed" > statt "Open". ;-) Ich glaubs dir. Weil ich vorhin schon 2 Minuten vor der Seite sass und nach dem Knopf für neue Bugs suchte. ;-)
Der Vollständigkeit halber:
Mit meiner gepatchten Version der avr-libc 1.6.1 ergibt sich für
mein obiges Programm ("Steuerung") :
Program: 4524 bytes (27.6% Full)
(.text + .data + .bootloader)
Data: 113 bytes (11.0% Full)
(.data + .bss + .noinit)
Also wesentlich besser. Aber immer noch 288 Bytes größer.
Vielleicht gibt es noch einen Bug ?
Frank
Dmitry hat Eric's Ankündigungsmail bei avrfreaks.net auch dahin gehend korrigiert, dass die neuen libm-Routinen zwar durchweg schneller, aber nicht in jedem Falle kleiner geworden sind. Dafür korrigieren sie aber viele Fehler in ,,Randbereichen'' (Behandlung von 0, Unendlich und NaN), in denen die alten Routinen einfach zu schlampig iplementiert waren.
Na dann ist es ja OK. Mich persönlich stört der Speichermehrverbrauch zur Zeit - bei meinem aktuellen Projekt - nicht. Allerdings ist er doch nicht ganz unerheblich, was bei kleineren AVR's ein KO-Kriterium sein könnte. Um mal ein unreflektierten Vorschlag in den Raum zu werfen: Wie wär's mit einer alternativen libm (=die alte Version) zusätzlich ? Die könnte man ja im Makefile beim Linken dann bei Bedarf "Umschalten". Frank
's ist ja nicht so, dass die neue libm durchweg größer wäre. Im Mittel sollte sie wohl im Speicherverbrauch ähnlich sein wie die alte. Ansonsten könntest du natürlich einfach die frühere Version der libm.a dagegen linken.
Jörg Wunsch wrote: > Ansonsten könntest du natürlich einfach die frühere Version der libm.a > dagegen linken. Sicher? Sind da die betreffenden Funktionen implementiert, oder geht der gleiche Zirkus los? In 1.4.5 heisst __floatunsisf genauso falsch und __floatundisf gibts garnicht.
Falls jemand an einem Build der avr-libc 1.4.5 für den GCC 4.2.2 (WINAVR-20071221) oder an dem der gepatchten 1.6.1-Version interessiert ist, möge er/sie sich - am besten mit Angabe der eMail-Adresse - melden. Den Build für die 1.4.5 muss ich erst noch machen, aber das ist kein großes Thema, denke ich. Frank
Andreas Kaiser wrote: > Sicher? Sind da die betreffenden Funktionen implementiert, oder geht der > gleiche Zirkus los? In 1.4.5 heisst __floatunsisf genauso falsch und > __floatundisf gibts garnicht. Das sind doch aber nur andere Namen für die gleiche Funktion, oder? Dann kannst du dir mit der Linkeroption --defsym die entsprechenden neuen Namen auf die alten umbiegen. Binary builds der einzelnen avr-libc-Versionen gibt's übrigens unter http://download.savannah.gnu.org/releases/avr/ Diese sind komplett unabhängig vom benutzten Betriebssystem.
Nur lässt sich lediglich dort was umbiegen, wo was zum umbiegen da ist. Allerdings sind Konvertierungen 64bit-unsigned => float wohl nicht allzu häufig.
>Dann kannst du dir mit der Linkeroption --defsym die entsprechenden >neuen Namen auf die alten umbiegen. Achso ? Gut zu wissen :-) Dann hätte ich mir die Arbeit sparen können. Wird in der kommenden 1.6.2 der Bug behoben sein ? lg, Frank
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.