avr-gcc 6.3 für Windows

Johann L. Persönliche Seite #4978759
Lesenswert?
• ▲
▼ 
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 melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Beitrag #4979973 wurde von einem Moderator gelöscht.
Johann L. Persönliche Seite #4979988
Lesenswert?
• ▲
▼ 
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
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Baltar Gast #4980128
Lesenswert?
• ▲
▼ 
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?
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Bernd Gast #4980520
Lesenswert?
• ▲
▼ 
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Johann L. Persönliche Seite #4980714
Lesenswert?
• ▲
▼ 
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
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Johann L. Persönliche Seite #4981146
Lesenswert?
• ▲
▼ 
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
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Bernd Gast #4981375
Lesenswert?
• ▲
▼ 
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Johann L. Persönliche Seite #4981384
Lesenswert?
• ▲
▼ 
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Bernd Gast #4981420
Lesenswert?
• ▲
▼ 
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...
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Johann L. Persönliche Seite #4981512
Lesenswert?
• ▲
▼ 
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Bernd Gast #4982616
Lesenswert?
• ▲
▼ 
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
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Johann L. Persönliche Seite #5091847
Lesenswert?
• ▲
▼ 
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Johann L. Persönliche Seite #5092312
Lesenswert?
• ▲
▼ 
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Bernd Gast #5092354
Lesenswert?
• ▲
▼ 
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.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren