www.mikrocontroller.net

Forum: Compiler & IDEs Winavr20071221 :-(


Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: die ??? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank wrote:
> von 4200 auf 5700 Bytes angewachsen

Was? Das kann ich ja fast nicht glauben. Quellen wären wirklich 
hilfreich.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich machs mal fertig.

Bitte geduld :-)

Autor: Frank (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ups, da fehlte noch eine Datei. Sorry.

Frank

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@let:
Hm. Ein Lichtblick :-)
Es geht also auch andersherum :-)

@alle:

Ich habe das selbe Makefile (= identische Flags) benutzt.

Frank

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest vor allem das Map-File studieren. Von beiden Versionen.

Autor: Frank (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich das richtig sehe ist der Floatingpoint-Code größer
geworden. Da haben die Codevision-Fans wieder was zu lachen ;)

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@holger:Bei mir doch auch ???

Es geht um 4.2.2

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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, ..."?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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."

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hm. Dann versuche ich morgen mal, dem neuen WINAVR die alte libc
>beizubringen.

Wozu ? Bleib doch erst mal beim alten 4.1.2.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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."

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo wird diese __clz_tab denn benutzt ?
Ich finde nichts diesbezügliches.

lg, Frank

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank B_. (frank_b) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe ein Problem gefunden:


#include <avr/io.h>
#include <math.h>

volatile float    a;


int main (void) 
{

 a=ADCH;
 
}


Program:    1380 bytes (8.4% Full)
(.text + .data + .bootloader)

Data:        260 bytes (25.4% Full)
(.data + .bss + .noinit)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der zugehörige GCC-Bugreport ist übrigens hier:

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

Autor: Frank B_. (frank_b) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
extern float __floatunsdisf(unsigned long long);

float __floatunsisf(unsigned long x)
{
    return __floatunsdisf(x);
}

float __floatundisf(unsigned long long x)
{
    return __floatunsdisf(x);
}

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Update, uint32_t=>float gibt es, ist aber auch falsch geschrieben:
extern float __floatunssisf(unsigned long);
float __floatunsisf(unsigned long x)
{
    return __floatunssisf(x);
}

extern float __floatunsdisf(unsigned long long);
float __floatundisf(unsigned long long x)
{
    return __floatunsdisf(x);
}

Autor: Frank B_. (frank_b) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klasse... ich bastle grade die gcc Toolchain zusammen.
Bin gespannt ob es dann funktioniert :-)

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Frank B_. (frank_b) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
c:\avrgcc\bin\avr-size.exe: unrecognized option `--mcu=atmega16'
Usage: c:\avrgcc\bin\avr-size.exe [option(s)] [file(s)]
 Displays the sizes of sections inside binary files
 If no input file(s) are specified, a.out is assumed
 The options are:
  -A|-B     --format={sysv|berkeley}  Select output style (default is berkeley)
  -o|-d|-x  --radix={8|10|16}         Display numbers in octal, decimal or hex
  -t        --totals                  Display the total sizes (Berkeley only)
            --common                  Display total size for *COM* syms
            --target=<bfdname>        Set the binary file format
            @<file>                   Read options from <file>
  -h        --help                    Display this information
  -v        --version                 Display the program's version

c:\avrgcc\bin\avr-size.exe: supported targets: elf32-avr elf32-little elf32-big
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 ?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1) Nein.

Autor: Frank B_. (frank_b) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> (Oder war noch mehr zu machen ?)

Bischen. Bei __floatunsisf nicht die richtige sondern die falsche 
Version auskommentieren ;-).

Autor: Frank B_. (frank_b) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank B_. (frank_b) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas: wg.falsch auskommentiert :  Jo.. ich sollte mal meine Brille 
aufsetzen.. :-)

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Frank B_. (frank_b) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank B_. (frank_b) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
'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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank B_. (frank_b) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank B_. (frank_b) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist im Repository schon behoben.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.