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.
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
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
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.
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.
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
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...
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.
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.
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?
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
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
1
#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.
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.
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...
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.
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.
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.
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.
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.
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?
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?
> 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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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
Μα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.
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
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.
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.
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...
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.).
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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. :-)
Danke für die Info.
Ich habe aber nicht herausgefunden, wie es jetzt zur Implementierung
kam. Also beispielsweise ob das Fundraising da jetzt einen Ausschlag
gegeben hat.
Beim GCC findet man auch die Optionen (Google hielt die Seiten bei
meinen Suchbegriffen nicht für relevant genug):
https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/AVR-Options.html#AVR-Optionshttps://gcc.gnu.org/install/configure.html#avr
Demnach gibt schon seit GCC 10 die Möglichkeit double als 64 Bit Werte
zu verwenden (war mir neu) :) (Ja das wird auf einem AVR langsam sein,
aber bei manchen Anwendungen spielt die Präzision eine Rolle und die
Geschwindigkeit ist Nebensache).
Malte _. schrieb:> Ich habe aber nicht herausgefunden, wie es jetzt zur Implementierung> kam. Also beispielsweise ob das Fundraising da jetzt einen Ausschlag> gegeben hat.
Mich würde das auch interessieren. Das ist doch jetzt schon die dritte
Implementierung, oder?
Vor allem liest sich dieser Maillist-Eintrag sehr bescheiden: Zu den
ohnehin deutlich schlechteren Ergebnissen der letzten Versionen gibt es
nun nochmals bis zu 3% mehr Verschlechterung - wenn das kein Fortschritt
ist...
Hallo,
wie das mit der Auszahlung ablief davon habe ich keine Ahnung. Die 3
größten Spender sollen ja Einfluss gehabt haben. Das die mich nicht
fragen war mir ja klar. ;-)
Ob die Spendensammlung ausschlaggebend war? Auch hier kann ich nur
mutmaßen. Ich denke schon. Außer irgendjemand von den Profis benötigt
avr-gcc so dringend auch in Zukunft das er es für nass gemacht hätte.
Ich weiß es ehrlich gesagt nicht. Der Reiz des Geldes wird wohl schon
welche angesprochen haben. Ich hoffe nur das sie ihr Bestens getan
haben.
Damit sind wir beim 3. Punkt. Ich hatte ehrlich gesagt mit der Aktion
gehofft bzw. bin davon ausgegangen das damit auch alle Altlasten
entsorgt werden die den kompilierten Code haben anwachsen lassen. Sieht
wohl nicht danach aus. Allerdings können die Leute immer noch daran
feilen. Wir werden sehen.
Wegen double64. Ja das hast du Johann L. hier aus dem Forum zu
verdanken.
Veit D. schrieb:> Damit sind wir beim 3. Punkt. Ich hatte ehrlich gesagt mit der Aktion> gehofft bzw. bin davon ausgegangen das damit auch alle Altlasten> entsorgt werden die den kompilierten Code haben anwachsen lassen. Sieht> wohl nicht danach aus.
Das wichtigste ist, daß jetzt weitere Arbeiten daran eine Zukunft haben.
Bisher wäre da jeder Aufwand, wie Johan ja auch angemerkt hat, beim
nächsten Releasewechsel für die Tonne gewesen.
Oliver
Hallo,
sehe ich jetzt auch so. Erstmal abwarten bis gcc 11 rauskommt und dann
schauen wir was insgesamt für avr dabei rumkam. Bis dahin kann noch viel
passieren.
Lars R. schrieb:> 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...
Johann hat etwas beigetragen und geleistet. Du nicht. :-)
Johannes F. schrieb:> 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.
99,9 Prozent der Leute, die mir bislang über den Weg gelaufen sind und
über CAP geredet haben, haben es nicht einmal ansatzweise verstanden.
;-)
Sheeva P. schrieb:> Johann hat etwas beigetragen und geleistet. Du nicht. :-)
???
Hast du überhaupt den Beitrag gelesen? Offenbar nicht, denn sonst
würdest du das nicht schreiben. Es ging darum, dass Johann Kritik geübt
hatte und dafür von anderen kritisiert wurde - obwohl er geleistet
hat. Das habe ich angeprangert.
Wenn man deinen Satz so liest, könnte man meinen, dass ich Johann
kritisiert hätte...
Wilhelm M. schrieb:> Ich denke nicht: zwar stelle ich ein gewissen "Atmen" der Codegrößen> fest, also mal kleiner, mal größer, aber ein genereller Trend zu größer> kann ich nicht bestätigen. Gefühlt wird es eher kleiner.
Das kann ich bestätigen.
Veit D. schrieb:> Ü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.
Bei beiden Arduino Umgebungen entsteht bei mir beim compilieren hex-Code
der gleich groß ist. Wo soll es da ein Problem geben?
Hallo,
@ Jens G.
dein Zitat und deine Antwort passen irgendwie nicht zusammen. Ich hatte
bezüglich der Pro IDE doch nur eine Feststellung beschrieben.
Wilhelm M. schrieb:> In gcc-12 ist das backend noch drin.
Was sollte sich hierbei ändern?
Feststellung: Die neue "Arduino Pro IDE" und die alte "Arduino IDE"
verwendet den gleichen Compiler.
Sorry: Bei mir ist der Eindruck entstanden, das es da Unterschiede gibt.
GCC 11.2 compiliert zumindest anstandslos AVR-Code, mit vergleichbarer
Codeeffizienz wie frühere Versionen. (Habe allerdings jetzt nur ein oder
zwei Beispiele hier verglichen.)
Jörg W. schrieb:> GCC 11.2 compiliert zumindest anstandslos AVR-Code
Gibt es irgendwo aktuelle Binaries mit LTO-Support? Dann würde ich es
mir auch einmal anschauen.
Lars R. schrieb:> Gibt es irgendwo aktuelle Binaries mit LTO-Support?
Für Windows? Keine Ahnung, sorry.
Ich baue mir den Compiler eh seit Jahren selbst. ;-) (Eigentlich schon
seit Jahrzehnten.)
Jörg W. schrieb:> GCC 11.2 compiliert zumindest anstandslos AVR-Code, mit> vergleichbarer> Codeeffizienz wie frühere Versionen.
Ist denn überhaupt bestätigt, daß der das neue backend nutzt, oder läuft
da doch noch das alte?
Oliver
Lars R. schrieb:> Gibt es irgendwo aktuelle Binaries mit LTO-Support? Dann würde ich es> mir auch einmal anschauen.
Man muss nur das Flag -flto aktivieren.
Veit D. schrieb:> Man muss nur das Flag -flto aktivieren.
Schon klar, aber LTO muss beim Buildvorgang des Compilers aktiviert
werden bzw. nicht deaktiviert worden sein.
Ich habe schon einige Jahre keine Umgebung mehr um selbst den avr-gcc zu
bauen. Nach avr-gcc 4.6.2 war ich ausgestiegen und nutze diesen bis
heute für die wenigen Projekte, bei denen ich einen avr-gcc benötige.
Lars R. schrieb:> Schon klar, aber LTO muss beim Buildvorgang des Compilers aktiviert> werden bzw. nicht deaktiviert worden sein.
Was eigentlich alle verfügbaren vorkompilierten avr-gcc toolchains
erfüllen.
Oliver
Thread beobachten
Seitenaufteilung abschalten