https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-Dropping-CC0
Johann hat die Gründe dafür u.a. vor ca. 2 Jahren erläutert: Beitrag "Re: newlib fuer AVR?" Er hat davor angekündigt, seinen Support für das AVR backend einzustellen, u.a. auch hier auf µc.net, mit Begründung. Leider finde ich den Beitrag nicht mehr.
Spielt das eine Rolle? Die Binaries werden bei gleichem Code seit der 4.9.2 eigentlich immer größer. Ich habe immer mal neue Versionen getestet, zuletzt die 8.3.0, aber bin immer wieder zurück gegangen.
Gustav schrieb: > Spielt das eine Rolle? Nö. Ich benutze noch den WINAVR. Der kann alles, was ich brauche und hat mir bisher auch noch keine Bugs eingebaut.
Gustav schrieb: > Spielt das eine Rolle? Die Binaries werden bei gleichem Code seit der > 4.9.2 eigentlich immer größer. Stimmt das überhaupt? Eine Tabelle wäre dazu geeignet mich zu überzeugen.
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.
dragon schrieb: > gcc11 könnte das avr Backend verlieren Klingt so als ob ich bald keinen Code mehr für einen AVR erzeugen könnte/dürfte. Ich glaub ich bring mich um. Zwanzigster Stock vom Hochhaus ist vermutlich ideal ....
Ver Zweifelter schrieb: > Zwanzigster Stock vom Hochhaus ist vermutlich ideal .... MicroChip wird vermutlich ein Sprungtuch spannen.
Hängt natürlich sehr vom Code ab. Aber bei umfangreichen Projekten zumindest bei mir ist die Codegröße beim 4.9.2 immernoch am kleinsten. Und gerade da stört es ja. Wenn man auf einem ATMega168 (Bootloader vorhanden; Code wurde schon extrem optimiert) bei 15358 Bytes ist und es muss noch eine Funktion rein und der 4.9.2 schafft einem 400 Byte Platz, ist das Gold wert. Es gibt noch eine ganze Reihe von Optimierungsparametern, welche helfen (und auch individuell unterschiedlich sind). Die kann man auch durchprobieren. Aber auch der 4.9.2 hat welche und am Ende war der immer besser als ein 5er, 6er oder 8er gcc. Leider. Ich hätte ja auch gerne noch kleineren Code. ;)
Gustav schrieb: > Es gibt noch eine ganze Reihe von Optimierungsparametern, welche helfen > (und auch individuell unterschiedlich sind). Die kann man auch > durchprobieren. Aber auch der 4.9.2 hat welche und am Ende war der immer > besser als ein 5er, 6er oder 8er gcc. Leider. Ich hätte ja auch gerne > noch kleineren Code. ;) Der wesentliche Faktor ist dabei natürlich Dein C/C++-Code ...
FYI, the avr backend of GCC (avr-gcc, avr-g++) has been deprecated for v10, release schedule spring 2020. If the backend is not re-written to use a different scheme to model condition-code, it will be removed from GCC in v11, release schedule spring 2021. https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
Ziemlich traurig, dass es Atmel nicht geschafft hat wenigstens einen einzigen Entwickler einzustellen, der am AVR-Backend arbeitet. Soweit hätte es nicht kommen müssen... Aber gut AVR ist eh auf dem absteigenden Ast, für mich persönlich habe ich erst letztes Jahr entschieden keine Hobbyprojekte mehr mit dem AVR anzufangen, weil ich mit einem typischen ARM Cortex M0+/M3/M4/M7 schneller ans Ziel komme. War aber trotzdem eine schöne 8Bit-Architektur.
Jemand müsste die ganzen rein AVR-optimierenden Verbesserungen, die im neuesten GCC existieren, für den 4.9.2 zurück portieren. ;)
TriHexagon schrieb: > Aber gut AVR ist eh auf dem absteigenden Ast, für mich persönlich habe > ich erst letztes Jahr entschieden keine Hobbyprojekte mehr mit dem AVR > anzufangen, ... Damit treibst du Microchip/Atmel in den Kokurs. Die sind auf deine Hobbyprojekte angewiesen. Kannst du das vor deinem Gewissen verantworten?
Ist schon schade. Andererseits arbeitet ja nicht nur der GCC recht intesiv an seiner eigenen Abschaffung. Firefox und selbst Linux (systemd) tun ja auch in letzter Zeit alles Menschnmögliche, um potentielle Nutzer und Entwickler möglichst langfristig zu vergraulen. Hatte Atmel zuletzt eigentlich für AVR mal einen (eigenen) C-Compiler im Portfolio? WIMRE haben die doch immer vom avr-gcc gelebt.
Sven P. schrieb: > WIMRE haben die doch immer vom avr-gcc gelebt. Nein. Sie haben den GCC viele Jahre lang reichlich ignoriert. Es war damals Eric Weddingtons Verdient, mit WinAVR ein brauchbares Package zu schaffen, damit auch Windows-Nutzer vom AVR-GCC aufwandsarm profitieren konnten (die Nutzer unixoider Systeme konnten das auch davor schon). Erst ab dem Moment (und dem Aufstieg von Arduino) rückte der GCC bei Atmel allmählich ins Blickfeld. Davor haben sie jahrelang voll auf ihre Kooperation mit IAR gesetzt.
Jörg W. schrieb: > Sven P. schrieb: >> WIMRE haben die doch immer vom avr-gcc gelebt. > > Nein. Sie haben den GCC viele Jahre lang reichlich ignoriert. Es war > damals Eric Weddingtons Verdient, [...] > > Davor haben sie jahrelang voll auf ihre Kooperation mit IAR gesetzt. Ahh, das meinte ich. IAR hab ich wohl ganz verdrängt.
> Kooperation mit IAR
Mit IAR macht man ja auch nichts falsch.
pumuggl schrieb: >> Kooperation mit IAR > > Mit IAR macht man ja auch nichts falsch. Nur daß der gemeine Bastler den Preis für den Comiler nicht zahlen will/kann. Was kostet der aktuell?
pumuggl schrieb: > Mit IAR macht man ja auch nichts falsch. Ich arbeite auf Arbeit mit dem IAR und halte das Ding für den größten Dreck überhaupt. Es ist echt krass, dass dies geschafft haben von v7 auf v8 noch schlechter zu werden.
Ich mache mir da keine allzu großen Sorgen: Erstens hat der derzeitige AVR-GCC keinen Selbstzerstörungsmechanismus eingebaut, und der Verschleiß von Software hält sich i.Allg. auch in Grenzen. Wenn man seinen GCC also gut behandelt, wird er auch in 10 oder 20 Jahren noch treu seinen Dienst tun. Zweitens wird derzeit an einem AVR-Backend für LLVM gebaut. Vielleicht wird es ja rechtzeitig bis Mai 2021 fertig. Und falls alle Stricke reißen: Die GNU Binutils werden den AVR sicher bis an sein Lebensende (und noch länger) unterstützen, so dass man immer die Möglichkeit hat, den verzuckerten Assembler¹ durch unverzuckerten zu ersetzen (die Ärzte warnen ja sowieso vor zu viel Zucker) ;-) Und für die Schleckermäuler, die auf den Zucker nicht verzichten wollen (ich selber gehöre auch dazu): Es gibt neben dem AVR weitere günstige Mikrocontroller, die auch von GCC 11+ unterstützt werden. —————————— ¹) das ist C, nach Aussage von Niklaus Wirth :)
Mw E. schrieb: > Ich arbeite auf Arbeit mit dem IAR und halte das Ding für den größten > Dreck überhaupt. Verwechsle bitte nicht den Compiler mit der IDE. Wir vergleichen schließlich hier mit GCC, nicht mit Eclipse, Arduino-IDE, Atmel Studio oder dergleichen. Den Compiler von IAR fand ich zu der Zeit, als ich ihn hin und wieder benutzt habe, wirklich gut. Das Einzige, was ich am GCC-Port Mist fand ist, dass er nur deren blödes proprietäres Binärformat unterstützt hat, obwohl sie ansonsten für viele andere Targets ELF in der Tasche haben und auch hätten den AVR-Teil auf ELF setzen können. Dann gäbe es plötzlich wieder viel mehr Ökosystem. Das zweite, was natürlich an IAR Mist ist, dass sie, obwohl der reine Compiler als Kommandozeilenprogramm ja nun so gut wie keine OS-Abhängigkeit hat, ihn immer nur für Windows gebaut haben. Ein Linux-Binary wäre mir dazumals deutlich lieber gewesen. Aber inzwischen habe ich ihn schon eine ganze Weile nicht mehr benutzen müssen. Falk B. schrieb: > Nur daß der gemeine Bastler den Preis für den Comiler nicht zahlen > will/kann. Selbst in der Industrie ist der Preis durchaus ein Punkt. Als ich damals bei Atmel war, kam mir mal eine Support-Anfrage eines FAE rein, dessen (deutsche, große) Kunden von IAR auf GCC umstellen wollten: sie wollten eine große Build-Farm für nightly builds aufbauen (was man heute wohl so "Continuous Integration" nennen würde), und die wäre mit IAR schlicht nicht finanzierbar gewesen.
> IAR und halte das Ding für den größten Dreck überhaupt. Auch wenn man es ostinat wiederholt wird es nicht wahrer. Funfact: Eine Software mit überwiegendem Anteil an Gleitkommarechnung (ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als mit MDK/Keil oder GCC. Und ja, die entsprechenden Schalter sind bei allen Compilern an. Aber du darfst das ja gerne weiterhin als Dreck bezeichnen. LED-Blinker profitieren eben eher nicht vom IAR-Compiler.
pumuggl schrieb: >> IAR und halte das Ding für den größten Dreck überhaupt. > > Auch wenn man es ostinat wiederholt wird es nicht wahrer. > > Funfact: > Eine Software mit überwiegendem Anteil an Gleitkommarechnung > (ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als > mit MDK/Keil oder GCC. Bench or GTFO.
Jörg W. schrieb: > Verwechsle bitte nicht den Compiler mit der IDE. Wir vergleichen > schließlich hier mit GCC, nicht mit Eclipse, Arduino-IDE, Atmel Studio > oder dergleichen. Nunja, das ist ein System. Bei Arduino redet man ja auch nicht nur von den Platinen. Zum IAR gehört nunmal einiges dazu. Den Debugger will man ja auch nutzen? Inzwischen schaffts der IAR sogar, dass die Breakpoints verrutschen beim hinzufügen von Codezeilen. Aber der Compiler selbst ist auch verbuggt. Bei einem großen mbedTLS struct hat er andere Adressen ausgerechnet beim Zugriff über . und -> Da sah aus als hätt der da ein alignment vergeigt. ssl_p ist der Pointer mit Zugriff über -> und sslvars direkt das struct mit Zugriff über . Die Adressen sind anders... Dementsprechend hat der TLS Stack nicht funktioniert. (Siehe Anhang) Den Support kannste in der Pfeife rauchen, der wurde zu einem humanen RSS Feed, aber in den Changelogs tauchte nie was auf was das Problem anging. Während der embeddet war der Support nicht erreichbar und wir brauchten ein Plugin für nen neuren SoC für den v7. Also ja, der IAR IST! scheisse. pumuggl schrieb: > Auch wenn man es ostinat wiederholt wird es nicht wahrer. Sagt der IAR Mitarbeiter ;) ? So oft wie du das hier einstreust kann ichs mir nicht wirklich anders vorstellen. Fix mal lieber den Bug im Anhang. Vincent H. schrieb: > pumuggl schrieb: >>> IAR und halte das Ding für den größten Dreck überhaupt. >> >> Auch wenn man es ostinat wiederholt wird es nicht wahrer. >> >> Funfact: >> Eine Software mit überwiegendem Anteil an Gleitkommarechnung >> (ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als >> mit MDK/Keil oder GCC. > > Bench or GTFO. DITO
Mw E. schrieb: > Jörg W. schrieb: >> Verwechsle bitte nicht den Compiler mit der IDE. Wir vergleichen >> schließlich hier mit GCC, nicht mit Eclipse, Arduino-IDE, Atmel Studio >> oder dergleichen. > > Nunja, das ist ein System. Sehe ich nicht so. Du kannst den IAR-Compiler komplett auf der Kommandozeile benutzen (den ganzen Lizenzsalat musst du natürlich laufen haben). Haben wir jahrelang gemacht. > Den Debugger will man ja auch nutzen? Das ist der Punkt mit dem für AVR nicht unterstützten ELF-Format: würden sie ELF als Objektformat auch bei AVR unterstützen, wäre man nicht auf deren Debugger angewiesen, sondern könnte jeden anderen Debugger (einschließlich Atmel Studio) ebenfalls nehmen.
Für m68k wird gerade Geld gesammelt, um jemand für die cc0 -> cc_mode Taransition anzuheuern :-/ http://gcc.gnu.org/ml/gcc/2019-10/msg00132.html
Hallo, sagt mal Leute könnt ihr alle nicht lesen? Wo steht hier das AVR komplett aus dem Support rausfliegt? https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-Dropping-CC0 Es geht erstens um alte µC wie der 68000 (Amiga und Atari Generation) und paar andere sehr alte Teile die bestimmt schon lange nicht mehr produziert werden. Also erzählt bitte keinen Mist. Jörg W., irgendwie solltest du das doch besser wissen wenn du in der Materie tiefer drin steckst als Entwickler. Ich vergleiche das mit der Linuxkernelentwicklung. Hornalte Hardware fliegt irgendwann raus. Es muss dann ein Entwickler geben der sich um die betagten Teile kümmert oder die Community. Also bitte nicht immer gleich absolute Weltuntergangspanik verbreiten. Edit: Jörg und Johann könnten ja einmal bitte auflisten welche alten AVR µC das betrifft damit die Leute hier wieder beruhigt schlafen können. :-)
:
Bearbeitet durch User
Veit D. schrieb: > Wo steht hier das AVR komplett aus dem Support rausfliegt? Er fliegt aus der weiteren Entwicklung raus, nicht mehr, aber auch nicht weniger. Johann hat die Gründe bereits dargelegt. Wie Yalu schon nannte, deshalb verrottet der alte (Compiler-)Code nicht. Es gibt ja einige Leute (auch hier im Thread), die mit mittlerweile sehr betagten Compilerversionen durchaus sehr zufrieden sind. Andererseits, von neueren Entwicklungen (wie Johanns Arbeiten für 64-bit-Gleitkomma) ist man eben mit alten, "abgehangenen" Versionen abgekoppelt. Irgendwann werden auch die Compilerversionen, für die man überhaupt noch Patches anbringen darf oder Bugs melden, dann end of life sein. Dann kann man entweder mit dem leben, was existiert, oder es braucht eine andere Plattform (LLVM …).
Hallo, muss nochmal nachfragen. Ich lese in dem Link nichts davon das der gesamte AVR Support rausfliegt. Ich lese das nur alte Targets, also alte µC rausfliegen. Reden wir aneinander vorbei oder verstehe ich das falsch oder ist der Artikel unvollständig?
Veit D. schrieb: > Ich lese in dem Link nichts davon das der gesamte AVR Support > rausfliegt. Dann lies doch einfach mal Johanns Erläuterungen, die im zweiten Beitrag verlinkt worden sind.
Hallo, ich möchte ja nicht meckern. Aber Johanns Beitrag/der Thread ist von 2017. Seitdem wird viel passiert sein. Und Atmel hat viele AVR Controller Familien und nicht nur Eine. Ich kann nicht glauben das Gesamt AVR aus dem GCC rausfliegt. Warum auch. Die werden doch in Millionen von Geräten eingebaut und es gibt unzählige Programmierer die das alles tagtäglich nutzen. Also entweder bin ich total bekloppt und verstehe absolut nichts oder hier gibt es ein riesengroßes Missverständnis.
Hallo, ich glaube ich habe das doch missverstanden. Habe das hier inkl. Link https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html gelesen und glaube jetzt besser zu verstehen um was geht. Es geht nicht darum alte µC rauszuwerfen sondern das gesamte AVR Grundgerüst ist hoffnungslos veraltet und müsste auf den neuesten Stand gebracht werden. Das wäre natürlich Schade wenn das versauern würde. Großes Entschuldigung für mein Missverständnis!!! Auf der anderen Seite folgt daraus die Frage wäre es so schlimm wenn es nicht mehr der GCC wäre den wir dann irgendwann nutzen? Für mich als Anwender der ja nur an der Oberfläche kratzt vom gesamten Toolchain Softwarepaket wenn ich C/C++ programmiere, spielt es doch im Grunde keine Rolle was da unten drunter ackert und compliert. Hauptsache C ist C und C++ ist C++. Oder fällt damit auch unser C/C++ hinten runter? Wenn ja würde ich mir vielleicht überlegen zu spenden. Wobei daran eigentlich ganze Firmen ein Interesse haben sollten.
Richtig verstanden. Das Problem ist, dass damit für AVR auch keine neuen gcc Compilerversionen mehr geben wird. Im Backend ist das anscheinend weniger ein Problem, aber das gemeinsame Frontend (von dem alle Prozessorarchitekturen profitieren) wird dadurch dann auch nicht mehr aktualisiert. Das betrifft dann sowohl Bugfixes als auch neue Features (z.B. C++23 und C2x Unterstützung). Dadurch entfällt natürlich auch jeglicher traditioneller gcc Support für AVR. Langfristig wird man dadurch auch inkompatible Libraries haben, die einfach einen moderneren Compiler voraussetzen die damit auf AVR nicht mehr nutzbar sind. Wie relevant das für einen ist, ist letztlich sehr individuell. Für mich persönlich ist das ein absolutes Ausschlusskriterium für AVR, andere hier im Thread sind anscheinend auch mit dem mitlerweile antiken gcc 4.9 glücklich. Den gcc10 wird man natürlich unabhängig davon ganz normal weiter für AVR nutzen können.
Jörg W. schrieb: > (wie Johanns Arbeiten für 64-bit-Gleitkomma) Ab welcher Version ist denn das enthalten?
Mw E. schrieb: > Aber der Compiler selbst ist auch verbuggt. > Bei einem großen mbedTLS struct hat er andere Adressen ausgerechnet beim > Zugriff über . und -> > Da sah aus als hätt der da ein alignment vergeigt. > ssl_p ist der Pointer mit Zugriff über -> und sslvars direkt das struct > mit Zugriff über . > Die Adressen sind anders... > Dementsprechend hat der TLS Stack nicht funktioniert. > (Siehe Anhang) Moin, was war denn die Antwort von IAR bezüglich dieses Compiler Bugs?
Jörg W. schrieb: > Wie Yalu schon nannte, deshalb verrottet der alte (Compiler-)Code nicht. Oh doch, genau so verrottet Software, und zwar schneller als einem lieb ist. Zwei, drei Jahre ohne Support und Weiterentwicklung bedeuten den Tod für Software. Bei einem Compiler bedeutet das auch zwangsweise den Tod der Plattform. Ist ja auch logisch: Es kommt kein neuer Nutzer zu einer Plattform dazu, wenn er feststellt dass es keinen aktuellen Compiler gibt. Und die Altbenutzer suchen Alternativen für die sterbende Plattform. So beschäftigen sich immer weniger Menschen damit, und das Ding verschwindet in der Versenkung. Ein ganz normaler Prozess in der Software.
Experte schrieb: > Bei einem Compiler bedeutet das auch zwangsweise den > Tod der Plattform. > > Ist ja auch logisch: Es kommt kein neuer Nutzer zu einer Plattform dazu, > wenn er feststellt dass es keinen aktuellen Compiler gibt. Silabs baut heute noch 8051 und liefert mit deren IDE zusammen einen 30 Jahre alten Keil Compiler aus! Da kann man heute noch die Nostalgie von C89 genießen und man muss shiften und Bytes einzeln tauschen anstatt einfach durch ne Zweierpotenz zu dividieren und auch die ganzen anderen Tricks die man früher gelehrt hat um dem Compiler zu helfen muss man anwenden weil der Compiler so simple Optimierungen noch nicht auf die Reihe bekommt. Dennoch erfreut der BusyBee sich größter Beliebtheit weil er so konkurrenzlos billig ist, daß der Compiler 30 Jahre alt ist, damit dürfen sich dann die Entwickler rumschlagen nachdem ihre Bosse beschlossen haben diesen Chip zu verwenden, das spielte bei der Entscheidung keine Rolle. Über den Preis geht alles. Und genau da muss Microchip dran arbeiten, sonst will bald wirklich keiner mehr AVR kaufen, nicht etwa weil der Compiler alt ist (danach fragt niemand, ein passender Compiler ist im Atmelstudio immer automatisch enthalten, auch in 30 Jahren noch, wie alt der ist interessiert die Entscheider nicht) sondern das Preis/Leistung-Verhältnis der Hardware entscheidet das.
Experte schrieb: > Ist ja auch logisch: Es kommt kein neuer Nutzer zu einer Plattform dazu, > wenn er feststellt dass es keinen aktuellen Compiler gibt. Naja, wann war der mit AS7 ausgelieferte GCC denn mal wirklich aktuell? Microchip liefert immer noch GCC 5.4.0 aus. Der ist aber auch erst etwas über drei Jahre "alt". Und der ARM GCC 6 ist etwas über zwei Jahre "alt". Nur, was Major Releases angeht dreht man bei GCC sowieso seit GCC 5 viel stärker am Rad als je zuvor: https://gcc.gnu.org/develop.html Der XC8 Compiler von Microchip basiert für AVR übrigens auf dem GCC, schauen wir mal, ob aus der Richtung was kommt.
Peter D. schrieb: > Jörg W. schrieb: >> (wie Johanns Arbeiten für 64-bit-Gleitkomma) > > Ab welcher Version ist denn das enthalten? Hallo Peter, noch ist es nicht enthalten. Johann und andere arbeiten daran. Beitrag "64 Bit float Emulator in C, IEEE754 compatibel"
Experte schrieb: >> Wie Yalu schon nannte, deshalb verrottet der alte (Compiler-)Code nicht. > > Oh doch, genau so verrottet Software, und zwar schneller als einem lieb > ist. Zwei, drei Jahre ohne Support und Weiterentwicklung bedeuten den > Tod für Software. Das erzähle jetzt mal bitte denen, die hier bekundet haben, dass sie nach wie vor für AVR am liebsten GCC 4.9.2 benutzen. Der ist vor 5 Jahren herausgegeben worden. Ganz offensichtlich ist er alles andere als "tot".
Beruflich muss ich mit GCC 3.x.x arbeiten :) Allerdings nicht für AVR. Ist auch wurscht. Aber ausgeleierte Bits produziert der nicht ;)
Michael F. schrieb: > was war denn die Antwort von IAR bezüglich dieses Compiler Bugs? Das hatte ich wohl nicht genau genug beschrieben. Diesen Bug hab ich reported über den Emailsupport (wegen Screenshots und Codezeilen). Danach gabs erst ne Mail zurück, dass das Pointerproblem angepackt wird. Danach kamen nur mails zurück, dass eine neue Version raus ist. (was ich als human RSS Feed bezeichnet hatte) Aber in den Changelogs stand nie was über das Problem. Nach ein paar Iterationen hatte ich keine Lust mehr und habs per Workaround gelöst. Sehr geil war bei einer Neuinstallation auch die Lahmlegung meines Rechners durch das unendlich erstellen desselben Prozesses beim Installer. doinst ein Treiberinstaller, sehr oft gestartet vom IAR installer. (siehe Anhang) @Jörg W. Jagut, da haben wir andere Ansichten was da zusammengehört und was nicht.
Bernd K. schrieb: > Silabs baut heute noch 8051 und liefert mit deren IDE zusammen einen 30 > Jahre alten Keil Compiler aus! Da kann man heute noch die Nostalgie von > C89 genießen und man muss shiften und Bytes einzeln tauschen anstatt > einfach durch ne Zweierpotenz zu dividieren und auch die ganzen anderen > Tricks die man früher gelehrt hat um dem Compiler zu helfen muss man > anwenden weil der Compiler so simple Optimierungen noch nicht auf die > Reihe bekommt. Dennoch erfreut der BusyBee sich größter Beliebtheit weil > er so konkurrenzlos billig ist, daß der Compiler 30 Jahre alt ist, damit > dürfen sich dann die Entwickler rumschlagen nachdem ihre Bosse > beschlossen haben diesen Chip zu verwenden, das spielte bei der > Entscheidung keine Rolle. Es gibt ja noch andere Compiler für MCS-51. Wer SiLabs einsetzt, ist nicht auf Keil angewiesen.
900ss D. schrieb: > Beruflich muss ich mit GCC 3.x.x arbeiten :) Allerdings nicht für AVR. > Ist auch wurscht. Lass mich raten: Tricore für ASIL Anwendung?
Karl schrieb: > Lass mich raten SPARC V8 :) Es gibt auch neuere GCC dafür. Aber ich darf als OS RTEMS verwenden welches samt Toolchain genau in dieser Version vorgegeben ist. Aber der alte GCC tut seinen Dienst. Weshalb sollte er auch nicht. Kann die Bedenken da oben nicht verstehen. Klar kann man die "neuen Features" oder was auch immer nicht verwenden. Ist aber kein Drama.
:
Bearbeitet durch User
Was für Vorgaben. xD Musst du zusätzlich noch im ungeheizten Keller im Stehen programmieren oder so? ;)
> doinst ein Treiberinstaller, sehr oft gestartet vom IAR installer. Das wird wohl die Version fuer AVR gewesen sein? Solchen (Jungo-)Treibermurks kenne ich nur von Atmel. Da musste man das haendisch im Nachgang mit: wdreg.exe -inf windrvr6.inf install reparieren. Ein Headerproblem hatte ich mal fuer STM32L053. Aber die wurden, so wurde mir versichert, auch nur automagisch aus den SVF-Dateien von ST generiert. Und das Problem konnte ich natuerlich selber fixen.
Rudolph R. schrieb: > Nur, was Major Releases angeht dreht man bei GCC sowieso seit GCC 5 > viel stärker am Rad als je zuvor: Nö, in jedem Frühjahr gibt es eine neue Major Release wie eh und je. Einzig das Versionierungsschema wurde umgestellt. Peter D. schrieb: > Jörg W. schrieb: >> (wie Johanns Arbeiten für 64-bit-Gleitkomma) > > Ab welcher Version ist denn das enthalten? Zunächst müssen Hindernisse aus dem Weg geräumt werden, d.h. dass avr-gcc 64-Bit (long) double unterstützt. Das sind 2 Zeilen im Compiler und dann mehr als 400 Zeilen drumrum... https://gcc.gnu.org/PR92055 Und die avr-libc muss etwas dynamischer werden. Angefangen damit, dass Alias-Symbole für double nur dann definiert werden, wenn double=float ist. https://savannah.nongnu.org/bugs/?57071 Wann und wo welche double-Routinen hinzukommen ist auch noch nicht klar. Die obigen Patches enthalten keine einzige double-Funktion, ist alles nur Vorgeklimper.
Vincent H. schrieb: > pumuggl schrieb: >>> IAR und halte das Ding für den größten Dreck überhaupt. >> >> Auch wenn man es ostinat wiederholt wird es nicht wahrer. >> >> Funfact: >> Eine Software mit überwiegendem Anteil an Gleitkommarechnung >> (ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als >> mit MDK/Keil oder GCC. > > Bench or GTFO. Natürlich kommt da nix mehr vom pro IAR Troll. Die genannten fuckups kann er auch nicht entkräften. Larry schrieb: >> doinst ein Treiberinstaller, sehr oft gestartet vom IAR installer. > > Das wird wohl die Version fuer AVR gewesen sein? > Solchen (Jungo-)Treibermurks kenne ich nur von Atmel. > Da musste man das haendisch im Nachgang mit: > wdreg.exe -inf windrvr6.inf install reparieren. Der IAR installiert normalerweise u.a. was für Atmel ARMs (ist der ARM IAR), aber das hatte ich abgewählt. J-Link reicht ;) Der IAR Support meinte dann "ihre installation ist kaputt", NO SHIT SHERLOCK!
Gustav schrieb: > Hängt natürlich sehr vom Code ab. Aber bei umfangreichen Projekten > zumindest bei mir ist die Codegröße beim 4.9.2 immernoch am kleinsten. > Und gerade da stört es ja. Wenn man auf einem ATMega168 (Bootloader > vorhanden; Code wurde schon extrem optimiert) bei 15358 Bytes ist und es > muss noch eine Funktion rein und der 4.9.2 schafft einem 400 Byte Platz, > ist das Gold wert. > > Es gibt noch eine ganze Reihe von Optimierungsparametern, welche helfen > (und auch individuell unterschiedlich sind). Die kann man auch > durchprobieren. Aber auch der 4.9.2 hat welche und am Ende war der immer > besser als ein 5er, 6er oder 8er gcc. Leider. Ich hätte ja auch gerne > noch kleineren Code. ;) "Code wurde schon extrem optimiert" Völlig falscher Ansatz, da wurde wohl im Vorfeld das Projekt völlig falsch eingeschätzt und der falsche µC für die geforderte Aufgabe verwendet.
Das Projekt ist stetig gewachsen und begann in einer Zeit, als der Mega328 noch nicht erhältlich war. Der 168er reichte anfangs auch völlig, aber durch neue Features, Lokalisation, Dinge, die erst gar nicht geplant waren, wuchs es immer weiter, was nicht zuletzt an der guten Kundenresonanz lag. Irgendwann kommt man nunmal an eine Grenze. Wir gehören nicht zu den Firmen, die ihre alte Hardware vernachlässigen und bieten auch nach Jahren noch Updates an, sofern möglich. Ich persönlich finde es auch peinlich, wie Unterhaltungsgerätehersteller das heutzutage handhaben.
Gustav schrieb: > Das Projekt ist stetig gewachsen und begann in einer Zeit, als der > Mega328 noch nicht erhältlich war. Der 168er reichte anfangs auch > völlig, aber durch neue Features, Lokalisation, Dinge, die erst gar > nicht geplant waren, wuchs es immer weiter, was nicht zuletzt an der > guten Kundenresonanz lag. Irgendwann kommt man nunmal an eine Grenze. Ich hatte auch schon mal ein ähnliches Problem. Der Kunde wollte immer mehr, dann habe ich ihm ein Redesign verkauft. Wenn sich da der Aufwand in Grenzen hält (z.B. nur größeren µC vom gleichen Hersteller), dann ist das schlussendlich kostengünstiger und hat selbst als Entwickler wieder mehr Freiheiten um das Produkt noch besser hin zu bekommen.
Johann L. schrieb: > Peter D. schrieb: >> Jörg W. schrieb: >>> (wie Johanns Arbeiten für 64-bit-Gleitkomma) >> >> Ab welcher Version ist denn das enthalten? > > Zunächst müssen Hindernisse aus dem Weg geräumt werden, d.h. dass > avr-gcc 64-Bit (long) double unterstützt. Ist upstream, siehe https://gcc.gnu.org/install/configure.html#avr
Cool! Ich bau bei nächstbester Gelegenheit deinen Patch in die avr-libc ein.
Jörg W. schrieb: > Ich bau bei nächstbester Gelegenheit deinen Patch in die avr-libc ein. Hast du eine Idee, wo / wie man -print-multi-lib und -print-multi-directory in avr-libc unterstützen könnte?
:
Bearbeitet durch User
Jörg W. schrieb: > Cool! > > Ich bau bei nächstbester Gelegenheit deinen Patch in die avr-libc ein. Würdest du das kundtun wenn eingebaut damit ich eine neue Toolchain bauen kann? Falls du die Versionsnummer änderst sehe ich das auch. Danke euch Fleißmeisen.
Veit D. schrieb: > Jörg W. schrieb: >> Cool! >> >> Ich bau bei nächstbester Gelegenheit deinen Patch in die avr-libc ein. > > Würdest du das kundtun wenn eingebaut damit ich eine neue Toolchain > bauen kann? Falls du die Versionsnummer änderst sehe ich das auch. Danke > euch Fleißmeisen. Mit der Toolchain kannst du dann aber nicht viel anfangen, es sei denn du willst selber an den Tools weiterentwickeln. Oder du machst configure wie gehabt, aber dann wirst du kein Unterschied merken.
Hallo Johann, das las sich jetzt so als wenn du mit "64Bit float" fast fertig bist und Jörg die derzeit funktionierende Fassung allen zur Verfügung stellen könnte. Weiter dachte ich dann das ich mit neu gebauter Toolchain dann 64bit float einmal ausprobieren könnte. So weit meine Gedankengänge. Alles ein Missverständnis?
Johann L. schrieb: > Hast du eine Idee, wo / wie man -print-multi-lib und > -print-multi-directory in avr-libc unterstützen könnte? Nicht so richtig. :( Ich weiß, dass du das immer wieder erwähnst, kannst du mal erläutern, was es dafür genau bräuchte?
Veit D. schrieb: > das las sich jetzt so als wenn du mit "64Bit float" fast fertig bist und > Jörg die derzeit funktionierende Fassung allen zur Verfügung stellen > könnte. Wishful thinking. Zu allererst müssen ein paar Steinchen aus dem Weg geräumt werden. Steinchen No. 1 war http://gcc.gnu.org/r277908 Jörg bezog sich auf Steinchen No. 2 https://savannah.nongnu.org/bugs/?57071#comment0 @Jörg: Wenn schon, könnte man auch gleich Protos und symbole für long double bereitstellen. Also
1 | .macro ENTRY_LONG_DOUBLE32 name |
2 | #if (__SIZEOF_LONG_DOUBLE__ == __SIZEOF_FLOAT__) |
3 | .global _U(\name) |
4 | _U(\name): |
5 | #endif /* long double = float */ |
6 | .endm |
7 | |
8 | ... |
9 | |
10 | ENTRY asinf |
11 | ENTRY_DOUBLE32 asin |
12 | ENTRY_LONG_DOUBLE_DOUBLE32 asinl |
Steinchen No. 3 ist avr-libc -print-multi-directory und -print-multi-lib beizubringen. Konkrete Vorschläge, wie das praktikabel umzusetzen ist, werden gerne entgegengenommen.
Hallo, aha. Tut mir leid, aber davon habe ich keinen blassen Schimmer. Wenn ich helfen könnte würde ich es tun. Bin weder Mathematiker noch Informatiker. Ich kann nicht einmal den Aufwand abschätzen welches Wissen dazugehört um überhaupt die Tools zu programmieren zum programmieren. Deswegen sei mir nicht böse. Ihr einsamen Ritter im Hintergrund.
Veit D. schrieb: > Bin weder Mathematiker noch Informatiker. Wenn es dich beruhigt: ich auch nicht. ;-) (Bin Elektroniker.)
Bin gelernter Industrieelektroniker und als Instandhalter tätig. :-)
Jörg W. schrieb: > kannst du mal erläutern, was es dafür genau bräuchte? Für libc/libm: Jede Zeile von -print-multi-lib beschreibt eine multilib-Variante
1 | avr25/tiny-stack;@mmcu=avr25@msp8 |
Links vom ; steht der relative Pfad zur Multilib-Variante, und rechts davon stehen die Multilib-Options, mit der die Quellen zu übersetzen sind. Hier also -mmcu=avr25 -msp8. Dazu können natürlich noch andere, non-multi Options wie -Os kommen. Das build-System der avrlibc verwendet bootstrap -> gen-avr-lib-tree.sh, d.h. Erzeugung der Verzeichnisstruktur müsste durch -print-multi-lib getrieben sein statt hardcodiert. Und natürlich müssen alle Multilib-Optionen aus gen-avr-lib-tree.sh:CFLAGS rausfliegen. Dazu müsste bootstrap den Compiler kennen, denn -print-multi-lib ist abhängig von Compilerversion und -konfiguration. Für Devicelib und Crt gilt das gleiche, nur das es da etwas komplizierter ist, die Multilib-Pfade zu eruieren, z.B. wie folgt:
1 | PML=`$CC -print-multi-lib` |
2 | foreach MCU |
3 | PMD=`$CC -print-multi-directory -mmcu=$MCU` |
4 | # Map -mmcu=$MCU to -mmcu=$ARCH |
5 | for LINE in $PML |
6 | if LINE.startswith("$PMD;") # Exactly 1 line must match here. |
7 | ARCH=LINE.extract.mmcu() # May be "" for the avr2 default. |
8 | |
9 | for LINE in $PML |
10 | if LINE.contains("@mmcu=$ARCH@") |
11 | or LINE.endswith("@mmcu=$ARCH") |
12 | or ($ARCH=="" and not LINE.contains("@mmcu=") |
13 | PATH=LINE.getpath() |
14 | MOPTS=LINE.getoptions().filter-out("-mmcu=...") |
15 | # avr-gcc will patch some multi-opts to align with $MCU, |
16 | # hence the path migh also change. |
17 | PATH=`$CC -mmcu=$MCU $MOPTS -print-multi-directory` |
18 | # Build $PATH/crt$MCU.o |
19 | if not exists $PATH/crt$MCU.o |
20 | $CC -mmcu=$MCU $MOPTS $CFLAGS crt1.S -o $PATH/crt$MCU.o |
21 | if not exists $PATH/lib$MCU.a |
22 | # Builf lib$MCU.a using -mmcu=$MCU $MOPTS $CFLAGS |
Gleiches gilt für configure.ac: Einträge wie die folgenden
1 | AC_CONFIG_FILES([ |
2 | avr/lib/avr2/tiny-stack/Makefile |
3 | avr/lib/avr2/tiny-stack/at90s2313/Makefile |
müssen generiert werden, die einzige Info die dazu verwendet wird: Es gibt ein Device "at90s2313" und die Infos auf $CC -print-multi-*. Hier könnte man ein m4 generieren; aclocal läuft ja eh schon. Die Multilib-Variabten für die Devices auszuarbeiten funktioniert, weil avr-gcc falsche Optionen korrigiert, weshalb der selbe PATH mehrfach auftreten kann; daher das "if not exists".
Johann L. schrieb: > Das build-System der avrlibc verwendet bootstrap -> gen-avr-lib-tree.sh, > d.h. Erzeugung der Verzeichnisstruktur müsste durch -print-multi-lib > getrieben sein statt hardcodiert. Und natürlich müssen alle > Multilib-Optionen aus gen-avr-lib-tree.sh:CFLAGS rausfliegen. Das klingt zumindest machbar. Dieses gen-avr-lib-tree.sh ist ja auch eher ein Hack.
Inzwischen gibt es auch ein Bounty für avr-gcc: https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
:
Bearbeitet durch User
Jörg W. schrieb: > Johann L. schrieb: >> Das build-System der avrlibc verwendet bootstrap -> gen-avr-lib-tree.sh, >> d.h. Erzeugung der Verzeichnisstruktur müsste durch -print-multi-lib >> getrieben sein statt hardcodiert. Und natürlich müssen alle >> Multilib-Optionen aus gen-avr-lib-tree.sh:CFLAGS rausfliegen. > > Das klingt zumindest machbar. Dieses gen-avr-lib-tree.sh ist ja auch > eher ein Hack. Irgendeine Art von Skript will man schon haben, ist auf jeden Fall besser als avr/lib/ händlisch zu maintainen. Und irgendwo müssen auch die potentiall unterstützten Devices gelistet sein. avr-gcc liefert diese Info nicht, denn es ist mehr oder weniger unmöglich, den Name der CRTs zu raten. Und wenn avr-gcc die Info geben könnte, würde es immer noch nicht mit älteren Compilerversionen funktionieren. Das eigenliche Problem ist aber, dass avr/lib/ Teil von $srcdir ist, d.h. in einer Quell-Distro enthalten ist; dies ist mit -print-multilib-lib nicht mehr machbar, weil der Build-Compiler — und damit die Multilib-Struktur — erst zur Build-Zeit bekannt ist, d.h. wenn der Anwender configure ausführt. gen-avr-lib-tree.sh (oder was auch immer avr/lib/ generiert) darf also nicht mehr vor configure laufen, und avr/lib/ muss irgendwo in $builddir generiert werden und nicht mehr in $srcdir. Und aus configure[.ac] müssen müssen alle Devices / Cores rausfliegen. Johann L. schrieb: > Für Devicelib und Crt gilt das gleiche, nur das es da etwas > komplizierter ist, die Multilib-Pfade zu eruieren, z.B. wie folgt: Da hatte ich viel zu kompliziert gedacht... Geht einfach so:
1 | PML = `$CC -print-multi-lib` |
2 | foreach MCU |
3 | # Map -mmcu=$MCU to -mmcu=$ARCH |
4 | for LINE in $PML |
5 | OPTIONS = options($LINE).replace("-mmcu=*" with "-mmcu=$MCU") |
6 | if path($LINE) == `$CC -print-multi-directory $OPTIONS` |
7 | add $MCU to path($LINE) |
Johann L. schrieb: > gen-avr-lib-tree.sh (oder was auch immer avr/lib/ generiert) darf also > nicht mehr vor configure laufen, und avr/lib/ muss irgendwo in $builddir > generiert werden und nicht mehr in $srcdir. Das finde ich ohnehin sinnvoll. Mal sehen, ob mir für die crt*.o eine Heuristik einfällt.
Beitrag #6058874 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > Johann L. schrieb: >> gen-avr-lib-tree.sh (oder was auch immer avr/lib/ generiert) darf also >> nicht mehr vor configure laufen, und avr/lib/ muss irgendwo in $builddir >> generiert werden und nicht mehr in $srcdir. > > Das finde ich ohnehin sinnvoll. Hättest Du denn Zeit und Muße entsprechende Patches zu reviewen und einzubauen? gen-avr-lib-tree.sh hab ich durch ein Python-Skript ersetzt. Das erzeugt zum einerseits ./avr/lib aus -print-multi-lib und andererseits m4-includes für configure.ac: Eines für die ganzen CHECK_AVR_DEVICE + AM_CONDITIONAL und eines für AC_CONFIG_FILES, d.h. das ganze Device-Wissen fliegt aus configure.ac raus. gen-avr-lib-tree.sh entählt so nur noch den Aufruf des py und die Device-Beschreibungen: Daten für -mmcu=, crt*.o und nicht-Multilib-Optionen. avr/lib ist so immer noch ein Teil der avr-libc Quellen; und ich tendiere momentan dazu, das auch so zu lassen (sofern überhaupt die Option besteht, das Design der avr-libc zu gestalten). Stattdessen könnte man ohne -print-multi-lib auskommen und das Wissen über -mdouble32/64 etc. in das py-Skript einbauen. configure würde dann testen, welche Multilib-Optionen vorhanden sind und nur entsprechende Teile von avr/lib aktivieren.
Johann L. schrieb: > Hättest Du denn Zeit und Muße entsprechende Patches zu reviewen und > einzubauen? Nach Weihnachten / erste Januarwoche, ja, da könnte das passen. Hauptproblem ist natürlich, dann auch einen Release zu machen. Wird wohl nur so gehen, dass eine Reihe von bekannten und dokumentierten Problemen ignoriert werden müssen, damit überhaupt ein Release zustande kommt.
Jörg W. schrieb: > Johann L. schrieb: >> Hättest Du denn Zeit und Muße entsprechende Patches zu reviewen und >> einzubauen? > > Nach Weihnachten / erste Januarwoche, ja, da könnte das passen. > > Hauptproblem ist natürlich, dann auch einen Release zu machen. Was ist denn für die nächste Release geplant? > Wird wohl nur so gehen, dass eine Reihe von bekannten und dokumentierten > Problemen ignoriert werden müssen, Was gibt es denn für Probleme? Wo wir gerade dabei sind: In configure.ac::CHECK_AVR_DEVICE und anderen Makros gib es die Zeile
1 | CC=`echo "${CC}" | sed 's/-mmcu=avr.//'` |
Wozu ist das erforderlich? http://svn.savannah.nongnu.org/viewvc/avr-libc/trunk/avr-libc/configure.ac?revision=2544&view=markup#l459
Peter D. schrieb: > Ab welcher Version ist denn das enthalten? https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=279994
:
Bearbeitet durch User
Rudolph R. schrieb: > Experte schrieb: >> Ist ja auch logisch: Es kommt kein neuer Nutzer zu einer Plattform dazu, >> wenn er feststellt dass es keinen aktuellen Compiler gibt. > > Naja, wann war der mit AS7 ausgelieferte GCC denn mal wirklich aktuell? > > Microchip liefert immer noch GCC 5.4.0 aus. > Der ist aber auch erst etwas über drei Jahre "alt". und hat Bugs: https://gcc.gnu.org/PR87695 Zum ersten mal reportiert Ende 2018, also ca. 1 Jahr nachdem Support für v5 eingestellt wurde. Erste v5 Release war bereits Frühjahr 2015, Entwicklung daran begann Frühjahr 2014. Es war also reichlich Zeit, das Problem zu erkennen während v5 supported wurde (insgesamt 4 1/2) Jahre. Alle PRs sind aus der Zeit danach (ca 1 Report / Monat). Die betroffene Version ist eine von Microchip, die für Arduino eingesetzt wird. Der Bug wurde bereits mehrfach gemeldet, als: https://gcc.gnu.org/PR87695 https://gcc.gnu.org/PR87771 https://gcc.gnu.org/PR88468 https://gcc.gnu.org/PR88665 https://gcc.gnu.org/PR89918 https://gcc.gnu.org/PR90286 https://gcc.gnu.org/PR90429 https://gcc.gnu.org/PR90956 https://gcc.gnu.org/PR91703 https://gcc.gnu.org/PR91904 https://gcc.gnu.org/PR93204 der jüngste PR ist von 2020-01-08. Es könnte also durchaus sein, dass zumindest 11 Anwender von avr-gcc gegen eine neuere Version nix einzuwänden hätten.
:
Bearbeitet durch User
Johann L. schrieb: > Johann L. schrieb: >> Inzwischen gibt es auch ein Bounty für avr-gcc: > > Bounty ist bei $535. Bounty ist bei $565, steigt aktuell also ca $1 pro Tag.
Johann L. schrieb: > Bounty ist bei $565, steigt aktuell also ca $1 pro Tag. Zu Schade dass Boutysource einen Paypal Account erfordert. Sonst würde ich den Betrag erhöhen. Es wäre sehr Wünschenswert wenn GCC auch in Zukunft die AVR unterstützt. Selbst wenn die CortexM bei gleichem Preis leistungfähiger sind, für viele Sachen sind AVRs schlicht ausreichen - ich empfinde die gegenüber den CortexM als so wunderbar einfach. Außerdem gibt genug fertige Projekte im Netz die für AVRs zugeschnitten sind und die man so einfach nutzen kann. Alte Compiler nutzen geht natürlich auch - bis irgendwann die Libs/Binaries aus irgend einem Grund nicht mehr mit dem System kompatibel sind. Beispiele davon habe ich schon genug. Ein Java ME Projekt, dessen Emulator nur mit Eclipse 3.2 und altes Java läuft. Openoffice Dokumente die nur mit einer alten Version gingen, die sich nicht mehr ausführen ließ. Eine MS Windows CE 5 Entwicklungsumgebung, die nur mit Windows XP lief und unter 7 abstürzte...
Malte _. schrieb: > Zu Schade dass Boutysource einen Paypal Account erfordert. Sonst würde > ich den Betrag erhöhen. Frag halt mal jemanden aus deinem Freundeskreis mit Paypalaccount ob derjenige das für dich macht.
Ist das Thema eigentlich in den Arduino-Foren bekannt? Ist ja ne aktive Community, vielleicht will da auch jemand zum Bounty beitragen?
Hallo, das Thema ist ein ganz heißes Eisen. Auch wenn viele bei dem Thema weggucken und alles kostenlos nutzen wollen, versuche ich einmal zu antworten. Käufer von originalen Arduinos finanzieren schon die Arduinoentwicklung und dessen Forum. Auf Grund der offen gelegten Hard- und Software bauen die Chinesen das nach. Viele kaufen die billigen Nachbauten wovon Arduino.cc keinen Cent sieht. Problem daran ist auch das niemand überhaupt weiß wie alles finanziert wird. Chinaboards sind Spottbillig und der Rest ist kostenlos. Beim Download der Arduino IDE kann man übrigens auch spenden, muss ich persönlich nicht machen, weil ich nur originale Arduinos kaufe. Andersherum, wenn Arduino nicht offen wäre, hätte es nicht diese Verbreitung die es jetzt hat. Dann hätte auch bestimmt ESP nicht die Verbreitung, weil die einfach anwendbare IDE fehlen würde. Henne - Ei Problem. Wenn die Arduino IDE nun einmal den avr-gcc nutzt, müßte Arduino.cc von jeden verkauften Arduino einen Betrag an "avr-gcc" weiterreichen. Aber! Das müßten dann alle machen, nicht nur Arduino.cc. Es kann dann nicht sein das nur auf Arduino "rumgehackt" wird. Wenn selbst früher Atmel und jetzt Microchip die davon direkt abhängig sind schon keine Lust dazu haben "avr-gcc" richtig zu unterstützen. Was heißt das für mich. Ich habe mehr davon wenn solche echt sinnvollen Sachen wir deine/eure 64Bit float Unterstützung Einzug halten statt immer neue C++ Sprachfeatures die bestimmt nur die wenigstens bis heute nutzen. Um den Kreis zu schließen. Ich würde wenn dann viel lieber euch direkt, den 64Bit float Programmierern, einen Obolus zukommen lassen, als der großen avr-gcc Gemeinde. Das ist laut meiner Ansicht Sache der µC Hersteller. Eine Gegenfrage muss noch sein. Bezahlen die Linuxnutzer irgendeinen Cent an die Distributationen oder gar Linuxentwickler direkt? Oder an die Foren wo sie Hilfe möchten? Bezahlen ESP Käufer an Arduino.cc oder "gcc" irgendeinen Cent? Ich sehe hier nur Johann und Jörg ackern. Bekommt ihr was vom avr-gcc Kuchen ab? Ich glaube nicht. Also warum soll ich einen Obolus an "avr-gcc" abdrücken und nicht an euch Fleißmeisen? Auch auf die Gefahr hin das ich bestimmte Zusammenhänge in Sachen avr-gcc verwechsel und die Gedankengänge etwas wild wechseln, so sollte doch mein Anliegen an die Bezahlproblematik zum Ausdruck gekommen sein. Doch noch ein "Edit" was ich vermeiden wollte. Den Usern in den Arduino Foren ist das Thema bestimmt vollkommen egal. Weil die sich um solche Internas nicht kümmern. Die sind mit Programmieren im allgemeinen voll ausgelastet. Nur ein Bruchteil vom Bruchteil guckt tiefer hinter die Front und beschäftigt sich mit dem Compiler und Toolchain. Also ähnlich wie hier wo sich die Leute Atmel Studio installieren und einfach glücklich sind und nicht wissen das eine uralte Toolchain drin ist. Das hornalte WinAVR wird ja auch heute noch wie warme Semmeln angepriesen. Da ist ja mit einem offiziellen Update die Arduino IDE mit avr-gcc 7.3 um Welten moderner.
:
Bearbeitet durch User
Veit D. schrieb: > Den Usern in den Arduino Foren ist das Thema bestimmt vollkommen egal. > Weil die sich um solche Internas nicht kümmern. Naja, ich dachte das Thema dort mal verkünden kostet ja nix. Für wen mit Forum-Account ist so eine End-of-Lifetime Ankündigung bestimmt kein großer Aufwand. So ein Bounty hat den Vorteil, dass jeder die Wahl hat, ob und wenn ja wieviel er geben will (wobei ich nicht weiß, was mit der Knete passiert, wenn das Projekt nicht zustande kommt). Es gibt kein Schnäppchen-Reflex was billig(er)es zu suchen wie bei dem China-Zeugs. > Ich sehe hier nur Johann und Jörg ackern. Bekommt ihr was vom avr-gcc > Kuchen ab? Ich glaube nicht. Also warum soll ich einen Obolus an > "avr-gcc" abdrücken und nicht an euch Fleißmeisen? Ich für meinen Teil möchte kein Geld dafür, weil ich keine Verpflichtungen diesbezüglich eingehen möchte. Wann ich was beitrage und wie lange und intensiv ich daran werkle, darüber möchte ich 100% selbst entscheiden – oder gar nicht entscheiden und einfach weiterbasteln wenn ich wieder Lust dazu hab oder mich was interessiert z.B. wie man arcsin implementiert. Ist auch der Grund dafür, warum ich damals abgelehnt hatte, AVR-Maintainer zu werden: dadurch hätte ich nicht mehr Zeit zu GCC beizutragen; mir genügt dass ich da Schreibrechte habe, was meine Arbeit vereinfacht. > Wenn die Arduino IDE nun einmal den avr-gcc nutzt, müßte Arduino.cc von > jeden verkauften Arduino einen Betrag an "avr-gcc" weiterreichen. Aber! > Das müßten dann alle machen, nicht nur Arduino.cc. Es kann dann nicht > sein das nur auf Arduino "rumgehackt" wird. Ich wollte ja nicht rumhacken, sondern anregen, dass jemand mit Arduino-Account das dort bekannt macht. > Wenn selbst früher Atmel und jetzt Microchip die davon direkt > abhängig sind schon keine Lust dazu haben "avr-gcc" richtig zu > unterstützen. Ja, fremdschäm...
Johann L. schrieb: > Ich für meinen Teil möchte kein Geld dafür, weil ich keine > Verpflichtungen diesbezüglich eingehen möchte. Dito – davon abgesehen, dass bei mir weder Zeit noch Wissen für den GCC ausreichend wären für so einen Job.
Veit D. schrieb: > Also warum soll ich einen Obolus an > "avr-gcc" abdrücken und nicht an euch Fleißmeisen? So richtig verstanden hast du das mit gcc-open source und dem bounty jetzt nicht. An "avr-gcc" kannst du nichts "abdrücken", und Arduino.cc nichts weiterreichen, weil es keine "avr-gcc ltd/GmbH/AG/inc..." oder ähnliches gibt. Es gibt nicht mal eine "gcc inc." Oliver
Hallo, die Anregung/Information könnte ich umgehend einem Moderator im Arduino Forum zukommen lassen. Mehr wie ein Thread wird das allerdings nicht werden der dann zügig hinten runterfällt. Ob das die Leute überhaupt verstehen ist auch fraglich, weil die sagen sich ich habe doch die fertige IDE und die läuft. Damit sind wir wieder beim Bruchteil vom Bruchteil die dafür Verständnis aufbringen können. Aber wie gesagt, die Anregung kann ich rübertragen, wäre kein Problem. Hat jemand einen offiziellen Link zur GCC Bounty? Sollen ja keine Trittbrettfahrer profitieren. > Ich wollte ja nicht rumhacken, sondern anregen, dass jemand mit > Arduino-Account das dort bekannt macht. Mach dir keine Sorgen, wir verstehen uns.
Veit D. schrieb: > Bezahlen die Linuxnutzer irgendeinen > Cent an die Distributationen oder gar Linuxentwickler direkt? Oder an > die Foren wo sie Hilfe möchten? Ja. Ich spende 1x im Jahr an das GNU Projekt, Arch Linux, Manjaro, Python, Mozilla und ein Hacker-Forum.
Hallo, nochmal für mich zum Verständnis. Das notwendige AVR Backend neu schreiben ist ein einmaliger Vorgang um zukünftig die avr Pflege im gcc einfacher bzw. auf dem neuen Stand zu haben? Was dann hoffentlich wieder für mehrere gcc Generationen nutzbar ist. Oder fängt das Spiel dann mit jeder gcc Version von Neuen an? @ Kaj: vorbildlich
> gcc11 könnte das avr Backend verlieren
Philosophische Frage: Wenn es keinen kümmert, wen stört es dann?
> ... wen stört es dann? Frage ich mich auch. Viele benutzen ältere Versionen des AVR-GCCs (z. B. 4.xx) und für die nächsten 5- 10 Jahre reichen die vorhandenen Versionen allemal aus.
Veit D. schrieb: > Das notwendige AVR Backend neu > schreiben ist ein einmaliger Vorgang um zukünftig die avr Pflege im gcc > einfacher bzw. auf dem neuen Stand zu haben? Was dann hoffentlich wieder > für mehrere gcc Generationen nutzbar ist. Oder fängt das Spiel dann mit > jeder gcc Version von Neuen an? Beitrag "Re: gcc11 könnte das avr Backend verlieren" https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html Das AVR-Backend verwendet eine bestimmte Darstellung des Condition Codes, der für v10 deprecated ist und für v11 entfernt wird. Weil Target avr diese Darstellung verwendet, wird damit auch dieses Backend entsorgt — mit allem was dazugehört — falls das Backend nicht umgestellt wird. Im header des Problem Reports ist ein Link zum Bounty: https:/gcc.gnu.org/PR92729 Momentan gibt es noch nicht einmal eine "offizielle" Warnung in den Caveats der v10 Release Notes: http://gcc.gnu.org/gcc-10/changes.html Timeline wird vermutlich so sein: Die Deprecation ist für v10, und kurz vor oder nach der ersten v10 Release werden die Release Notes glattgezogen. Also dieses Frühjahr. Nachdem der Release Branch für die v10 erstellt wurde, beginnt auf Master die Entwicklung für v11, und es ist geplant, cc0 (den alten Condition Code) gleich danach zu entfernen. Nach der offiziellen Ankündigung konnte es also nur wenige Wochen dauern, bis das avr Backend (und andere, die ebenfalls noch cc0 verwenden) tatsächlich enfernt werden; und eben nicht ein ganzes Jahr bis zur v11 Release. Nicht dass ich davon ausgehe, dass irgendjemand die Release Notes liest — schon garnich für eine Version, an der noch entwickelt wird und die noch nicht verfügbar ist. Aber es zeigt, welchen Wert solche Backends bei den GCC Maintainern haben. Das Backend bleibt dann weiter nutzbar — sofern es nicht zu anderen Deprecations kommt. Eine, die in nicht allzu ferner Zukunft zu erwarten ist, ist die Umstellung auf einen bestimmten (neuen) Register-Allokator. Guess what: avr-gcc verwendet den alten Allokator. Der Hauptgrund, warum avr-gcc nicht auf den neuen Allokator umgestellt wurde, ist, dass der neue Allokator ziemlich blöd ist und mit cc0 Condition Code nicht zurechtkommt. Auf den neuen Allokator umzustellen wäre ein Klacks im Verleich zur cc0 -> CCmode Umstellung, bei der quasi jede Instruktion samt assoziiertem Code angefasst werden muss. Das m68k (Motorola 68000) Backend wurde kürzlich umgestellt, dachdem ein vergleichbares Bounty für m68k binnen kurzer Zeit > $5000 gesammelt hatte. Daraufhin wurde dann auch ein Bounty für avr ins Leben gerufen, in der Hoffnung, dass das was bringt. Der Autor der m68k Umstellung wäre garantiert auch in der Lage, avr zu bewältigen, wobei das avr Backend etwas[tm] verwinkelter ist.
Bilderstürmer schrieb: > Frage ich mich auch. Viele benutzen ältere Versionen des AVR-GCCs (z. B. > 4.xx) und für die nächsten 5- 10 Jahre reichen die vorhandenen Versionen > allemal aus. Ich ärgere mich nur, ausgerechnet mit einer toten Plattform herumgespielt zu haben.
Veit D. schrieb: > nochmal für mich zum Verständnis. Das notwendige AVR Backend neu > schreiben ist ein einmaliger Vorgang um zukünftig die avr Pflege im gcc > einfacher bzw. auf dem neuen Stand zu haben? Was dann hoffentlich wieder > für mehrere gcc Generationen nutzbar ist. Oder fängt das Spiel dann mit > jeder gcc Version von Neuen an? Das ist eine einmalige Maßnahme, damit zukünftige Versionen des gcc überhaupt noch avr -Code erzeugen können. Ohne die Änderung wird’s ansonsten keine aktuellen AVR-gcc mehr geben. Wobei „einmalig“ in der Computerwelt nicht „nie wieder“ bedeutet. Oliver
:
Bearbeitet durch User
Troll schrieb: > Ich ärgere mich nur, ausgerechnet mit einer toten Plattform > herumgespielt zu haben. Wie gesagt, es gibt da keine Probleme. In den nächsten 10 Jahren werde ich auf jeden Fall noch mit den AVRs klarkommen, so wie in den vergangenen 10 Jahren auch. Und wenn die Controller-Familie in Zukunft noch eine wichtige Rolle spielen sollte, dann ist microchip etwas aufgerufen etwas zu unternehmen.
Bilderstürmer schrieb: > Troll schrieb: > >> Ich ärgere mich nur, ausgerechnet mit einer toten Plattform >> herumgespielt zu haben. > > Wie gesagt, es gibt da keine Probleme. In den nächsten 10 Jahren werde > ich auf jeden Fall noch mit den AVRs klarkommen, so wie in den > vergangenen 10 Jahren auch. Und wenn die Controller-Familie in Zukunft > noch eine wichtige Rolle spielen sollte, dann ist microchip etwas > aufgerufen etwas zu unternehmen. Tja - wenn das weder Microchip, noch AVR, noch sonstwen relevantes kümmert, sind die Dinger Auslaufmodelle. Werden die noch industriell verbaut? Ich bezweifle es.
Hallo, das sehe ich auch so. Es müsste eigentlich im Sinne von Microchip sein, dass AVR Controller weiter unterstützt werden. > Das m68k (Motorola 68000) Backend wurde kürzlich umgestellt, dachdem ein > vergleichbares Bounty für m68k binnen kurzer Zeit > $5000 gesammelt > hatte. Wenn die "arme" Firma Microchip keine $5000 für die Controller Familie übrig hat wird der Verkauf immer zäher laufen, neue Controller Derivate werden wie Blei im Lager liegen bzw. in kürzester Zeit wieder eingestampft werden. Ciao
Heiko L. schrieb: > Werden die noch industriell verbaut? Werden sie. Es ist nur die Frage inwieweit andere Controller die AVRs in Zukunft verdrängen können.
Dumme Frage, wäre es denkbar/gibt es für CLang der ja LLVM-Code erzeugt die Möglichkeit daraus Atmel-Maschinensprache zu machen, oder spricht da was prinzipielle dagegen?
Guest schrieb: > Dumme Frage, wäre es denkbar/gibt es für CLang der ja LLVM-Code > erzeugt > die Möglichkeit daraus Atmel-Maschinensprache zu machen, oder spricht da > was prinzipielle dagegen? Nee - muss man nur ein Backend für schreiben...
Heiko L. schrieb: > Nee - muss man nur ein Backend für schreiben... Man könnte auch das alte AVR-Backend des clang reaktivieren.
Jürgen schrieb: > Wenn die "arme" Firma Microchip keine $5000 für die Controller Familie > übrig hat Die Integration "aller" AVRs in den Microchip XC8 Compiler hat sicher mehr gekostet ;-)
Volker S. schrieb: > Jürgen schrieb: >> Wenn die "arme" Firma Microchip keine $5000 für die Controller Familie >> übrig hat > > Die Integration "aller" AVRs in den Microchip XC8 Compiler hat sicher > mehr gekostet ;-) Und allein die Lizenzen dafür sicher auch...
:
Bearbeitet durch User
Johann L. schrieb: > Im Header des Problem Reports ist ein Link zum Bounty: > > https:/gcc.gnu.org/PR92729 Korrekte URL: https://gcc.gnu.org/PR92729
Warum nicht gleich den Ziellink? https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
Die Gäste legen wieder ein Benehmen an den Tag, unglaublich. Warum nicht...? Sicherlich weil auf der "Linkseite" noch mehr Informationen zum Thema stehen.
Beitrag #6109387 wurde von einem Moderator gelöscht.
Wilhelm M. schrieb: > Heiko L. schrieb: >> Nee - muss man nur ein Backend für schreiben... > > Man könnte auch das alte AVR-Backend des clang reaktivieren. Das AVR-Backend ist doch im Upstream-LLVM enthalten, auch wenn es vom Status als "experimentell" gekennzeichnet ist.
Beitrag #6110305 wurde von einem Moderator gelöscht.
Beitrag #6111390 wurde von einem Moderator gelöscht.
Troll schrieb: > Ich ärgere mich nur, ausgerechnet mit einer toten Plattform > herumgespielt zu haben. Jede Plattform ist tot. Die Frage ist nur der Zeitraum. Oliver S. schrieb: > Das ist eine einmalige Maßnahme, damit zukünftige Versionen des gcc > überhaupt noch avr -Code erzeugen können. Ohne die Änderung wird’s > ansonsten keine aktuellen AVR-gcc mehr geben. Wobei „einmalig“ in der > Computerwelt nicht „nie wieder“ bedeutet. Eben. Zum anderen gibt es auch andere Compiler für AVRs. Wenn gcc11 kein AVR-Backend hat - so what? Nimmt man halt gcc10. Wenn gcc25 kein AVR-Backend hat, die Entwicklung im Jahr 2020 stehen geblieben ist und C++35 endlich mit getrennten Adressräumen vernünftig klarkommt und "Code für AVR" schreiben unendlich schmerzhaft geworden ist - dann wird sich schon einer drum kümmern. Unwahrscheinlich, aber möglich. Vermutlich erstmal ein Student, der was lernen will. Vielleicht ist der GCC bis dahin auch schon tot und LLVM rult die world. Jürgen schrieb: > Wenn die "arme" Firma Microchip keine $5000 für die Controller Familie > übrig hat wird der Verkauf immer zäher laufen, neue Controller Derivate > werden wie Blei im Lager liegen bzw. in kürzester Zeit wieder > eingestampft werden. Ja und nein. Einerseits: Wer sagt denn, dass denen das nicht ganz recht wäre? Sie haben mit den PICs die eigene Konkurrenz im Haus. Ein paar Chipvarianten weniger wäre bestimmt nicht soo ungern gesehen... Andererseits: Wer sagt denn, dass ein toter Compiler für Microchip nicht super ist? Die großen Industriekunden nehmen lieber einen zertifizierten Compiler mit bezahltem Support, egal wie schlecht der ist verglichen mit der Alternative. Ohne Alternative wird die Entscheidung viel einfacher.
S. R. schrieb: > Wer sagt denn, dass denen das nicht ganz recht wäre? Dass sie seit der Übernahme von Atmel massiv in die Entwicklung neuer AVRs investiert haben. (Mega 0 und Konsorten) Diese Investition muss sich auf jeden Fall für sie amortisieren, d.h. so schnell, wie manch einer befürchtet hatte nach der Übernahme werden sie die AVR8-Plattform nicht aufgeben. Warum sie sich dann nicht an der Toolchain-Entwicklung so recht beteiligen, erschließt sich einem dabei natürlich nicht. Gemessen an der Investition in die neuen AVRs wären USD 100000 für die Toolchain-Entwicklung ja fast nur Rauschen. > Die großen Industriekunden nehmen lieber einen zertifizierten Compiler > mit bezahltem Support Hatte sich Atmel früher auch gedacht und ausschließlich auf den IAR gesetzt – mit denen sie, schon durch die mentale Nähe zwischen Schweden und Norwegen, eine gute Beziehung hatten. Sie haben sich eines besseren belehren lassen müssen und nach vielen Jahren irgendwann erkannt, wie viel ihnen der AVR-GCC letztlich an Reputation und damit indirekt auch Umsatz produziert hat.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Warum sie sich dann nicht an der Toolchain-Entwicklung so recht > beteiligen, erschließt sich einem dabei natürlich nicht. Sie wollen ihre eigene Toolchain (MPLABX, XC8) durchsetzen?
Volker S. schrieb: > Jörg W. schrieb: >> Warum sie sich dann nicht an der Toolchain-Entwicklung so recht >> beteiligen, erschließt sich einem dabei natürlich nicht. > > Sie wollen ihre eigene Toolchain (MPLABX, XC8) durchsetzen? Das ist das Ende von AVR.
Jörg W. schrieb: >> Wer sagt denn, dass denen das nicht ganz recht wäre? > Dass sie seit der Übernahme von Atmel massiv > in die Entwicklung neuer AVRs investiert haben. Wäre es auch möglich, dass sie schlicht halbfertige Entwicklungen von Atmel ausentwickelt und auf den Markt geschickt haben? Ansonsten wirkt ein "wir ignorieren AVR-GCC und alle anderen OSS-Compiler einfach" ziemlich bescheuert. Gut, sehe ich persönlich auch oft genug. Ich fände es schön, wenn der AVR-GCC erhalten bleibt, bin aber nicht wirklich kompetent genug, daran zu arbeiten.
S. R. schrieb: >> Dass sie seit der Übernahme von Atmel massiv >> in die Entwicklung neuer AVRs investiert haben. > > Wäre es auch möglich, dass sie schlicht halbfertige Entwicklungen von > Atmel ausentwickelt und auf den Markt geschickt haben? Nein, sie haben wirklich in Norwegen aufgestockt.
Hallo, ich habe nun endlich von Microchip eine Antwort erhalten auf die Frage ob sie bereit sind den Backendumbau zu unterstützen. Diese niederschmetternde Antwort habe ich erhalten und bin wütend. Ich weiß nicht wie ich das einordnen soll? Entweder stellen die sich absichtlich dumm oder haben keine Ahnung und kommen mit scheinheiligen Begründungen um die Ecke. Ich meine wenn sie nicht wollen sollen sie es einfach klar sagen.
1 | Please find the response from our internal team below |
2 | |
3 | 'Because XC8-AVR is based on an earlier version, and we do not directly support GCC development, we have no plans to help to do the port for GCC 11. |
4 | |
5 | We have found that later versions of GCC produce larger code which is why we do not use a later release of GCC as the basis for XC8-AVR.' |
Veit D. schrieb: > Hallo, > > ich habe nun endlich von Microchip eine Antwort erhalten auf die Frage > ob sie bereit sind den Backendumbau zu unterstützen. Diese > niederschmetternde Antwort habe ich erhalten und bin wütend. Ich weiß > nicht wie ich das einordnen soll? Entweder stellen die sich absichtlich > dumm oder haben keine Ahnung und kommen mit scheinheiligen Begründungen > um die Ecke. Ich meine wenn sie nicht wollen sollen sie es einfach klar > sagen. . >
1 | > Please find the response from our internal team below |
2 | > |
3 | > 'Because XC8-AVR is based on an earlier version, and we do not directly |
4 | > support GCC development, we have no plans to help to do the port for GCC |
5 | > 11. |
6 | > |
7 | > We have found that later versions of GCC produce larger code which is |
8 | > why we do not use a later release of GCC as the basis for XC8-AVR.' |
9 | > |
Eine wirklich innovative Strategie.
Veit D. schrieb: > Ich meine wenn sie nicht wollen sollen sie es einfach klar sagen. Haben sie doch: - XC8-AVR basiert auf einer älteren Version von GCC. - Microchip unterstützt den GCC nicht direkt. - Es gibt keine Pläne, einem AVR-Port für GCC 11 zu helfen. Ich finde das eine klare, eindeutige Ansage.
Ne, die schieben den letzten Satz als Grund vor. Die wollen auf einer alten gcc Version sitzen bleiben.
Für C++-Anwender können sie sich etwas mehr Zeit lassen, denn C++23 wird ja wohl ein (fast) library-only change.
Veit D. schrieb: > Die wollen auf einer > alten gcc Version sitzen bleiben. genau so siehts aus. Ich würde sagen eine klare Ansage zur mittelfristigen Zukunft von AVRs für Neuentwicklungen.
Guest schrieb: > Dumme Frage, wäre es denkbar/gibt es für CLang der ja LLVM-Code erzeugt > die Möglichkeit daraus Atmel-Maschinensprache zu machen, oder spricht da > was prinzipielle dagegen? Die Art des aktuellen Problems: Das avr-Backend soll aus GCC fliegen, weil es nicht die aktuelle GCC-Infrastruktur nutzt. Bei LLVM ändert sich die Infrastruktur viel schneller als bei GCC oder SDCC: LLVM hat den Ruf, die IR quasi bei jeder neuen Version umzukrempeln. Wenn da die Backendentwickler nicht liefern, fliegt das Backend gleich bei der nächsten Version wieder raus (statt wie bei GCC nach vielen Fristen und Ankündigungen).
Hallo, das wird am Ende dann doch wieder irgendwie von der Community gerettet, von Leuten die in die Zukunft des gcc blicken wollen. Vielleicht, keine Ahnung, denkt Microchip wirklich nur in Assembler und C, nicht in C++. Sieht man an den Code Bsp. in den Manuals. Die Hauptentwicklung in gcc ist ja C++. C steht ja seit Jahren still. Ich will ja nur verstehen warum Microchip den Fortschritt ignoriert. Ich muss das ja nicht aktzeptieren. Die Microchip eigene IDE nutzt ja auch keine aktuellen gcc Versionen. Vielleicht ignoriert Microchip grundsätzlich alle C++ Programmierer die ihre AVRs nutzen und die bringen dennoch neue AVRs raus. An den Untergang von AVR µC glaube ich jetzt wirklich noch nicht. Weil was nutzt man hier im Forum wenn man nicht AVR ATmega programmiert? Man nutzt die Cortex Controller von ST. Man nimmt nicht die Microchip SAMxx schlagmichtot. Ich halte das AVR Standbein für wichtig für sie. Zurück zum Thema. Ich meine das Arduino Konzept zeigt ja Eindrucksvoll das man mit C++ wunderbar ein µC übergreifendes Funktionsgerüst zur Verfügung stellen kann. Rein mit C wäre das so nicht möglich. Und auch hier im Forum zeigen tagtäglich die C++ Programmierer was so machbar ist. Ich meine weiter, jeder schreit nach Sicherheit, fängt mit Daten/Zugriffkapselung mittels C++ an. Den Faden kann jeder nach Belieben weiterspinnen. Allein deswegen schockiert mich die Ignoranz. Wenn avr ab >gcc10 stehen bleiben sollte trifft das in erster Linie uns C++ Programmierer. Das wäre Schade. Eigentlich wollte ich noch an Arduino schreiben mit der Bitte die sollen als Großkunde mal mit Microchip reden ob sie das Problem vielleicht kurzerhand gemeinsam lösen oder gemeinsam finanzieren wollen. Wäre für die ja ein Witz. Die müßten ja nur kurz vor Schluss den Fehlbetrag auffüllen geteilt durch 2. Wenn sie schlau sind.
Ich mache mir da im Moment selbst als darauf angewiesener Anwender noch(!) keine Gedanken: 1) Als C++-Anwender habe ich im Moment C++20, und C++23 wird eine mostly-library Release, und die C++-stdlib habe ich für AVR eh nicht, sprich, die Teile, die ich brauche, schreibe ich selbst. Also habe ich wohl bis C++26 Zeit, mit gcc-10 auszukommen. 2) In dieser Zeit wird sicher eine Lösung erwachsen, ggf. wird das AVR-clang Backend reaktiviert. Eine strenge Vermeidung von IB lässt mich recht sicher sein, dass keine großen Unwägbarkeiten aufkommen werden. 3) Sollte in den 6 Jahren keinegcc/clang/xxx-Lösung auftauchen, muss ich eh die AVR-Projekte einstampfen, da dann MicroChip die AVR einstampfen werden muss.
Hallo, 1) und 2) gehe ich mit 3) sehe ich wie gesagt nicht so krass, weil das laut meiner Meinung nur C++ Programmierer betrifft. Alle anderen kommen ja heute noch mit ausgelieferten gcc5 in der IDE klar. Ich habe keine Zahlen zur Hand, schätze aber den Anteil der C++ Programmierer deutlich geringer ein wie C Programmierer auf AVR bezogen. Kann mich auch kräftig irren. Es ist wie ist. Schlechtes Gewissen muss ich nicht haben, gespendet ist. Jetzt liegst nicht in meiner Hand. Abwarten Tee trinken.
Und nicht vergessen: Microchip hat ihren Compiler, den sie ausliefern und unterstützen. Der Rest ist denen vermutlich schlicht scheißegal. Es gibt einen guten AVR-Compiler, auch für C++. Die meisten Projekte leben nicht an der blutigen Kante der neuesten Standards, sondern eher um C++11 rum. Aus meiner Sicht wird das also auch 2030 noch kein Todesurteil sein. Die Distributionen werden schlicht einen alten AVR-GCC ausliefern und pflegen, fertig. Interessant ist, was mit den neuen Chips passieren wird, die komplett aus dem Support rausfallen. Schön wäre es, wenn sich die deswegen nicht ordentlich verkaufen lassen und Microchip nochmal nachdenkt. Halte ich für sehr unwahrscheinlich. Tja.
Veit D. schrieb: > Entweder stellen die sich absichtlich > dumm oder haben keine Ahnung und kommen mit scheinheiligen Begründungen > um die Ecke. Ich meine wenn sie nicht wollen sollen sie es einfach klar > sagen. > >
1 | > We have found that later versions of GCC produce larger code which is |
2 | > why we do not use a later release of GCC as the basis for XC8-AVR.' |
3 | > |
Ich nehme an, die beziehen sich auf die folgenden beiden Einträge, laut denen GCC9 für AVR unter gewissen Umständen signifikant größeren Code generiert, als GCC8: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91189
Ja mag ja alles sein. Aber gcc7 soll auch größeren Code produziert haben im Vergleich davor. gcc8 Code wurde dann wieder kleiner. Will sagen das die Codegrößen mit den gcc Versionen leicht mitatmen. Zudem die sich auf gcc11 bezogen, der ja noch voll in der Entwicklung steckt wenn vielleicht in den nächsten Wochen erstmal der finale gcc10 vor der Tür steht. Etwas seltsam ist die Aussage schon. Selbst wenn, wenn gcc12 wieder kleinen Code produziert finden die das nicht schön? Kann man sicherlich viel darüber spekulieren warum und warum nicht. Ich wollte es einmal kundt tun. :-)
Veit D. schrieb: > Will sagen das > die Codegrößen mit den gcc Versionen leicht mitatmen. Ob man die in einem der beiden Bugtracker Einträge angegebenen ~20% noch als "leicht mitatmen" bezeichnen kann ist fraglich... Im Readme zu XC8 2.00 ist GCC5.4 aufgeführt. Ob es da noch Änderungen bei XC8 2.10 gab => ??? http://ww1.microchip.com/downloads/en/DeviceDoc/Readme_XC8_for_AVR.pdf
Veit D. schrieb: > Ja mag ja alles sein. Aber gcc7 soll auch größeren Code produziert haben > im Vergleich davor. gcc8 Code wurde dann wieder kleiner. Will sagen das > die Codegrößen mit den gcc Versionen leicht mitatmen. Momentan ist es eher wie bei: ausatmen – einatmen – nicht atmen
Hallo, habs mal selbst untersucht. Von 20% bin ich Meilenweit entfernt. Sind von mir 2 Projekte mit einem ATtiny841. Ich halte es nicht für dramatisch, auch wenn der 9er derzeit mit Abstand den größten Code erzeugt. Bin mal gespannt auf den 10er. Nur was bei der Betrachtung komplett untern den Tisch fällt ist, wie der Compiler das Programm optimiert. Also wird das Programm vielleicht etwas schneller im Vergleich zum alten Compiler und man nimmt etwas mehr Codegröße in Kauf? Was Microchip scheinbar auch komplett nicht betrachtet hat ist, dass man ja erst mit C++ seinen Code zur Compilezeit optimieren lassen kann. Da ginge sicherlich "mehr" wie derzeit bei mir rauskommt. Vermutlich wissen die das überhaupt nicht, weil sie mit C++ nichts machen. Die betrachten nur sturr irgendwelche Dateigrößen. Laut deren Logik müßten sie dann ihre IDE mit dem gcc 6 oder 8 ausliefern. Aber warum rege ich mich auf, die machen eh nix. 100% Basis in der Tabelle sind die Werte vom gcc 5.4
:
Bearbeitet durch User
Veit D. schrieb: > habs mal selbst untersucht. Von 20% bin ich Meilenweit entfernt. Sind > von mir 2 Projekte mit einem ATtiny841. Ich halte es nicht für > dramatisch, auch wenn der 9er derzeit mit Abstand den größten Code > erzeugt. Bin mal gespannt auf den 10er. Interessant wäre ggf. auch nochmal das mit -O3 zu machen. Allerdings ist das m.E. ohne eine Laufzeituntersuchung wenig zielführend. Generell habe ich die Beobachtung gemacht, dass ggf. Änderungen am Code, die in naiver Betrachtung eine Anwachsen des Maschinencodes nach sich ziehen müssten, zu einem kleineren Umfang geführt haben. Dies kann ich ad-hoc nicht durch Zahlen belegen und es handelt sich dabei um Projekte, die vollständig aus C++-templates bestehen.
Es ist wenig verwunderlich, dass bei einem nicht oder kaum maintainten Backend der erzeugte Code im Laufe der Zeit langsam etwas schlechter wird. Eigentlich sollte man immer an der Entwicklung dranbleiben, um je nach Entwicklung der andere Teile des Compilers (dort ändert sich durch neue Optimierungen, Bugfixes etc immer etwas) im Backend Anpassungen vorzunehmen. Leicht kann es ein, dass der Code, der das backend erreicht etwas anders (meist etwas besser) ist als zuvor, aber das Backend dann nicht so gut damit zurechtkommt, so dass der am Ende erzegte Code doch etwas schelchter ist. Beispiel: In den letzten Jahren wurde bei SDCC deutlich mehr Arbeit ins stm8-Backend als ins mcs51-Backend gesteckt. Codegrößenentwicklung Dhrystone mcs51: https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/historygraphs/dhrystone-mcs51-size.svg Codegrößenentwicklung Dhrystone stm8: https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/historygraphs/dhrystone-stm8-size.svg
Veit D. schrieb: > Nur was bei der Betrachtung komplett untern den Tisch fällt ist, > wie der Compiler das Programm optimiert. Also wird das Programm > vielleicht etwas schneller im Vergleich zum alten Compiler und > man nimmt etwas mehr Codegröße in Kauf? Das gilt für moderne, komplexe Architekturen im Allgemeinen eher als für einfache Architekturen wie AVR. Pipeline-Optimierungen, die den Code vergrößern, sind z.B. auf Prozessoren ohne nennenswerte Pipeline eher nutzlos und können durch den erhöhten Registerdruck wieder zu schlechteren Ergebnissen führen. Zumal auf den kleinen Controllern die Programmgeschwindigkeit der Codegröße eher untergeordnet ist - man hat wenig Speicher, aber meist keinen Vorteil von einem 10% schnelleren Programm. Veit D. schrieb: > Was Microchip scheinbar auch komplett nicht betrachtet hat ist, dass man > ja erst mit C++ seinen Code zur Compilezeit optimieren lassen kann. Das stimmt nicht, es gibt auch optimierende C-Compiler, und irgendwo stehen auch die Grenzen durch die Problemstellung. Ab einem gewissen Punkt helfen nur bessere Algorithmen (so es die gibt). Wilhelm M. schrieb: > Interessant wäre ggf. auch nochmal das mit -O3 zu machen. Allerdings ist > das m.E. ohne eine Laufzeituntersuchung wenig zielführend. Wie gesagt, wenn man nicht gerade mit großen Caches und tiefen Pipelines arbeitet, spart kleiner Code oft mehr Laufzeit ein als großer Code. Ein 8088 ist durch die Prefetch-Einheit limitiert, nicht durch die ALU. :-)
S. R. schrieb: > Veit D. schrieb: >> Was Microchip scheinbar auch komplett nicht betrachtet hat ist, dass man >> ja erst mit C++ seinen Code zur Compilezeit optimieren lassen kann. > > Das stimmt nicht, es gibt auch optimierende C-Compiler, und irgendwo > stehen auch die Grenzen durch die Problemstellung. Ab einem gewissen > Punkt helfen nur bessere Algorithmen (so es die gibt). Meine Aussage sollte auf die Programmiermöglichkeiten bezogen sein die man im einfachsten Fall mit constexpr zur Kompilierzeit wegoptimieren lassen kann. Im weiteren Fall die "magischen" Möglichkeiten die man mit Templates erreichen kann. Das was Wilhelm bis ins letzte Detail exorziert. ;-)
Hallo, O3 Optimierung ist erledigt. Allerdings klappt das mit dem 2. Projekt nicht. Ich erhalte immer folgende Fehlermeldung mit unterschiedlichen overlow Byte Angaben. Error: ATtiny841_DOGM.elf section `.text' will not fit in region `text' Worauf sich das bezieht kann ich nicht entnehmen. Es gibt keine Dateiangabe zum Fehler nur 'Line 1'. In Zeile 1 ist in allen Dateien entweder eine Leerzeile oder eine Kommentarzeile. Nebenfrage. Was ist der Unterschied zwischen der .hex und der .elf Datei? Beide sind zum flashen geeignet und beide enthalten den eigentlichen Programmcode. Sind die unterschiedlich komprimiert?
:
Bearbeitet durch User
Veit D. schrieb: > Meine Aussage sollte auf die Programmiermöglichkeiten bezogen sein die > man im einfachsten Fall mit constexpr zur Kompilierzeit wegoptimieren > lassen kann. Im Falle von constexpr-if ist sogar keine Optimierung mehr, sondern der Code wird gar nicht instanziiert (obgleich er wohlgeformt sein muss, aber eben nicht notwendigerweise compilierbar). Code, der nicht instanziiert wird, wird auch im backend nicht generiert.
Veit D. schrieb: > Error: ATtiny841_DOGM.elf section `.text' will not fit in region `text' > Worauf sich das bezieht kann ich nicht entnehmen. Passst nicht ins flash.
Veit D. schrieb: > Error: ATtiny841_DOGM.elf section `.text' will not fit in region `text' > Worauf sich das bezieht kann ich nicht entnehmen. Das sagt eigentlich genau das, was es meint: Das Programm passt nicht in den Speicher. Wie du ja auch bei Projekt1 seihst, ist die benötigte Flashgröße mit -O3 größer als bei den anderen Versionen. Die .hex-Datei enthält nur den nackten Programmcode, die .elf-Datei zusätlich noch Symbole etc. Kompilier
:
Bearbeitet durch User
Jetzt wo ihr es sagt. :-) Ich konnte mit 'text' nichts anfangen. Damit ist sicherlich der Programmcode gemeint. Danke.
:
Bearbeitet durch User
Veit D. schrieb: > Ich konnte mit 'text' nichts anfangen. Damit ist sicherlich der > Programmcode gemeint. So ist es.
Veit D. schrieb: > Ich halte es nicht für dramatisch, auch wenn der 9er derzeit mit > Abstand den größten Code erzeugt. Bin mal gespannt auf den 10er. v10 ist genauso schlech wie v9. > Nur was bei der Betrachtung komplett untern den Tisch fällt ist, wie der > Compiler das Programm optimiert. Also wird das Programm vielleicht etwas > schneller im Vergleich zum alten Compiler und man nimmt etwas mehr > Codegröße in Kauf? Es wird größer. Es wird langsamer. Er verbraucht mehr RAM (Stack). Beispiel:
1 | float f (float); |
2 | |
3 | float call (float x) |
4 | {
|
5 | return f (x); |
6 | }
|
Übersetzt mit v8:
1 | call: |
2 | /* prologue: function */ |
3 | /* frame size = 0 */ |
4 | /* stack size = 0 */ |
5 | .L__stack_usage = 0 |
6 | jmp f |
Übersetzt mit v10:
1 | call: |
2 | push r28 |
3 | push r29 |
4 | rcall . |
5 | rcall . |
6 | in r28,__SP_L__ |
7 | in r29,__SP_H__ |
8 | /* prologue: function */ |
9 | /* frame size = 4 */ |
10 | /* stack size = 6 */ |
11 | .L__stack_usage = 6 |
12 | std Y+1,r22 |
13 | std Y+2,r23 |
14 | std Y+3,r24 |
15 | std Y+4,r25 |
16 | ldd r22,Y+1 |
17 | ldd r23,Y+2 |
18 | ldd r24,Y+3 |
19 | ldd r25,Y+4 |
20 | /* epilogue start */ |
21 | pop __tmp_reg__ |
22 | pop __tmp_reg__ |
23 | pop __tmp_reg__ |
24 | pop __tmp_reg__ |
25 | pop r29 |
26 | pop r28 |
27 | jmp f |
Es gibt auch nicht-triviale Beispiele und auch welche ohne float. > Was Microchip scheinbar auch komplett nicht betrachtet hat ist, > dass man ja erst mit C++ seinen Code zur Compilezeit optimieren > lassen kann. Features wie constexpr und Zeugs lassen einen evtl. kompakteren Code formulieren, das behebt aber nicht die Bugs an anderer Stelle. Und ein Artefekt, das so krass ist wie das obige, würde ich durchaus als Bug bezeichnen. Bei 'nem Testfall wie dem obigen hilft dir constexpr oder C vs. C++ grad garnix. Wilhelm M. schrieb: > es handelt sich dabei um Projekte, > die vollständig aus C++-templates bestehen. Was über das Programm (außer über seine Wartbarkeit und Anpassbarkeit / Portierbarkeit) nix aussagt. Für jedes Programm mit Templates gibt es ein Progremm ohne Templates, das (bei gleichem Compiler, gleichen Optionen, gleichen Umgebungsvariablen und abgesehen von Debug-Info) den gleichen Code generiert. Um gekehrt lässt sich jedes Programm ohne Templates so mit beliebig vielen Tamplates dekorieren, dass das Programm effektiv das gleiche ist und der erzeugte Code der selbe. Philipp Klaus K. schrieb: > Es ist wenig verwunderlich, dass bei einem nicht oder kaum maintainten > Backend der erzeugte Code im Laufe der Zeit langsam etwas schlechter > wird. > > Eigentlich sollte man immer an der Entwicklung dranbleiben, um je nach > Entwicklung der andere Teile des Compilers (dort ändert sich durch neue > Optimierungen, Bugfixes etc immer etwas) im Backend Anpassungen > vorzunehmen. > > Leicht kann es ein, dass der Code, der das backend erreicht etwas anders > (meist etwas besser) ist als zuvor, aber das Backend dann nicht so gut > damit zurechtkommt, so dass der am Ende erzegte Code doch etwas > schelchter ist. Vielleicht ist ja nicht klar, was im GCC ein "Backend" darstellt. Das Backend ist eine Sammlung von Pattern und Hooks, die bestimmte Aufgaben erledigen oder beschreiben. Organisatorisch besteht es nur aus 'ner handvoll Dateien (momenten ca. 40), aber die Ausführung ist nicht in einem Block oder linear à la Frontend -> Middleend -> Backend. Jedenfalls ist es nicht so, dass das Backend nach dem Middleend den Code "übernimmt" und danach bis zur finalen Assembler-Ausgabe alleinig transformiert — oder überhaupt transformiert, das passiert nur an ca. 5 Stellen für AVR-spezfische Optimierungen oder Built-ins. > Beispiel: In den letzten Jahren wurde bei SDCC deutlich mehr Arbeit ins > stm8-Backend als ins mcs51-Backend gesteckt. Das oben gezeigte Problem ist nicht nur kein Problem des AVR-Backends, es ist noch nicht einmal möglich, im AVR-Backend drumrum zu hacken. So ziemlich alle Optimierungen, die halbwegs sinnvoll im AVR-Backend implementierbar sind, sind dort implementiert. Außer http://gcc.gnu.org/PR84211
:
Bearbeitet durch User
Johann L. schrieb: > Es gibt auch nicht-triviale Beispiele und auch welche ohne float. Nicht jeder 4-Byte-type hat das Problem. Ein uint32_t ergibt im Gegensatz zu float in v9.2 den besseren Code, in v10.0.1 wieder nicht mehr. Johann L. schrieb: > Außer > http://gcc.gnu.org/PR84211 Wäre das o.g. Problem den mit Deinem Patch beseitigt?
Johann L. schrieb: > Übersetzt mit v8: > jmp f > > Übersetzt mit v10: > push r28 > push r29 > rcall . > rcall . > in r28,__SP_L__ > in r29,__SP_H__ > std Y+1,r22 > std Y+2,r23 > std Y+3,r24 > std Y+4,r25 > ldd r22,Y+1 > ldd r23,Y+2 > ldd r24,Y+3 > ldd r25,Y+4 > pop __tmp_reg__ > pop __tmp_reg__ > pop __tmp_reg__ > pop __tmp_reg__ > pop r29 > pop r28 > jmp f (Kommentare der besseren Vergleichbarkeit wegen entfernt) Das ist schon krass. Ein simpler Funktionsaufruf braucht 42 statt 2 Bytes und 43 statt 3 Taktzyklen. So gesehen wird praktisch jeder, der 1. ordentlich optimierten Code erwartet, 2. C++-mäßig nicht unbedingt auf dem neuesten Stand sein muss und 3. auch neuere AVR-Typen einsetzen möchte, den Microchip-Fork namens XC8 dem Original-GCC (egal in welcher Version) vorziehen. Da die Punkte 1 und 2 wohl auf 99,9% der kommerziellen AVR-Kunden zutreffen und Microchip natürlich auch die neuesten AVR-Typen verkaufen will (d.h. auch Punkt 3 bedienen muss), kann ich gut verstehen, dass die Firma lieber ihr eigenes Süppchen kocht anstatt sich den GCC-Entwicklern anzuschließen. Ich finde das zwar schade, aber so funktioniert halt Wirtschaft.
Johann L. schrieb: > Bei 'nem Testfall wie dem obigen hilft dir constexpr oder C > vs. C++ grad garnix. Schon:
1 | using tt = float; |
2 | |
3 | tt f (const tt& x); |
4 | |
5 | tt call(const tt& x) { |
6 | return f(x); |
7 | }
|
Damit wirds besser.
Wilhelm M. schrieb: > Damit wirds besser. Das ist doch komplett anderer Code, und du weisst das auch. Ersetze zum Beispiel ein Modul (*.o), das aus meinem Code generiert wurde (egal mit welcher Compilerversion oder welchen Schalten) mit einem Modul, das aus deinem Code erzeugt wurde. Was passiert? Genau. Das Programm crasht weil die Codes / Interfaces inkompatibel sind.
Johann L. schrieb: > Wilhelm M. schrieb: >> Damit wirds besser. > > Das ist doch komplett anderer Code, und du weisst das auch. Ersetze zum > Beispiel ein Modul (*.o), das aus meinem Code generiert wurde (egal mit > welcher Compilerversion oder welchen Schalten) mit einem Modul, das aus > deinem Code erzeugt wurde. > > Was passiert? > > Genau. Das Programm crasht weil die Codes / Interfaces inkompatibel > sind. Typische AVR-Firmware (*) hat damit kein Problem, weil eher alles in Source vorliegt und kaum Sekunden bis Build-Ende braucht. Der Aufwand Object-Libraries zu bauen, lohnt da nicht. *Die Avrlibc (und Compilersupportzeugs) nehme ich mal aus, da diese überwiegend (inline-)Assembler-Code sind.
Carl D. schrieb: > Typische AVR-Firmware (*) hat damit kein Problem, weil eher alles in > Source vorliegt und kaum Sekunden bis Build-Ende braucht. Der Aufwand > Object-Libraries zu bauen, lohnt da nicht. Es gibt einen Unterschied zwischen "ich übergebe einen float" und "ich übergebe eine konstante Referenz / einen Zeiger auf einen float". Einen sehr deutlichen sogar. Wolltsjanurmaljesachthaben.
:
Bearbeitet durch User
S. R. schrieb: > Wolltsjanurmaljesachthaben Ist außerdem ziemlich egal: Johanns Beispiel zeigt, dass da eben einiges im Argen liegt, wenn eine einstmals sehr ordentlich funktionierende Optimierung plötzlich wieder verschwunden ist in einer neueren Version.
Hallo, bin auch extrem überrascht über diese krassen Unterschiede. Das wird ja richtig aufgebläht. Deswegen kann ich nun Microchip irgendwie verstehen. Aber man kann auf der anderen Seite ja etwas dagegen tun. Mal ganz naiv gefragt. Welche Programmierfähigkeiten muss man den haben um das Backend aufräumen zu können? Ist Assembler die Grundlage? Müssen die besagten 40 Dateien "nur" (im vollen Respekt) hier und da abgeändert werden oder ist das wirklich alles von Grund auf neu programmieren? Muss man dabei in völlig anderen bis dahin unbekannten Levels denken als was man sonst so für seine Programmierkünste kennt? Naiv gefragt. :-)
Johann L. schrieb: > Wilhelm M. schrieb: >> Damit wirds besser. > > Das ist doch komplett anderer Code, und du weisst das auch. Ja und? > Ersetze zum > Beispiel ein Modul (*.o), das aus meinem Code generiert wurde (egal mit > welcher Compilerversion oder welchen Schalten) mit einem Modul, das aus > deinem Code erzeugt wurde. Tja, wenn die Deklaration nicht zur Definition passt, bekomme ich undefined reference. Compiliert also nicht. Gut so. Aber Du hast meinen Punkt wohl nicht gesehen: bei Input-Parametern habe ich die Wahl, zwischen per-value oder per-const-ref. Was ich nehme, hängt von den Faktoren ab: - Muss ich eh eine Kopie machen. - Ist die Kopie aufwändig zu erstellen (bei Berücksichtung der Plattform) Da ich ja weiß, dass alles was größer als ein Byte ist, bei AVR kostenintensiv ist, lasse ich also nach Möglichkeit die Kopie weg. Es sei denn, ich brauch eine Kopie. Nun, dann muss ich eine Kopie machen, und dann ist der Maschinencode so wie er ist. In Deinem Beispiel ist es ja eine Optimierung für eine perfektes Forwarding eines Parameters. Und natürlich hast Du Recht, dass der Compiler das optimieren sollte. Das Problem entsteht m.E. wohl hauptsächlich dann, wenn die Definition der aufgerufenen Funktion in der TU nicht sichtbar ist. Verwendet man also sonst header-only Bibliotheken bleibt das Problem an der Schnittstelle zur C-Lib. Und da vermute ich, dass der o.g. Fall schon ein seltener Spezialfall ist. Wilhelm M. schrieb: > Johann L. schrieb: >> Außer >> http://gcc.gnu.org/PR84211 > > Wäre das o.g. Problem den mit Deinem Patch beseitigt? Das Problem besteht also seit v9. Die Frage hast Du nicht beantwortet: würde der Patch helfen?
Johann L. schrieb: > Es wird größer. > > Es wird langsamer. > > Er verbraucht mehr RAM (Stack). > > Beispiel:float f (float); > > float call (float x) > { > return f (x); > } > > > > Übersetzt mit v8:call: > /* prologue: function */ > /* frame size = 0 */ > /* stack size = 0 */ > .L__stack_usage = 0 > jmp f > > > > Übersetzt mit v10: > [... ewig viel Code] Jetzt wäre meine Frage, bei welcher Optimierungsstufe das auftritt. Veit D. schrieb: > O3 Optimierung ist erledigt. Ich halte beim GCC eine (globale) Optimierung mit O3 grundsätzlich für fraglich. Das gilt meiner Meinung nach insbesondere für Mikrocontroller, wo eben mal NOP-Schleifen ausgerollt werden und man sich somit schnell den Flash zukleistert. Gegebenenfalls mag eine Optimierung einzelner Funktionen mit O3 natürlich trotzdem Sinn machen.
Veit D. schrieb: > Mal ganz naiv gefragt. Welche Programmierfähigkeiten muss man den haben > um das Backend aufräumen zu können? Ist Assembler die Grundlage? Müssen > die besagten 40 Dateien "nur" (im vollen Respekt) hier und da abgeändert > werden oder ist das wirklich alles von Grund auf neu programmieren? Infosammlung: https://forum.dronebotworkshop.com/components/for-coders-the-avr-backend-of-gcc-avr-gcc-avr-g-has-been-deprecated-for-gcc-v10/ Oliver
Für mich stellt sich auch folgende Frage: cc0 wird ja erst mit gcc-11 komplett wegfallen. In gcc-10 ist es also noch enthalten, allerdings mit erheblichen (neuen) Mängeln für AVR (die vermutlich die C-Programmierer mehr treffen als die C++-Programmierer?). Wäre es möglich und sinnvoll mit vertretbarem Aufwand machbar, diese Mängel durch in-offizielle Patches zu beheben? Etwa ein gcc10-for-avr-fork? Der einzige, der hier wahrscheinlich in die Bresche springen könnte, wäre Johann. Wilhelm M. schrieb: > Wilhelm M. schrieb: >> Johann L. schrieb: >>> Außer >>> http://gcc.gnu.org/PR84211 >> >> Wäre das o.g. Problem den mit Deinem Patch beseitigt? > > Das Problem besteht also seit v9. Die Frage hast Du nicht beantwortet: > würde der Patch helfen? Den Patch habe ich mal gerade schnell angepasst. Er löst das Problem nicht (wäre ja auch zu einfach gewesen). Oder sollte er das tun und ich habe bei der Anpassung eine Fehler gemacht?
Jörg W. schrieb: > dass da eben einiges im Argen liegt, wenn eine einstmals sehr > ordentlich funktionierende Optimierung plötzlich wieder verschwunden > ist in einer neueren Version. Ist nicht wirklich eine Optimierung "verschwunden", d.h. es ist nicht so, dass v8 es fiesen Code sehen und optimieren würde. In v9/v10 tickt der Registerallokator nicht ganz richtig und entscheidet, dass memory für den Wert der beste Ablageort ist. Veit D. schrieb: > Mal ganz naiv gefragt. Welche Programmierfähigkeiten muss man den haben > um das Backend aufräumen zu können? Ist Assembler die Grundlage? Müssen > die besagten 40 Dateien "nur" (im vollen Respekt) hier und da abgeändert > werden oder ist das wirklich alles von Grund auf neu programmieren? Angefasst werden müssen i.W nur 2 Dateien: Maschinenbeschreibung (avr.md) und ein paar Hooks (avr.c). Man sollte C++ können, wobei die Codingrules die Sprachmittel auf ein sinnvolles Maß einschränken. Du wirst in GCC also keinen so irrsinnigen C++-Code sehen wie in manchen Beiträgen hier im Forum. avr.md besteht aus RTL Pattern, die Instruktion(ssequenz)en beschreiben. Das sind Lisp-ähnliche Darstellungen deren Semantik. Eine 16-Bit Addition R30 += 1 wäre zum Beispiel:
1 | (set (reg:HI 30) |
2 | (plus:HI (reg:QI 30) |
3 | (const_int 1))) |
Wobei HI "Half Integer" ist, also 16-Bit Integer. Hinzu kommen: * Attribute: Beschreiben Eigenschaften wie Instruktionslänge. * Conditions: Können eine Insn an- oder abschalten, z.B. dass ne mult-Insn nur für Devices mit MUL vorhanden ist. * Prädikate: Beschreiben, welche Typen von Operanden erlaubt sind: Memory, Register, Constanten, ... * Constraints: Beschreiben für den Register-Allokator, welche Registerklassen, Konstanten, ... für die Operanden erlaubt sind. Das sieht aus wie Constraints bei Inline-Asm. * Template: Beschreibt ähnlich einem printf-String, welcher asm-Code auszugeben ist. Das sieht aus wie das Template bei Inline-Asm. * Name: Bestimmte Insns folgen einer Nomenklatur, so dass der Compiler weiß, was das Device / Architektur kann. Gibt's z.B. eine "mulhi3", dann kann man "int16=int16*int16" berechnen, ansonsten nicht und der Compiler macht was anderes wie Call zu __mulhi3 in der libgcc. Das aktuelle cc0 beschreibt den Effekt auf SREG als Attribut. CCmode hingegen beschreibt es explizit als RTL:
1 | (parallel[ |
2 | (set (reg:HI 30) |
3 | (plus:HI (reg:QI 30) |
4 | (const_int 1))) |
5 | (set (reg:CNZV SREG) |
6 | (plus:CNZV (reg:QI 30) |
7 | (const_int 1)))]) |
Wobei SREG ein neues Hard-Reg ist und "CNZV" ein neuer Machine-Mode (so wie HI oben). "parallel" bedeutet, dass beide Effekte gleichzeitig geschehen, nicht nacheinander. Man muss sich also verschiedene, neue Machine-Modes überlegen, die den Effekt auf SREG modellieren: ADIW und SBIW setzen beide C, N, Z, V, aber mit unterschiedlicher Semantik. Und das dann für alle Insns im Backend, wobei es sich für viele nicht lohnt, den Effekt auf SREG zu modellieren. Dann kommt einfach ein "(clobber (reg:CVNZ SREG))" hinzu. > Muss man dabei in völlig anderen bis dahin unbekannten Levels denken als > was man sonst so für seine Programmierkünste kennt? Naiv gefragt. :-) Nö. Der größte Unterschied ist, dass es nicht linearer Code ist sondern eine Sammlung von Hooks und Pattern. Wilhelm M. schrieb: > Johann L. schrieb: >> Außer >> http://gcc.gnu.org/PR84211 >> > Wäre das o.g. Problem den mit Deinem Patch beseitigt? Nein. Wilhelm M. schrieb: > Tja, wenn die Deklaration nicht zur Definition passt, bekomme ich > undefined reference. Compiliert also nicht. Gut so. Und was soll dann dein Testfall darstellen? Es ist einfach anderer Code. Wenn du so um jedes Compiler-Problem rumhacken willst, viel Spaß dabei. > Aber Du hast meinen Punkt wohl nicht gesehen: bei Input-Parametern habe > ich die Wahl, zwischen per-value oder per-const-ref. Was ich nehme, > hängt von den Faktoren ab: > > - Muss ich eh eine Kopie machen. > - Ist die Kopie aufwändig zu erstellen (bei Berücksichtung der > Plattform) - Der Compiler hat keinen Bug, die dir das vermiesen. > In Deinem Beispiel ist es ja eine Optimierung für eine perfektes > Forwarding eines Parameters. Und natürlich hast Du Recht, dass der > Compiler das optimieren sollte. Das ist doch überhaupt nicht der Punkt. [ ] Ich habe verstanden, was ein Testfall für einen Compiler-Bug ist.
:
Bearbeitet durch Moderator
Also ich kann die Aussage von Microchip durchaus nachvollziehen. Bis ich der Einzige, der das Vorgehen der Verantwortlichen in diesem Projekt (GCC) höchst merkwürdig empfindet? So wie ich das verstehe, werden von anderen Entwicklern Änderungen am Compiler-Code vorgenommen (Registerallokator usw. wurde hier genannt), welche, für diese Leute, undurchschaubare Änderungen an völlig anderen Stellen (wie AVR-Backend) verursachen. Dann werden ganze Teile der Infrastruktur (wie dieses "cc0") aus dem Projekt entfernt und damit wird funktionaler Code außer Betrieb genommen usw. Alleine bei diesen zwei Punkten würde ich doch erwarten, dass erstens derjenige, der Änderungen vornimmt, auch die Auswirkungen dieser Änderungen korrigieren muss (anhand der Testcases usw. sind solche Vergrößerungen des erzeugten Codes doch nachvollziehbar) und zweitens derjenige, der sagt, dass er dieses "cc0" loswerden will, auch gefälligst den Code, der das (noch) nutzt umzustellen hat. Stattdessen stellt man sich hier noch hin und droht: "Wenn ihr unseren Mist nicht wieder in Ordnung bringt, setzen wir euch vor die Tür!" So wie ich das sehe, arbeiten Leute, wie Johann, ohne Bezahlung an diesem Projekt. Was ist denn das für eine Erwartungshaltung? Ich kann doch keine ehrenamtlichen Leute zwingen wollen, etwas zu tun, was die gar nicht gewollt haben. Einem Verein würden die Mitglieder massenhaft davonlaufen. GCC sorgt doch selbst dafür, dass sich Unternehmen nicht (finanziell) beteiligen. Wenn ein Unternehmen jetzt Geld in die Hand nimmt, um eine weitere Plattform zu unterstützen, erwartet man doch, dass diese Investition sich nicht mit der Zeit "abnutzt", ist doch ein abstruser Gedanke bei Software. Auch kann man nicht erwarten, dass eben dieses Unternehmen "am Ball bleibt" und bei jedem GCC-Release wieder Geld "nachbuttert" um die Verschlechterungen zu beheben, die dieses Unternehmen doch gar nicht wollte. Das ist für mich in etwa dieselbe Haltung wie beim Linux-Kernel. Ständig gibt es Gejammer, weil man Smartphones nicht aktuell halten kann, weil Treiber, die die binäre API für Kernel-Version xy nutzen, nicht mehr mit Version xy+1 funktionieren. Die Verantwortlichen vom Linux-Kernel sagen dann, dass der Hersteller des SoC ja für die neue Version neue Treiber entwickeln könnte - aber warum sollte man das tun? Wenn man das SoC-Produkt nicht mehr anbietet, investiert niemand mehr darein. Wir haben auch mit proprietären Lösungen in unserem Unternehmen zu tun, Kompatibilität zu zwanzig Jahren alten Komponenten ist selbstverständlich. Es geht auch anders: Bei Windows 10 x64 funktioniert auch noch ein Treiber für Windows Vista x64. Und: Bisher hat noch kein avr-gcc solch guten Code erzeugt wie der uralte Keil-Compiler für die ollen Intel 8051er. Mit LTO ging es zwar etwas in die richtige Richtung, aber seither kam kein "großer Wurf" mehr. Kurzum: Ich sehe das Problem nicht technisch begründet, eher in der Art und Weise, wie bei diesen Open-Source-Projekten (wie Linux-Kernel und GCC) Entscheidungen getroffen werden. Dass Microchip hier sagt, da machen wir nicht mit, ist die schlichte Konsequenz. Man darf nun auf mich einprügeln...
Doch die Maintainer der Backends müssen am Ball bleiben. Wenn sie das nicht tun, wird eben im Laufe der Zeitder erzeugte Code schlechter, und irgendwann fällt das Backend eben runter, wenn der Aufwand, Infrastruktur für ein nicht maintaintes Backend zu erhalten, zu große wird. GCC ist da noch recht konservativ (ähnlich wie SDCC). Bei LLVM geht sowas noch deutlich schneller. Um Fortschritte (bessere Optimierung, Unterstützung neuer Architekturen, etc) zu machen, sind eben Änderungen nötig. Klar, wenn man keine Änderungen machen würde, könnte das alte Backend ewig bleiben, und muss nicht angepasst werden. Aber dann gäbe es halt auch keinen GCC 10. Und bei GCC ist das Problem nochmal geringer, da selbst alte Zweige noch lange maintaint werden, und damit benutzbar bleiben: Selbst zu GCC 7 gab es im November noch ein Bugfix-Release 7.5.
Lars R. schrieb: > GCC sorgt doch selbst dafür, dass sich Unternehmen nicht (finanziell) > beteiligen. Ah ja. Sag das mal ARM. ;-)
Lars R. schrieb: > Einem Verein würden die Mitglieder massenhaft > davonlaufen. Du übersiehst, daß es bei gcc zum Thema "AVR" schlicht überhaupt niemanden gibt, der davonlaufen könnte. Oliver
Lars R. schrieb: > Also ich kann die Aussage von Microchip durchaus nachvollziehen. Mir gehts genau umgekehrt, ich kann gcc verstehen wenn sie irgendwann den parasitären Bremsklotz nicht mehr mitschleifen sondern einfach liegen lassen und ohne diese Last weiterziehen. > Einem Verein würden die Mitglieder massenhaft davonlaufen. In einem Verein ziehen alle gemeinsam an einem Strang, die einen mehr, die anderen weniger, aber alle immerhin ein bisschen. Entweder tun sie das als aktive Mitglieder die sich an den Tätigkeiten beteiligen oder als Fördermitglieder die sich stattdessen finanziell beteiligen. Was will zum Beispiel ein Musikverein (gcc) mit einem "Mitglied" (Microchip) das weder aktiv mitspielt noch jemals irgendwas in die Vereinskasse gezahlt hat, stattdessen aber Aufzeichnungen von dessen Auftritten unter eigenem Label publiziert? Soll der Verein ihm weiterhin seine persönlichen Musikwünsche erfüllen und ihm jedes Jahr in seiner Hofeinfahrt zum Geburtstag ein Ständchen spielen? Wie stellst Du Dir das vor?
Lars R. schrieb: > GCC sorgt doch selbst dafür, dass sich Unternehmen nicht (finanziell) > beteiligen. Wenn ein Unternehmen jetzt Geld in die Hand nimmt, um eine > weitere Plattform zu unterstützen, erwartet man doch, dass diese > Investition sich nicht mit der Zeit "abnutzt", ist doch ein abstruser > Gedanke bei Software. Auch kann man nicht erwarten, dass eben dieses > Unternehmen "am Ball bleibt" und bei jedem GCC-Release wieder Geld > "nachbuttert" um die Verschlechterungen zu beheben, die dieses > Unternehmen doch gar nicht wollte. Doch, man kann eben davon ausgehen, dass das Unternehmen Maintainer zur Verfügung stellt, wenn es denn ein langfristiges Interesse hat. Beim GCC-ARM kommen die ARM-spezifischen Dinge meist von ARM-Mitarbeitern und das obwohl sich ARM damit sogar noch selbst (nämlich Keil) Konkurenz macht. Das ist halt so ungefähr das genaue Gegenteil zu dem was Microchip macht, die sich ja für ihre XC-irgendwas Compiler sehr großzügig beim GCC bedienen aber ihre eigenen Änderungen wenn überhaupt nur widerwillig und völlig obskur veröffentlichen. Bernd K. schrieb: > Was will zum Beispiel ein Musikverein (gcc) mit einem "Mitglied" > (Microchip) das weder aktiv mitspielt noch jemals irgendwas in die > Vereinskasse gezahlt hat, stattdessen aber Aufzeichnungen von dessen > Auftritten unter eigenem Label publiziert? Soll der Verein ihm weiterhin > seine persönlichen Musikwünsche erfüllen und ihm jedes Jahr in seiner > Hofeinfahrt zum Geburtstag ein Ständchen spielen? Schöner hätte ich es nicht sagen können ;)
Lars R. schrieb: > Also ich kann die Aussage von Microchip durchaus nachvollziehen. Ne kann ich nicht. Du verdrehst nämlich Ursache und Wirkung. gcc hat mit AVR und allen anderen Plattformen erstmal gar nichts zu tun. Rein gar nichts. gcc ist nur der reine Compiler. Wer den für seine Plattform nutzen möchte dockt an. gcc ist der Einzigste große ernstzunehmende open source Compiler den es gibt und der zum Glück ständig weiterentwickelt wird. Ja selbst Intel und AMD unterstützen gcc. Obwohl Intel das nicht müßte weil die ihren eigenen haben. Warum machen die das wohl. Software hat immer ein Verfallsdatum. Jedes OS jede Anwendung entwickelt sich weiter. Jede Hardware entwickelt sich weiter. Möchtest du dich einfrieren lassen? Möchtest du ohne Fortschritt leben? Unser Leben besteht praktisch nur noch aus Software. Internet hier, Internet da, Smartphone App hier, App da, bezahlen per Smartphone, alles in Software. Wenn da was nicht funktioniert steht man blöd da. Genau deshalb darf die Entwicklung nicht stehen bleiben. Die Einfriermethode übt derzeit Microchip und vielleicht auch andere, aber hier gehts erstmal im Microchip/AVR. Die wollen beim uralten Entwicklungsstand gcc 5.4 stehen bleiben. Die werden das vermutlich aussitzen weil sich bestimmt jemand findet (Community) welche finden, der/die das am Ende machen. Wenn es dann wieder funktioniert schreien solche wie du nicht rum. Da kommen dann wieder Sätze wie, funktioniert doch alles, was habt ihr denn. Anders, wenn du was Großes programmiert hast mit vielen Libs und vielen dessen Schnittstellen und das wächst von Jahr zu Jahr immer weiter und du stellst irgendwann fest, dass die Schnittstellen nicht mehr so recht passen und du quälst dir einen ab um ja nicht daran rumfummeln zu müssen, dann wirst du auch irgendwann, hoffentlich, die Erkenntnis erlangen, entweder doch alles zu modernisieren oder du wirfst alles über den Haufen, weil du einfach kein Land mehr sieht, weil drumrumhacken auch keinen Sinn mehr macht und nur die Fehlerquote erhöht. Du merkst ich kann deine Aussage und Meinung in keinster Weise nachvollziehen. Tut mir leid dir das so sagen zu müssen. Und der Codegrößenvergleich von Microchip hinkt demzufolge auch hinten und vorne, denn wenn sie das Backend unterstützen würden, würde auch mit neuen Compiler die Codegröße wieder schrumpfen. Ganz einfache Logik.
Lars R. schrieb: > Ständig gibt es Gejammer, weil man Smartphones nicht > aktuell halten kann, weil Treiber, die die binäre API > für Kernel-Version xy nutzen, nicht mehr mit > Version xy+1 funktionieren. Von welcher "binären API" redest du eigentlich? Es gab nie eine. Lars R. schrieb: > Die Verantwortlichen vom Linux-Kernel sagen dann, dass > der Hersteller des SoC ja für die neue Version neue Treiber > entwickeln könnte - aber warum sollte man das tun? Witzigerweise glaubst du, dass ich für SoC xy und SoC xy+1 auch völlig neue Treiber bräuchte, was ebenso falsch ist wie der Rest deiner Annahmen. Ein Treiber, der normal in den Kernel integriert ist, wird (a) von den Kernel-Maintainern so lange unterstützt, wie es mit überschaubarem Aufwand möglich ist und (b) muss meist nur geringfügige Anpassungen bekommen, um mit neueren SoCs zu funktionieren. Gag am Rande: Ein für SoC-Hersteller aaa integrierter Treiber läuft auch auf SoC-Hersteller bbb, weil beide Hersteller ihre IP vom gleichen Hersteller ccc kauften. Und da liegt der Hund begraben.
Hallo, der aktuelle Stand vom Spendenkonto steht übrigens schon bei 1110,- Dollar. Die Hoffnung wächst. Vor kurzem waren es noch knapp über 300,-.
:
Bearbeitet durch User
Das AVR-Backend des llvm benötigt auch noch etwas Arbeit ;-) Funktioniert zwar schon ganz gut, aber es gibt noch einige Schwachstellen: es sind weniger AVRs spezifiziert (kann man leicht aber selbst nachziehen) und PROGMEM mit Nacharbeit geht dann auch. Etwas unschöner sind manche fehlenden Optimierungen. Aber insgesamt wenigstens schon mal benutzbar. https://bugs.llvm.org/buglist.cgi?component=Backend%3A%20AVR&list_id=109466&product=libraries&resolution=---
:
Bearbeitet durch User
Bernd K. schrieb: > Was will zum Beispiel ein Musikverein (gcc) mit einem "Mitglied" > (Microchip) das weder aktiv mitspielt noch jemals irgendwas in die > Vereinskasse gezahlt hat, Microchip hat damit garnix zu tun. Und Microchip ist kein "Mitglied" von GCC oder der FSF. Für Michrochip ist es natürlich nett, wenn es freie / open Entwicklungstools für eines ihrer Produkte gibt. Das bedeutet aber in keinster Weise eine Verpflichtung für Microchip, sich daran zu beteiligen. Wäre ungefär so, also würdest du Untestützung von Microchip erwarten / fordern, wenn du irgendein AVR-Tool programmierst oder baust. Das momentane cc0 Problem ist bzgl. avr Backend, nicht bzgl. µchip, µchip ist noch nicht mal Maintainer und war es auch nie. Nicht das ich das Gebaren von µchip bzgl. GCC toll fände, aber mit dem Momentanen GCC-cc0-CCmode Schlamassel (von dem ja auch andere Backends betroffen sind) hat das garnix zu tun. Die Situation ist eher so wie in einem Mietshaus mit Lift, wo der Vermieter einfach den Lift abstellt weil zu teuer oder was auch immer. Dem Mieter im Erdgeschoss (oder dem dort wohnenden Vermieter) ist das xxx-egal, aber dem Mieter im 1. mit Rollstuhl ist das nicht ganz so egal.
Johann L. schrieb: > Die Situation ist eher so wie in einem Mietshaus mit Lift, wo der > Vermieter einfach den Lift abstellt weil zu teuer oder was auch immer. Wer ist den in so einen OS-Projekt der Vermieter der dafür bezahlt wird? Das Bild wäre doch eher ein Haus wird genossenschaftlich verwaltet. Irgendwann hat einer auf dem Flachdach noch ein kleinen Bungalow gebaut und den Aufzug angepasst (avr-backend). Das Genossenschaftsmitglied ist aber irgendwann verschwunden (gibt ja keinen Maintainer mehr). Nun hat die Genossenschaft beschlossen, dass für barrieregerechtes Wohnen (neue Features) ein neuer Aufzug gebaut werden soll, und das Party-Volk das den Bungalow oben als tolle Event-Lokation gefunden hat fordert, das die anderen Parteien die Verlängerung auf das Dach bezahlen (= die Arbeit reinstecken) sollen, da sie sonst nicht mehr so schön feiern können...
Johann L. schrieb: > Microchip hat damit garnix zu tun. Und Microchip ist kein "Mitglied" > von GCC oder der FSF. Mein Vorposter hat das mit seinem Vereinsvergleich impliziert, ich hab das Argument nur fortgeführt.
Johannes F. schrieb: > Das Bild wäre doch eher ein Haus wird genossenschaftlich verwaltet. Vielleicht sollten wir alle komischen Bilder sein lassen und diskutieren um das es geht. 1) Microchip hat mit FSF GCC zunächst garnix zu tun, ist kein Maintainer etc. 2) Es ist ein Unterschied, ob a) Interfaces in einer Software angepasst werden, oder hinzugefügt werden, Interfaces entfernt werden für die es bessere gibt etc. Oder b) Komplette und wesentliche Teile einer Software entfernt werden (cc0), so dass andere Teile der Software i.w. neu geschrieben werden müssen (AVR Backend).
Warum ist das ein Unterschied? Wenn die Mehrheit der aktiven (wenn es nicht die Mehrheit wäre, stünde ja ein Fork im Raum) entscheidet, dass die Änderung langfristig das beste ist, dann ist das so. Dann müssen die Schnorrer die bisher einfach so von der Arbeit anderer profitiert haben entweder den Arsch hoch bekommen und auch die Anpassungen vornehmen (selber oder jemanden dafür bezahlen) oder halt weiter die alte Version nutzen. Die löst sich ja nicht in Luft auf.
Johannes F. schrieb: > Warum ist das ein Unterschied? Die Punkte hatte ich schon in meinem Beitrag aufgeführt. Alleine schon das Selbstverständnis: Die Firma Microchip ist ein börsennotierter Konzern, das andere ein Verein. Bei dem ganzen Open-Source-Zeug schwingt immer so eine überhebliche und belehrende Argumentation mit. Da wird immer von "Freiheit" usw. schwadroniert, das ist ein Wort, welches ich mit Demokratie bzw. deren Abwesenheit verbinde, aber nicht damit, wie der Lizenzvertrag für eine Software ausgestattet ist. Das aber nur am Rande. Es ist für mich ein Unding, dass man ganz einfach die ehrenamtliche Arbeit von Freiwilligen entwertet. Und, wie gesagt, gäbe es ja eine Lösung: Man darf Neuerungen einbringen, wenn derjenige, der die Neuerung bringt, auch sicherstellt, dass er alle Änderungen durchführt. Also kurzum: Derjenige, der dieses "cc0" weghaben will, muss vorher sicherstellen, dass jeglicher Code mit dem Nachfolger funktioniert. Und wenn er das nicht kann oder nicht will oder keine Zeit dafür hat oder was auch immer, hat er einfach die Finger davon zu lassen. Ich kann im Unternehmen auch nicht einfach ein Produkt aus dem Fenster werfen, wenn der Nachfolger nicht funktionsfähig ist. Aber genau hier liegt der Knackpunkt: Die wirtschaftlichen Interessen von Microchip (oder wem auch immer) sind denen egal. Vermutlich denken die sich, wenn ich daran schon nix verdiene, mache ich, was ich will. Aber dann ist der Gedanke gar nicht mehr so löblich ("Freiheit" usw.), sondern ganz im Gegenteil ziemlich egoistisch... Und ganz abgesehen davon: So wie ich das verstehe, wären viele der Probleme (Registerzuteilung usw.) dadurch auch nicht gelöst, wenn das Backend nun den "cc0"-Nachfolger nutzen würde. Offenbar weil diejenigen, die am Register-Code gearbeitet haben, diesen auch nach Belieben manipulieren ohne zu prüfen, ob tatsächlich jegliches Backend danach noch richtig funktioniert. Es fehlt, aus meiner Sicht, ganz klar an der entsprechenden Qualitätssicherung. Ich habe keine Ahnung, wie es dort geregelt ist, aber ich fürchte so wie in einem "richtigen Unternehmen" (mit entsprechenden Vorgaben) wird dort nicht gearbeitet, da darf wohl jeder an allem herum schrauben wie er mag. Wäre ich an Microchips Stelle würde ich da auch kein Geld hinein investieren ohne verbindliche Zusagen, wie die sich zu verhalten haben mit dem, was man finanziert hat.
Ich war in diesem Forum lange nicht aktiv, da mich mein Berufsleben in eine andere Welt, fern ab von Bits und Bytes geführt hat. Es ist wirklich schade was hier gerade mit dem AVR GCC passiert. Ich erinnere mich immer noch gerne zurück an diese wunderschöne Zeit, wo die Welt noch im Döschen war :-). @Jörg W: Schön das es Dich noch gibt und Du weiterhin hier aktiv bist! Ich bin Dir immer noch ein Bier schuldig (THE BEER-WARE LICENSE) :-D
Lars R. schrieb: > Also kurzum: Derjenige, der dieses "cc0" weghaben will, muss vorher > sicherstellen, dass jeglicher Code mit dem Nachfolger funktioniert. Und > wenn er das nicht kann oder nicht will oder keine Zeit dafür hat oder > was auch immer, hat er einfach die Finger davon zu lassen. Ach je, muß er das und hat er das? Steht wo, und sagt wer? So funktioniert das halt nicht. avr-gcc ist so lebending wie die Commnunity, die daran mitentwickelt. Open-Source in Reinkultur. Oliver
Oliver S. schrieb: > Ach je, muß er das und hat er das? Steht wo, und sagt wer? > So funktioniert das halt nicht. > > avr-gcc ist so lebending wie die Commnunity, die daran mitentwickelt. > Open-Source in Reinkultur. Das habe ich ja genau heraus gestellt... ;-) Ich schrieb ja, dass ich vermute, dass eben das nirgendwo in "dem Laden" steht. Und was bei dieser "Reinkultur" heraus kommt, sieht man dann. Es brauchte ja auch erst Google, die Linux in Form von Android massentauglich für Privatleute gemacht haben. Aber anstelle, dass diese Community Google dafür ein Denkmal hingestellt hat, werden die noch für ihr Engagement ständig kritisiert.
Die Freiheit ist, dass jeder die Software ändern kann. Du darfst gleich einen Fork machen, und das i386er Backend rauswerfen, wenn dir das für ein gutes AVR-Backend im Weg ist. Oder auch, dass du überhaupt die Möglichkeit hast, das AVR-Backend für die 11er Version anzupassen. Eine GCC GmbH mit Closed Source würde halt sagen: gibt es nicht mehr, pech gehabt. (Und wenn du sagst das macht keine kommerzielle Firma, schau mal z.B. wie viele APIs alleine Apple in den letzten Jahren weggeworfen hat oder welche Dienste google eingestellt hat). Aber ich finde es total überheblich anderen (die nicht von den die das fordern bezahlt werden, wenn überhaupt) vorschreiben zu wollen, wofür die ihre Zeit einsetzen. (Aber wiederum, ist OpenSource, du kannst einen Fork pflegen, der diese Regeln hat, wunder dich nur nicht, wenn die Zahl der Beitragenden überschaubar bleibt) Wenn sich keiner mehr um das AVR-Backend kümmert, weil das in 8.x perfekt war, dann bleibt doch bei 8.x und beschwert euch nicht, wenn der Rest der Welt sich weiter dreht.
Johannes F. schrieb: > Aber ich finde es total überheblich anderen (die nicht von den die das > fordern bezahlt werden, wenn überhaupt) vorschreiben zu wollen, wofür > die ihre Zeit einsetzen. Das ist ja genau das, was ich kritisiere! Leute haben das AVR-Backend mit ihrem privaten Zeiteinsatz entwickelt und nun schreibt man denen vor, dass sie entweder was machen müssen oder man ihre Arbeit "wegwirft". Das ist total überheblich - und zwar von denen, die die alte Infrastruktur weghaben wollen, denn die wollen die Änderungen selbst ja nicht durchführen...
Wieso? Deren Arbeit bleibt ja im 8.x erhalten. Und OpenSource ist nun einmal eine Do-O-cracy. Wer macht sagt an. Und die Mehrheit will die Änderungen in der Infrastruktur, sonst gäbe es einen Fork. (Siehe OpenOffice <-> LibreOffice)
Oder anders formuliert: Warum ist die (Frei-)Zeit der Leute die irgendwann das AVR-Backenend dahin gekipt haben und sich seit Jahren kaum/nicht darum kümmern mehr wert als von den Leuten die den Compiler für alle Sprachen verbessern wollen, so dass diese Zeit in das exotische Backend investieren "müssen", das sie garnicht interessiert?
Hallo Lars, >...die die alte Infrastruktur weghaben wollen... Naja, das wird ja sicher auch seinen Grund haben. Und wenn dadurch Änderungen an darauf aufbauenden Komponenten vorgenommen werden müssen, hat das doch nichts mit Arroganz zu tun. Das eigentlich Ärgerliche an dieser Situation ist doch das offensichtlich Microchip keinerlei Bereitschaft zeigt sich an einer Problemlösung zu beteiligen. Zumal es sich bei beim AVR-GCC um ein auch im professionellen Umfeld eingesetztes Werkzeug handelt und nicht um irgend eine Bastellösung. Wäre ich als Verantwortlicher in einem Unternehmen für die Auswahl der potentiellen Lieferanten verantwortlich, würde ich daraus für die Zukunft meine Schlüsse ziehen. rhf
Lars R. schrieb: > Also kurzum: Derjenige, der dieses "cc0" weghaben will, muss vorher > sicherstellen, dass jeglicher Code mit dem Nachfolger funktioniert. Nö. Warum sollte die Freizeit des Einen (der "cc0" benutzt) mehr wert sein als die Freizeit des Anderen (der "cc0" geschrieben hat) oder die Freizeit eines Dritten (der den Nachfolger vom "cc0" schreibt)? Roland F. schrieb: > Zumal es sich bei beim AVR-GCC um ein auch im professionellen Umfeld > eingesetztes Werkzeug handelt und nicht um irgend eine Bastellösung. Microchip liefert einen Compiler für die AVR-Serie, wie sie auch Compiler für die PIC-Serie liefern. Wenn du mit dem kommerziellen Support von denen nicht zufrieden bist, dann kannst du dir (aus Microchips Sicht!) die Unzufriedenheit und die Chips sonstwo hinschieben. Interessiert die nicht. Und so arbeiten dummerweise viele Firmen.
S. R. schrieb: > > Microchip liefert einen Compiler für die AVR-Serie, wie sie auch > Compiler für die PIC-Serie liefern. Wenn du mit dem kommerziellen > Support von denen nicht zufrieden bist, dann kannst du dir (aus > Microchips Sicht!) die Unzufriedenheit und die Chips sonstwo > hinschieben. Interessiert die nicht. > > Und so arbeiten dummerweise viele Firmen. Hallo, genau das ist der Knackpunkt. Microchip bietet eine funktionierende Entwicklungsumgebung an, die leider veraltet ist. Wer mit aktuellerer Toolchain programmieren möchte muss sich selbst kümmern. Leider interessiert sich Microchip nicht für C++ Programmierer. Genau um diesen Punkt entspringt die Streitfrage ob man Microchip Vorwürfe machen kann oder nicht, also ob sie die Umbauarbeiten unterstützen sollten oder nicht. Ich meine, wenn sie mitdenken würden, kämen sie drauf das ihre Produkte auch in Zukunft besser gekauft würden wenn sich rumspricht man kann diese mit > C++10 programmieren. Es werden jedoch einige Jahre ins Land gehen bis das die Runde macht. Ich meine jedoch auch, dass Microchip nicht ganz freigesprochen werden kann von der fehlenden avr-gcc Unterstützung. Schließlich enthält ihre Entwicklungsumgebung den avr-gcc Compiler. Die sind also schon darauf angewiesen das es einen avr-gcc überhaupt gibt. Das sie für die Nutzung nichts zahlen müssen ist klar. Aber man könnte ja wenn es einmal brennt freundlich unterstützen, schließlich profitiert man davon wiederum. Zudem es eine Einmalzahlung wäre. Genauso gut könnten sie für begrenzte Zeit 1-2 Programmierer abstellen. Wäre alles denkbar. Schwieriges Thema - ich weiß. Firmen ticken anders.
Veit D. schrieb: > Zudem es eine Einmalzahlung wäre. Wer sagt das? In zehn Jahren oder so wird dann vielleicht der "cc0"-Nachfolger wieder rausgeworfen, und dann? Und der GCC-"Haufen" wird sicherlich keine "Spende" unter Bedingungen akzeptieren, dass die diesen Code nie mehr unbrauchbar machen dürfen. Roland F. schrieb: > Wäre ich als Verantwortlicher in einem Unternehmen für die Auswahl der > potentiellen Lieferanten verantwortlich, würde ich daraus für die > Zukunft meine Schlüsse ziehen. Dann suche mal einen Lieferanten, der zuverlässiger als MCP ist! Du kannst heute noch PIC erhalten, die seit Ewigkeiten im Sortiment sind. Die kündigen eigentlich nie etwas ab und falls doch, gibt es einen binärkompatiblen Ersatztypen! So viel zu den Schlüssen, die du ziehen willst. Außer denen fällt mir höchstens noch Texas Instruments ein, welche ähnlich zuverlässig sind. Wenn in "meinem" Unternehmen auf MCP und TI verzichtet werden müsste, wäre ich deutlich unglücklicher als jetzt!
Hallo Lars, Lars R. schrieb: > Wer sagt das? In zehn Jahren oder so wird dann vielleicht der > "cc0"-Nachfolger wieder rausgeworfen, und dann? Dann gibt es eben wieder eine "Spende", das sind doch keine Beträge für solche Firmen. Und sie bekommen ja im Gegenzug auch etwas dafür. > Dann suche mal einen Lieferanten, der zuverlässiger als MCP ist! Du > kannst heute noch PIC erhalten, die seit Ewigkeiten im Sortiment sind. > Die kündigen eigentlich nie etwas ab und falls doch, gibt es einen > binärkompatiblen Ersatztypen! Gut, das relativiert meine Kritik zu einem guten Stück. Trotzdem wirft das Verhalten in Bezug auf den avr-gcc kein gutes Licht auf Microchip. rhf
:
Bearbeitet durch User
Veit D. schrieb: > Ich meine, wenn sie mitdenken würden, kämen sie drauf das > ihre Produkte auch in Zukunft besser gekauft würden wenn > sich rumspricht man kann diese mit > C++10 programmieren. Das bezweifle ich stark. Es gibt sicherlich die eine oder andere Nische, in der man "sehr kleine Controller" und "wirklich modernes C++" mischt, aber die sind nicht relevant genug; und C++11 kann der gcc 5.4 auch. Wenn man modernes C++ braucht, kann man jeden beliebigen ARM nehmen. Atmel hatte auch die im Angebot... zumal es für avr-gcc keine richtige libc++ gibt, insofern bringt es sowieso weniger als es könnte. Nebenfrage: Wie sieht's eigentlich mit den kommerziellen Compilern für ARM- oder PIC32 aus? Sind die auf dem gleichen Stand wie GCC oder LLVM? Veit D. schrieb: > Zudem es eine Einmalzahlung wäre. Genauso gut könnten sie für begrenzte > Zeit 1-2 Programmierer abstellen. Wäre alles denkbar. Sinnvoll wäre, einfach einen Entwickler dafür einzustellen und den machen zu lassen. Aber das sind dann laufende (Personal-)Kosten, alles noch viel schlimmerer. Ich sehe die Denkweise ja auf Arbeit auch...
Hallo, @ Lars: ich meinte das mit der "Einmalzahlung" genauso wie es Roland verstanden hat. Danke. Wenn das aller 10 Jahre passiert - na und. Daran müssen keine Bedingungen geknüpft sein. Jede größere Firma verbrennt System bedingt hier und da Geld. Der Betrag hier würde nicht sinnlos verbrannt werden. @ S.R.: Es gibt auch keinen Grund auf moderneres C++ als C++11 zu verzichten. Es gibt keinen einzigen Grund dafür. Warum soll man auf ARM wechseln? Das "Problem" liegt wie gesagt woanders. Microchip denkt nicht in C++. Die denken nur in Assembler und C. Sieht man ja in allen "AVR Manuals" an den Code Examples. Deswegen wird es denen egal sein und deswegen reicht denen auch die nächsten 100 Jahre der alte gcc 5.4. Das ist der Knackpunkt. Leider wird man das Zähneknirschend aktzeptieren müssen. Leider!
Johannes F. schrieb: > Du darfst gleich einen Fork machen Was hier grad garnix bringen würde. Was willst du denn in so einem GCC-Fork machen? Für Versionen bis v10 wird AVR eh unterstützt. Und wenn du v11 oder neuer haben wolltest, dann kannst du das AVR-Backend i.W. neu schreiben, also jedes Pattern anpassen (mit jedes wiein JEDES). Und wenn du das machen willst, dann kannst du das auch gleich im Original-GCC machen. > Oder auch, dass du überhaupt die Möglichkeit hast, das AVR-Backend für > die 11er Version anzupassen. Das hast du so auch. Aber wie bekommst du einen avr-gcc-11? Genau, du würdest die GCC-Änderungen von Master reinmergen. Die dir früher oder später den Boden unter den Füßen wegziehen, d.h. du bekommst deinen Compiler nicht mehr generiert, es sei denn du schreibst das Backend zu 90% neu. > Aber wiederum, ist OpenSource, du kannst einen Fork pflegen, Na dann mach mal.
Roland F. schrieb: > Und wenn dadurch > Änderungen an darauf aufbauenden Komponenten vorgenommen werden müssen, Das ist in etwa so wie die "Änderungen", die du machen musst, um dein C++-Projekt durch einen Python-Compiler zu bekommen – oder umgekehrt.
Johann L. schrieb: > Johannes F. schrieb: >> Du darfst gleich einen Fork machen > > Was hier grad garnix bringen würde. Was willst du denn in so einem > GCC-Fork machen? Du könntest ja z.B. einen Fork pflegen, in dem das cc0 nicht entfernt wird. Wenn man einige Beiträge so liest ist das ja eine sinnlose willkürliche Entscheidung und ansonsten alles was dir hilfreich erscheint zurückportieren. Wenn es DIR ausreichend wichtig ist, kannst du es machen. Du bist nicht auf das goodwill einer Firma angewiesen. Aber halt im Umkehrschluss, wenn es weder dir noch irgendwem anders ausreichend wichtig ist, gibt es Neuerungen nicht mehr für AVR.
Johannes F. schrieb: > gibt es Neuerungen nicht mehr für AVR. Es ist nicht nur AVR betroffen, sondern auch noch andere Backends.
J. W. schrieb: > Welche Backends sind denn noch davon betroffen? Steht doch im Link vom Eingangspost...
Johann L. schrieb: > Es ist nicht nur AVR betroffen, sondern auch noch andere Backends. Wenn soviele Backends betroffen sind die jeweils eine eigene aktive Community haben, dann ist es doch kein Problem einen Fork zu pflegen bei dem cc0 erhalten bleibt, oder sind das am Ende doch alles "Leichen" für die sich keiner ernsthaft interessiert?
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.