Hat den zufällig jemand "schon" gebaut? Die Version ist ja schon länger draußen und ich habe leider noch keine Windows-Binaries sichten können...
Bernd schrieb: > Hat den zufällig jemand "schon" gebaut? Die Version ist ja schon länger > draußen und ich habe leider noch keine Windows-Binaries sichten > können... Mit cygwin: configure -> make -> make install
Hier ist ein avr-gcc-6.3.1 dabei, generiert unter Linux für MinGW32: https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20(Win32)/ Binutils von git master zu dieser Zeit und avr-libc entsprechend von svn trunk. Mehr Tools (gdb, make, ...) sind nicht dabei. "Installtert" wird durch Auspacjen des ZIP an gewünschter Stelle. Aufruf dann per absolutem Pfad oder indem das bin-Verzeichnis zu PATH hinzugefügt wird. configure ist:
1 | $ avr-gcc -v |
2 | ... |
3 | Configured with: ../../gcc.gnu.org/gcc-6-branch/configure --target=avr --prefix=/local/gnu/install/gcc-6-avr-mingw32 --host=i386-mingw32 --build=x86_64-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared --enable-lto --with-dwarf2 --with-gnu-ld --with-gnu-as |
4 | Thread model: single |
5 | gcc version 6.3.1 20161222 [gcc-6-branch revision 243886] (GCC) |
6 | |
7 | $ avr-as -version |
8 | GNU assembler (GNU Binutils) 2.27.51.20161222 |
Beitrag #4979973 wurde von einem Moderator gelöscht.
lölö schrieb im Beitrag #4979973: > Ist diese Version besonders erstrebenswert? Liegt im Auge des Betrachters. Seit dem neuesten WinAVR gab es zum Beispiel folgende Änderungen: https://gcc.gnu.org/gcc-6/changes.html https://gcc.gnu.org/gcc-5/changes.html https://gcc.gnu.org/gcc-4.9/changes.html https://gcc.gnu.org/gcc-4.8/changes.html https://gcc.gnu.org/gcc-4.7/changes.html https://gcc.gnu.org/gcc-4.6/changes.html https://gcc.gnu.org/gcc-4.5/changes.html https://gcc.gnu.org/gcc-4.4/changes.html
Also, ich habe immer Vertrauen in die Entwickler und nehme gerne neue Versionen. :) Daher mein großer Dank. Es ist zwar noch mindestens ein alter (kosmetischer) Bug drin, mit dem ich mich seit längerem herumplage, aber ansonsten ist es supi.
Johann L. schrieb: > lölö schrieb im Beitrag #4979973: >> Ist diese Version besonders erstrebenswert? > > Liegt im Auge des Betrachters. Seit dem neuesten WinAVR gab es zum > Beispiel folgende Änderungen: > > https://gcc.gnu.org/gcc-6/changes.html > https://gcc.gnu.org/gcc-5/changes.html > https://gcc.gnu.org/gcc-4.9/changes.html > https://gcc.gnu.org/gcc-4.8/changes.html > https://gcc.gnu.org/gcc-4.7/changes.html > https://gcc.gnu.org/gcc-4.6/changes.html > https://gcc.gnu.org/gcc-4.5/changes.html > https://gcc.gnu.org/gcc-4.4/changes.html Gibt es Benchmarks für die AVR-Familie, in denen Zeiten und Codegrößen der Versionen (4, 5, 6) verglichen werden?
Johann L. schrieb: > nämlich? Kompiliere mal das
1 | const __flash char string1[] = "same string"; |
2 | const __flash char string2[] = "same string"; |
3 | |
4 | char foo(unsigned char i) { |
5 | return string1[i] + string2[i]; |
6 | }
|
mit den Parametern -fmerge-all-constants -Wall -Os
Hmpf. Bei einem (closed source mega328) Projekt bekomme ich leider auch einen
1 | c:/program files (x86)/avr-gcc-6.3.1/bin/../lib/gcc/avr/6.3.1/../../../../avr/bi |
2 | n/ld.exe: BFD (GNU Binutils) 2.27.51.20161222 assertion fail ../../../source/bin |
3 | utils-master/bfd/elf32-avr.c:2145 |
4 | collect2.exe: error: ld returned 1 exit status |
6.1.0 lief noch. Kann es noch nicht besser eingrenzen. Das Projekt ist sehr umfangreich.
Bernd schrieb: > Hmpf. Bei einem (closed source mega328) Projekt bekomme ich leider auch > einen > >
1 | c:/program files |
2 | > (x86)/avr-gcc-6.3.1/bin/../lib/gcc/avr/6.3.1/../../../../avr/bi |
3 | > n/ld.exe: BFD (GNU Binutils) 2.27.51.20161222 assertion fail |
4 | > ../../../source/bin |
5 | > utils-master/bfd/elf32-avr.c:2145 |
6 | > collect2.exe: error: ld returned 1 exit status |
> > 6.1.0 lief noch. > > Kann es noch nicht besser eingrenzen. Das Projekt ist sehr umfangreich. Mit Binutils bin ich nicht firm. Irgendwas mit Relaxing. Das Changeset, das die Assertion triggert, ist relativ neu und von 2014: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=931b79ccd6cc6ad4d8fe60a9c6de9443322a7cc8
Bernd schrieb: > Johann L. schrieb: >> nämlich? > > Kompiliere mal das > >
1 | const __flash char string1[] = "same string"; |
2 | > const __flash char string2[] = "same string"; |
3 | >
|
4 | > char foo(unsigned char i) { |
5 | > return string1[i] + string2[i]; |
6 | > } |
> > mit den Parametern > > -fmerge-all-constants -Wall -Os https://gcc.gnu.org/PR80462
Danke dafür. Testen kann ich es aber erst, wenn das Binary irgendwann vorliegt. ;) Was den anderen Fehler angeht: Durch kleinere Änderungen am Code geht er, dann kommt er wieder. Genauso je nach Optimierungsparametern. Völlig irregulär. Dass es am Code liegt, wage ich zu bezweifeln, denn es ist die einzige Compilerversion, die das macht.
Bernd schrieb: > Was den anderen Fehler angeht: Durch kleinere Änderungen am Code geht > er, dann kommt er wieder. Genauso je nach Optimierungsparametern. Völlig > irregulär. Dass es am Code liegt, wage ich zu bezweifeln, denn es ist > die einzige Compilerversion, die das macht. Wenn, liegt es eher an den Binutils. Ohne Testfall kann ich das leider nicht nachvollziehen. Verwendest du Relaxing (-mrelax ö.ä) ? Und gibt es das Problem gegebenenfalls auch ohne Relaxing? Brauchst du Linker Stubs ("Trampolines") ? Verwendest du LTO? Wenn es "kleine" Änderungen am Code triggert, wäre interessant, welche Unterschiede es im Assembler (.s-Dateien wie erzeugt mit -save-temps) gibt. Änderung an den (Optimierungs-)Parametern ist i.d.R. keine "kleine" Änderung.
:
Bearbeitet durch User
Das Problem tritt auch ohne -flto auf. Verwendet wird auch -Wl,-relax,-gc-sections Lasse ich das weg, geht es. Natürlich kann ich nicht garantieren, dass es nicht wieder durch eine andere Änderung in Erscheinung tritt... Eine frische Beobachtung ist: Mit -fno-reorder-blocks tritt das Problem auch nicht mehr auf. Ob das Zufall ist oder nicht, kann ich nicht sagen...
Bernd schrieb: > Das Problem tritt auch ohne -flto auf. > > Verwendet wird auch > -Wl,-relax,-gc-sections Kannst du denn wenigstens die Object-Files (*.o ohne Debug-Info) zur Verfügung stellen? -Wl,-relax ist nicht so toll, weil dann der Assembler bereits manche Werte berechnet, die durch das nachträgliche Relaxing dann falsch werden. Besser ist daher avr-gcc -mrelax ... (was den Assembler mit --mlink-relax füttert). Wenn der Fehler durch alleinige Änderung von -Wl,-relax zu -mrelax verschwindet, ist er vermutlich ein Anwenderfehler aus o.g. Grund. Oder schlechtes Design — warum die Funktionalität hinter --mlink-relax verschaltert wurde anstatt standardmäßig an zu sein, da musst du Atmel fragen. > Eine frische Beobachtung ist: Mit -fno-reorder-blocks tritt das Problem > auch nicht mehr auf. Kein ursächlicher Zusammenhang sondern nur Rauschen.
:
Bearbeitet durch User
So sicher wäre ich mir mit dem Rauschen nicht. -mrelax anstatt -Wl,-relax verbessert die Situation deutlich, aber mit -freorder-blocks -freorder-blocks-algorithm=simple tritt das Problem trotzdem noch auf.
Was heißt denn "deutlich"? Entweder die Assertion beißt zu oder nicht... Ohne Testfall ist das aber eh rumgerate, und -freorder o.ä. hat nichts ursächlich mit dem Problem zu tun.
War relativ schwierig, aber hier ist ein Beispiel:
1 | #include <avr/io.h> |
2 | |
3 | void foo(char unused) { |
4 | while (GPIOR0) GPIOR0 = 0; |
5 | }
|
6 | |
7 | char bar(void) { |
8 | if (GPIOR0) return 0; |
9 | foo(0); |
10 | foo(0); |
11 | return 1; |
12 | }
|
13 | |
14 | int main(void) { |
15 | if (bar()) goto end; |
16 | |
17 | switch (GPIOR0) { |
18 | case 0: |
19 | foo(0); |
20 | foo(0); |
21 | |
22 | case 1: |
23 | foo(0); |
24 | |
25 | case 2: |
26 | foo(0); |
27 | foo(0); |
28 | foo(0); |
29 | foo(0); |
30 | foo(0); |
31 | foo(0); |
32 | foo(0); |
33 | foo(0); |
34 | foo(0); |
35 | |
36 | case 3: |
37 | foo(0); |
38 | foo(0); |
39 | |
40 | case 4: |
41 | foo(0); |
42 | foo(0); |
43 | |
44 | case 5: |
45 | foo(0); |
46 | |
47 | case 6: |
48 | foo(0); |
49 | foo(0); |
50 | }
|
51 | end:
|
52 | foo(0); |
53 | }
|
Aufruf: avr-gcc main.c -mmcu=atmega168 -flto -Os -mrelax
Bernd schrieb: > War relativ schwierig, aber hier ist ein Beispiel: > > ... > > avr-gcc main.c -mmcu=atmega168 -flto -Os -mrelax https://sourceware.org/PR21404
Ich kriege hier auch manchmal einen
1 | relocation truncated to fit: R_AVR_7_PCREL against `no symbol' |
Allerdings habe ich keinen asm-Code verwendet... alles ist reines c. Und der Fehler kommt und geht auch sehr sporadisch. Ich versuche auch mal ein Beispiel hinzukriegen... was aber relativ schwierig ist.
Johann L. schrieb: > https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20(Win32)/ > > > "Installtert" wird durch Auspacken des ZIP an gewünschter Stelle. > Aufruf dann per absolutem Pfad oder indem das bin-Verzeichnis zu PATH > hinzugefügt wird. Hab auch mal eine 6.4.1 und eine 7.1.1 hochgeladen. Release 7.2 ist in ca. 2 Wochen geplant.
Ich würde mir im Moment sogar fast lieber eine neue 4er Version wünschen, die nur die Bugfixes aus den späteren Versionen enthält. Alles, was nach der 4er Version kam, erzeugt immer größeren Code. Ich weiß, dass das nicht realistisch ist...
Bernd schrieb: > Alles, was nach der 4er Version kam, erzeugt immer größeren Code. Ich hab für ein größeres Projekt den Code von 8.0 mit 6.3 verglichen, ist minimal kleiner geworden (Rauschen). Im Vergleich zur 4.9 um ca 2% kleiner (bei ca. 14K Binärcode), und mit der 4.7 streikt der Compiler (LTO + Globale Register). > Ich würde mir im Moment sogar fast lieber eine neue 4er Version > wünschen, die nur die Bugfixes aus den späteren Versionen enthält. Optionen hast du mehrere: 1) Deine private 4.x Version pflegen, die Quellen hast du ja. 2) Für spätere Versionen irgendwelche Zauber-Optionen finden, die die Codegröße erträglich machen. 3) Sich an der GCC-Entwicklung beteiligen und entsprechende Probleme selber beheben. Was du beobachtest ist vermutlich notorisch schwierig zu beheben (Loop-Optimierung, ungenaues Kostenmodell, Register-Allokation, nicht-optimale Adressierungsarten, ...) 4) Professionellen Support einkaufen wenn das Tool professionell eingesetzt wird, evtl. sich mit anderen Anwendern mit gleichen Interessen zusammentun. 5) Das Problem auf einer Plattform mit mehr Aufmerksamkeit nachvollziehen wie z.B. auf x86_64 nebst Eintrag im GCC Bugtracker. Selbst hatte ich noch ziemlich lange die alte 3.4.5 im Einsatz, weil die besseren Code generierte als die 4.x. Erst ab ca. 4.7 hab ich dann 4.x verwendet.
:
Bearbeitet durch User
Johann L. schrieb: > 8.0 mit 6.3 verglichen, > ist minimal kleiner geworden (Rauschen). Im Vergleich zur 4.9 um ca 2% > kleiner (bei ca. 14K Binärcode) Meine Erfahrungen sind eher umgekehrt. Ich benutze den gcc aber nie ohne Optimierungsparameter! Wenn man durch die Parameter das Maximum rausholt, also jeweils für 4.9, 6.3 und 8.0, dann wächst die Codegröße hier immer um je ca. 2% (von links nach rechts). Wie es ohne Parameter aussieht, weiß ich nicht auswendig, da es witzlos ist (die Unterschiede mit zu ohne Parameter sind weit größer). Es mag also sein, dass die 8.0 out-of-the-box besser optimiert als die 4.9. Aber richtig parametrisiert ist die 4.9 unschlagbar (ich habe diverse Bootloader nur mit der 4.9 kompilieren können, obwohl ich gerne die 8.0 genutzt hätte- trotz intensiver Parametersuche war da nix zu machen). Wenn ich Zeit finde, bastele ich mal ein Beispielprogramm.
> ... jeweils für 4.9, 6.3 und 8.0, dann wächst die Codegröße > hier immer um je ca. 2% ... Poste bitte ein Programm beim dem das nachzuvollziehen ist.
--param hab ich garnicht verwendet. Ein Bootloader sollte doch einfach genug sein, um rauszufinden, welcher Pass für den größeren Code verantwortlich ist?
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.