Forum: Compiler & IDEs newlib fuer AVR?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Tun die nicht, und gabs auch noch nie.

Und auch sonst gibt es keine C++ Standardlib für AVR.

Oliver

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
...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
von Olaf (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> 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

von Retro N. (retronerd)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Kaj G. (Firma: RUB) (bloody)


Bewertung
3 lesenswert
nicht lesenswert
Retro N. schrieb:
> Dir scheint der Unterschied zwischen Compiler und Toolchain nicht klar
> zu sein.
prust
Du scheinst nicht zu wissen wer Johann ist :)

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Retro N. (retronerd)


Bewertung
0 lesenswert
nicht lesenswert
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
von Matthias K. (mkeller)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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. :/

von Retro N. (retronerd)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
8 lesenswert
nicht lesenswert
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?

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
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.

von Retro N. (retronerd)


Bewertung
0 lesenswert
nicht lesenswert
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
von Olaf (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> 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

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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. :)

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Retro N. (retronerd)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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
von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.