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
:
Bearbeitet durch User
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
Johannes F. schrieb: > Das man hier und da auch größere Umbauten Umbauen ist was anderes als Wegschmeissen.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
Die Situation entspannt sich dahin gehend, als dass das AVR-Beckend im LLVM nicht nicht mehr experimentell ist (und ganz gut funktioniert).
Ganz blöd gefragt: wie kommt man an einen avr-clang? Oliver
Oliver S. schrieb: > Ganz blöd gefragt: wie kommt man an einen avr-clang? git clone cmake ... make -j 8
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.
Hallo, ein User hat einen Link gepostet. https://llvm.org/docs/ReleaseNotes.html#changes-to-the-avr-target
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.
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"
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.
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?
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.
1 | __attribute__ ((interrupt(PORT1_VECTOR))) |
2 | void port1(void) { ... } |
ist, wäre bei Clang
1 | #pragma vector=PORT1_VECTOR
|
2 | __interrupt void port1(void) { ... } |
oder so ähnlich...
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.
Danke für den Hinweis. Es ist schon länger hin, dass ich mich damit beschäftigt hatte.
Noch jemand, der sich über GCC ärgert: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140546.html
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
Die Targets:
1 | llc --version |
2 | LLVM (http://llvm.org/): |
3 | LLVM version 11.0.0git |
4 | DEBUG build with assertions. |
5 | Default target: x86_64-unknown-linux-gnu |
6 | Host CPU: skylake |
7 | |
8 | Registered Targets: |
9 | aarch64 - AArch64 (little endian) |
10 | aarch64_32 - AArch64 (little endian ILP32) |
11 | aarch64_be - AArch64 (big endian) |
12 | amdgcn - AMD GCN GPUs |
13 | arm - ARM |
14 | arm64 - ARM64 (little endian) |
15 | arm64_32 - ARM64 (little endian ILP32) |
16 | armeb - ARM (big endian) |
17 | avr - Atmel AVR Microcontroller |
18 | bpf - BPF (host endian) |
19 | bpfeb - BPF (big endian) |
20 | bpfel - BPF (little endian) |
21 | hexagon - Hexagon |
22 | lanai - Lanai |
23 | mips - MIPS (32-bit big endian) |
24 | mips64 - MIPS (64-bit big endian) |
25 | mips64el - MIPS (64-bit little endian) |
26 | mipsel - MIPS (32-bit little endian) |
27 | msp430 - MSP430 [experimental] |
28 | nvptx - NVIDIA PTX 32-bit |
29 | nvptx64 - NVIDIA PTX 64-bit |
30 | ppc32 - PowerPC 32 |
31 | ppc64 - PowerPC 64 |
32 | ppc64le - PowerPC 64 LE |
33 | r600 - AMD GPUs HD2XXX-HD6XXX |
34 | riscv32 - 32-bit RISC-V |
35 | riscv64 - 64-bit RISC-V |
36 | sparc - Sparc |
37 | sparcel - Sparc LE |
38 | sparcv9 - Sparc V9 |
39 | systemz - SystemZ |
40 | thumb - Thumb |
41 | thumbeb - Thumb (big endian) |
42 | wasm32 - WebAssembly 32-bit |
43 | wasm64 - WebAssembly 64-bit |
44 | x86 - 32-bit X86: Pentium-Pro and above |
45 | x86-64 - 64-bit X86: EM64T and AMD64 |
46 | xcore - XCore |
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.
Und 5-6 GB RAM, wenn ich mich nicht täusche. Plus ungefähr einen Vormittag Zeit auf einem mobilen i5 der 8. Generation.
J. W. schrieb: > Und 5-6 GB RAM, wenn ich mich nicht täusche. 8Gb ohne Swappartition reichen nicht. Oliver
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.
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
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
Μα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
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.
So richtig "8-bit-aware" scheint Clang (noch) nicht zu sein. Einfaches Beispiel:
1 | uint16_t shl8(uint16_t x) { |
2 | return x << 8; |
3 | }
|
GCC 9.3.0 mit -O1, -O2, -O3 oder -Os:
1 | shl8: |
2 | mov r25,r24 |
3 | ldi r24,0 |
4 | ret |
Clang 9.0.1 mit -O1, -O2, -O3 oder -Os:
1 | shl8: |
2 | lsl r24 |
3 | rol r25 |
4 | lsl r24 |
5 | rol r25 |
6 | lsl r24 |
7 | rol r25 |
8 | lsl r24 |
9 | rol r25 |
10 | lsl r24 |
11 | rol r25 |
12 | lsl r24 |
13 | rol r25 |
14 | lsl r24 |
15 | rol r25 |
16 | lsl r24 |
17 | rol r25 |
18 | ret |
Neuere Clang-Versionen habe ich nicht ausprobiert. Gibt es da vielleicht schon Fortschritte?
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.
1 | define dso_local zeroext i16 @shl8(i16 zeroext %0) local_unnamed_addr addrspace(1) #0 {
|
2 | %2 = shl i16 %0, 8 |
3 | ret i16 %2 |
4 | } |
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
Christopher J. schrieb: > Das dürfte man durchaus mal als Bug melden. Ja bitte machen: Dylan ist da ganz zugänglich ...
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
:
Bearbeitet durch User
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-Options https://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.
:
Bearbeitet durch User
Malte _. schrieb: > https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/AVR-Options.html#AVR-Options > https://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) :) Praktisch wertlos und unbenutzbar weil noch niemand die Patches in die avr-libc eingebaut hat.
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.
Irgendwelche weiteren Untergangsszenarien? Oder ist alles gut?
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.
Hallo, du kannst die Toolchain von Zak Kemble nehmen oder ich gebe dir meine oder ...
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 abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.