Ich habe bis jetzt immer mit dem WinAVR-Paket, auf das vom Tutorial
verwiesen wird (http://sourceforge.net/projects/winavr/files/),
'gearbeitet'. Nun habe ich mir GCC 4.7.2 installiert und bekomme beim
Build die im Betreff genannte Fehlermeldung. Wie kann ich mir jetzt das
Makefile mit korrekten Optionen für avr-size erzeugen lassen?
Die Option -C war ein grässlicher Hack, den Eric Weddington in
WinAVR eingebracht hat und sich nicht ausreden ließ. (Ihm war
dabei von vornherein klar, dass eine solche Option zumindest in
der gewählten Implementierung keine Chance hat, es jemals in die
offiziellen Binutils zu schaffen.)
Benutze die Option -B und ggf. den avr-size.sh Script, den es zuvor
für diesen Zweck gab.
Danke erstmal.
Jörg Wunsch schrieb:> Benutze die Option -B
Das will ich ja probieren, aber wo ersetzt man jetzt das -C in -B?
Ich habe ja kein selbst erstelltes Makefile.
Ralf G. schrieb:> Ich habe ja kein selbst erstelltes Makefile.
Dann entweder ein solches benutzen, oder das Kommando avr-size durch
einen Wrapper ersetzen, der das -C einfach ignoriert und das richtige
(umbenannte) avr-size.exe mit -B aufruft.
Jörg Wunsch schrieb:> Dann entweder ein solches benutzen, oder das Kommando avr-size durch> einen Wrapper ersetzen, der das -C einfach ignoriert und das richtige> (umbenannte) avr-size.exe mit -B aufruft.
Hmm.
Ich glaube, ich hab' noch was vergessen:
Build wird vom AVR-Studio (4.18) gestartet. Wenn ich das richtig
verstanden habe, wird aus den Projekteinstellungen ein Makefile
gebastelt.
Heißt das jetzt: Fehlermeldung erstmal ignorieren und avr-size extra
aufrufen! Oder kann da in einer Konfigurationsdatei einfach fix was
geändert werden?
Stefan Ernst schrieb:> Oder richtig Quick&Dirty ein älteres avr-size (mit -C Support) drüber> kopieren.
Sowas wollte ich erst machen! War nur zu blöd, mal richtig nachzusehen
wo avr-size ist :-(
Jetzt geht's...
Hmm... GCC 4.7.2 genehmigt sich gleich noch ein paar Bytes mehr Flash...
Ralf G. schrieb:> Wenn ich das richtig> verstanden habe, wird aus den Projekteinstellungen ein Makefile> gebastelt.
Ja, man kann aber auch ein eigenes drunterlegen und ihm sagen, dass
er jenes benutzt.
Jörg Wunsch schrieb:> Ja, man kann aber auch ein eigenes drunterlegen und ihm sagen, dass> er jenes benutzt.
Später vielleicht ;-)
Durch eure Anstöße funktioniert's jetzt erstmal.
Danke.
Ralf G. schrieb:> Hmm... GCC 4.7.2 genehmigt sich gleich noch ein paar Bytes mehr Flash...
Da lässt sich einiges durch Optionen nachtrimmen, bei mir bis zu 7%
besseren Code (beide Varianten mit -Os aber weiteren Optionen).
Johann L. schrieb:> Da lässt sich einiges durch Optionen nachtrimmen, bei mir bis zu 7%> besseren Code (beide Varianten mit -Os aber weiteren Optionen).
Welche weiteren optionen verwendest du?
Danke, michi
Johann L. schrieb:> Da lässt sich einiges durch Optionen nachtrimmen, bei mir bis zu 7%> besseren Code (beide Varianten mit -Os aber weiteren Optionen).
Kann schon sein. Ich habe bei dem Projekt, was ich mir zum Vergleich
rausgesucht habe, an den Optionen erstmal nichts geändert.
Optionen =
wie von AVR Studio vorgegeben + -fno-inline-small-functions + -Os
GCC 4.3.3 -> 1018 bytes (99.4% Full)
GCC 4.7.2 -> 1048 bytes (102.3% Full)
ohne -fno-inline-small-functions
GCC 4.3.3 -> 1114 bytes (108.8% Full)
GCC 4.7.2 -> 1048 bytes (102.3% Full)
??
Ohne was über die Quelle zu wissen, lann man dazu kaum was sagen.
Einige Optimierungsschalter sind in
AVR-GCC-Codeoptimierung: GCC-Optionen erklärt. Aber GCC kennt
hunderte von Optonen...
Ralf G. schrieb:> GCC 4.3.3 -> 1018 bytes (99.4% Full)
Naja, wenn der Code schon bis Unterkante Oberkiefer steht...
Johann L. schrieb:> Ohne was über die Quelle zu wissen, lann man dazu kaum was sagen.
Ist mir klar.
> Naja, wenn der Code schon bis Unterkante Oberkiefer steht...
Ich habe nicht gemeckert. Es ist mir nur aufgefallen. Und wenn sonst
alle anderen meinen: 'Dafür ist das Programm aber jetzt viiiel
schneller!', dann haben sich die Compilerentwickler was dabei gedacht
und ich kann damit gut leben. Vielleicht muss ich mich ja nur mal mit
der 'Feinabstimmung der Optimizer' beschäftigen (falls ich das mal
will!). Okay, eins hab' ich ja bereits rausgefunden:
'-fno-inline-small-functions' nützt schon mal nichts.
Johann L. schrieb:> Naja, wenn der Code schon bis Unterkante Oberkiefer steht...
Ach ja: Das ganze ist ein funktionierendes Programm. Es war reines
Interesse da mal den neuen Compiler ranzulassen.
[krümelkack]
Johann L. schrieb:> Wenn es mehr als 100% belegt kann man aber nicht testen, ob es> funktioniert...
[/krümelkack]
Die 99.4%-Variante vom GCC 4.3.3 meinte ich natürlich.
Was ich damit meinte ist: Es wäre interessant, den mit avr-gcc 4.7.2
erzeugten Code so klein zu bekommen, daß er auch ausführbar wird.
Wenn man so an der "bleeding edge" der Codegröße ist, muss man natürlich
an alles Stellen punkten.
Im C-Code zu sündigen und dann vom Compiler Ablass zu erwarten,
funktioniert i.d.R. nicht.
Johann L. schrieb:> Im C-Code zu sündigen und dann vom Compiler Ablass zu erwarten,> funktioniert i.d.R. nicht.
Ich erwarte gar nichts! Ich wollte einfach nur mal sehen, was passiert!
Und ob das gesündigt ist, kannst du doch gar nicht einschätzen mit
deiner Glaskugel. Und wenn's schlampig programmiert sein sollte, dann
mach ich doch den Compiler nicht dafür verantwortlich.
Ich hab' mal weiter probiert
(http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#GCC-Optionen
):
'-fno-split-wide-types' ist die einzige Option, die bei beiden
Compilerversionen 2 Bytes spart.
'-fno-inline-small-functions' nützt nur in Version 4.3.3 was
Ralf G. schrieb:> GCC 4.3.3 -> 1018 bytes (99.4% Full)> GCC 4.7.2 -> 1048 bytes (102.3% Full)>> ohne -fno-inline-small-functions> GCC 4.3.3 -> 1114 bytes (108.8% Full)> GCC 4.7.2 -> 1048 bytes (102.3% Full)Johann L. schrieb:> Was ich damit meinte ist: Es wäre interessant, den mit avr-gcc 4.7.2> erzeugten Code so klein zu bekommen, daß er auch ausführbar wird.
GCC 4.3.3 nehmen :-)
Ralf G. schrieb:> Johann L. schrieb:>> Im C-Code zu sündigen und dann vom Compiler Ablass zu erwarten,>> funktioniert i.d.R. nicht.> Und ob das gesündigt ist, kannst du doch gar nicht einschätzen mit> deiner Glaskugel.
Das was ich schrieb ist eine allgemeine Binsenweisheit, unabhängig von
dir und von deinem Code.
Ob du in deinem Code Böcke schiesst oder nicht weißt nur du selbst.
Ralf G. schrieb:> GCC 4.3.3 nehmen :-)
Das halte ich für den falschen Weg. Ich habe mit dem gcc 4.7.2 ein
Dutzend Projekte neu compiliert und musste feststellen, dass das Binary
in den meisten Fällen gegenüber dem 4.3.3er kleiner wurde.
Aber es gab durchaus auch Programme, die minimal größer wurden. Ich habe
mir dann die betreffenden Stellen durch Analyse der lss-Datei im Code
angeschaut und konnte da durch diverse Codeumstellungen bzw.
Optimierungen dem 4.7.2er Compiler noch etwas unter die Arme greifen, so
dass letztendlich auch diese Programme kleiner wurden.
Es lohnt sich also durchaus, mal nach den betreffenden Stellen zu
schauen.
