Hi, ich wollt mal fragen ob schon mal jemand hier avr-gcc code optimiert
hat.
Dis Problem ist weniger, die Optimierungen zu machen, sondern ich hab
überhaupt keinen Plan, wie die zurück in avr-gcc kommen. Das System von
Mailinglisten ist mir auch net klar, unterhalten sich da nur
irgendwelche bugzilla maildaemons oder funktioniert das wie ein Forum?
Zudem hab ich keinen Testumgebung, wenn auch ein Testprogramm das ich
angehängt hab.
Hier mal die Ergebnisse, es geht um die Codegröße.
Übersetzt wurde mit -Os
1
avr-gcc | ohne mit
2
---------+------------
3
4.2.4 | 504 264
4
4.3.2 | 486 272
Das "ohne" und "mit" bezieht sich darauf, ob der Patch aktiviert ist
oder nicht.
Wenn das ganze eh in der Tonne landen würde oder ein wochenlanger
Vollzeitjob wäre, die Änderungen zurückfliessen zu lassen, würd ich es
sein lassen.
Im wesentlichen geht es um Bit-Manipulationen, wie in der Quelle zu
sehen.
Grüß, Johann
> Das System von> Mailinglisten ist mir auch net klar, unterhalten sich da nur> irgendwelche bugzilla maildaemons oder funktioniert das wie ein Forum?
Das Prinzip einer Mailingliste ist ganz einfach. Jede Mail, die von
einem Listenteilnehmer an die Listenadresse geschickt wird, wird an alle
Listenteilnehmer weitergereicht.
Auf AVR-Freaks hast du Bedenken wegen der Menge der Mails geäußert.
Bezüglich der AVR-GCC-Liste kann ich dich beruhigen, da ist die Anzahl
der Mails sehr überschaubar. An manchen Tagen bekommt man da nicht eine
einzige Mail. Und dein Anliegen dürfte da gut hinpassen, also melde dich
einfach an. Du kannst die Liste auch jederzeit problemlos wieder
abbestellen.
Johann L. wrote:
> Das "ohne" und "mit" bezieht sich darauf, ob der Patch aktiviert ist> oder nicht.
Welcher Patch? Wenn Du Dich da an dieser Software versucht hast kann ich
Dir, ohne den Code dieses Patches zu sehen, mit Sicherheit sagen dass Du
da etwas massiv kaputt gemacht hast.
Michael G. wrote:
> Welcher Patch? Wenn Du Dich da an dieser Software versucht hast kann ich> Dir, ohne den Code dieses Patches zu sehen, mit Sicherheit sagen dass Du> da etwas massiv kaputt gemacht hast.
Wow, was für eine überhebliche und völlig blödsinnige Aussage.
Wenn du den Patch nicht kennst, worauf basiert denn dann das Urteil?
@linuxgeek: Unfug!
Compiler sind zwar komplex, aber keine schwarze Magie. Man kann sowas
lernen, hat vielleicht mal sowas studiert, schon mal mit Internas von
Compilern zu tun gehabt, ...
Insbesondere Änderungen in der Spezifikation der Zielmaschine (also hier
AVR) haben durchaus begrenzte Auswirkungen. Wenn ich Johann in der
Vorgängerdiskussion richtig interpretiert habe, dann handelt es sich um
AVR-spezifische instruction patterns für Umgang mit Bitfeldern. Und das
ist überschaubar.
Bischen Einblick in das bevorzugte Prozedere müsste eigentlich Jörg
Wunsch haben - mal sehen wann er wach ist.
A. K. wrote:
> Bischen Einblick in das bevorzugte Prozedere müsste eigentlich Jörg> Wunsch haben - mal sehen wann er wach ist.
Naja, ich weiß einfach nicht, wo ich anfangen soll. ;-) Wie eine
Mailingliste funktioniert, kann man sich garantiert irgendwo im
Internet anlesen. avr-gcc-list [at nongnu.org] würde ich auch
empfehlen, aber bitte erst eintragen, dann posten -- dieser Tage
sind praktisch alle Mailinglisten gegen Mails von Nichtmitgliedern
gesperrt, damit die Spamflut in Grenzen bleibt. Dafür gibt es
einfache Webinterfaces, auf denen man sich schnell ein- und
austragen kann, man kann auch die Mailauslieferung abschalten und
trotzdem eingetragen bleiben (d. h. eigene Postings würden dann
weiter akzeptiert).
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Allerdings klingt mir das da oben alles recht konfus, ich habe da
keinen Anfang und kein Ende sehen können. Wo ist der Patch? Leider
wird es auch darauf hinaus laufen, dass man sich mit der testsuite
für den GCC wohl oder übel befassen muss. Erstens darf das Ergebnis
des testsuite-Laufs mit dem Patch natürlich nicht schlechter werden
als ohne, das ist ein grundlegendes Akzeptanzkriterium für GCC.
Zweitens sollte man einen eigenen Test hinzu fügen, der die
Wirksamkeit der Änderung demonstriert und dann auch künftig als
Nachweis dient, dass nicht spätere Codeänderungen das gewünschte
Verhalten aus Versehen wieder kaputt machen.
Wenn das alles getan ist, kann man einen Bugzilla-Eintrag machen
und den Patch auf die GCC-Patch-Mailingliste posten. Danach muss
man aber noch mächtig am Ball bleiben, damit der Patch schließlich
irgendwann wirklich eingebaut wird. Ich habe den Patch für die
binären Konstanten (0bXXX) seinerzeit mal durchgedrückt, das hat
ziemlich lange gedauert. Bei einem rein AVR-spezifischen Teil könnte
das aber einfacher sein, da man nur erstmal ohne Widerspruch von
Denis (Денис Чертыков) auskommen sollte, um danach Anatoly (Анатолий
Соколов) ein wenig zu nerven, dass er es ins GCC-Subversion einpflegt.
Michael G. wrote:
> Johann L. wrote:>> Welcher Patch? Wenn Du Dich da an dieser Software versucht hast kann ich> Dir, ohne den Code dieses Patches zu sehen, mit Sicherheit sagen dass Du> da etwas massiv kaputt gemacht hast.
Die obiger Quelle sammelt ein paar Beispiele, für welche avr-gcc miesen
Code macht, weil er bestimmte Sachen sehr ineffizient macht.
Anbei die Ausgabe, für Anregungen wäre ich dankbar.
Und insbesondere auch über ein Wort, warum der Code mit "Sicherheit
falsch" sei.
Mit -fno-split-wide-types wird's nochmal 10 Byte kleiner
(extract_gprbit).
== alter Beitrag entfernt ==
Hier endlich das richtige Patch.
Bei allen Pattern handelt es sich um combiner-Pattern, d.h. sie greifen
im combine-Pass (*.r162)
Teilweise werden die Pattern nicht genommen, weil sie noch zu teuer sind
wegen ihrer komplexen rtx-Struktur. Zur Korrektheit tut das aber nix.
Rein vom Draufgucken sieht der Patch ja erstmal nicht schlecht aus.
Vom Inhalt verstehst du ohnehin mehr als ich. ;-)
Meta-Informationen with "GJL" sollte da nicht drin stehen: statt
dessen wird von dir erwartet, dass du ein passendes ChangeLog-
Schnipsel mit lieferst, in dem dann auch dein Name auftaucht.
(Sowas vergess ich gern mal, das produziert dann zusätzliche
Nachfragen.) Ein paar Kommentare, was die Schnipsel machen,
wären m. E. nicht schlecht, eventuell auch als Kommentar über den
ganzen Block obendrüber. Ja, ich weiß, der Rest von avr.md ist
auch nicht wirklich super kommentiert...
Ansonsten habe ich die restliche Verfahrensweise ja oben beschrieben.
avr-gcc-list ist das sinnvollere Medium für die Diskussion, dort
lesen zumindest noch diejenigen mit, die mit dem Inhalt von avr.md
auch was anfangen können. Hast du die Testsuite mal laufen lassen
um zu zeigen, dass der Patch keine negativen Auswirkungen darauf
hat? Schließlich und endlich solltest du noch einen oder mehrere
Tests für die Testsuite erzeugen, die die positiven Wirkungen deines
Patches verifizieren. In den sauren Apfel habe ich damals für die
0b-Konstanten auch beißen müssen, und das war gut so: es gab noch
einige Fälle (vor allem auf 64-bit-Maschinen), die ich in Folge
interner Überläufe nicht berücksichtigt hatte.
Jörg Wunsch wrote:
> Meta-Informationen ...
schon klar :-)
> Ja, ich weiß, der Rest von avr.md ist> auch nicht wirklich super kommentiert...
RTL ist selbsterklärend g> avr-gcc-list ist das sinnvollere Medium für die Diskussion, dort
hmmm sowas wie avr-gcc-devel gibt's net?
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
sagt:
>> The list is primarily intented for users of the tools,>> not for dicussions between developers. Developers should>> use their respective project mailing lists ...> Hast du die Testsuite mal laufen lassen um zu zeigen,> dass der Patch keine negativen Auswirkungen darauf hat?
Tests ...hüstel... gibt's da was für AVR? Momentan bin ich auf
http://gcc.gnu.org/viewcvs/tags/gcc_4_3_2_release/gcc/testsuite/gcc.target/
Und vermisse sowas wie avr/ dort. Gibt's irgendwo ne gute Beschreibung
zum Aufsetzen der Testsuite, wo man nicht auto-xxx und so studiert haben
muss?
Und dann: Ich fixe ja keine Bugs, wie geht das mit Codegröße vergleichen
gegen die gcc-4.3.2?
Aber vorher wären erstmal die binutils und multilibs dran. Was für ne
avr-binutils-Version tut's denn zusammen mit gcc-4.3.2? Hatte da immer
Probleme mit den neuen Targets weil GCC falschen Assembler erzeugt.
Johann L. wrote:
> hmmm sowas wie avr-gcc-devel gibt's net?
Ja.
>>> The list is primarily intented for users of the tools,>>> not for dicussions between developers. Developers should>>> use their respective project mailing lists ...
Hmm, ja. Das bezieht sich eher auf avr-libc, da gibt's noch eine
Entwickler-Mailingliste. AVR-GCC ist in diesem Sinne einfach nur
GCC.
>> Hast du die Testsuite mal laufen lassen um zu zeigen,>> dass der Patch keine negativen Auswirkungen darauf hat?>> Tests ...hüstel... gibt's da was für AVR?
Es gibt nur eine allgemeine, da es keinen genügend gut benutzbaren
Simulator für den AVR gibt, den die GCC-Entwickler nehmen könnten.
Hmm, hast Recht, damit kann man das natürlich so ziemlich vergessen.
> Und vermisse sowas wie avr/ dort. Gibt's irgendwo ne gute Beschreibung> zum Aufsetzen der Testsuite, wo man nicht auto-xxx und so studiert haben> muss?
Ist zu lange her, dass ich das das letzte Mal gemacht habe. Ich
erinnere mich dunkel, dass besonders der Start des Tests irgendein
ziemlich ominöses Kommando war...
> Aber vorher wären erstmal die binutils und multilibs dran. Was für ne> avr-binutils-Version tut's denn zusammen mit gcc-4.3.2?
2.18 genügt auf jeden Fall, möglicherweise sogar 2.17.
#
#
# Weil gcc die binutils 2.16.1 verwendet. So wie ich die spärliche
# gcc configure-Hilfe verstehe müsste er doch mit
# --with-build-time-tools die dort gewählten binutils verwenden?
#
#
1
--with-build-time-tools=PATH
2
use given path to find target tools during the build
#
#
1
Reading specs from /local/gcc-4.3.2-obj-avr/./gcc/specs
../../../gcc.gnu.org/gcc_4_3_2_release/libssp/ssp.c: In function '__guard_setup':
7
../../../gcc.gnu.org/gcc_4_3_2_release/libssp/ssp.c:70: warning: implicit declaration of function 'open'
8
../../../gcc.gnu.org/gcc_4_3_2_release/libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in this function)
9
../../../gcc.gnu.org/gcc_4_3_2_release/libssp/ssp.c:70: error: (Each undeclared identifier is reported only once
10
../../../gcc.gnu.org/gcc_4_3_2_release/libssp/ssp.c:70: error: for each
#
# Hast du ne Idee wie man
# a) gcc beigringt, die richtigen binutils zu verwenden im
# multilib build
# b) was der Fehler mit der libssp ist?
#
# Ist das ein Problem mit gpm/mpfr?
#
Johann L. wrote:
> aber zu b) libssp hab ich keine Idee...
--disable-libssp
libssp macht Datei-EA über fopen() und Konsorten, das setzt ein
irgendwie geartetes Betriebssystem voraus. Sowas hat der AVR nicht.
Thread beobachten
Seitenaufteilung abschalten