Hallo,

für alle Programmierer:
Wir haben festgestellt, dass es bei den aktuellen WinAVR-Versionen zu erheblichen Performanceverlusten kommt.

Ich habe mal die Prozessorauslastung der FC gemessen und zwischen meiner alten WinAVR-Version (WinAVR-20060421) und der aktuellesten (WinAVR-20081205) verglichen



Oben: neuer Compiler --> 80% Auslastung (mit Optimize-Einstellung OPT=2 (1-3 machen keinen Unterschied) mit OPT = 0 ist es 100% Auslastung)
Unten: alter Compiler --> 45% Auslastung
(Zu sehen ist die Bearbeitungszeit der Flight-Ctrl-Routine von V0.72)

Die Version WinAVR-20060421 findet man hier: http://downloads.sourceforge.net/winavr/WinAVR-20060421-install.exe?use_mirror=mesh
Diese Version verwendet noch den GCC 3.4.6. alle späteren Versionen verwenden bereits den GCC 4.1.1 oder höher. Dadurch tritt vermutlich der Performanceverlust ein.

Gruss,
Holger

Danke Holger.

Wo wir gerade beim Thema Compiler sind. Wie sieht es denn mit der Umgebung für die NC Software aus?
Welche Versionen verwendet ihr dafür?
Ich bin immer noch dabei eure GPS Struktur "mit Leben zu füllen". Leider bisher noch nicht 100%ig erfolgreich und das schlechte Wetter macht Testen quasi unmöglich.

Jochen

Hallo Programmier- Experten,
ich habe nun folgendes Problem:
Nachdem ich einige Änderungen in die FC 0.73c eingebaut habe, bekomme ich mit der WinAVR-20060421 nun die Fehlermeldung: "error: unable to find a register to spill in class `BASE_POINTER_REGS'".
Bei den AVR-Bugs gibts die Info: Fixed in >= 4.4.0.
Wenn ich mit der WinAVR-20081205 compiliere, ist die Fehlermeldung dann auch weg, aber ich habe die von Holger genannten Performance- Verluste, wodurch z.B. im Kopter-Tool bei laufenden Motoren keine Daten mehr ankommen.

Hat jemand noch eine Idee, welcher Compiler benutzt werden sollte.

Gruß
MartinR

Zeig mal den Codeauszug, bei dem das Problem auftritt.

killagreg meinte

Zeig mal den Codeauszug, bei dem das Problem auftritt.

Hallo Killagreg,
hier die Fehlermeldung:


Compiling: fc.c
avr-gcc -c -mmcu=atmega644p -I. -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=fc.lst -std=gnu99 -DVERSION_MAJOR=0 -DVERSION_MINOR=73 -DVERSION_PATCH=2 -DVERSION_SERIAL_MAJOR=10 -DVERSION_SERIAL_MINOR=1 -DNC_SPI_COMPATIBLE=5 fc.c -o fc.o
fc.c: In function `MotorRegler':
fc.c:835: warning: comparison is always false due to limited range of data type
fc.c:836: warning: comparison is always false due to limited range of data type
fc.c:1687: error: unable to find a register to spill in class `BASE_POINTER_REGS'
fc.c:1687: error: this is the insn:
(insn 2646 2645 2647 284 (set (reg:SI 28 r28 [997])
(minus:SI (reg:SI 1801 [ IntegralNick2 ])
(reg:SI 24 r24 [orig:996 IntegralNick ] [996]))) 31 {subsi3} (insn_list 2645 (nil))
(expr_list:REG_DEAD (reg:SI 1801 [ IntegralNick2 ])
(expr_list:REG_DEAD (reg:SI 24 r24 [orig:996 IntegralNick ] [996])
(nil))))
fc.c:1687: confused by earlier errors, bailing out
make.exe: *** [fc.o] Error 1

> Process Exit Code: 2
> Time Taken: 00:08




Hier die fc.c ab Zeile 1677:

1677 Motor = tmp_int;
1687 }
1679 else Motor = 0;
1680 }
1681 /*
1682 if(Poti1 > 20) Motor1 = 0;
1683 if(Poti1 > 90) Motor6 = 0;
1684 if(Poti1 > 140) Motor2 = 0;
1685 //if(Poti1 > 200) Motor7 = 0;
1686 */
1687 }


Gruß
Martin

Hallo Martin,

avr-gcc -c -mmcu=atmega644p -I. -O2 

das der Bug #31644 ('BASE_POINTER_REGS') bei -O0 nicht auftritt hast du gesehen
und deinen Code damit einmal testweise compiliert?

1678 }
1679 else Motor = 0;
1680 }
...
1687 }

fc.c:1687: confused by earlier errors, bailing out

Also das der Compiler konfus ist, kann ich verstehen. Da fehlt eine Klammer auf in Zeile 1679.
Die Klammer zu in Zeile 1687 ist dann die zugehörige zum Funktionsende, nehme ich an.

Und sowas...

fc.c:835: warning: comparison is always false due to limited range of data type

...gehört auch verboten. Sieh dir bitte mal den Vergleich an der da nicht stimmt.
Das ist bestimmt sowas einfaches falsch wie

uint32_t foo;
if (foo < 0)
{ /* someting */}

Grüße,
Toby

Hallo Toby,
ich habe es gerade ausprobiert, das Problem tritt nur bei Optimization level =2 auf. 0,1,3 funktionieren.
Danke für den Hinweis.

Zu Deinen anderen Anmerkungen:
- Die Anzahl der Klammern ist richtig. In diesem Bereich habe ich auch nichts geändert.
- Die Warnungen in Zeile 836/ 836 beziehen sich noch auf Original Trunk-Code. Dieser Code stammt nicht von mir. Ich habe es so gelassen, da die Ursache unkritisch ist.

Gruß
Martin

Hallo Martin,

gern geschehen.

Die Klammern hätten aber falsch sein können. Die Korrektheit der Gramatik
konnte man an deinem Code-Auszug nicht eindeutig feststellen.

Wegen der Kompiler-Warnungen in FC (SVN Tag V0.72p) hatte ich Holger und
Ingo vor zwei Wochen schon mal eine Mail mit Korrekturen geschrieben.
Vieleicht melden Sie sich ja noch und nehmen auch gleich das zur
Verbesserungen auf.

Grüße,
Toby

HolgerB meinte

Wir haben festgestellt, dass es bei den aktuellen WinAVR-Versionen zu erheblichen Performanceverlusten kommt.

genau dieses Problem trat bei mir auf. Es kam zum Abriss der BT-Verbindung bei Motorstart. Nach Compilieren mit der älteren GCC-Version war das Problem behoben

Hi,
bin grad am Rechner neu aufsetzen....Ist das Problem mit der neuen Version noch aktuell oder hat sich da was getan?
Möchte ungerne rumprobieren wenn es da schon Erfahrungswerte gibt.

Hat zu den neuen Versionen schon jemand Erfahrungswerte?

Lasst die Finger von den neueren Versionen, die auf dem GCC 4.x aufsetzen.

Ähm...
merkt denn der Rest der Welt nicht, dass mit GCC 4.x bescheidener Maschinencode raus kommt?

Denn seit WinAVR-20060421 sind schon seit vorgestern 4 Jahre vergangen!

Hat einer sich schon mal den MCode angesehen? Was macht denn GCC 4.x anders als 3.x?

@ Walmo

Der GCC 4.x ist unter anderem auch für die größeren Xmegas optimiert. Ich denke bei dem Kompromiss ist wohl etwas bei der Performance für die kleinen 8bit-Prozessoren auf der Strecke geblieben. Der Performence unterschied ist mit ca. Faktor 2 gewaltig. Aber vieleleicht hast du ja Zeit und Lust der Sache mal auf den Gund zu gehen?

Grüße Gregor

ich habe ein wenig gegoogled.

Interessanter Thread aus mikrocontroller.net
Gruß

Manfred

Doch mit die alte GCC unterstützt doch den 1284P NICHT? Wie wird dann für diesen Controller kompiliert? Mit der Neuen geht es auch nicht! PLS Help

Geduld...!

HolgerB meinte

Für Programmierer: ein angepasster Compiler - mit Atmega1284-Unterstützung - folgt

http://forum.mikrokopter.de/topic-post219841.html#post219841