Forum: Compiler & IDEs gcc11 könnte das avr Backend verlieren


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 Lars R. (larsr)


Bewertung
-2 lesenswert
nicht lesenswert
Johannes F. schrieb:
> Johann L. schrieb:

Die Sachlage scheint mir ziemlich eindeutig zu sein: Es geht hier nicht 
um eine "Community" sondern um die Interessen von ARM bzw. deren 
Plattform, wenn du mal im GCC-Bugtracker nachschaust, steht da bei der 
Mehrheit der Bugs "arm-none-eabi" drin...

Für die klassische x86-Plattform dürfte GCC kaum Relevanz haben (außer 
bei Linux), wobei das ja in der deutlichen Minderheit ist, da bei 
Windows VC++ und bei Apple mittlerweile Clang eingesetzt wird.

Alle "kleinen Plattformen" zusammen können doch nicht ansatzweise die 
Bedeutung erlangen, die ARM für GCC hat. Wobei Keil beim MDK (Keil ist 
seit einiger Zeit eine Tochterfirma von ARM) von GCC auf Clang 
gewechselt ist.

von Μαtthias W. (matthias) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Lars R. schrieb:
> Für die klassische x86-Plattform dürfte GCC kaum Relevanz haben (außer
> bei Linux), wobei das ja in der deutlichen Minderheit ist, da bei
> Windows VC++ und bei Apple mittlerweile Clang eingesetzt wird.

Linux dürfte wohl auf der Mehrheit aller Server eingesetzt werden. Da 
von kaum Relevanz bei x86 zu sprechen halte ich für gewagt. Aber sicher 
geht da bisschen was verloren was hauptsächlich an clang listen dürfte.

Aber auch beim GCC geht's aus meiner Sicht ordentlich voran. Das AVR 
Backend stört da wohl und behindert den Fortschritt. Wenn es keiner 
pflegt fliegt es halt nach längerer Ankündigung raus. Normaler 
Fortschritt. Röhrenradios sind ja auch so gut wie ausgestorben.

Matthias

von Oliver S. (oliverso)


Bewertung
3 lesenswert
nicht lesenswert
Lars R. schrieb:
> Die Sachlage scheint mir ziemlich eindeutig zu sein: Es geht hier nicht
> um eine "Community" sondern um die Interessen von ARM bzw. deren
> Plattform, wenn du mal im GCC-Bugtracker nachschaust, steht da bei der
> Mehrheit der Bugs "arm-none-eabi" drin...

Die Sache ist absolut eindeutig, und das wurde inzwischen doch auch 
eindeutig geklärt:

Innerhalb von gcc gibt es niemanden, der die Verantwortung für alle 
Plattformen hat. Die einzelnen Plattformen werden von aktiv 
teilnehmenden Entwicklern gepflegt und weiterentwickelt. Da gibt es dann 
auch mal "Pflichtarbeiten", wenn sich am gcc selber was geändert hat.

Beim avr-gcc ist nach dem "Auscheiden" von Johann die aktuelle Anzahl 
der aktiv teilnehmenden Entwickler exakt Null. In Worten: 0.

Microchip will oder kann nicht, und auch sonst niemand.

Entweder findet sich bis zum Stichtag jemand, der das machen will und 
kann, oder AVR ist draussen. Ende der Diskussion.

Oliver

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Innerhalb von gcc gibt es niemanden, der die Verantwortung für alle
> Plattformen hat. Die einzelnen Plattformen werden von aktiv
> teilnehmenden Entwicklern gepflegt und weiterentwickelt. Da gibt es dann
> auch mal "Pflichtarbeiten", wenn sich am gcc selber was geändert hat.

Scheint hier niemand zu raffen worum es geht.

Es geht nicht darum, dass die Backends nicht mehr maintained würden, es 
gibt z.B. Bug-Fixes für die Backends etc, und wenn ein Backend so buggy 
ist und das es nicht den Qualitätsstandards genügt, fliegt es raus. Und 
das ist schon mehr als 1× passiert.

Was momentan abgeht ist was kompeltt anderes.

von Johannes F. (doppelgrau)


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
>> Aber wiederum, ist OpenSource, du kannst einen Fork pflegen,
>
> Na dann mach mal

Warum sollte ich?
Werde dafür nicht bezahlt und habe keinen Bedarf an einen AVR-compiler.
Und halt scheinbar auch so wenig andere (Bedarf an einen aktuellen 
Compiler), dass keiner sich der Arbeit annimmt. (IMHO wäre es politisch 
klug gewesen von MicroChip dann paar Mannmonate springen zu lassen, aber 
das ist ja deren Entscheidung)

Johann L. schrieb:
> Was momentan abgeht ist was kompeltt anderes.

Was den?

Das man hier und da auch größere Umbauten in Softwareprojekten vornehmen 
muss, ist doch total normal und kleines 1&1 der Softwareentwicklung. Und 
das dabei Teile für die sich offensichtlich kein Entwickler mehr 
interessiert auf den Prüfstand gestellt werden auch.
Und ob man das Resultat dann gcc11 oder "ngcc" nennt ist doch total 
egal, und passiert auch dauernd in Firmen (gut, da entscheiden meist 
nicht die Entwickler sondern eher der Vertrieb, aber kommt für einen 
reinen Nutzer am Ende aufs gleiche raus). Funktionen oder Produkte 
werden auf einmal angekündigt, oder durch angeblich tollere Sachen 
ersetzt werden, die halt in deinem Use-Case gewisse Probleme haben.

von Roland F. (rhf)


Bewertung
2 lesenswert
nicht lesenswert
Hallo Johann,
> Was momentan abgeht ist was kompeltt anderes.

Wenn ich es richtig verstanden habe, wird das Frontend des gcc im Zuge 
einer Modernisierung so verändert, das alle Backends für die jeweiligen 
Prozessorfamilien neu geschrieben werden müssen.
Bei einem komplett neuen avr-Backend ist davon auszugehen, das es 
einerseits schwieriger zu warten ist und andererseits auf absehbare Zeit 
eine schlechtere Code-Qualität als das aktuelle Backend liefern wird. 
Kurz: das Neuschreibens und Unterhalten des Backends ist sehr aufwendig 
und unter Umständen auch für den Verantwortlichen nicht sehr 
befriedigend.
Es stellt sich also die Frage ob es sich lohnt seine Arbeit zu 
investieren, besonders vor dem Hintergrund, das das Interesse der 
gcc-Verantwortlichen an "alten" Prozessoren eher gering ist und selbst 
kleine, gut begründetet Änderungen/Verbesserungen im aktuellen Backend 
ablehnen (wobei da offensichtlich auch Unkenntnis im Spiel ist, siehe 
Beitrag "Re: newlib fuer AVR?").

Ist das in etwa so richtig?

rhf

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Johannes F. schrieb:
> Das man hier und da auch größere Umbauten

Umbauen ist was anderes als Wegschmeissen.

: Bearbeitet durch User
von Lars R. (larsr)


Bewertung
1 lesenswert
nicht lesenswert
Johann L. schrieb:
> Umbauen ist was anderes als Wegschmeissen.

Sehe ich halt genau so.

Kurios finde ich an diesem Beitrag nur, dass immer gefordert wird, dass 
sich jemand beteiligen möge und wenn derjenige, der genau dies jahrelang 
getan hat, praktisch dieselbe Kritik äußert, wird der von denen genau so 
belächelt wie ich.

Diese Geisteshaltung kann ich wirklich nicht nachvollziehen...

von Johannes F. (doppelgrau)


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Johannes F. schrieb:
>> Das man hier und da auch größere Umbauten
>
> Umbauen ist was anderes als Wegschmeissen.

Aber manchmal bedingt das eine das andere, weil die Erweiterungen dann 
dazu nicht mehr passen, weil sich die interne Logik ändert.
Wechselt das CMS von PHP5 nach PHP7 kannst alle PlugIns wegwerfen, die 
die alte DB-API nutzen. Und das ist ja eine minimale Wartungs-Änderung. 
Richtig lustig würde es ja, wenn man gleich auf verteilte Datenbanken 
wechseln um richtig schön Wolkig zu sein (skaliert so schön), dann 
bricht gleich alles was ACID voraussetzt / annimmt und nicht mit den 
Implikationen des CAP-Theorems klarkommt.

Oder schau dir die Webbrowser an, wo kannst du noch NAPI-Plugins nutzen?
Konnte alles weggeworfen werden, weil es zum internen Umbau nicht 
passte.

: Bearbeitet durch User
von Lars R. (larsr)


Bewertung
-1 lesenswert
nicht lesenswert
Das mag ja alles sein, aber Netscape war damals auch eine richtige 
Firma.

Ein Open-Source-Projekt hat sich gefälligst so zu verhalten, dass die 
Mitarbeit der Freiwilligen geschätzt wird, sonst braucht man sich über 
mangelnde Mitarbeit nicht zu wundern.

Für mich ist das Verhalten von dem Haufen indiskutabel, da kann man 
Argumente bringen wie man will. Die können sich nicht aufführen wie ein 
Pascha und erwarten, dass andere diese Meinung teilen.

von Johannes F. (doppelgrau)


Bewertung
0 lesenswert
nicht lesenswert
NAPI Plugins gabs auch beim Firefox und Chrome, beide (größtenteils - 
Chrome gibts als Chromium ohne die kleinen google-Anteile) OpenSource...

Und die Erweiterung sind oftmals auch OpenSource. Ich kann nicht 
erkennen, das es den Projekten geschadet hat. Browser sind stabiler 
geworden (NAPI-Schnittstelle und Plugins waren eine der 
Haupt-Absturzursache) und Entwickler gibt es immer noch...

Außerdem, was die Wertschätzung der Mitarbeit angeht: Zurück auf die 
Frage oben, warum die Zeit der "alten" Entwickler mehr Wert haben soll 
als die neuer Entwickler die aktuell Lust haben aktiv was zu machen?

: Bearbeitet durch User
von Oliver S. (oliverso)


Bewertung
1 lesenswert
nicht lesenswert
Lars R. schrieb:
> Ein Open-Source-Projekt hat sich gefälligst so zu verhalten, dass die
> Mitarbeit der Freiwilligen geschätzt wird, sonst braucht man sich über
> mangelnde Mitarbeit nicht zu wundern.

Open Source hat nichts mit Freiwilligen zu tun. Die Zeiten sind bei den 
großen Projekten schon lange vorbei. Daher gehts da auch vorwärts.

Oliver

von Johann L. (gjlayde) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
Roland F. schrieb:
> Wenn ich es richtig verstanden habe, wird das Frontend des gcc im Zuge
> einer Modernisierung so verändert, das alle Backends für die jeweiligen
> Prozessorfamilien neu geschrieben werden müssen.

Technisch ist es ein Teil des Middleends, also weder Frontend (das 
bezeichnet sprachabhängige Teile für C, C++, LTO, Ada, Fortran, ...) 
noch Backend.

Es wird auch nicht wirklich was verändert, es wird einfach eine von 2 
Alternativen (cc0, CCmode) rausgekickt.  Das sind wesentlich 
unterschiedliche Ansätze um Condition Code zu modellieren. cc0 gibt's 
seit es GCC gibt, CCmode ist neuer.  cc0 hat paar Nachteile, etwa können 
Vergleich und Branch nur als Einheit geschedult werden, d.h. 
Vergleich+Branch folgen immer direkt aufeinander.  Für Architekturen wie 
AVR ist das jedoch kein Nachteil.

Im Compiler werden die Alternativen i.w. unterschieden per
#ifdef HAVE_cc0
Was gemacht werden wird, ist effektiv alle diese Stellen zu entfernen.

> Bei einem komplett neuen avr-Backend ist davon auszugehen, das es
> einerseits schwieriger zu warten ist

Etwas schwiertiger.  Das Hauptproblem ist die Umstellung.  cc0 hat den 
Vorteil, das es ziemlich einfach ist; sowohl von der Darstellung / 
Beschreibung als auch vom Ablauf.

> und andererseits auf absehbare Zeit eine schlechtere Code-Qualität
> als das aktuelle Backend liefern wird.

Davon ist auszugehen. Sowohl Korrektheit als auch Performance 
betreffend.

> Kurz: das Neuschreibens und Unterhalten des Backends ist sehr
> aufwendig und unter Umständen auch für den Verantwortlichen nicht
> sehr befriedigend.

Ja.  Man kann ja nicht teilweise umstellen.

Und irgendwann wird dann noch auf einen neuen Register-Allokator 
umgestellt, von RA.2 auf RA.3.

Umstellung RA.1 -> RA.2 war vor X Jahren und problemlos, im Backend hat 
man davon nix gemerkt — was ja auch so sein soll.  Welcher Reg-Allokator 
verwendet wird ist ja unabhängig von den verwendeten Interfaces.

Mit RA.2 -> RA.3 ist das aber nicht mehr so.  RA.3 kann zum Beispiel 
nicht mit cc0 umgehen, und auch nicht mit CCmode falls Spill-Code den 
Prozessorstatus verändern kann.  Was bei AVR durchaus der Fall ist. 
Größere Architekturen haben damit kein Poblem, die haben Instruktionen 
wie ADD üblicherweise 2-fach: Eine Version mit Carry Setzen und eine 
ohne Condition-Code zu verändern.

Weil irgendwann auf RA.3 umgestellt werden soll, fliegt auch cc0 raus, 
denn RA.3 kann damit eh nicht umgehen.  Und die Umsetzung von cc0 per 
#ifdef ist nicht mehr ganz zeitgemäß, ginge aber auch anders.  So viel 
Stellen im Compiler sind das nämlich nicht.  Dafür kennt RA.3 einige 
Hooks nicht mehr, was für AVR mit seinen wenigen Adressregistern 
bedeutet, dass X-Reg noch schlechter unterstützt wird (oder gar nicht 
mehr).  Oder weil RA.3 mit den wenigen Adress-Registern nicht 
zurechtkommt, gibt es alle Nase lang Spill-Fails Internal Compiler 
Errors.

tl;dr: Selbst falls die beiden Umstellungen irgendwann für AVR gemacht 
werden, d.h. falls AVR nicht rausfliegt, wird der Code absehbar und 
dauerhaft schlechter.

: Bearbeitet durch User
von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
>
> tl;dr: Selbst falls die beiden Umstellungen irgendwann für AVR gemacht
> werden, d.h. falls AVR nicht rausfliegt, wird der Code absehbar und
> dauerhaft schlechter.

'grübel' Ich dachte die ganze Zeit das durch die Umstellung der Code 
wieder besser wird. Auch das dann die Codegrößen wieder schrumpfen, die 
bis jetzt von Version zu Version angestiegen sind, eben weil das backend 
nicht ganz optimal passt.

Also wenn das so stimmt wie gesagt, wenn!, dass die Codequalität danach 
trotzdem schlecht bleibt und weiterhin schlechter wird, dann brauch ich 
mich nicht ins Zeug legen für avr-gcc. Dann hole ich mir auch meine 
Spende zurück. Dann hätte ja alles gar keinen Sinn. Das wäre wiederum 
sehr traurig um den gcc für avr.

von Johann L. (gjlayde) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Veit D. schrieb:
> Johann L. schrieb:
>>
>> tl;dr: Selbst falls die beiden Umstellungen irgendwann für AVR gemacht
>> werden, d.h. falls AVR nicht rausfliegt, wird der Code absehbar und
>> dauerhaft schlechter.
>
> 'grübel' Ich dachte die ganze Zeit das durch die Umstellung der Code
> wieder besser wird.

CCmode ist einfach ein neuerer Besen, der für Boliden besser kehrt.  Der 
Code wird dadurch "besser" weil das Middle-End einfacher wartbar wird, 
denn eine Art, den Condition Code zu modellieren (cc0), fliegt einfach 
ersatzlos raus.

Für AVR und vermutlich einige / alle anderen Back-Ends die noch cc0 
verwenden — oder noch bis neulich cc0 verwendeten — bringt CCmode 
absehbar nix. Außer haufen Arbeit und Instabilität für / durch die 
Umstellung.

> Auch das dann die Codegrößen wieder schrumpfen, die bis jetzt von
> Version zu Version angestiegen sind, eben weil das backend
> nicht ganz optimal passt.

Das sind keine Probleme des Back-Ends.  Wenn das so wäre, wäre das im 
AVR Back-End längst behoben.  Die Probleme liegen im Middle-End.

> Also wenn das so stimmt wie gesagt, wenn!, dass die Codequalität danach
> trotzdem schlecht bleibt und weiterhin schlechter wird, dann brauch ich
> mich nicht ins Zeug legen für avr-gcc. Dann hole ich mir auch meine
> Spende zurück. Dann hätte ja alles gar keinen Sinn. Das wäre wiederum
> sehr traurig um den gcc für avr.

Prinzipiell ist nicht ausgeschlossen, dass sich das Middle-End in dieser 
Beziehung wieder bessert. Momentan gibt es eben niemand, der die 
entsprechenden Maintainer nervt.  Wobei nur nerven natürlich nix bringt; 
man braucht schon Testfälle.  Am besten solche, die auch für ARM, 
PowerPc oder x86 funktionieren, dann gehen die Dinge plötzlich ganz 
fix...

von Wilhelm M. (wimalopaan)


Bewertung
3 lesenswert
nicht lesenswert
Die Situation entspannt sich dahin gehend, als dass das AVR-Beckend im 
LLVM nicht nicht mehr experimentell ist (und ganz gut funktioniert).

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Ganz blöd gefragt: wie kommt man an einen avr-clang?

Oliver

von Wilhelm M. (wimalopaan)


Bewertung
1 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Ganz blöd gefragt: wie kommt man an einen avr-clang?

git clone
cmake ...
make -j 8

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nur mal zur Zwischeninfo. Arduino.cc antwortet nicht einmal auf Github. 
Ist nun 14 Tage her. Ich wüßte auch nicht wie ich die sonst kontaktieren 
sollte.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert

von Lars R. (larsr)


Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:
> 'grübel' Ich dachte die ganze Zeit das durch die Umstellung der Code
> wieder besser wird. Auch das dann die Codegrößen wieder schrumpfen, die
> bis jetzt von Version zu Version angestiegen sind, eben weil das backend
> nicht ganz optimal passt.

Man muss in diesem Beitrag schon wirklich bewusst manche Stellen 
"überlesen" wollen, um weiterhin bei der Meinung zu bleiben, dass die 
Ursache dieser Probleme im AVR-Backend liegen würde.

Wie gesagt: Am GCC wird vorrangig das gemacht, was die ARM-Plattform 
weiterbringt. Hier ist offenbar Kapazität bei den Entwicklern ohne Ende 
vorhanden (vermutlich weil Geld fließt). Die Änderungen, die dann 
gemacht werden, werden aber einfach "durchgewunken", egal, ob andere 
Plattformen dadurch Nachteile erledigen oder nicht.

Und spinnen wir das mal weiter: Wenn diejenigen, die behaupten, dass 
Microchip (oder wer auch immer) für die AVR-Unterstützung im GCC etwas 
zahlen müsse, wieso sollten die ein Interesse daran haben, am Middleend 
(oder wo auch immer) etwas zu verändern und sich nachher der Gefahr 
auszusetzen, sich was anhören zu müssen, wenn ARM darunter leiden würde?

Ich bin mir ziemlich sicher: Würde jemand einen Patch comitten, der bei 
AVR wieder zu einer Verbesserung, um - sagen wir mal - 10%, führt aber 
gleichzeitig bei ARM nur zu 1% Verschlechterung, dann würde das einfach 
reverted.

Wenn ihr das alle billig und angemessen findet - okay. Hier wird einfach 
mit unterschiedlichem Maß gemessen. Man sieht das doch schon im 
Bugtracker, bei ARM kann man Bugs in mehreren Stufen priorisieren, bei 
den "unbeliebten" Plattformen nur in einer Stufe - egal wie gravierend 
der Bug ist!

Das sind doch nachprüfbare Fakten - man schaue einfach in die 
Beschreibung zum Bugmeldeverfahren bei GCC.

So viel ich weiß, ist AVR die einzige 8-Bit-Plattform bei GCC (im 
offiziellen Code), andere der Plattformen, die die rauswerfen wollen, 
sind 16 Bit. Wie bereits geschildert, geht es hier nicht um technische 
Einschränkungen, sondern einzig um bewusste (politische) Entscheidungen.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert

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


Bewertung
2 lesenswert
nicht lesenswert
Lars R. schrieb:
> Am GCC wird vorrangig das gemacht, was die ARM-Plattform weiterbringt.

Ich glaube, das ist ein wenig zu kurz gegriffen.

Natürlich spielt ARM eine wesentliche Rolle (und zwar weniger, weil da 
irgendjemand „GCC“ dafür bezahlen würde, sondern schlicht, weil ARM 
selbst Entwickler dafür bezahlt, bei GCC mitzuarbeiten), aber amd64 aka 
x86_64 wird ihnen gewiss mindestens genauso wichtig sein.

Aber sieh das mal andersrum: ARM bezahlt Leute dafür, dort was 
mitzumachen – obwohl sie mittlerweile mit Keil einen eigenen Compiler 
haben. Das hat eben Atmel und dann Microchip nie ernsthaft gemacht. Die 
haben stattdessen auf IAR gesetzt oder irgendwelche eigenen 
Branches/Forks befummelt – und dann zum Teil noch Geld dafür haben 
wollen.

Ursprünglich war der GCC übrigens für 32-bit-CPUs konzipiert worden, 
16bittige sind dann „irgendwie“ mit reingekommen, aber 8bitter waren nie 
wirklich Zielsystem. Daher ist der AVR (wenn ich Johann richtig 
verstanden habe) auch eher als so eine Art „Pseudo-16bit-CPU“ damals 
implementiert worden – was im Gegenzug einige andere Optimierungen 
verhindert hat, wenn bspw. bei einer 16-bit-Rechnung die oberen 8 Bits 
gar keine Rolle spielten.

von Veit D. (devil-elec)


Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Veit D. schrieb:
>> ein User hat einen Link gepostet.
>> https://llvm.org/docs/ReleaseNotes.html#changes-to-the-avr-target
>
> Beitrag "Re: gcc11 könnte das avr Backend verlieren"

Die Frage ist, kann ein llvm einen gcc für AVR gleichwertig ersetzen?

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Wenn ARM sich aktiv um gcc kümmert muss man sich nicht wundern. Auch AMD 
und Intel tragen zu gcc bei. Obwohl das Intel nicht müßte, da die ihren 
eigenen Compiler hegen und pflegen.

Jörg W. schrieb:
> Aber sieh das mal andersrum: ARM bezahlt Leute dafür, dort was
> mitzumachen – obwohl sie mittlerweile mit Keil einen eigenen Compiler
> haben. Das hat eben Atmel und dann Microchip nie ernsthaft gemacht. Die
> haben stattdessen auf IAR gesetzt oder irgendwelche eigenen
> Branches/Forks befummelt – und dann zum Teil noch Geld dafür haben
> wollen.

Genau, kommt aufs gleiche raus nur umgedreht. Kümmerte sich früher Atmel 
nicht darum und heute Microchip weiterhin nicht, dann landet alles 
irgendwann auf dem Abstellgleis. Damit liegt alle Last auf den Schultern 
der Community, also die die das können.

Übrigens werkelt Arduino.cc an einer "Arduino Pro IDE". Momentan noch 
alles Betastatus. Aber die nutzen bei der Pro IDE den clang Compiler. 
Also auch keinen gcc mehr.

Wenn das mit dem avr-backend nichts wird, sieht es echt traurig aus.
Aber noch ist nicht aller Tage Abend. Noch habe ich Hoffnung für avr im 
gcc. Bei Motorola klappte es schließlich auch. Ich hatte mir das mal 
spassenshalber angeschaut, weil ich hier auch so viel gefragt und 
geschrieben habe, aber da blicke ich echt nicht durch. Dafür langen 
meine Programmierkenntnisse einfach nicht. Selbst mit "logischer 
Textersetzung" käme man nicht weit, wenn es nur Fleißarbeit wäre.

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


Bewertung
4 lesenswert
nicht lesenswert
Veit D. schrieb:
> Übrigens werkelt Arduino.cc an einer "Arduino Pro IDE".

Arduino hat immer nur poliert (sprich, IDE gebastelt), nie an der 
Substanz gearbeitet. Weder am Compiler noch an der Basis-Bibliothek 
(libc) noch an AVRDUDE. Nur ihre Abstraktionsbibliothek ist ein 
nennenswerter Beitrag jenseits der IDE selbst.

Wenn ihnen plötzlich beide Compiler wegbrechen würden, würden sie 
schlicht und ergreifend ziemlich alt aussehen. Allerdings wäre es aus 
ihrer Sicht vermutlich einfacher, einen Fork des älteren GCC-Codes 
weiter zu pflegen, statt sich um die Anpassungen im Middleend von GCC 11 
zu kümmern.

von Michael F. (michaelfu)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Aber sieh das mal andersrum: ARM bezahlt Leute dafür, dort was
> mitzumachen – obwohl sie mittlerweile mit Keil einen eigenen Compiler
> haben.

Sicher?

Ich dachte, selbst in Keil MDK wird seit längerem der Arm Compiler 
genutzt und damit wäre es (mehr oder weniger) nur noch eine alternative 
IDE zu Arm DS5 (mit künstlich beschnittenem Device-Support).

Eine Frage bezüglich LLVM: In wie weit wären Projekte für GCC mit LLVM 
kompatibel oder fängt man da wieder ganz von vorne an?

von S. R. (svenska)


Bewertung
2 lesenswert
nicht lesenswert
Lars R. schrieb:
> Am GCC wird vorrangig das gemacht, was die ARM-Plattform weiterbringt.

ARMv7, ARMv8, x86_64 und eventuell noch x86. Das sind nunmal die großen 
Architekturen, da gibt es vom Hersteller bezahlte Entwickler, und da 
sind moderne Programmiersprachen relevant.

AVR ist einige Größenordnungen kleiner, es gibt keine 
C++-Standardbibliothek, der Hersteller kümmert sich nicht und aktive 
Entwickler gibt's auch kaum. Der meiste AVR-Code in der Welt ist 
Assembler oder C, da kommt es auf aktuelle Compilerversionen nicht an.

Hier im Forum will einzig Wilhelm sein C++27 sehen.

Lars R. schrieb:
> Wenn ihr das alle billig und angemessen findet - okay.

Es ist anhand der Faktenlage logisch und nachvollziehbar. Und wenn man 
AVR entfernen muss, um die vier Großen voranzubringen, dann hat man in 
Summe die Welt trotzdem vorangebracht.

Lars R. schrieb:
> Wie bereits geschildert, geht es hier nicht um technische
> Einschränkungen, sondern einzig um bewusste (politische)
> Entscheidungen.

Ist es immer politisch, ein totes Pferd nicht mehr zu reiten?

von J. W. (dilbert)


Bewertung
0 lesenswert
nicht lesenswert
> Eine Frage bezüglich LLVM: In wie weit wären Projekte für GCC mit LLVM
> kompatibel oder fängt man da wieder ganz von vorne an?

Zu AVR im Clang kann ich nichts sagen, aber beim MSP430 musste man, wenn 
ich mich nicht täusche, die Unterbrechungsroutinen anders markieren.

Was bei GCC z.B.
    __attribute__ ((interrupt(PORT1_VECTOR)))
    void port1(void) { ... }
ist, wäre bei Clang
    #pragma vector=PORT1_VECTOR
    __interrupt void port1(void) { ... }
oder so ähnlich...

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
J. W. schrieb:
> oder so ähnlich...

Die ISR für clang/clang++ müssen (unmangled) so heißen, wie im 
startup-code definiert. Also etwa folgendermaßen.

__attribute__((interrupt)) void __vector_21(void)  {}

Kann man natürlich beliebig mit CPP-Gewurstel "schöner" machen.

von J. W. (dilbert)


Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis. Es ist schon länger hin, dass ich mich damit 
beschäftigt hatte.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Noch jemand, der sich über GCC ärgert:

http://lists.llvm.org/pipermail/llvm-dev/2020-April/140546.html

von Johann L. (gjlayde) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Lars R. schrieb:
> Am GCC wird vorrangig das gemacht, was die ARM-Plattform weiterbringt.

AM GCC wird vorrangig das gemacht, was die an GCC arbeitenden Entwickler 
machen.  Und die stellt google, arm, redhead, ibm, codesourcery, suse, 
st, ...

> Hier ist offenbar Kapazität bei den Entwicklern ohne Ende
> vorhanden (vermutlich weil Geld fließt).

Es fließt kein Geld zum GCC, sondern Firmen lassen daran arbeiten (oder 
auch nicht).

> Die Änderungen, die dann gemacht werden, werden aber einfach
> "durchgewunken", egal, ob andere Plattformen dadurch Nachteile
> erledigen oder nicht.

> Und spinnen wir das mal weiter: Wenn diejenigen, die behaupten, dass
> Microchip (oder wer auch immer) für die AVR-Unterstützung im GCC etwas
> zahlen müsse,

Wie gesagt: Da wird nix gezahlt.

> Ich bin mir ziemlich sicher: Würde jemand einen Patch comitten, der bei
> AVR wieder zu einer Verbesserung, um - sagen wir mal - 10%, führt aber
> gleichzeitig bei ARM nur zu 1% Verschlechterung, dann würde das einfach
> reverted.

Um einen Patch zu committen muss er erst mal durch ein Review.  GCC ist 
keine Code-Bonanza wo jeder einfach seinen Code reinhaut.


> okay. Hier wird einfach mit unterschiedlichem Maß gemessen.
> Man sieht das doch schon im Bugtracker, bei ARM kann man Bugs
> in mehreren Stufen priorisieren, bei den "unbeliebten" Plattformen
> nur in einer Stufe - egal wie gravierend der Bug ist!

Wie Maße sind:

1) Primary Targets: Wichtige Host-Systeme wie x86_64, ARM, PowerPC. 
Offenbar gehört AVR nicht dazu.  In absehbarer Zeit wird GCC nicht auf 
einem AVR laufen.

2) Secondary Targets: Targets, für die besondere Qualitätsansprüche bei 
Releases gelten.

3) Der ganze Rest, z.B. avr.

Damit ein Target "secondary" ist, müssen bestimmte Voraussetzungen 
gelten:

i) Das Target ist standardkonform.  Trifft für avr nicht zu, denn double 
ist ein 32-Bit Typ.

ii) libsupc++ wird unterstützt, das ist der minimale Kern der C++ 
Standard-Bibliothek und Basis der libstdc++-v3 mit z.B. 
bits/c++config.h, bits/os_defines.h, bits/cpu_defines, bits/locale.h 
etc. Wird von avr nicht unterstützt.  Stattdessen frickelt jeder, der 
avr-g++ einsetzt, seine eigenen Header zusammen.

iii) Das Target wird so gut unterstützt, dass qualitativ hochwertige GCC 
Releases möglich sind. Konkret: Gibt es mit einem Target Probleme, die 
von den Backend-Maintainern / -Entwicklern nicht zeitnah gelöst werden, 
dann wird NICHT die GCC Release bis zum St Nimmerleinstag aufgeschoben, 
sondern es gibt eine Release und das Target wird auf 3-klassig 
runtergestuft.


Der einzige Punkt, wo in den letzten 10 Jahren überhaupt Bewegung 
erkennbar war, ist Punkt i:  Ab v10 wird 64-Bit double unterstützt – 
zumindest im Compiler und der libgcc.  Wann / ob die (avr-)libc 64-Bit 
double unterstützt weiß ich nicht.


Und es gab durchaus Maintainer, die AVR gerne als Secondary Target 
gesehen hätten genau weil die Architektur sich in einigen wesentlichen 
Punkten von den anderen Targets unterscheidet.

Aber von nix kommt eben nix:

* Von Atmel kommt nix.

* Von Microchip kommt nix.

* Von der "AVR-Community" – was immer das sein soll – kommt nix.


> Das sind doch nachprüfbare Fakten - man schaue einfach in die
> Beschreibung zum Bugmeldeverfahren bei GCC.

Ja, i), ii) und iii) sind definitiv nachprüfbar.


> Wie bereits geschildert, geht es hier nicht um technische
> Einschränkungen, sondern einzig um bewusste (politische) Entscheidungen.

Ja, cc0 / CCmode ist ein Novum. Gebaren dieser Art gab es bislang nicht 
im GCC.

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


Bewertung
1 lesenswert
nicht lesenswert
Johann L. schrieb:
> libsupc++ wird unterstützt, das ist der minimale Kern der C++
> Standard-Bibliothek und Basis der libstdc++-v3 mit z.B.
> bits/c++config.h, bits/os_defines.h, bits/cpu_defines, bits/locale.h
> etc. Wird von avr nicht unterstützt.

Weiß gar nicht mehr genau, was das alles war. Teilweise vermutlich ein 
nicht komplett implementiertes stdio, weiß nicht, ob die 
double-Geschichte da auch mit reinspielte (auf jeden Fall tat sie's bei 
FORTRAN).

Möglicherweise hätte man für standardkonformes stdio die avr-libc 
aufbohren können oder zusehen, dass die newlib unterstützbar 
wird/bleibt, aber wie du schon schriebst, so wirklich viel kam da auch 
nie aus der Community rüber. Gerade Arduino setzt massiv auf C++ und 
hätte da ja vielleicht am ehesten Motivation haben können für "tier 2" 
Support - schließlich machen sie Geld damit. Aber gerade Arduino war nun 
auch nie sonderlich integrativ, die haben gern genutzt, was da war, aber 
ansonsten ihr eigenes Süppchen vor sich hin geköchelt.

von Frank K. (fchk)


Bewertung
-1 lesenswert
nicht lesenswert
Veit D. schrieb:

> Also wenn das so stimmt wie gesagt, wenn!, dass die Codequalität danach
> trotzdem schlecht bleibt und weiterhin schlechter wird, dann brauch ich
> mich nicht ins Zeug legen für avr-gcc. Dann hole ich mir auch meine
> Spende zurück. Dann hätte ja alles gar keinen Sinn. Das wäre wiederum
> sehr traurig um den gcc für avr.

Welche Motivation hast Du eigentlich, Dich so an AVR zu klammern?

AVR ist
- nicht besonders schnell, auch nicht im Vergleich zu anderen 8 Bit 
Architekturen
- nicht besonders billig, vor allem wenn man die gebotene Leistung 
betrachtet, bei Digikey kostet ein Mega2560 genauso viel wie ein 
PIC32MZ1024EFH100-I/PF, nur letzterer ist ein 32 Bit MIPS mit 200 MHz 
und 512k RAM
- nicht besonders stromsparend mit der 5V Halbleitertechnik, da sind 
Architekturen wie EFM8/EFM32 und MSP430 weiter

Es gibt ja genug Alternativen. Von daher lasst ihn sterben.

fchk

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


Bewertung
1 lesenswert
nicht lesenswert
Die von dir genannten Alternativen sind aber im Vergleich zu AVR 
reichliche Exoten, d.h. du findest weniger Codebeispiele rundrum und 
weniger Community. Das halte ich für einen AVR schon für ein 
wesentliches Argument.

Ich würde dann eher als Alternative auf 5-V-fähige ARMs ausweichen, 
bspw. SAMC21.

(Wenn die direkte 5-V-Fähigkeit kein Thema ist, wird die Auswahl ja 
sowieso nochmal massiv größer.)

Aber es ging in diesem Thread natürlich nicht um Alternativen zu AVRs, 
sondern um GCC und deren Gebaren.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Aber es ging in diesem Thread natürlich nicht um Alternativen zu AVRs,
> sondern um GCC und deren Gebaren.

Was indirekt dann doch auch mit Alternativen zu tun hat. Wenn AVR im gcc 
ausstirbt (und clang nicht so schnell als vollwertiger Ersatz dienen 
kann), ist das auch für Hobbiisten ein weiterer Grund, auf ARM 
unzusteigen.

Oliver

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Die von dir genannten Alternativen sind aber im Vergleich zu AVR
> reichliche Exoten

Ich sehe da auch eher die mega0-serie bzw. tiny1 als Motivation.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Was indirekt dann doch auch mit Alternativen zu tun hat. Wenn AVR im gcc
> ausstirbt (und clang nicht so schnell als vollwertiger Ersatz dienen
> kann), ist das auch für Hobbiisten ein weiterer Grund, auf ARM
> unzusteigen.

Das AVR backend im LLVM  hat den experimentellen Status schon verloren 
und funktioniert ganz passabel. Bis gcc11 da ist ohne AVR hat LLVM-11 
oder 12 sicher da weiterhin aufgeholt.

Das lange lamentieren hier hilft eigentlich nur dem LLVM weiter auf die 
Sprünge zu helfen. Lasst es einfach aussterben: alles hat seine Zeit.

von Veit D. (devil-elec)


Bewertung
1 lesenswert
nicht lesenswert
Frank K. schrieb:
> Welche Motivation hast Du eigentlich, Dich so an AVR zu klammern?

Hallo,

die Antwort ist nicht kompliziert. Weil die 8Bitter übersichtlich zum 
programmieren sind und man sich nicht im Manual verliert. Ansonsten wie 
Wilhelm sagt. Die neue Mega0 und Tiny1 Serie wurden Registermäßig 
aufgeräumt und aufgebohrt. Benötigen in den meisten Fällen nur 1 bis 2 
Takte für einen Befehl. Damit machen die schon wieder Boden gut im 
Vergleich zu vermeintlich schnelleren und der I/O Port ist nicht 
entkoppelt vom Kerntakt.

20MHz oder 200MHz? Was schnell ist muss man erst definieren. Es muss 
ausreichend schnell sein für sein zu lösendes Problem. Für mich reicht 
das was die mit ihren 16/20MHz leisten.

Was ich dazu sagen muss zur besseren Einordnung meiner Aussage(n). Ich 
bin kein Entwickler der davon leben muss. Ich habe mich auf die AVR 8Bit 
Architektur eingeschossen.

von Benedikt M. (bmuessig)


Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:
> der aktuelle Stand vom Spendenkonto steht übrigens schon bei 1110,-
> Dollar. Die Hoffnung wächst. Vor kurzem waren es noch knapp über 300,-.

Ich habe gerade auch was zur Bounty dazugegeben.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Oliver S. schrieb:
>> Ganz blöd gefragt: wie kommt man an einen avr-clang?
>
> git clone
> cmake ...
> make -j 8

Nachdem sowohl die Windows- als auch die msys2-Version des 10er 
llvm/clang AVR für ein unknown triple halten, und selber compilieren in 
meiner Linux-VM an zu wenig Plattenplatz gescheitert ist (da waren „nur“ 
60GB frei, reicht leider nicht), bleibst da nicht mehr als bei der 
Hoffnung, daß das irgendwann einmal kommt.

Oliver

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Wilhelm M. schrieb:
>> Oliver S. schrieb:
>>> Ganz blöd gefragt: wie kommt man an einen avr-clang?
>>
>> git clone
>> cmake ...
>> make -j 8
>
> Nachdem sowohl die Windows- als auch die msys2-Version des 10er
> llvm/clang AVR für ein unknown triple halten, und selber compilieren in
> meiner Linux-VM an zu wenig Plattenplatz gescheitert ist (da waren „nur“
> 60GB frei, reicht leider nicht), bleibst da nicht mehr als bei der
> Hoffnung, daß das irgendwann einmal kommt.

Version 11 wird es beinhalten.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Die Targets:
llc --version
LLVM (http://llvm.org/):
LLVM version 11.0.0git
DEBUG build with assertions.
Default target: x86_64-unknown-linux-gnu
Host CPU: skylake

Registered Targets:
aarch64    - AArch64 (little endian)
aarch64_32 - AArch64 (little endian ILP32)
aarch64_be - AArch64 (big endian)
amdgcn     - AMD GCN GPUs
arm        - ARM
arm64      - ARM64 (little endian)
arm64_32   - ARM64 (little endian ILP32)
armeb      - ARM (big endian)
avr        - Atmel AVR Microcontroller
bpf        - BPF (host endian)
bpfeb      - BPF (big endian)
bpfel      - BPF (little endian)
hexagon    - Hexagon
lanai      - Lanai
mips       - MIPS (32-bit big endian)
mips64     - MIPS (64-bit big endian)
mips64el   - MIPS (64-bit little endian)
mipsel     - MIPS (32-bit little endian)
msp430     - MSP430 [experimental]
nvptx      - NVIDIA PTX 32-bit
nvptx64    - NVIDIA PTX 64-bit
ppc32      - PowerPC 32
ppc64      - PowerPC 64
ppc64le    - PowerPC 64 LE
r600       - AMD GPUs HD2XXX-HD6XXX
riscv32    - 32-bit RISC-V
riscv64    - 64-bit RISC-V
sparc      - Sparc
sparcel    - Sparc LE
sparcv9    - Sparc V9
systemz    - SystemZ
thumb      - Thumb
thumbeb    - Thumb (big endian)
wasm32     - WebAssembly 32-bit
wasm64     - WebAssembly 64-bit
x86        - 32-bit X86: Pentium-Pro and above
x86-64     - 64-bit X86: EM64T and AMD64
xcore      - XCore

von Malte _. (malte) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> selber compilieren in
> meiner Linux-VM an zu wenig Plattenplatz gescheitert ist (da waren „nur“
> 60GB frei, reicht leider nicht),

Weiß denn jemand wie viel Speicher benötigt wird? 60GB hätte ich in 
meinem /home jetzt auch nicht frei.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Malte _. schrieb:
> Oliver S. schrieb:
>> selber compilieren in
>> meiner Linux-VM an zu wenig Plattenplatz gescheitert ist (da waren „nur“
>> 60GB frei, reicht leider nicht),
>
> Weiß denn jemand wie viel Speicher benötigt wird? 60GB hätte ich in
> meinem /home jetzt auch nicht frei.

Bei mir sind es ca 80GB.

von J. W. (dilbert)


Bewertung
0 lesenswert
nicht lesenswert
Und 5-6 GB RAM, wenn ich mich nicht täusche.
Plus ungefähr einen Vormittag Zeit auf einem mobilen i5 der 8. 
Generation.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
J. W. schrieb:
> Und 5-6 GB RAM, wenn ich mich nicht täusche.

8Gb ohne Swappartition reichen nicht.

Oliver

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> J. W. schrieb:
>> Und 5-6 GB RAM, wenn ich mich nicht täusche.
>
> 8Gb ohne Swappartition reichen nicht.

Mein Kiste hat 64GB Ram und braucht 30-45min.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Was ist der LLVM denn für eine Bloatware?
(ernsthafte Frage)
Den GCC kann ich auf einer Linux VM mit 30GB HDD und 1GB RAM bauen o_O

von Μαtthias W. (matthias) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Was ist der LLVM denn für eine Bloatware?
> (ernsthafte Frage)
> Den GCC kann ich auf einer Linux VM mit 30GB HDD und 1GB RAM bauen o_O

Kann der GCC dann auch Code für alle von Wilhelm genannten Targets 
erzeugen? LLVM ist halt mehr als "nur" ein Compiler. Ich hab's nicht 
getestet aber kann gut sein das da auch so Sachen wie clangd, 
clang-format und clang-tidy dabei sind.

Oft sind die finalen Binaries auch nicht sooooo groß sondern nur die 
Zwischenprodukte. WIMRE braucht man zum übersetzen von Firefox zwingend 
einen Compiler/Linker der im 64 Bitmodus läuft auch wenn das exe nachher 
unter 100MB hat.

Matthias

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Μαtthias W. schrieb:
> Kann der GCC dann auch Code für alle von Wilhelm genannten Targets
> erzeugen?

Zumindest für den größten Teil (und wahrscheinlich einige Exoten mehr).

Wenn man versucht, ihn für "alle" Target zu compilieren, wird er 
vermutlich noch viel "bloatiger" (da man für jedes host-target-Tupel ein 
eigenes build directory braucht).

Allerdings ist das beim GCC nicht die primäre Philosophie, sondern man 
baut ihn für jeweils eins dieser Tupel.

: Bearbeitet durch Moderator
von Μαtthias W. (matthias) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Μαtthias W. schrieb:
>> Kann der GCC dann auch Code für alle von Wilhelm genannten Targets
>> erzeugen?
>
> Zumindest für den größten Teil (und wahrscheinlich einige Exoten mehr).
>
> Wenn man versucht, ihn für "alle" Target zu compilieren, wird er
> vermutlich noch viel "bloatiger" (da man für jedes host-target-Tupel ein
> eigenes build directory braucht).
>
> Allerdings ist das beim GCC nicht die primäre Philosophie, sondern man
> baut ihn für jeweils eins dieser Tupel.

Genau auf das wollte ich raus. clang kann das eben schon nach einem 
build auch wenn dann dort noch libc und libc++ für die einzelnen 
Architekturen fehlen dürften?

Matthias

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Was ist der LLVM denn für eine Bloatware?

Ich glaube, sowas fällt unter "moderne Softwareentwicklung".
Android ist auch so ein Monster.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Also LLVM baut immer für alle Targets?
Durchaus ein interessantes Konzept, aber bisher brauchte ich nur 
x86(_64), MIPS, ARM und AVR ;)

Was will man denn zB mit powerpc und sparc?
Das dürfte doch schon eher ne Nische sein.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Also LLVM baut immer für alle Targets?

Grundsätzlich ja, aber man kann natürlich auch beschränkte LLVMs bauen. 
Bringt nur wenig.

> Durchaus ein interessantes Konzept, aber bisher brauchte ich nur
> x86(_64), MIPS, ARM und AVR ;)

So geht es den meisten, die LLVM nur als Compiler benutzen, aber er 
lässt sich auch wunderbar als Bibliothek verwenden, z.B. als 
JIT-Compiler für bestimmte Bytecodes...

> Was will man denn zB mit powerpc und sparc?

...und dann braucht man diese Targets wieder, wenn das Programm auf 
diesen Architekturen lauffähig sein soll.

Der große Vorteil ist natürlich, dass der Großteil von LLVM 
architekturunabhängig ist (Frontend und Optimizier) und wenn man ein 
Monster-Binary baut, dann ist das mit allen Backends immernoch kleiner 
als fünf Kopien von Frontend und Optimizer rumzuschleppen.

> Das dürfte doch schon eher ne Nische sein.

Naja, ein Vorteil ist, dass man diese Nischen nicht vergisst, weil die 
immer "dabei" sind. Da freuen sich alle drüber, die damit arbeiten. In 
deinem Fall ist "AVR" so eine Nische...

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Was will man denn zB mit powerpc und sparc?
> Das dürfte doch schon eher ne Nische sein.

Naja, wenn man ein Rechencluster betreibt, dann dürfte man mit PowerPC 
oder SPARC weiter kommen als mit AVR aber ja, das sehe ich auch als 
Nische.

Mikrocontroller im Allgemeinen und AVR im speziellen sehe ich aber auch 
als Nische, auch wenn das aus Sicht dieses Forums vielleicht nicht so 
wahrgenommen wird. In der jeweiligen Nische nehmen dann die jeweiligen 
Architekturen wieder überproportional viel Platz ein, wie eben AVR im 
Embedded-Bereich, wo x86 wiederum eher ein "Nischendasein" fristet.

Wenn man einen Softwareentwickler für Netzwerkhardware fragt ob MIPS 
eine "Nische" darstellt, so wird er ganz sicher antworten, dass doch 
MIPS allgegenwärtig ist. Selbiges gilt für den Automotive-Softwarespezi 
mit seiner Power-Architektur oder eben für den Herr über den Cluster mit 
seinen SPARC-Prozessoren.

Ein sehr großer "Treiber" für die Erweiterung von LLVM auf weitere 
Targets dürfte die Verbreitung von Rust als Programmiersprache sein. 
Gerade im Embedded-Bereich sehe ich da große Stärken gegenüber 
Alternativen wie C/C++ (weil weniger fehleranfällig) oder Java/C#/Go 
(weil keine GC, keine VM notwendig, kompakte Binaries etc.).

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Mw E. schrieb:
>> Was will man denn zB mit powerpc und sparc?
>> Das dürfte doch schon eher ne Nische sein.
>
> Naja, wenn man ein Rechencluster betreibt, dann dürfte man mit PowerPC
> oder SPARC weiter kommen als mit AVR aber ja, das sehe ich auch als
> Nische.
>
> Mikrocontroller im Allgemeinen und AVR im speziellen sehe ich aber auch
> als Nische, auch wenn das aus Sicht dieses Forums vielleicht nicht so
> wahrgenommen wird. In der jeweiligen Nische nehmen dann die jeweiligen
> Architekturen wieder überproportional viel Platz ein, wie eben AVR im
> Embedded-Bereich, wo x86 wiederum eher ein "Nischendasein" fristet.
>
> Wenn man einen Softwareentwickler für Netzwerkhardware fragt ob MIPS
> eine "Nische" darstellt, so wird er ganz sicher antworten, dass doch
> MIPS allgegenwärtig ist. Selbiges gilt für den Automotive-Softwarespezi
> mit seiner Power-Architektur oder eben für den Herr über den Cluster mit
> seinen SPARC-Prozessoren.
>
> Ein sehr großer "Treiber" für die Erweiterung von LLVM auf weitere
> Targets dürfte die Verbreitung von Rust als Programmiersprache sein.
> Gerade im Embedded-Bereich sehe ich da große Stärken gegenüber
> Alternativen wie C/C++ (weil weniger fehleranfällig) oder Java/C#/Go
> (weil keine GC, keine VM notwendig, kompakte Binaries etc.).

Manchmal gibt es auf großen Servern laufende Software, die llvm als 
Compiler verwendet. Wenn man dann als HW-Hersteller nicht aus den 
Rechenzentren verschwinden will, dann muß man sich um ein llvm-Backend 
kümmern. Bei mindestens einem der genannten "Nischenprozessoren" war das 
so.

Und ob Fe2O3 da wirklich Einfluß hat, darf man bezweifeln.

von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
So richtig "8-bit-aware" scheint Clang (noch) nicht zu sein.

Einfaches Beispiel:

uint16_t shl8(uint16_t x) {
  return x << 8;
}

GCC 9.3.0 mit -O1, -O2, -O3 oder -Os:

shl8:
  mov r25,r24
  ldi r24,0
  ret

Clang 9.0.1 mit -O1, -O2, -O3 oder -Os:

shl8:
  lsl r24
  rol r25
  lsl r24
  rol r25
  lsl r24
  rol r25
  lsl r24
  rol r25
  lsl r24
  rol r25
  lsl r24
  rol r25
  lsl r24
  rol r25
  lsl r24
  rol r25
  ret

Neuere Clang-Versionen habe ich nicht ausprobiert. Gibt es da vielleicht
schon Fortschritte?

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Manchmal gibt es auf großen Servern laufende Software, die llvm als
> Compiler verwendet. Wenn man dann als HW-Hersteller nicht aus den
> Rechenzentren verschwinden will, dann muß man sich um ein llvm-Backend
> kümmern. Bei mindestens einem der genannten "Nischenprozessoren" war das
> so.
>
> Und ob Fe2O3 da wirklich Einfluß hat, darf man bezweifeln.

Das mit dem Einfluss von Rust war nicht auf SPARC, sondern auf AVR und 
MSP430 bezogen und in beiden Fällen bin ich mir relativ sicher, dass das 
ein treibender Faktor war.

Für AVR ist hier ein Blog-Artikel von einem der Hauptentwickler des 
llvm-avr backends:
https://dylanmckay.io/blog/rust/avr/llvm/2017/02/09/safer-microcontrollers-almost-here.html

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Für AVR ist hier ein Blog-Artikel [...]

Du hättest ja dazusagen können, dass
(a) der Artikel von 2017 ist;
(b) der einzige Artikel im gesamten Blog ist;
(c) keine aktuell relevante Information enthält.
Da steht halt drin, welche Patches man 2017 brauchte, um Rust und AVR zu 
machen. Mehr nicht.

von Malte _. (malte) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Du hättest ja dazusagen können, dass
> (a) der Artikel von 2017 ist;
> (b) der einzige Artikel im gesamten Blog ist;
> (c) keine aktuell relevante Information enthält.
> Da steht halt drin, welche Patches man 2017 brauchte, um Rust und AVR zu
> machen. Mehr nicht.
Ich fand es durchaus interessant. Weniger wegen den Patches, sondern um 
zu sehen warum jemand die Motivation hatte den AVR Support zu 
implementieren - und dass es scheinbar wieder ein einziger aus 
Eigeninteresse motivierter Entwickler war, keine größere Gruppe, den wir 
den Support zu verdanken haben.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Aufkllärung zum LLVM.

@Christopher
Mit Nische wollt ich jetzt nicht sagen, dass ppc und sparc so gut wie 
nicht mehr existieren.
Sondern, dass doch eher sehr wenige Compilerbenutzer einen für sparc/ppc 
brauchen.
ARM, x86 nutzen ja sehr viele und MIPS sollte durch PIC32 sowie das 
ganze Netzwerggerödel auchnoch gut vertreten sein.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Du hättest ja dazusagen können, dass
> (a) der Artikel von 2017 ist;

Der ist halt nicht aktuell, dafür aber "historisch wertvoll". A propos 
Historie: Es war eben auch dieser Dylan McKay, der im avr-llvm Repo den 
letzten Commit gemacht hat, bevor es in Mainline-LLVM gemerget wurde und 
sein letzter Commit im Mainline-LLVM ist jetzt 19 Tage her. Ich denke, 
das ist Beweis genug, dass der Kerl keine "Eintagsfliege" ist bzw. war.

von Christopher J. (christopher_j23)


Bewertung
1 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Clang 9.0.1 mit -O1, -O2, -O3 oder -Os:
>
> shl8:
>   lsl r24
>   rol r25
>   lsl r24
>   rol r25
>   lsl r24
>   rol r25
>   lsl r24
>   rol r25
>   lsl r24
>   rol r25
>   lsl r24
>   rol r25
>   lsl r24
>   rol r25
>   lsl r24
>   rol r25
>   ret
>
> Neuere Clang-Versionen habe ich nicht ausprobiert. Gibt es da vielleicht
> schon Fortschritte?

Gerade mit Clang 10.0.0 getestet (seit heute in den Arch-Repos). Leider 
exakt das gleiche Bild. Das dürfte man durchaus mal als Bug melden.

In LLVM-IR sieht die Funktion ja noch sehr kompakt aus.
define dso_local zeroext i16 @shl8(i16 zeroext %0) local_unnamed_addr addrspace(1) #0 {
  %2 = shl i16 %0, 8
  ret i16 %2
}

PS:
Wenn ich mir die ganzen "FIXME" hier anschaue, dann frag ich mich schon, 
wie eigentlich AVR-LLVM das "experimental"-Stadium verlassen konnte:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/AVR/AVRInstrInfo.td

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Das dürfte man durchaus mal als Bug melden.

Ja bitte machen: Dylan ist da ganz zugänglich ...

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Der ist halt nicht aktuell, dafür aber "historisch wertvoll".

Ich wollte nicht meckern, dass du den Link hingestellt hast.

Nur hatte ich irgendwie erwartet, dass ich aufs Blog gehe und da dann 
weiterführende Informationen finde (z.B. "was ist seit Version x.y 
passiert", "heute Bug xyzzy gefixt", was man halt so in Entwicklerblogs 
findet) und wurde jämmerlich enttäuscht. Darum mein Beitrag.

Ziemlich leere Blogs verschwinden meist klanglos wieder. Leider.

von Yalu X. (yalu) (Moderator)


Bewertung
5 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Das dürfte man durchaus mal als Bug melden.

Das ist ja kein Bug, sondern eine (noch) nicht implementierte
Optimierung. Als Bug würde ich das höchstens dann sehen, wenn die
Optimierung bereits implementiert wäre, aber aus irgendeinem Grund nicht
zur Anwendung käme.

Deswegen würde ich keinen Bug melden, sondern einen Feature-Request
stellen. Das kommt bei den Entwicklern positiver an als ein Bug-Report,
der implizit immer auch eine Prise Kritik enthält, die in diesem Fall
aber nicht angebracht ist.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich wollte nicht meckern, dass du den Link hingestellt hast.
>
> Nur hatte ich irgendwie erwartet, dass ich aufs Blog gehe und da dann
> weiterführende Informationen finde (z.B. "was ist seit Version x.y
> passiert", "heute Bug xyzzy gefixt", was man halt so in Entwicklerblogs
> findet) und wurde jämmerlich enttäuscht. Darum mein Beitrag.

Ok, ich werde versuchen in Zukunft "gehaltvollere" Artikel zu verlinken 
;)

Yalu X. schrieb:
> Das ist ja kein Bug, sondern eine (noch) nicht implementierte
> Optimierung.

Da hast du natürlich recht. Die Implementierung ist ja nicht kaputt, 
sondern lediglich "nicht optimal".

Wilhelm M. schrieb:
> Ja bitte machen: Dylan ist da ganz zugänglich ...

Ich würde es ein bisschen als "anmaßend" empfinden, wenn ich als einer 
der von AVR so gut wie keine Ahnung hat, da irgendwelche 
Feature-Requests oder Bug-Reports erstellt. Das überlasse ich lieber 
Leuten, die sich ein bisschen besser auskennen.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Ich würde es ein bisschen als "anmaßend" empfinden, wenn ich als einer
> der von AVR so gut wie keine Ahnung hat, da irgendwelche
> Feature-Requests oder Bug-Reports erstellt. Das überlasse ich lieber
> Leuten, die sich ein bisschen besser auskennen.

Yalu hats entdeckt, ihm gebührt die Ehre.

von Veit D. (devil-elec)


Bewertung
4 lesenswert
nicht lesenswert
Hallo,

Leute, Microchip das den Betrag um satte 5000,- Dollar erhöht. Aktueller 
Stand damit bei 7150,- Dollar. Hat scheinbar mein Anschreiben doch noch 
etwas umdenken bewirkt.  :-)

Der Betrag müßte ja nun für einen Entwickler ausreichend sein denke ich. 
Wie geht das nun weiter? Wartet man bis sich Einer meldet oder liegt 
schon einer auf der Lauer? Oder ...

PS: ich gehe davon aus das der Nickname vom Firmenname abgeleitet ist 
und sich niemand einen Spass erlaubt hat als großzügiger Spender, wie 
auch immer

: Bearbeitet durch User
von J. W. (dilbert)


Bewertung
0 lesenswert
nicht lesenswert
@Veit,

womit hast Du denen im Anschreiben gedroht? ;-)

von Veit D. (devil-elec)


Bewertung
1 lesenswert
nicht lesenswert
Mit Firma aufkaufen und filetieren.  :-)  :-)

Unter anderem hatte ich denen versucht klar zu machen, dass sie sich 
scheinbar nicht vorstellen können wieviel Leute ihre Controller mit C++ 
programmieren und das davon jeder profitiert. Scheinbar hat die 
Supportabteilung die 'Info' nach oben weitergereicht. Nehme ich jetzt 
einmal an. Ist aber jetzt auch egal. Ihre Reaktion war die Einzig 
Richtige. :-)

Ich merke auch gerade das im obigen Text das Erste 'das' eigentlich 
'hat' lauten soll.  :-)

Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.