Winavr20071221 :-(

@ 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:

> 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.

@ 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

Du solltest vor allem das Map-File studieren. Von beiden Versionen.

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.

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.

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.

__clz_tab sollte aber eigentlich durch die libm.a gar nicht nötig
sein.  Linkst du denn auch mit -lm?

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)

Der zugehörige GCC-Bugreport ist übrigens hier:

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

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 ?

1) Nein.

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

Ist im Repository schon behoben.