Ich hab AVR zwar schon einige Jahre nicht mehr genutzt, aber ich dachte mal wo ich gerade dabei bin kann ich ja auch mal eben avr installieren. Interessanterweise passiert hier das: cd newlib ../newlib-2.5.0/configure --prefix='/usr/local/cross' \ --target avr --program-prefix='cross-avr-' \ CC_FOR_TARGET=cross-avr-gcc CXX_FOR_TARGET=cross-avr-g++ \ GCC_FOR_TARGET=cross-avr-gcc AR_FOR_TARGET=cross-avr-ar \ AS_FOR_TARGET=cross-avr-as LD_FOR_TARGET=cross-avr-ld \ NM_FOR_TARGET=cross-avr-nm RANLIB_FOR_TARGET=cross-avr-ranlib make -j5 make[1]: Entering directory `/usr/src/CrossCompiler/Cross_avr/newlib' make[1]: Für das Ziel »all-target« ist nichts zu tun. Unterstuetzt newlib kein avr? Kochen die da irgendein eigenes Sueppchen? Olaf
Am einfachsten generiert man die newlib in-tree, d.h. * in GCC_SRC: ln -s NEWLIB_SRC/newlib * Falls libgloss gewünscht: in GCC_SRC: ln -s NEWLIB_SRC/libgloss * configure-build-install GCC Zunächst stellt sich aber die Frage, was du mit newlib überhaupt willst. Die avr-libc besteht großteils aus handverlesenem Assembler, bei der newlib ist das nicht der Fall, denn es gibt keinen dedizierte avr-Unterstützung. Siehe z.B:
1 | ./newlib/libc/machine |
2 | ./newlib/libc/include/machine |
3 | ./newlib/libm/machine |
4 | ./libgloss |
"avr" ist zwar in ./config.sub gelistet, aber es ist nicht davon auszugehen, dass sie für avr Problemlos generiert werden kann — wohl einer der Gründe, weshalb RTEMS die avr-Unterstützung eingestellt hat. Hinzu kommt, dass es niemanden gibt, der avr-gcc supported, d.h. über eher kurz denn lang ist dieser Compiler tot.
:
Bearbeitet durch User
> Hinzu kommt, dass es quasi niemanden gibt, der avr-gcc supported, d.h. > über eher kurz denn lang ist dieser Compiler tot. Ach so, das wusste ich nicht. Ist schon was her das ich AVR das letzte mal genutzt hab. Dann lass ich es einfach sein. Olaf
Olaf schrieb: >> Hinzu kommt, dass es quasi niemanden gibt, der avr-gcc supported, d.h. >> über eher kurz denn lang ist dieser Compiler tot. > > Ach so, das wusste ich nicht. Ist schon was her das ich AVR das letzte > mal genutzt hab. Noch ist es ja nicht soweit, und bis v8 ist der Support jedenfalls noch da. Ebenfalls möglich ist, dass sich µchip aufrappelt und bei Deprecation der benötigten 2 Features das avr-Backend anpasst (effektiv neu schreibt). > Dann lass ich es einfach sein. avr-gcc war ja nie ein schlechter Compiler, aber die glanzvollen Zeiten von WinAVR sind einfach vorbei. Selbst in 2017 gibt es Entwickler, die ein > 7 Jahre altes WinAVR erfolgreich einsetzen, und so mag es sein, dass selbt im Jahre 2025 Entwickler noch glücklich mit ihrem avr-gcc v7.x oder v8.x sein werden... Dein Problem ist aber definitiv nicht der Compiler, sondern weil du Newlib hergenommen hast anstatt avr-libc.
...und das da Olaf schrieb: > --target avr stimmt auch nicht. Der Code ist für Host avr, denn der Code will auf einem AVR laufen: --> --host=avr --build=x86_64-linux-gnu
:
Bearbeitet durch User
> dass selbt im Jahre 2025 Entwickler noch glücklich mit ihrem avr-gcc > v7.x oder v8.x sein werden... Das mag sein. Vorrausgesetzt der Compiler laeuft dann noch auf dem Hostsystem. Ich frag mich z.B auch gerade ob ich den hier nicht auch mal updaten sollte: m68k-palmos-coff-gcc --version 2.7.2.2-kgpd-071097 ...bisher geht es und das koennte in Arbeit enden die man nur noch selten benoetigt. > Dein Problem ist aber definitiv nicht der Compiler, sondern weil du > Newlib hergenommen hast anstatt avr-libc. Ja. Mein Problem war das ich nichts von avr-libc wusste sondern davon ausgegangen bin das es mit newlib geht wie fuer meine anderen Zielsysteme. Aber jetzt bin ich ja schlauer. :-) Olaf
Johann L. schrieb: > avr-gcc war ja nie ein schlechter Compiler, aber die glanzvollen Zeiten > von WinAVR sind einfach vorbei. Und was glaubst Du wohl, welchen Compiler das neueste Atmel Studio 7 verwendet? Dir scheint der Unterschied zwischen Compiler und Toolchain nicht klar zu sein.
Retro N. schrieb: > Dir scheint der Unterschied zwischen Compiler und Toolchain nicht klar > zu sein. prust Du scheinst nicht zu wissen wer Johann ist :)
Johann L. schrieb: > Selbst in 2017 gibt es Entwickler, die > ein > 7 Jahre altes WinAVR erfolgreich einsetzen Das kann ich voll bestätigen.
Beitrag #5207579 wurde von einem Moderator gelöscht.
Beitrag #5207910 wurde von einem Moderator gelöscht.
Mag ja alles sein, aber wie kommt es dann, dass er avr-gcc mit dem ollen WINAVR gleichsetzt und wörtlich behauptet avr-gcc sei tot, während Microchip/ATMEL den besagten avr-gcc als Teil des ATMEL Studios mit eigener Toolchain weiterhin kostenlos anbietet?
:
Bearbeitet durch User
Johann L. schrieb: > Olaf schrieb: >>> Hinzu kommt, dass es quasi niemanden gibt, der avr-gcc supported, d.h. >>> über eher kurz denn lang ist dieser Compiler tot. >> Ach so, das wusste ich nicht. Ist schon was her das ich AVR das letzte >> mal genutzt hab. > > Noch ist es ja nicht soweit, und bis v8 ist der Support jedenfalls noch > da. Ebenfalls möglich ist, dass sich µchip aufrappelt und bei > Deprecation der benötigten 2 Features das avr-Backend anpasst (effektiv > neu schreibt). Das wusste ich nicht... Und was für einen Compiler will Microchip/Ärmel für die AVRs in Zukunft anbieten, wenn nicht GCC? Gibt es hier zu noch andere Quellen?
Johann L. schrieb: > Noch ist es ja nicht soweit, und bis v8 ist der Support jedenfalls noch > da. Ebenfalls möglich ist, dass sich µchip aufrappelt und bei > Deprecation der benötigten 2 Features das avr-Backend anpasst (effektiv > neu schreibt). Ich fürchte, die werden lieber dann v7 einfach nur weiternutzen und hoffen, dass die AVRs bedeutungslos geworden sind, bevor man GCC 7 auf den dann aktuellen C-Compilern nicht mehr compilieren kann. :/
Jörg W. schrieb: > Ich fürchte, die werden lieber dann v7 einfach nur weiternutzen und > hoffen, dass die AVRs bedeutungslos geworden sind, bevor man GCC 7 > auf den dann aktuellen C-Compilern nicht mehr compilieren kann. :/ Öööhh War das jetzt Ironie, oder wie schätzt Du die Entwicklung ein? Werden 8 Bit µC durch ARM komplett verdrängt? Wird Microchip die PIC und AVR Architektur zusammenlegen bzw. eine davon sterben lassen? Wann wird das sein? Was ST angeht, geben die wenigstens 10 Jahre Longevity ab 1/1/2017 auf alle STM32 und STM8.
Retro N. schrieb: > War das jetzt Ironie, oder wie schätzt Du die Entwicklung ein? Ich kenne den Laden halt. Habe da knapp 10 Jahre lang gearbeitet (allerdings vor der Übernahme durch Microchip und auch nicht direkt mit AVRs). Ich weiß, was für Leute sie da beschäftigen, und ich sehe derzeit keinen, der auch nur ansatzweise so detailliert wie Johann im GCC stecken würde. Gut, das könnte sich natürlich auch mal ändern, aber ich glaub' da nicht dran. Für kommerzielle Kunden könnten sie ohnehin wieder dahin zurück gehen, wo sie mal herkamen: IAR. > Werden 8 Bit µC durch ARM komplett verdrängt? Kann schon passieren. Ich habe ja auch nicht über irgendeinen Zeitrahmen geschrieben, in dem das passieren würde. Auch gehe ich davon aus, dass sich ein GCC 7.x in 10 Jahren noch problemlos wird compilieren lassen. Die AVRs sind jetzt um die 20 Jahre alt. Ihren Zenit an Bedeutung haben sie gewiss schon überschritten.
Retro N. schrieb: > Mag ja alles sein, aber wie kommt es dann, dass er avr-gcc mit dem ollen > WINAVR gleichsetzt Ich habe sie nicht gleichgesetzt, sondern gesagt, dass avr-gcc aus der WinAVR-Distribution eine gute Qualität hatte. Die Tools hatten bessere Qualität (Bugfixes, Erweiterungen, etc), welche die jeweilige Stock-Versionen der entsprechenden Tools nicht hatten. Die Distributionen, die µchip heute bereitstellt, haben, abgesehen vom Host-OS, eine merklich kleinere Bandbreite. > und wörtlich behauptet avr-gcc sei tot, während Microchip/ATMEL Über die Politik der genannten Konzerne kann ich nichts sagen. avr-gcc ist GNU-Software, deren Copyright bei der FSF liegt. Mein Einblick in GCC und avr-gcc beruht auf den Beiträgen, die ich beginnend 2010 etwa 7 Jahre lang gemacht hatte. Das avr-Backend stellt mit 30000 LOC (ohne Tests) zwar nur einen verschwindend kleinen Teil von GCC dar, aber es ist natürlich nicht unabhängig von GCC und dessen Infrastruktur. Insbesondere verwendet es einen bestimmten Register-Allokator (ira/reload) und eine bestimmte Darstellung des Condition-Codes (cc0), welche gegenüber den neueren lra+CCmode als veraltet gelten und über kurz oder lang aus GCC entsorgt werden. Die Tatsache, dass cc0 für avr und andere deeply-embedded, bare-metal Targets sehr gute Dienste leistet und die (in diesem Zusammenhang) weitaus kompaktere und wartbarere Alternative im Vergleich zu CCmode ist, stellt für die entsprechenden Maintainer kein Argument dar. Konkret: Deprecation der entsprechenden Features bedeutet de facto Deprecation der nutzenden Targets. Wäre es einfach möglich, auf die neuen Features zu wechseln, dann wäre das bereits geschehen. Nicht-einfach bedeutet im Falle von avr, das Backend i.w. neu zu schreiben. Momentan sehe ich niemanden, die "hier" schreit und begeistert wäre, wesentlichen Aufwand darin zu investieren, ein (noch) schlechter wartbares Backend aufzusetzen, das absehbar schlechteren Code generiert, und der zudem die Bürde übernimmt, mit seinem Namen X erwartbare Bugs und Performance Regressions assoziiert zu sehen. Über den Zeitrahmen dieser Deprecation kann ich keine Aussage machen; noch nicht einmal darüber, ob sie denn irgendwann stattfinden wird. Aber bereits die mögliche Perspektive genügt mir, davon Abstand zu nehmen, weiterhin einen Teil meine Zeit auf dieses Projekt zu verwenden. Meine Beiträge waren semi-professionell, wobei das "semi" i.w. bedeutet, für Beiträge professioneller Qualität kein Entgelt zu erhalten. Da ich diesbezüglich mit keiner Firma liiert bin oder war -- und noch nicht einmal Compiler oder Mikrocontroller professionell einsetze oder je eingesetzt habe -- gibt mir das natürlich auch die volle Freiheit zu entscheiden, was und wie ich beitrage: Ich bin keinem Projektleiter, Brötchengeber, Advokaten oder sonst jemandem verpflichtet oder Rechenschaft schuldig. Und wenn ich auch nur den Ansatz des Eindrucks habe, das, was ich mache, könnte binnen weniger Jahre in der Tonne landen, dann lass ich es. Hinzu gesellt sich die generelle Haltung, welche Maintainer mitunter Beiträgen für deeply embedded entgegenbringen, exemplarisch zu beobachten am Review zu PR49857: Vom avr-Maintainer approved und begrüßt, werden die 3 Zeilen, die im Target-unabhängigen Teil zur Anbindung benötigt werden, als "too specific" abgelehnt, gleichwohl weder Host-Performance noch irgendein anderes Target davon berührt, die Erweiterung wohldokumentiert und in einen Hook gekapselt -- ja der ablehnende Maintainer versteht noch nichtmal die Feinheit von Address Spaces und bringt einen nicht-funktionierenden Alternativvorschlag nach dem anderen... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857#c17 Insgesamt ergibt sich eine Atmosphäre, die nicht dazu angetan ist, Entwickler im entsprechenden Bereich zu halten oder gar anzuziehen. Inzwischen gib es ein avr-Backend in clang/llvm, und erst kürzlich hatte ich Kontakt mit einem der Entwickler, der den Zustand in folgende Worte kleidete: "the AVR support in Clang is incredibly rough, doesn't generate optimal code at all, and doesn't always even generate correct code". Aber: "the LLVM maintainers seem to be more interested in properly supporting micro-archs than the GCC ones". Was immer der aktuelle Stand der entsprechenden Backends auch sein mag, als entscheidend für deren Zukunft wird sein, zu welchem Grade sie in der Lage sind, Entwickler anzuziehen und zu halten. Während das für llvm/clang zumindest momentan gegeben ist, sehe ich die entsprechende Vorraussetzung für gcc nicht erfüllt. Wenn ich eine entsprechende Wertung zu gcc abgeben sollte, dann als "a compiler in the decline and with a tendency to self-destruction for respective targets". Soviel zum tl;dr Hintergrund, weshalb m.E. avr-gcc über kurz oder lang tot ist. > den besagten avr-gcc als Teil des ATMEL Studios mit > eigener Toolchain weiterhin kostenlos anbietet?
> code". Aber: "the LLVM maintainers seem to be more interested in > properly supporting micro-archs than the GCC ones". Interessant waere ja noch die Frage womit eigentlich so ein durschnittlicher Maintainer seine Broetchen bezahlt. Da koennte ich mir auch eine Vorliebe fuer die eine oder andere Architektur vorstellen. Ansonsten bestaetigst du ganz allgemein den Eindruck den ich derzeit von der Softwareentwicklung habe. Viele Projekte sind so gross und fett geworden das ihre Umsetzung oder auch nur Pflege unrealistisch oder zweifelhaft geworden ist. Und zwar selbst dann wenn es einen Projektleiter gibt der mit Geld um sich wirft und die Peitsche schwingen kann. Bei Opensource-Sachen wo es auf freundlich gesinnte Initiative des Einzelnen ankommt sieht es dann natuerlich um so schlimmer aus. Olaf
Olaf schrieb: > Da koennte ich mir auch eine Vorliebe fuer die eine oder andere > Architektur vorstellen. Wobei es ja hier weniger um Vorlieben für eine Architektur geht, sondern darum, dass einzelne Leute dann sinnlos Dinge blockieren, nur weil sie sie gerade selbst nicht benötigen. Ich finde das mehr als schade, wenn man weiß, wie viel Arbeit Johann da schon hineingesteckt hat und wieviel das AVR-Backend des GCC durch sein Zutun besser geworden ist.
Johann L. schrieb: > Wenn ich eine entsprechende > Wertung zu gcc abgeben sollte, dann als "a compiler in the decline and > with a tendency to self-destruction for respective targets". > Soviel zum tl;dr Hintergrund, weshalb m.E. avr-gcc über kurz oder lang > tot ist. Vielen Dank für die Klarstellung und den Einblick in das Hintergrundgeschehen. Dein Resume ist ja leider mehr als traurig, aber damit ist deine Meinung absolut nachvollziehbar. Schade das auch solche herausragenden Projekte in der Open Source Community irgendwann zur Resignation engagierter Entwickler führen, weil sie an der Egozentrik Einzelner kaputt gehen. Linux droht hier ein ähnliches Schicksal. https://www.heise.de/forum/heise-online/News-Kommentare/Kommentar-Linux-scheitert-an-Ego-zen-t-rik/forum-383726/comment/ Echte (nicht kommerzielle) Alternativen zum avr-gcc gibt es ja derzeit eher nicht. llvm/Clang ist zwar vielversprechend, es ist aber zu befürchten daß sich die Vermutung von Jörg bewahrheitet und die AVRs schon das zeitliche gesegnet haben, bis der avr-llvm tatsächlich ernsthaft nutzbar ist.
:
Bearbeitet durch User
> Linux droht hier ein ähnliches Schicksal.
Da ist es jetzt schon lange so. Wie schon gesagt, ich denke das liegt
einfach an der Projektgroesse, noch erschwert dadurch das es viele
gegensaetzliche kommerzielle Interessen gibt.
Vor 15Jahren hab ich nach einer Linuxinstallation 1-2Wochen gebraucht
bis ich die Probleme ausgebuegelt habe die eine nicht perfekte Software
mitgebracht hat. Heute brauch ich einen Monat nach einer Neuinstallation
bis ich den Mist geradegezogen habe den die Maintainer da reingehauen
haben weil sie was eigenes inkompatibles wollen.
Ich versuch gerade ein kleines Programm namens Photivo zu kompilieren.
Es ist geradezu absurd was dazu fuer ein Aufwand zu treiben ist. Die
Software besitzt sogar drei unterschiedliche Buildsysteme weil sich die
Programmierer nicht mehr einigen koennen...
Olaf
Johann L. schrieb: > Ich habe sie nicht gleichgesetzt, sondern gesagt, dass avr-gcc aus der > WinAVR-Distribution eine gute Qualität hatte. Der WINAVR hat den Charme, daß er speziell für den dummen Anwender gemacht wurde, der weder Ahnung noch Lust dazu hat, sich sowas erst mühsam selber compilieren zu müssen. Einfach downloaden, auspacken und läuft. Daher wird er auch 7 Jahre später noch sehr gerne benutzt. Er ist auch sehr ausgereift. Wenn neuere AVR-GCC Versionen hi und da mal einen Befehl einsparen, würde ich das eher als Mikrooptimierung ansehen, die praktisch nur selten Auswirkungen hat. Compiler sind irgendwann mal auf einem Stand, wo immer neuere Features kaum einen Nutzen haben. Man muß also nicht ständig neuen Versionen hinterher jagen, sondern kann sie einfach nur benutzen. Ich hab auch noch nen Keil C51 von 1995 in Benutzung. Ich hab mal ne neue Demo probiert, aber einen Quantensprung habe ich nicht mehr feststellen können.
Peter D. schrieb: > Wenn neuere AVR-GCC Versionen hi und da mal einen Befehl einsparen, > würde ich das eher als Mikrooptimierung ansehen, die praktisch nur > selten Auswirkungen hat. Peter, du bist arg weltfremd … Gerade durch Johanns Zutun hat sich seit ca. GCC 4.7 massiv etwas getan beim AVR-Frontend des GCC's, das ist nicht nur „mal ein Befehl“, je nach Anwendung kannst du mit Einsparungen zwischen 10 und 30 % rechnen. Hinzu kommen noch die named address spaces und mit ihnen der __flash-Qualifier, die man eigentlich hätte beim AVR-GCC von Anfang an haben wollen. Vom Fixen teilweise durchaus desaströser Bugs ganz zu schweigen … WinAVR ist nicht hinfällig geworden, weil neuere Compilerversionen nicht besser geworden wären, sondern weil Atmel danach dann endlich begriffen hatte, wie wertvoll der AVR-GCC für sie tatsächlich ist (davor haben sie offiziell voll auf das IAR-Pferd gesetzt), sodass sie ihn und die umgebenden Tools ins Atmel Studio integriert haben.
Johann L. schrieb: > Wenn ich eine entsprechende > Wertung zu gcc abgeben sollte, dann als "a compiler in the decline and > with a tendency to self-destruction for respective targets". Gilt das nur für AVR oder allgemein für embedded, und speziell mit Blick auf Cortex-M?
Jörg W. schrieb: > Gerade durch Johanns Zutun hat sich seit ca. GCC 4.7 massiv etwas > getan beim AVR-Frontend des GCC's Ich hab da überhaupt keinen Überblick, wieviel neue Versionen seit dem WINAVR (4.3.3) rausgekommen sind. Es scheinen aber ne Menge zu sein. Jörg W. schrieb: > je nach Anwendung kannst du mit Einsparungen zwischen 10 und 30 % > rechnen. Magst Du mal ein Beispiel geben. Manchmal stellt sich der WINAVR etwas ungeschickt an, das stimmt. Aber auf ein gesamtes Projekt gesehen, sind das geschätzt <1% Code.
Peter D. schrieb: > Magst Du mal ein Beispiel geben. Habe ich nicht zur Hand, schon deshalb nicht, weil ich so alte Compiler hier nicht mehr habe. Johann war eingestiegen als (er möge mich korrigieren, falls ich falsch liege) GCC 4.7 der aktuelle Entwicklungsstand von GCC war. Er hat sich Unmengen an "bad optimization"-Bugs im AVR-GCC dann vorgenommen und für diese Fixes oder Workarounds implementiert. Schau einfach mal hier ins "Compiler & IDE"-Forum, in wie vielen Threads er dort reagiert hat. Sicher muss man nicht immer die allerneueste Version des Compilers haben, aber irgendwas jünger als GCC 4.7 empfiehlt sich beim AVR-GCC allemal.
Jörg W. schrieb: > Johann war eingestiegen als (er möge mich korrigieren, falls ich falsch > liege) GCC 4.7 der aktuelle Entwicklungsstand von GCC war. Ich kann mich dunkel erinnern, daß die Versionen nach dem WINAVR (4.3.3) recht schnell hochgezählt haben. Und teilweise gab es auch ernste Bugs, die der WINAVR noch nicht hatte. Also nicht nur ungünstig optimiert, sondern richtig falsch. Auch gab es Probleme mit dem Einfügen des Sourcecodes in das .lss-File. Ich hab das daher nicht mehr weiter verfolgt.
Peter D. schrieb: > Auch gab es Probleme mit dem Einfügen des Sourcecodes in das .lss-File. Klar, logisch: wenn man nicht gut optimiert, kann man immer eine prima Zuordnung zwischen C-Quellcode und Assemblercode vornehmen. Je besser man optimiert, um so mehr dröseln beide auseinander: C-Quellzeilen verteilen sich dann an verschiedenen Stellen im Assemblercode. Wie willst du da ein „schönes“ .lss-File erzeugen? Wenn du das als Qualitätskriterium nehmen willst, solltest du also möglichst wenig optimieren. Wenn das Qualitätskriterium jedoch eine möglichst optimale Umsetzung des Codes ist, dann sind die von Johanns Arbeit beeinflussten GCC-Versionen eben eindeutig besser. Ich habe aus ebendiesem Grunde übrigens diesen Hang zu .lss-Files nie verstanden: ich schau mir lieber den vom Compiler generierten Assemblercode (also nicht das Disassemblerlisting) an und halte den neben den Sourcecode um zu verstehen, was der Compiler da getrieben hat. Das hat allerdings seit LTO auch seine Tücken, aber über LTO brauchst du mit dem GCC 4.3 natürlich nicht nachdenken. :)
Jörg W. schrieb: > Klar, logisch: wenn man nicht gut optimiert, kann man immer eine prima > Zuordnung zwischen C-Quellcode und Assemblercode vornehmen. So wie ich das verstanden habe, war der Hauptgrund der, daß sich das Interface (Objectformat) geändert hat und daher die Zuordnung nicht mehr klappte. Es steht zwar beim WINAVR manches doppelt da, aber es ist immer noch gut erkennbar, welche Zeile welchen Code generiert. Auch bei Optimierung -Os und auch bei Inlining. Man konnte auch schön sehen, wie sich bei -O0 alles aufgebläht hat. Jörg W. schrieb: > Das hat allerdings seit LTO auch seine Tücken, aber über LTO > brauchst du mit dem GCC 4.3 natürlich nicht nachdenken. :) Beim WINAVR nannte sich das noch: --combine -fwhole-program Es inlined alle einmaligen Funktionsaufrufe und das Listing bleibt weiterhin gut lesbar.
Peter D. schrieb: > So wie ich das verstanden habe, war der Hauptgrund der, daß sich das > Interface (Objectformat) geändert hat und daher die Zuordnung nicht mehr > klappte. Da hat sich nichts grundlegend geändert. Wenn, dann eher zum Guten: mit neueren DWARF-Versionen im Debugformat gibt es detailliertere Informationen für den Debugger bspw. zur tatsächlichen Lebensdauer von Variablen. Allerdings darfst du nicht auf die Idee kommen, diese neueren DWARF-Versionen mit einem uralten AVR-Studio zu benutzen: die haben einen DWARF-Parser gehackt, der offenbar vorrangig auf trial&error bezüglich des damals vom GCC generierten DWARFs beruht und nicht auf einer sauberen Implementierung der DWARF-Spec. Daher stolpern sie über die zusätzlichen Elemente neuerer DWARF-Daten und erbrechen sich. Das ist aber kein Fehler des GCC, sondern eben einer der damaligen AVR-Studio-Implementierung mit ihrer sehr hausbackenen Debugger-Implementierung. >> Das hat allerdings seit LTO auch seine Tücken, aber über LTO >> brauchst du mit dem GCC 4.3 natürlich nicht nachdenken. :) > > Beim WINAVR nannte sich das noch: --combine -fwhole-program Das ist 'ne ganz andere Nummer. Da hat der Compiler bereits initial alles vorliegen, was er zum Optimieren braucht. Bei LTO dröselt er tatsächlich erst nach dem Linken auf, was jetzt noch eingedampft werden kann.
Jörg W. schrieb: > Peter D. schrieb: >> Wenn neuere AVR-GCC Versionen hi und da mal einen Befehl einsparen, >> würde ich das eher als Mikrooptimierung ansehen, die praktisch nur >> selten Auswirkungen hat. > > Peter, du bist arg weltfremd … *hust* schau dir mal PR81625 an: https://gcc.gnu.org/PR81625 Solch alte Versionen wie 3.4.5 (aus WinAVR-20060421) hat man ja nicht mehr auf dem Radar, aber 25% mehr bei neueren Versionen ist schon ne Hausnummer. Der Testfall ist jetzt auch kein exotischer Code, und die Anwendung wurde für einen AVR geschieben. Das Optimierungspotential der neuen Versionen ist sogar noch größer, da bereits der 3.4 keinen optimalen Code erzeugte. > Gerade durch Johanns Zutun hat sich seit ca. GCC 4.7 massiv etwas > getan beim AVR-Frontend des GCC's, das ist nicht nur „mal ein Befehl“, > je nach Anwendung kannst du mit Einsparungen zwischen 10 und 30 % > rechnen. Hinzu kommen noch die named address spaces und mit ihnen > der __flash-Qualifier, die man eigentlich hätte beim AVR-GCC von > Anfang an haben wollen. Am Front- oder Middle-End hab ich nicht gearbeitet. Die Target-unabhäbgigen Teile der Address-Spaces stammen i.w. von IBM / Meissner. Die Ablehnung von PR49857 lässt auch erkennen, dass bereits Änderungsvorschläge, die ganz klar nebenwirkungsfrei bezüglich Host-Performance und andere Targets sind — und die auch in keinster Weise Maintenance-Aufwände erwarten lassen — abgelehnt werden. Wenn es gar ins Eingemachte ginge mit Instruktionsgenerierung, dann spätestens wäre jedem klar, wo der Hammer hängt; und bei entsprechende Entscheidungen kann ich mit auch kaum vorstellen, dass llvm-Maintainer einem avr Vorzug vor arm, x86 oder ppc geben würden. > Vom Fixen teilweise durchaus desaströser Bugs ganz zu schweigen … Ja, allen voran PR46779, der ab 4.4 auftrat und dem WinAVR nur durch gut Glück entging — weil es die 4.4 gerade nicht mehr erlebte. Peter D. schrieb: > Compiler sind irgendwann mal auf einem Stand, wo immer neuere Features > kaum einen Nutzen haben. Es wäre bereits ein großer Fortschritt, wenn sie nicht schlechter würden und Dinge, die sie einmal problemlos beherrschten, nicht wieder vergäßen. In seiner Blauäugigkeit mag man dem Irrglaube aufsitzen, die Lösung der durch einen Compiler zu bewältigenden Aufgabe strebe einem Optimum zu, dass sich durch die Vielzahl der unterstützten, sowohl unterschiedlichen als auch hinreichend ähnlichen Architekturen irgendwann eine abstrakte, ideale Lösung herrausschäle, eine Quintessenz quasi, welcher die logische Schärfe und kristallene Klarheit einer mathematischen Lösung innewohne und die, fortan, immerwährende Gültigkeit besäße — dem Euklid'schen Algorithmus gleich, der, vor tausenden Jahren erdacht, unschlagbar einfach und unverbesserlich, seither einerseits Bestand hat als Teil des kulturellen Erbes der Menschheit, der andererseits klaglos und unangefochten effizient in heutigen Kryprosystemen seinen Dienst tut, beweisbar korrekt, gleichwohl bereits von einem Schüler durchdrungen und sogar erneut entdeckt werden kann. So nachvollziehbar solch ein Hang zum Idealismus auch sein mag, aber Compiler sind gegeben durch die zunehmende Komplexität der Architekturen und der zu verdauenden Sprachen und Erweiterungen durch ein Minimum an Hässlichkeit und fortwährenden Aufwänden ausgezeichnet, die keine Art von Konvergenz gegen ein wie auch immer geartetes Ideal erkennen lässt, und die eher beständig zu stopfenden Socken gleichen — mit positivem Wachstumskoeffizienten der Löcher, wohlgemerkt — denn einer Skulptur, die einer Vollendung zustrebt. Jörg W. schrieb: > Peter D. schrieb: >> Beim WINAVR nannte sich das noch: --combine -fwhole-program > > Das ist 'ne ganz andere Nummer. Da hat der Compiler bereits initial > alles vorliegen, was er zum Optimieren braucht. Bei LTO dröselt er > tatsächlich erst nach dem Linken auf, was jetzt noch eingedampft > werden kann. Bei LTO erfolgt die Optimierung lediglich zur "Link Time", wird aber immer noch vom Compiler höchstselbst ausgeführt, indem der Linker dem Compiler das nun vollständige Programm erneut zum Fraß vorwirft: Als Bytecode, der in entsprechenden elf-Sections der a's und o's enthalten ist und in lto-"Sprache" steht, die ihr eigenes GCC lto-Frontend besitzt. Der Linker / Locator selbst optimiert — abgesehen vom Aufsammeln weniger Brotkrumen wie --gc-sections oder Jump-Relaxing — nicht mehr. Den Weg durch's Tool-Gedärm sieht man mit
1 | -v -Wl,-v -save-temps |
:
Bearbeitet durch User
Johann L. schrieb: > eher beständig zu stopfenden Socken gleichen Wäre interessant zu wissen, ob das bei LLVM/Clang auch so ist, oder ob das an der Festgefahrenheit einiger GCC-"Stakeholder" liegt.
Die Geschichte finde ich höchst interessant, insbesondere deswegen, weil ich persönlich mit einer mindestens ebenso archaischen Plattform (m68k/ColdFire) vollkommen gegensätzliche Erfahrungen gemacht habe. Ohne dass sich (nach meiner Kenntnis) ein (m68k-) Maintainer gross darum bemüht hätte, ist von 4.6.3 bis 6.1 die Codesize eines relativ umfangreichen (>80000 Lines of Code, grob 460k Binary) Systems mit -Os um etwa 1,5% gesunken und mit -O2 um etwa 2% gestiegen (bei in beiden Fällen, aber insbesondere mit -O2 durch wesentlich aggresiveres Inlining "gefühlt" deutlich besserem/eleganterem Code und messbar besserer Performance). Die 5-er Versionen hatten da allerdings ein spürbares Tief...
Peter D. schrieb: > Ich kann mich dunkel erinnern, daß die Versionen nach dem WINAVR (4.3.3) > recht schnell hochgezählt haben. Und teilweise gab es auch ernste Bugs, > die der WINAVR noch nicht hatte. Ich habe damals den 4.3.3 sehr schnell mit dem 4.7.2 ausgetauscht. Der erzeugte Code wurde wesentlich kleiner und mit LTO konnte man noch einiges mehr rausholen. Ich kann da Jörgs Zahlen (10-30%) nur bestätigen. Bugs habe ich mit 4.7.2 nie feststellen können - ganz im Gegenteil: es wurden jede Menge Fehler beseitigt. Beim 5er gcc habe ich da keine Einsparungen mehr feststellen können - und so bin ich beim 4.7.2er geblieben. Läuft auch noch prima im 4.18er AvrStudio - solange man kein Windows10 verwendet.
Frank M. schrieb: > Beim 5er gcc habe ich da keine Einsparungen mehr feststellen können - > und so bin ich beim 4.7.2er geblieben. Läuft auch noch prima im 4.18er > AvrStudio - solange man kein Windows10 verwendet. Also um mich auch mal zu outen, ich verwende u.a. auch noch das AVR-Studio 4.19 mit avr-gcc 4.9.2 - und das funktioniert ganz hervorragend (auch debugging) unter Windows 10.
Johann L. schrieb: > die keine Art > von Konvergenz gegen ein wie auch immer geartetes Ideal erkennen lässt, > und die eher beständig zu stopfenden Socken gleichen — mit positivem > Wachstumskoeffizienten der Löcher, wohlgemerkt — denn einer Skulptur, > die einer Vollendung zustrebt. Das ist wohl generell mit jeder Software so. Altium baut auch gerne mal Verschlimmbesserungen ein. Aber es fragt wenigstens bei einer neuen Version, ob sie parallel installiert werden soll oder die alte überschrieben werden soll. Ich benutze die alte 14.2, wenn ich Polygon-Planes erstellen oder ändern will, was bei den neueren nur noch extrem umständlich geht.
:
Bearbeitet durch User
Jörg W. schrieb: > Johann L. schrieb: >> eher beständig zu stopfenden Socken gleichen > > Wäre interessant zu wissen, ob das bei LLVM/Clang auch so ist, oder > ob das an der Festgefahrenheit einiger GCC-"Stakeholder" liegt. Ich würde GCC nicht als festgefahren bezeichnen, und dessen Maintainer auch nicht. Jedem Target ist eben auch die Relevanz beigemessen, die sich durch die Aktivität in seinem Bereich ergibt, und für avr ist die: bescheiden. Es gab sogar Befürworter im Steering Committee, avr als Secondary Target hochzustufen — auch und gerade deshalb weil sich AVR in einigen Aspekten klar von anderen GCC-Targets unterscheidet. Konsequenz wäre, dass es keine GCC-Release mehr gäbe, ohne dass auch avr entsprechenden Qualitätskriterien genügte. Das würde aber auch einen Stamm an entsprechenden Entwicklern / Maintainern erfordern, die auftretende Probleme zeitnah beheben und einen qualititiv hochwertigen Support sicherstellen — was bekanntermaßen nicht gegeben ist. Noch nicht einmal der Hardwarehersteller selbst zeigte zu irgendeinem Zeitpunkt erkennbar Interesse oder Initialive in diese Richtung. Und zwei technische Grundvoraussetzungen für 2nd-ary Target sind bis heute nicht erfüllt: ein Standard-konformer double-Support sowie C++ Support mindestens für die libsupc++ https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/libsupc%2B%2B/ wo EMBECOSM entsprechende Anstrengungen wohl irgendwann einstellte. Andererseits wird avr-gxx auch für professionelle Projekte eingesetzt, und entsprechende Embedded-Entwickler erachten Stabilität, Qualität und Features der GNU-Tools offenbar als ausreichend für einen solchen Einsatz, und das schon über viele jahre und Versionen hinweg (was für avr-llvm trivialerweise noch nicht gegeben ist). Mir als Contributor zu avr-gxx vielen ja in erster Linie Dinge auf, die nicht so gut funktionieren wie sie optimalerweise funktionieren könnten, und von daher ist meine Wahrnehmung diesbezüglich garantiert mit einem klaren negiativen Bias beaufschlagt. Was avr-llvm abgeht, so hat llvm einerseits die bessere Presse als "neuere" Compiler-Architektur, und andererseits ist dessen avr-Backend noch dermaßen in den Puppen was Korrektheit und Effizienz angeht, dass es diesbezüglich dort nur aufwärts gehen kann. Markus F. schrieb: > Die Geschichte finde ich höchst interessant, insbesondere deswegen, weil > ich persönlich mit einer mindestens ebenso archaischen Plattform > (m68k/ColdFire) vollkommen gegensätzliche Erfahrungen gemacht habe. > > Ohne dass sich (nach meiner Kenntnis) ein (m68k-) Maintainer gross darum > bemüht hätte, [...] Mit m68k ist man ja recht komfortabel unterwegs: * int = void* = word = 32 Bits, damit liegt man voll im Mainstream. Bei avr hat man int = void* = 2*word. Bei einem m68k entspräche das einen default von 64-Bit int (inclusive Promotions zu 64 Bits z.B. beim Rechnen mit uint32_t) sowie 64-Bit Zeigern, und zwar auch für Stack- und Frame-Pointer! * m68k hat 8 Adress-Register und kann sogar 2-Reg Adressierungen. avr kann noch nichteinmal per Stackpointer auf den Stack zugreifen und braucht quasi für jeden Frame-Zugriff einen Frame-Pointer. Außer dem ziemlich nixnutzigen X-Register gibt es nur 2 Register, über die man auf den Speicher zugreifen kann: Y, das bei entsprechend komplexem Code aber vom Frame-Pointer belegt wird, und das Z-Register, das als einziges, brauchbares Adressregister übrig bleibt. * Dem Ideal 1nsn = 1instruction kommt m68k sehr nahe; bei avr gibt es viele insns, die ganze Instruktionsketten erzeugen und die nicht in einzel-insns aufgespalten werden, und wo eine solche Aufspaltung weder zu besseren Code noch zu einem besser wartbaren Backend führen würde. * avr verwendet traditionell 2 Register (TMP und ZERO) als fixed, d.h. sie sind immer verfügbar und laufen nicht via Reg-Allokator. Das wurde damals so implementiert und ins ABI eingebaut, weil es sich beim Portieren als günstig für die Codeerzeugung herausstellte. Das in eine andere (explizite) Darstellung zu überführen wäre extrem aufwändig, und man kann davon ausgehen, dass die Codegüte leiden würde. Solche "Hacks" gibt es auf m68k sicher auch nicht. Aber auch m68k verwendet noch das implizite cc0 zur Darstellung des Condition-Codes und nicht den expliziten CCmode. Zwangsläufig verwendet m68k also noch den alten Register-Allokator, denn der neue Allokator unterstützt gar kein cc0 mehr. Welcher Aufwand eine Umstellung ist, kann ich nicht sagen. Aber generell ist sie um so einfacher, je besser sich ein Target im GCC beschreiben lässt und wird zudem einfacher, wenn der Condition-Code sich entsprechend einfach verhält. Wenn man z.B. ein Target so modelliert, dass alle Instruktionen CCmode clobbern, dann ist das wesentlich einfacher zu portieren, als eine feinziselierte cc0-Modellierung unterschiedlichster Instruktionen zu übertragen. Und der neue Allokator unterstützt auch keine Memory-, Stack- oder Frame-Zugriffe, die den Condition-Code ändern, z.B.
1 | void bar (char*); |
2 | |
3 | char foo (void) |
4 | {
|
5 | char x[100]; |
6 | bar (x); |
7 | return x[70]; |
8 | }
|
Da Y maximal einen Offset von 63 unterstützt, wird für den Zugriff addiert / subtrahiert (adiw+sbiw in insn 12), was den Prozessorstatus ändert. Ohne den Prolog-Epilog-Sermon (Y=r29:r28):
1 | movw r24,r28 ; 18 *movhi/1 [length = 1] |
2 | adiw r24,1 ; 5 *addhi3/3 [length = 1] |
3 | call bar ; 6 call_insn/2 [length = 2] |
4 | adiw r28,71-63 ; 12 movqi_insn/4 [length = 3] |
5 | ldd r24,Y+63 |
6 | sbiw r28,71-63 |
Auf m68k ist der Zugruff nur eine Instruktion, die direkt auf das entsprechende Slot zugreifen kann (insn 14). Und ich geh mal davon aus, dass diese den Condition-Code nicht berührt:
1 | pea -100(%fp) | 6 pushasi |
2 | jsr bar | 8 *call/2 |
3 | move.b -30(%fp),%d0 | 14 |
Jedenfalls sitzen avr und m68k was Deprecation von cc0 und ira/reload angeht — zumindest momentan noch — im gleichen Boot.
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.