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 ....
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.
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.
pumuggl schrieb:>> Kooperation mit IAR>> Mit IAR macht man ja auch nichts falsch.
Nur daß der gemeine Bastler den Preis für den Comiler nicht zahlen
will/kann. Was kostet der aktuell?
pumuggl schrieb:> Mit IAR macht man ja auch nichts falsch.
Ich arbeite auf Arbeit mit dem IAR und halte das Ding für den größten
Dreck überhaupt.
Es ist echt krass, dass dies geschafft haben von v7 auf v8 noch
schlechter zu werden.
Ich mache mir da keine allzu großen Sorgen:
Erstens hat der derzeitige AVR-GCC keinen Selbstzerstörungsmechanismus
eingebaut, und der Verschleiß von Software hält sich i.Allg. auch in
Grenzen. Wenn man seinen GCC also gut behandelt, wird er auch in 10 oder
20 Jahren noch treu seinen Dienst tun.
Zweitens wird derzeit an einem AVR-Backend für LLVM gebaut. Vielleicht
wird es ja rechtzeitig bis Mai 2021 fertig.
Und falls alle Stricke reißen: Die GNU Binutils werden den AVR sicher
bis an sein Lebensende (und noch länger) unterstützen, so dass man immer
die Möglichkeit hat, den verzuckerten Assembler¹ durch unverzuckerten zu
ersetzen (die Ärzte warnen ja sowieso vor zu viel Zucker) ;-)
Und für die Schleckermäuler, die auf den Zucker nicht verzichten wollen
(ich selber gehöre auch dazu): Es gibt neben dem AVR weitere günstige
Mikrocontroller, die auch von GCC 11+ unterstützt werden.
——————————
¹) das ist C, nach Aussage von Niklaus Wirth :)
Mw E. schrieb:> Ich arbeite auf Arbeit mit dem IAR und halte das Ding für den größten> Dreck überhaupt.
Verwechsle bitte nicht den Compiler mit der IDE. Wir vergleichen
schließlich hier mit GCC, nicht mit Eclipse, Arduino-IDE, Atmel Studio
oder dergleichen.
Den Compiler von IAR fand ich zu der Zeit, als ich ihn hin und wieder
benutzt habe, wirklich gut. Das Einzige, was ich am GCC-Port Mist fand
ist, dass er nur deren blödes proprietäres Binärformat unterstützt hat,
obwohl sie ansonsten für viele andere Targets ELF in der Tasche haben
und auch hätten den AVR-Teil auf ELF setzen können. Dann gäbe es
plötzlich wieder viel mehr Ökosystem. Das zweite, was natürlich an IAR
Mist ist, dass sie, obwohl der reine Compiler als Kommandozeilenprogramm
ja nun so gut wie keine OS-Abhängigkeit hat, ihn immer nur für Windows
gebaut haben. Ein Linux-Binary wäre mir dazumals deutlich lieber
gewesen.
Aber inzwischen habe ich ihn schon eine ganze Weile nicht mehr benutzen
müssen.
Falk B. schrieb:> Nur daß der gemeine Bastler den Preis für den Comiler nicht zahlen> will/kann.
Selbst in der Industrie ist der Preis durchaus ein Punkt. Als ich damals
bei Atmel war, kam mir mal eine Support-Anfrage eines FAE rein, dessen
(deutsche, große) Kunden von IAR auf GCC umstellen wollten: sie wollten
eine große Build-Farm für nightly builds aufbauen (was man heute wohl so
"Continuous Integration" nennen würde), und die wäre mit IAR schlicht
nicht finanzierbar gewesen.
> IAR und halte das Ding für den größten Dreck überhaupt.
Auch wenn man es ostinat wiederholt wird es nicht wahrer.
Funfact:
Eine Software mit überwiegendem Anteil an Gleitkommarechnung
(ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als
mit MDK/Keil oder GCC.
Und ja, die entsprechenden Schalter sind bei allen Compilern an.
Aber du darfst das ja gerne weiterhin als Dreck bezeichnen.
LED-Blinker profitieren eben eher nicht vom IAR-Compiler.
pumuggl schrieb:>> IAR und halte das Ding für den größten Dreck überhaupt.>> Auch wenn man es ostinat wiederholt wird es nicht wahrer.>> Funfact:> Eine Software mit überwiegendem Anteil an Gleitkommarechnung> (ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als> mit MDK/Keil oder GCC.
Bench or GTFO.
Jörg W. schrieb:> Verwechsle bitte nicht den Compiler mit der IDE. Wir vergleichen> schließlich hier mit GCC, nicht mit Eclipse, Arduino-IDE, Atmel Studio> oder dergleichen.
Nunja, das ist ein System. Bei Arduino redet man ja auch nicht nur von
den Platinen.
Zum IAR gehört nunmal einiges dazu.
Den Debugger will man ja auch nutzen?
Inzwischen schaffts der IAR sogar, dass die Breakpoints verrutschen beim
hinzufügen von Codezeilen.
Aber der Compiler selbst ist auch verbuggt.
Bei einem großen mbedTLS struct hat er andere Adressen ausgerechnet beim
Zugriff über . und ->
Da sah aus als hätt der da ein alignment vergeigt.
ssl_p ist der Pointer mit Zugriff über -> und sslvars direkt das struct
mit Zugriff über .
Die Adressen sind anders...
Dementsprechend hat der TLS Stack nicht funktioniert.
(Siehe Anhang)
Den Support kannste in der Pfeife rauchen, der wurde zu einem humanen
RSS Feed, aber in den Changelogs tauchte nie was auf was das Problem
anging.
Während der embeddet war der Support nicht erreichbar und wir brauchten
ein Plugin für nen neuren SoC für den v7.
Also ja, der IAR IST! scheisse.
pumuggl schrieb:> Auch wenn man es ostinat wiederholt wird es nicht wahrer.
Sagt der IAR Mitarbeiter ;) ?
So oft wie du das hier einstreust kann ichs mir nicht wirklich anders
vorstellen.
Fix mal lieber den Bug im Anhang.
Vincent H. schrieb:> pumuggl schrieb:>>> IAR und halte das Ding für den größten Dreck überhaupt.>>>> Auch wenn man es ostinat wiederholt wird es nicht wahrer.>>>> Funfact:>> Eine Software mit überwiegendem Anteil an Gleitkommarechnung>> (ARM M4/Float) läuft mit IAR übersetzt ca. 50 % schneller als>> mit MDK/Keil oder GCC.>> Bench or GTFO.
DITO
Mw E. schrieb:> Jörg W. schrieb:>> Verwechsle bitte nicht den Compiler mit der IDE. Wir vergleichen>> schließlich hier mit GCC, nicht mit Eclipse, Arduino-IDE, Atmel Studio>> oder dergleichen.>> Nunja, das ist ein System.
Sehe ich nicht so.
Du kannst den IAR-Compiler komplett auf der Kommandozeile benutzen (den
ganzen Lizenzsalat musst du natürlich laufen haben). Haben wir jahrelang
gemacht.
> Den Debugger will man ja auch nutzen?
Das ist der Punkt mit dem für AVR nicht unterstützten ELF-Format: würden
sie ELF als Objektformat auch bei AVR unterstützen, wäre man nicht auf
deren Debugger angewiesen, sondern könnte jeden anderen Debugger
(einschließlich Atmel Studio) ebenfalls nehmen.
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. :-)
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.
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.
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".
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.
> 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.
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?
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.
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,
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.
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`
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.
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
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.
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.
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
> ... 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
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...
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...
Die Gäste legen wieder ein Benehmen an den Tag, unglaublich.
Warum nicht...? Sicherlich weil auf der "Linkseite" noch mehr
Informationen zum Thema stehen.
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.
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.
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.'
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.
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.'
Ja mag ja alles sein. Aber gcc7 soll auch größeren Code produziert haben
im Vergleich davor. gcc8 Code wurde dann wieder kleiner. Will sagen das
die Codegrößen mit den gcc Versionen leicht mitatmen. Zudem die sich auf
gcc11 bezogen, der ja noch voll in der Entwicklung steckt wenn
vielleicht in den nächsten Wochen erstmal der finale gcc10 vor der Tür
steht. Etwas seltsam ist die Aussage schon. Selbst wenn, wenn gcc12
wieder kleinen Code produziert finden die das nicht schön?
Kann man sicherlich viel darüber spekulieren warum und warum nicht.
Ich wollte es einmal kundt tun. :-)
Veit D. schrieb:> Will sagen das> die Codegrößen mit den gcc Versionen leicht mitatmen.
Ob man die in einem der beiden Bugtracker Einträge angegebenen ~20% noch
als "leicht mitatmen" bezeichnen kann ist fraglich...
Im Readme zu XC8 2.00 ist GCC5.4 aufgeführt. Ob es da noch Änderungen
bei XC8 2.10 gab => ???
http://ww1.microchip.com/downloads/en/DeviceDoc/Readme_XC8_for_AVR.pdf
Veit D. schrieb:> Ja mag ja alles sein. Aber gcc7 soll auch größeren Code produziert haben> im Vergleich davor. gcc8 Code wurde dann wieder kleiner. Will sagen das> die Codegrößen mit den gcc Versionen leicht mitatmen.
Momentan ist es eher wie bei:
ausatmen – einatmen – nicht atmen
Hallo,
habs mal selbst untersucht. Von 20% bin ich Meilenweit entfernt. Sind
von mir 2 Projekte mit einem ATtiny841. Ich halte es nicht für
dramatisch, auch wenn der 9er derzeit mit Abstand den größten Code
erzeugt. Bin mal gespannt auf den 10er.
Nur was bei der Betrachtung komplett untern den Tisch fällt ist, wie der
Compiler das Programm optimiert. Also wird das Programm vielleicht etwas
schneller im Vergleich zum alten Compiler und man nimmt etwas mehr
Codegröße in Kauf?
Was Microchip scheinbar auch komplett nicht betrachtet hat ist, dass man
ja erst mit C++ seinen Code zur Compilezeit optimieren lassen kann. Da
ginge sicherlich "mehr" wie derzeit bei mir rauskommt. Vermutlich wissen
die das überhaupt nicht, weil sie mit C++ nichts machen. Die betrachten
nur sturr irgendwelche Dateigrößen. Laut deren Logik müßten sie dann
ihre IDE mit dem gcc 6 oder 8 ausliefern.
Aber warum rege ich mich auf, die machen eh nix.
100% Basis in der Tabelle sind die Werte vom gcc 5.4
Veit D. schrieb:> habs mal selbst untersucht. Von 20% bin ich Meilenweit entfernt. Sind> von mir 2 Projekte mit einem ATtiny841. Ich halte es nicht für> dramatisch, auch wenn der 9er derzeit mit Abstand den größten Code> erzeugt. Bin mal gespannt auf den 10er.
Interessant wäre ggf. auch nochmal das mit -O3 zu machen. Allerdings ist
das m.E. ohne eine Laufzeituntersuchung wenig zielführend.
Generell habe ich die Beobachtung gemacht, dass ggf. Änderungen am Code,
die in naiver Betrachtung eine Anwachsen des Maschinencodes nach sich
ziehen müssten, zu einem kleineren Umfang geführt haben. Dies kann ich
ad-hoc nicht durch Zahlen belegen und es handelt sich dabei um Projekte,
die vollständig aus C++-templates bestehen.
Es ist wenig verwunderlich, dass bei einem nicht oder kaum maintainten
Backend der erzeugte Code im Laufe der Zeit langsam etwas schlechter
wird.
Eigentlich sollte man immer an der Entwicklung dranbleiben, um je nach
Entwicklung der andere Teile des Compilers (dort ändert sich durch neue
Optimierungen, Bugfixes etc immer etwas) im Backend Anpassungen
vorzunehmen.
Leicht kann es ein, dass der Code, der das backend erreicht etwas anders
(meist etwas besser) ist als zuvor, aber das Backend dann nicht so gut
damit zurechtkommt, so dass der am Ende erzegte Code doch etwas
schelchter ist.
Beispiel: In den letzten Jahren wurde bei SDCC deutlich mehr Arbeit ins
stm8-Backend als ins mcs51-Backend gesteckt.
Codegrößenentwicklung Dhrystone mcs51:
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/historygraphs/dhrystone-mcs51-size.svg
Codegrößenentwicklung Dhrystone stm8:
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/historygraphs/dhrystone-stm8-size.svg
Veit D. schrieb:> Nur was bei der Betrachtung komplett untern den Tisch fällt ist,> wie der Compiler das Programm optimiert. Also wird das Programm> vielleicht etwas schneller im Vergleich zum alten Compiler und> man nimmt etwas mehr Codegröße in Kauf?
Das gilt für moderne, komplexe Architekturen im Allgemeinen eher als für
einfache Architekturen wie AVR. Pipeline-Optimierungen, die den Code
vergrößern, sind z.B. auf Prozessoren ohne nennenswerte Pipeline eher
nutzlos und können durch den erhöhten Registerdruck wieder zu
schlechteren Ergebnissen führen.
Zumal auf den kleinen Controllern die Programmgeschwindigkeit der
Codegröße eher untergeordnet ist - man hat wenig Speicher, aber meist
keinen Vorteil von einem 10% schnelleren Programm.
Veit D. schrieb:> Was Microchip scheinbar auch komplett nicht betrachtet hat ist, dass man> ja erst mit C++ seinen Code zur Compilezeit optimieren lassen kann.
Das stimmt nicht, es gibt auch optimierende C-Compiler, und irgendwo
stehen auch die Grenzen durch die Problemstellung. Ab einem gewissen
Punkt helfen nur bessere Algorithmen (so es die gibt).
Wilhelm M. schrieb:> Interessant wäre ggf. auch nochmal das mit -O3 zu machen. Allerdings ist> das m.E. ohne eine Laufzeituntersuchung wenig zielführend.
Wie gesagt, wenn man nicht gerade mit großen Caches und tiefen Pipelines
arbeitet, spart kleiner Code oft mehr Laufzeit ein als großer Code. Ein
8088 ist durch die Prefetch-Einheit limitiert, nicht durch die ALU. :-)
S. R. schrieb:> Veit D. schrieb:>> Was Microchip scheinbar auch komplett nicht betrachtet hat ist, dass man>> ja erst mit C++ seinen Code zur Compilezeit optimieren lassen kann.>> Das stimmt nicht, es gibt auch optimierende C-Compiler, und irgendwo> stehen auch die Grenzen durch die Problemstellung. Ab einem gewissen> Punkt helfen nur bessere Algorithmen (so es die gibt).
Meine Aussage sollte auf die Programmiermöglichkeiten bezogen sein die
man im einfachsten Fall mit constexpr zur Kompilierzeit wegoptimieren
lassen kann. Im weiteren Fall die "magischen" Möglichkeiten die man mit
Templates erreichen kann. Das was Wilhelm bis ins letzte Detail
exorziert. ;-)
Hallo,
O3 Optimierung ist erledigt. Allerdings klappt das mit dem 2. Projekt
nicht. Ich erhalte immer folgende Fehlermeldung mit unterschiedlichen
overlow Byte Angaben.
Error: ATtiny841_DOGM.elf section `.text' will not fit in region `text'
Worauf sich das bezieht kann ich nicht entnehmen.
Es gibt keine Dateiangabe zum Fehler nur 'Line 1'.
In Zeile 1 ist in allen Dateien entweder eine Leerzeile oder eine
Kommentarzeile.
Nebenfrage. Was ist der Unterschied zwischen der .hex und der .elf
Datei? Beide sind zum flashen geeignet und beide enthalten den
eigentlichen Programmcode. Sind die unterschiedlich komprimiert?
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
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
floatf(float);
2
3
floatcall(floatx)
4
{
5
returnf(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
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.
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.
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.
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.
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:> 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.
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=---
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
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.
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
