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.
Angehängte Dateien:
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 ;)
Angehängte Dateien:
-
prcessbomb.png
64 KB
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
Auf welcher gcc-Version basiert denn der XC8-AVR?
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
Angehängte Dateien:
-
gcc_Vergleich.png
11 KB
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. ;-)
Angehängte Dateien:
-
gcc_Vergleich.png
19 KB
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?
Thread beobachten
Seitenaufteilung abschalten
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.