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?
Johannes F. schrieb:> Johann L. schrieb:
Die Sachlage scheint mir ziemlich eindeutig zu sein: Es geht hier nicht
um eine "Community" sondern um die Interessen von ARM bzw. deren
Plattform, wenn du mal im GCC-Bugtracker nachschaust, steht da bei der
Mehrheit der Bugs "arm-none-eabi" drin...
Für die klassische x86-Plattform dürfte GCC kaum Relevanz haben (außer
bei Linux), wobei das ja in der deutlichen Minderheit ist, da bei
Windows VC++ und bei Apple mittlerweile Clang eingesetzt wird.
Alle "kleinen Plattformen" zusammen können doch nicht ansatzweise die
Bedeutung erlangen, die ARM für GCC hat. Wobei Keil beim MDK (Keil ist
seit einiger Zeit eine Tochterfirma von ARM) von GCC auf Clang
gewechselt ist.
Lars R. schrieb:> Für die klassische x86-Plattform dürfte GCC kaum Relevanz haben (außer> bei Linux), wobei das ja in der deutlichen Minderheit ist, da bei> Windows VC++ und bei Apple mittlerweile Clang eingesetzt wird.
Linux dürfte wohl auf der Mehrheit aller Server eingesetzt werden. Da
von kaum Relevanz bei x86 zu sprechen halte ich für gewagt. Aber sicher
geht da bisschen was verloren was hauptsächlich an clang listen dürfte.
Aber auch beim GCC geht's aus meiner Sicht ordentlich voran. Das AVR
Backend stört da wohl und behindert den Fortschritt. Wenn es keiner
pflegt fliegt es halt nach längerer Ankündigung raus. Normaler
Fortschritt. Röhrenradios sind ja auch so gut wie ausgestorben.
Matthias
Lars R. schrieb:> Die Sachlage scheint mir ziemlich eindeutig zu sein: Es geht hier nicht> um eine "Community" sondern um die Interessen von ARM bzw. deren> Plattform, wenn du mal im GCC-Bugtracker nachschaust, steht da bei der> Mehrheit der Bugs "arm-none-eabi" drin...
Die Sache ist absolut eindeutig, und das wurde inzwischen doch auch
eindeutig geklärt:
Innerhalb von gcc gibt es niemanden, der die Verantwortung für alle
Plattformen hat. Die einzelnen Plattformen werden von aktiv
teilnehmenden Entwicklern gepflegt und weiterentwickelt. Da gibt es dann
auch mal "Pflichtarbeiten", wenn sich am gcc selber was geändert hat.
Beim avr-gcc ist nach dem "Auscheiden" von Johann die aktuelle Anzahl
der aktiv teilnehmenden Entwickler exakt Null. In Worten: 0.
Microchip will oder kann nicht, und auch sonst niemand.
Entweder findet sich bis zum Stichtag jemand, der das machen will und
kann, oder AVR ist draussen. Ende der Diskussion.
Oliver
Oliver S. schrieb:> Innerhalb von gcc gibt es niemanden, der die Verantwortung für alle> Plattformen hat. Die einzelnen Plattformen werden von aktiv> teilnehmenden Entwicklern gepflegt und weiterentwickelt. Da gibt es dann> auch mal "Pflichtarbeiten", wenn sich am gcc selber was geändert hat.
Scheint hier niemand zu raffen worum es geht.
Es geht nicht darum, dass die Backends nicht mehr maintained würden, es
gibt z.B. Bug-Fixes für die Backends etc, und wenn ein Backend so buggy
ist und das es nicht den Qualitätsstandards genügt, fliegt es raus. Und
das ist schon mehr als 1× passiert.
Was momentan abgeht ist was kompeltt anderes.
Johann L. schrieb:>> Aber wiederum, ist OpenSource, du kannst einen Fork pflegen,>> Na dann mach mal
Warum sollte ich?
Werde dafür nicht bezahlt und habe keinen Bedarf an einen AVR-compiler.
Und halt scheinbar auch so wenig andere (Bedarf an einen aktuellen
Compiler), dass keiner sich der Arbeit annimmt. (IMHO wäre es politisch
klug gewesen von MicroChip dann paar Mannmonate springen zu lassen, aber
das ist ja deren Entscheidung)
Johann L. schrieb:> Was momentan abgeht ist was kompeltt anderes.
Was den?
Das man hier und da auch größere Umbauten in Softwareprojekten vornehmen
muss, ist doch total normal und kleines 1&1 der Softwareentwicklung. Und
das dabei Teile für die sich offensichtlich kein Entwickler mehr
interessiert auf den Prüfstand gestellt werden auch.
Und ob man das Resultat dann gcc11 oder "ngcc" nennt ist doch total
egal, und passiert auch dauernd in Firmen (gut, da entscheiden meist
nicht die Entwickler sondern eher der Vertrieb, aber kommt für einen
reinen Nutzer am Ende aufs gleiche raus). Funktionen oder Produkte
werden auf einmal angekündigt, oder durch angeblich tollere Sachen
ersetzt werden, die halt in deinem Use-Case gewisse Probleme haben.
Hallo Johann,
> Was momentan abgeht ist was kompeltt anderes.
Wenn ich es richtig verstanden habe, wird das Frontend des gcc im Zuge
einer Modernisierung so verändert, das alle Backends für die jeweiligen
Prozessorfamilien neu geschrieben werden müssen.
Bei einem komplett neuen avr-Backend ist davon auszugehen, das es
einerseits schwieriger zu warten ist und andererseits auf absehbare Zeit
eine schlechtere Code-Qualität als das aktuelle Backend liefern wird.
Kurz: das Neuschreibens und Unterhalten des Backends ist sehr aufwendig
und unter Umständen auch für den Verantwortlichen nicht sehr
befriedigend.
Es stellt sich also die Frage ob es sich lohnt seine Arbeit zu
investieren, besonders vor dem Hintergrund, das das Interesse der
gcc-Verantwortlichen an "alten" Prozessoren eher gering ist und selbst
kleine, gut begründetet Änderungen/Verbesserungen im aktuellen Backend
ablehnen (wobei da offensichtlich auch Unkenntnis im Spiel ist, siehe
Beitrag "Re: newlib fuer AVR?").
Ist das in etwa so richtig?
rhf
Johann L. schrieb:> Umbauen ist was anderes als Wegschmeissen.
Sehe ich halt genau so.
Kurios finde ich an diesem Beitrag nur, dass immer gefordert wird, dass
sich jemand beteiligen möge und wenn derjenige, der genau dies jahrelang
getan hat, praktisch dieselbe Kritik äußert, wird der von denen genau so
belächelt wie ich.
Diese Geisteshaltung kann ich wirklich nicht nachvollziehen...
Johann L. schrieb:> Johannes F. schrieb:>> Das man hier und da auch größere Umbauten>> Umbauen ist was anderes als Wegschmeissen.
Aber manchmal bedingt das eine das andere, weil die Erweiterungen dann
dazu nicht mehr passen, weil sich die interne Logik ändert.
Wechselt das CMS von PHP5 nach PHP7 kannst alle PlugIns wegwerfen, die
die alte DB-API nutzen. Und das ist ja eine minimale Wartungs-Änderung.
Richtig lustig würde es ja, wenn man gleich auf verteilte Datenbanken
wechseln um richtig schön Wolkig zu sein (skaliert so schön), dann
bricht gleich alles was ACID voraussetzt / annimmt und nicht mit den
Implikationen des CAP-Theorems klarkommt.
Oder schau dir die Webbrowser an, wo kannst du noch NAPI-Plugins nutzen?
Konnte alles weggeworfen werden, weil es zum internen Umbau nicht
passte.
Das mag ja alles sein, aber Netscape war damals auch eine richtige
Firma.
Ein Open-Source-Projekt hat sich gefälligst so zu verhalten, dass die
Mitarbeit der Freiwilligen geschätzt wird, sonst braucht man sich über
mangelnde Mitarbeit nicht zu wundern.
Für mich ist das Verhalten von dem Haufen indiskutabel, da kann man
Argumente bringen wie man will. Die können sich nicht aufführen wie ein
Pascha und erwarten, dass andere diese Meinung teilen.
NAPI Plugins gabs auch beim Firefox und Chrome, beide (größtenteils -
Chrome gibts als Chromium ohne die kleinen google-Anteile) OpenSource...
Und die Erweiterung sind oftmals auch OpenSource. Ich kann nicht
erkennen, das es den Projekten geschadet hat. Browser sind stabiler
geworden (NAPI-Schnittstelle und Plugins waren eine der
Haupt-Absturzursache) und Entwickler gibt es immer noch...
Außerdem, was die Wertschätzung der Mitarbeit angeht: Zurück auf die
Frage oben, warum die Zeit der "alten" Entwickler mehr Wert haben soll
als die neuer Entwickler die aktuell Lust haben aktiv was zu machen?
Lars R. schrieb:> Ein Open-Source-Projekt hat sich gefälligst so zu verhalten, dass die> Mitarbeit der Freiwilligen geschätzt wird, sonst braucht man sich über> mangelnde Mitarbeit nicht zu wundern.
Open Source hat nichts mit Freiwilligen zu tun. Die Zeiten sind bei den
großen Projekten schon lange vorbei. Daher gehts da auch vorwärts.
Oliver
Roland F. schrieb:> Wenn ich es richtig verstanden habe, wird das Frontend des gcc im Zuge> einer Modernisierung so verändert, das alle Backends für die jeweiligen> Prozessorfamilien neu geschrieben werden müssen.
Technisch ist es ein Teil des Middleends, also weder Frontend (das
bezeichnet sprachabhängige Teile für C, C++, LTO, Ada, Fortran, ...)
noch Backend.
Es wird auch nicht wirklich was verändert, es wird einfach eine von 2
Alternativen (cc0, CCmode) rausgekickt. Das sind wesentlich
unterschiedliche Ansätze um Condition Code zu modellieren. cc0 gibt's
seit es GCC gibt, CCmode ist neuer. cc0 hat paar Nachteile, etwa können
Vergleich und Branch nur als Einheit geschedult werden, d.h.
Vergleich+Branch folgen immer direkt aufeinander. Für Architekturen wie
AVR ist das jedoch kein Nachteil.
Im Compiler werden die Alternativen i.w. unterschieden per
1
#ifdef HAVE_cc0
Was gemacht werden wird, ist effektiv alle diese Stellen zu entfernen.
> Bei einem komplett neuen avr-Backend ist davon auszugehen, das es> einerseits schwieriger zu warten ist
Etwas schwiertiger. Das Hauptproblem ist die Umstellung. cc0 hat den
Vorteil, das es ziemlich einfach ist; sowohl von der Darstellung /
Beschreibung als auch vom Ablauf.
> und andererseits auf absehbare Zeit eine schlechtere Code-Qualität> als das aktuelle Backend liefern wird.
Davon ist auszugehen. Sowohl Korrektheit als auch Performance
betreffend.
> Kurz: das Neuschreibens und Unterhalten des Backends ist sehr> aufwendig und unter Umständen auch für den Verantwortlichen nicht> sehr befriedigend.
Ja. Man kann ja nicht teilweise umstellen.
Und irgendwann wird dann noch auf einen neuen Register-Allokator
umgestellt, von RA.2 auf RA.3.
Umstellung RA.1 -> RA.2 war vor X Jahren und problemlos, im Backend hat
man davon nix gemerkt — was ja auch so sein soll. Welcher Reg-Allokator
verwendet wird ist ja unabhängig von den verwendeten Interfaces.
Mit RA.2 -> RA.3 ist das aber nicht mehr so. RA.3 kann zum Beispiel
nicht mit cc0 umgehen, und auch nicht mit CCmode falls Spill-Code den
Prozessorstatus verändern kann. Was bei AVR durchaus der Fall ist.
Größere Architekturen haben damit kein Poblem, die haben Instruktionen
wie ADD üblicherweise 2-fach: Eine Version mit Carry Setzen und eine
ohne Condition-Code zu verändern.
Weil irgendwann auf RA.3 umgestellt werden soll, fliegt auch cc0 raus,
denn RA.3 kann damit eh nicht umgehen. Und die Umsetzung von cc0 per
#ifdef ist nicht mehr ganz zeitgemäß, ginge aber auch anders. So viel
Stellen im Compiler sind das nämlich nicht. Dafür kennt RA.3 einige
Hooks nicht mehr, was für AVR mit seinen wenigen Adressregistern
bedeutet, dass X-Reg noch schlechter unterstützt wird (oder gar nicht
mehr). Oder weil RA.3 mit den wenigen Adress-Registern nicht
zurechtkommt, gibt es alle Nase lang Spill-Fails Internal Compiler
Errors.
tl;dr: Selbst falls die beiden Umstellungen irgendwann für AVR gemacht
werden, d.h. falls AVR nicht rausfliegt, wird der Code absehbar und
dauerhaft schlechter.
Johann L. schrieb:>> tl;dr: Selbst falls die beiden Umstellungen irgendwann für AVR gemacht> werden, d.h. falls AVR nicht rausfliegt, wird der Code absehbar und> dauerhaft schlechter.
'grübel' Ich dachte die ganze Zeit das durch die Umstellung der Code
wieder besser wird. Auch das dann die Codegrößen wieder schrumpfen, die
bis jetzt von Version zu Version angestiegen sind, eben weil das backend
nicht ganz optimal passt.
Also wenn das so stimmt wie gesagt, wenn!, dass die Codequalität danach
trotzdem schlecht bleibt und weiterhin schlechter wird, dann brauch ich
mich nicht ins Zeug legen für avr-gcc. Dann hole ich mir auch meine
Spende zurück. Dann hätte ja alles gar keinen Sinn. Das wäre wiederum
sehr traurig um den gcc für avr.
Veit D. schrieb:> Johann L. schrieb:>>>> tl;dr: Selbst falls die beiden Umstellungen irgendwann für AVR gemacht>> werden, d.h. falls AVR nicht rausfliegt, wird der Code absehbar und>> dauerhaft schlechter.>> 'grübel' Ich dachte die ganze Zeit das durch die Umstellung der Code> wieder besser wird.
CCmode ist einfach ein neuerer Besen, der für Boliden besser kehrt. Der
Code wird dadurch "besser" weil das Middle-End einfacher wartbar wird,
denn eine Art, den Condition Code zu modellieren (cc0), fliegt einfach
ersatzlos raus.
Für AVR und vermutlich einige / alle anderen Back-Ends die noch cc0
verwenden — oder noch bis neulich cc0 verwendeten — bringt CCmode
absehbar nix. Außer haufen Arbeit und Instabilität für / durch die
Umstellung.
> Auch das dann die Codegrößen wieder schrumpfen, die bis jetzt von> Version zu Version angestiegen sind, eben weil das backend> nicht ganz optimal passt.
Das sind keine Probleme des Back-Ends. Wenn das so wäre, wäre das im
AVR Back-End längst behoben. Die Probleme liegen im Middle-End.
> Also wenn das so stimmt wie gesagt, wenn!, dass die Codequalität danach> trotzdem schlecht bleibt und weiterhin schlechter wird, dann brauch ich> mich nicht ins Zeug legen für avr-gcc. Dann hole ich mir auch meine> Spende zurück. Dann hätte ja alles gar keinen Sinn. Das wäre wiederum> sehr traurig um den gcc für avr.
Prinzipiell ist nicht ausgeschlossen, dass sich das Middle-End in dieser
Beziehung wieder bessert. Momentan gibt es eben niemand, der die
entsprechenden Maintainer nervt. Wobei nur nerven natürlich nix bringt;
man braucht schon Testfälle. Am besten solche, die auch für ARM,
PowerPc oder x86 funktionieren, dann gehen die Dinge plötzlich ganz
fix...
Hallo,
nur mal zur Zwischeninfo. Arduino.cc antwortet nicht einmal auf Github.
Ist nun 14 Tage her. Ich wüßte auch nicht wie ich die sonst kontaktieren
sollte.
Veit D. schrieb:> 'grübel' Ich dachte die ganze Zeit das durch die Umstellung der Code> wieder besser wird. Auch das dann die Codegrößen wieder schrumpfen, die> bis jetzt von Version zu Version angestiegen sind, eben weil das backend> nicht ganz optimal passt.
Man muss in diesem Beitrag schon wirklich bewusst manche Stellen
"überlesen" wollen, um weiterhin bei der Meinung zu bleiben, dass die
Ursache dieser Probleme im AVR-Backend liegen würde.
Wie gesagt: Am GCC wird vorrangig das gemacht, was die ARM-Plattform
weiterbringt. Hier ist offenbar Kapazität bei den Entwicklern ohne Ende
vorhanden (vermutlich weil Geld fließt). Die Änderungen, die dann
gemacht werden, werden aber einfach "durchgewunken", egal, ob andere
Plattformen dadurch Nachteile erledigen oder nicht.
Und spinnen wir das mal weiter: Wenn diejenigen, die behaupten, dass
Microchip (oder wer auch immer) für die AVR-Unterstützung im GCC etwas
zahlen müsse, wieso sollten die ein Interesse daran haben, am Middleend
(oder wo auch immer) etwas zu verändern und sich nachher der Gefahr
auszusetzen, sich was anhören zu müssen, wenn ARM darunter leiden würde?
Ich bin mir ziemlich sicher: Würde jemand einen Patch comitten, der bei
AVR wieder zu einer Verbesserung, um - sagen wir mal - 10%, führt aber
gleichzeitig bei ARM nur zu 1% Verschlechterung, dann würde das einfach
reverted.
Wenn ihr das alle billig und angemessen findet - okay. Hier wird einfach
mit unterschiedlichem Maß gemessen. Man sieht das doch schon im
Bugtracker, bei ARM kann man Bugs in mehreren Stufen priorisieren, bei
den "unbeliebten" Plattformen nur in einer Stufe - egal wie gravierend
der Bug ist!
Das sind doch nachprüfbare Fakten - man schaue einfach in die
Beschreibung zum Bugmeldeverfahren bei GCC.
So viel ich weiß, ist AVR die einzige 8-Bit-Plattform bei GCC (im
offiziellen Code), andere der Plattformen, die die rauswerfen wollen,
sind 16 Bit. Wie bereits geschildert, geht es hier nicht um technische
Einschränkungen, sondern einzig um bewusste (politische) Entscheidungen.
Lars R. schrieb:> Am GCC wird vorrangig das gemacht, was die ARM-Plattform weiterbringt.
Ich glaube, das ist ein wenig zu kurz gegriffen.
Natürlich spielt ARM eine wesentliche Rolle (und zwar weniger, weil da
irgendjemand „GCC“ dafür bezahlen würde, sondern schlicht, weil ARM
selbst Entwickler dafür bezahlt, bei GCC mitzuarbeiten), aber amd64 aka
x86_64 wird ihnen gewiss mindestens genauso wichtig sein.
Aber sieh das mal andersrum: ARM bezahlt Leute dafür, dort was
mitzumachen – obwohl sie mittlerweile mit Keil einen eigenen Compiler
haben. Das hat eben Atmel und dann Microchip nie ernsthaft gemacht. Die
haben stattdessen auf IAR gesetzt oder irgendwelche eigenen
Branches/Forks befummelt – und dann zum Teil noch Geld dafür haben
wollen.
Ursprünglich war der GCC übrigens für 32-bit-CPUs konzipiert worden,
16bittige sind dann „irgendwie“ mit reingekommen, aber 8bitter waren nie
wirklich Zielsystem. Daher ist der AVR (wenn ich Johann richtig
verstanden habe) auch eher als so eine Art „Pseudo-16bit-CPU“ damals
implementiert worden – was im Gegenzug einige andere Optimierungen
verhindert hat, wenn bspw. bei einer 16-bit-Rechnung die oberen 8 Bits
gar keine Rolle spielten.
Hallo,
Wenn ARM sich aktiv um gcc kümmert muss man sich nicht wundern. Auch AMD
und Intel tragen zu gcc bei. Obwohl das Intel nicht müßte, da die ihren
eigenen Compiler hegen und pflegen.
Jörg W. schrieb:> Aber sieh das mal andersrum: ARM bezahlt Leute dafür, dort was> mitzumachen – obwohl sie mittlerweile mit Keil einen eigenen Compiler> haben. Das hat eben Atmel und dann Microchip nie ernsthaft gemacht. Die> haben stattdessen auf IAR gesetzt oder irgendwelche eigenen> Branches/Forks befummelt – und dann zum Teil noch Geld dafür haben> wollen.
Genau, kommt aufs gleiche raus nur umgedreht. Kümmerte sich früher Atmel
nicht darum und heute Microchip weiterhin nicht, dann landet alles
irgendwann auf dem Abstellgleis. Damit liegt alle Last auf den Schultern
der Community, also die die das können.
Übrigens werkelt Arduino.cc an einer "Arduino Pro IDE". Momentan noch
alles Betastatus. Aber die nutzen bei der Pro IDE den clang Compiler.
Also auch keinen gcc mehr.
Wenn das mit dem avr-backend nichts wird, sieht es echt traurig aus.
Aber noch ist nicht aller Tage Abend. Noch habe ich Hoffnung für avr im
gcc. Bei Motorola klappte es schließlich auch. Ich hatte mir das mal
spassenshalber angeschaut, weil ich hier auch so viel gefragt und
geschrieben habe, aber da blicke ich echt nicht durch. Dafür langen
meine Programmierkenntnisse einfach nicht. Selbst mit "logischer
Textersetzung" käme man nicht weit, wenn es nur Fleißarbeit wäre.
Veit D. schrieb:> Übrigens werkelt Arduino.cc an einer "Arduino Pro IDE".
Arduino hat immer nur poliert (sprich, IDE gebastelt), nie an der
Substanz gearbeitet. Weder am Compiler noch an der Basis-Bibliothek
(libc) noch an AVRDUDE. Nur ihre Abstraktionsbibliothek ist ein
nennenswerter Beitrag jenseits der IDE selbst.
Wenn ihnen plötzlich beide Compiler wegbrechen würden, würden sie
schlicht und ergreifend ziemlich alt aussehen. Allerdings wäre es aus
ihrer Sicht vermutlich einfacher, einen Fork des älteren GCC-Codes
weiter zu pflegen, statt sich um die Anpassungen im Middleend von GCC 11
zu kümmern.
Jörg W. schrieb:> Aber sieh das mal andersrum: ARM bezahlt Leute dafür, dort was> mitzumachen – obwohl sie mittlerweile mit Keil einen eigenen Compiler> haben.
Sicher?
Ich dachte, selbst in Keil MDK wird seit längerem der Arm Compiler
genutzt und damit wäre es (mehr oder weniger) nur noch eine alternative
IDE zu Arm DS5 (mit künstlich beschnittenem Device-Support).
Eine Frage bezüglich LLVM: In wie weit wären Projekte für GCC mit LLVM
kompatibel oder fängt man da wieder ganz von vorne an?
Lars R. schrieb:> Am GCC wird vorrangig das gemacht, was die ARM-Plattform weiterbringt.
ARMv7, ARMv8, x86_64 und eventuell noch x86. Das sind nunmal die großen
Architekturen, da gibt es vom Hersteller bezahlte Entwickler, und da
sind moderne Programmiersprachen relevant.
AVR ist einige Größenordnungen kleiner, es gibt keine
C++-Standardbibliothek, der Hersteller kümmert sich nicht und aktive
Entwickler gibt's auch kaum. Der meiste AVR-Code in der Welt ist
Assembler oder C, da kommt es auf aktuelle Compilerversionen nicht an.
Hier im Forum will einzig Wilhelm sein C++27 sehen.
Lars R. schrieb:> Wenn ihr das alle billig und angemessen findet - okay.
Es ist anhand der Faktenlage logisch und nachvollziehbar. Und wenn man
AVR entfernen muss, um die vier Großen voranzubringen, dann hat man in
Summe die Welt trotzdem vorangebracht.
Lars R. schrieb:> Wie bereits geschildert, geht es hier nicht um technische> Einschränkungen, sondern einzig um bewusste (politische)> Entscheidungen.
Ist es immer politisch, ein totes Pferd nicht mehr zu reiten?
> Eine Frage bezüglich LLVM: In wie weit wären Projekte für GCC mit LLVM> kompatibel oder fängt man da wieder ganz von vorne an?
Zu AVR im Clang kann ich nichts sagen, aber beim MSP430 musste man, wenn
ich mich nicht täusche, die Unterbrechungsroutinen anders markieren.
Was bei GCC z.B.
J. W. schrieb:> oder so ähnlich...
Die ISR für clang/clang++ müssen (unmangled) so heißen, wie im
startup-code definiert. Also etwa folgendermaßen.
__attribute__((interrupt)) void __vector_21(void) {}
Kann man natürlich beliebig mit CPP-Gewurstel "schöner" machen.
Lars R. schrieb:> Am GCC wird vorrangig das gemacht, was die ARM-Plattform weiterbringt.
AM GCC wird vorrangig das gemacht, was die an GCC arbeitenden Entwickler
machen. Und die stellt google, arm, redhead, ibm, codesourcery, suse,
st, ...
> Hier ist offenbar Kapazität bei den Entwicklern ohne Ende> vorhanden (vermutlich weil Geld fließt).
Es fließt kein Geld zum GCC, sondern Firmen lassen daran arbeiten (oder
auch nicht).
> Die Änderungen, die dann gemacht werden, werden aber einfach> "durchgewunken", egal, ob andere Plattformen dadurch Nachteile> erledigen oder nicht.> Und spinnen wir das mal weiter: Wenn diejenigen, die behaupten, dass> Microchip (oder wer auch immer) für die AVR-Unterstützung im GCC etwas> zahlen müsse,
Wie gesagt: Da wird nix gezahlt.
> Ich bin mir ziemlich sicher: Würde jemand einen Patch comitten, der bei> AVR wieder zu einer Verbesserung, um - sagen wir mal - 10%, führt aber> gleichzeitig bei ARM nur zu 1% Verschlechterung, dann würde das einfach> reverted.
Um einen Patch zu committen muss er erst mal durch ein Review. GCC ist
keine Code-Bonanza wo jeder einfach seinen Code reinhaut.
> okay. Hier wird einfach mit unterschiedlichem Maß gemessen.> Man sieht das doch schon im Bugtracker, bei ARM kann man Bugs> in mehreren Stufen priorisieren, bei den "unbeliebten" Plattformen> nur in einer Stufe - egal wie gravierend der Bug ist!
Wie Maße sind:
1) Primary Targets: Wichtige Host-Systeme wie x86_64, ARM, PowerPC.
Offenbar gehört AVR nicht dazu. In absehbarer Zeit wird GCC nicht auf
einem AVR laufen.
2) Secondary Targets: Targets, für die besondere Qualitätsansprüche bei
Releases gelten.
3) Der ganze Rest, z.B. avr.
Damit ein Target "secondary" ist, müssen bestimmte Voraussetzungen
gelten:
i) Das Target ist standardkonform. Trifft für avr nicht zu, denn double
ist ein 32-Bit Typ.
ii) libsupc++ wird unterstützt, das ist der minimale Kern der C++
Standard-Bibliothek und Basis der libstdc++-v3 mit z.B.
bits/c++config.h, bits/os_defines.h, bits/cpu_defines, bits/locale.h
etc. Wird von avr nicht unterstützt. Stattdessen frickelt jeder, der
avr-g++ einsetzt, seine eigenen Header zusammen.
iii) Das Target wird so gut unterstützt, dass qualitativ hochwertige GCC
Releases möglich sind. Konkret: Gibt es mit einem Target Probleme, die
von den Backend-Maintainern / -Entwicklern nicht zeitnah gelöst werden,
dann wird NICHT die GCC Release bis zum St Nimmerleinstag aufgeschoben,
sondern es gibt eine Release und das Target wird auf 3-klassig
runtergestuft.
Der einzige Punkt, wo in den letzten 10 Jahren überhaupt Bewegung
erkennbar war, ist Punkt i: Ab v10 wird 64-Bit double unterstützt –
zumindest im Compiler und der libgcc. Wann / ob die (avr-)libc 64-Bit
double unterstützt weiß ich nicht.
Und es gab durchaus Maintainer, die AVR gerne als Secondary Target
gesehen hätten genau weil die Architektur sich in einigen wesentlichen
Punkten von den anderen Targets unterscheidet.
Aber von nix kommt eben nix:
* Von Atmel kommt nix.
* Von Microchip kommt nix.
* Von der "AVR-Community" – was immer das sein soll – kommt nix.
> Das sind doch nachprüfbare Fakten - man schaue einfach in die> Beschreibung zum Bugmeldeverfahren bei GCC.
Ja, i), ii) und iii) sind definitiv nachprüfbar.
> Wie bereits geschildert, geht es hier nicht um technische> Einschränkungen, sondern einzig um bewusste (politische) Entscheidungen.
Ja, cc0 / CCmode ist ein Novum. Gebaren dieser Art gab es bislang nicht
im GCC.
Johann L. schrieb:> libsupc++ wird unterstützt, das ist der minimale Kern der C++> Standard-Bibliothek und Basis der libstdc++-v3 mit z.B.> bits/c++config.h, bits/os_defines.h, bits/cpu_defines, bits/locale.h> etc. Wird von avr nicht unterstützt.
Weiß gar nicht mehr genau, was das alles war. Teilweise vermutlich ein
nicht komplett implementiertes stdio, weiß nicht, ob die
double-Geschichte da auch mit reinspielte (auf jeden Fall tat sie's bei
FORTRAN).
Möglicherweise hätte man für standardkonformes stdio die avr-libc
aufbohren können oder zusehen, dass die newlib unterstützbar
wird/bleibt, aber wie du schon schriebst, so wirklich viel kam da auch
nie aus der Community rüber. Gerade Arduino setzt massiv auf C++ und
hätte da ja vielleicht am ehesten Motivation haben können für "tier 2"
Support - schließlich machen sie Geld damit. Aber gerade Arduino war nun
auch nie sonderlich integrativ, die haben gern genutzt, was da war, aber
ansonsten ihr eigenes Süppchen vor sich hin geköchelt.
Veit D. schrieb:> Also wenn das so stimmt wie gesagt, wenn!, dass die Codequalität danach> trotzdem schlecht bleibt und weiterhin schlechter wird, dann brauch ich> mich nicht ins Zeug legen für avr-gcc. Dann hole ich mir auch meine> Spende zurück. Dann hätte ja alles gar keinen Sinn. Das wäre wiederum> sehr traurig um den gcc für avr.
Welche Motivation hast Du eigentlich, Dich so an AVR zu klammern?
AVR ist
- nicht besonders schnell, auch nicht im Vergleich zu anderen 8 Bit
Architekturen
- nicht besonders billig, vor allem wenn man die gebotene Leistung
betrachtet, bei Digikey kostet ein Mega2560 genauso viel wie ein
PIC32MZ1024EFH100-I/PF, nur letzterer ist ein 32 Bit MIPS mit 200 MHz
und 512k RAM
- nicht besonders stromsparend mit der 5V Halbleitertechnik, da sind
Architekturen wie EFM8/EFM32 und MSP430 weiter
Es gibt ja genug Alternativen. Von daher lasst ihn sterben.
fchk
Die von dir genannten Alternativen sind aber im Vergleich zu AVR
reichliche Exoten, d.h. du findest weniger Codebeispiele rundrum und
weniger Community. Das halte ich für einen AVR schon für ein
wesentliches Argument.
Ich würde dann eher als Alternative auf 5-V-fähige ARMs ausweichen,
bspw. SAMC21.
(Wenn die direkte 5-V-Fähigkeit kein Thema ist, wird die Auswahl ja
sowieso nochmal massiv größer.)
Aber es ging in diesem Thread natürlich nicht um Alternativen zu AVRs,
sondern um GCC und deren Gebaren.
Jörg W. schrieb:> Aber es ging in diesem Thread natürlich nicht um Alternativen zu AVRs,> sondern um GCC und deren Gebaren.
Was indirekt dann doch auch mit Alternativen zu tun hat. Wenn AVR im gcc
ausstirbt (und clang nicht so schnell als vollwertiger Ersatz dienen
kann), ist das auch für Hobbiisten ein weiterer Grund, auf ARM
unzusteigen.
Oliver
Jörg W. schrieb:> Die von dir genannten Alternativen sind aber im Vergleich zu AVR> reichliche Exoten
Ich sehe da auch eher die mega0-serie bzw. tiny1 als Motivation.
Oliver S. schrieb:> Was indirekt dann doch auch mit Alternativen zu tun hat. Wenn AVR im gcc> ausstirbt (und clang nicht so schnell als vollwertiger Ersatz dienen> kann), ist das auch für Hobbiisten ein weiterer Grund, auf ARM> unzusteigen.
Das AVR backend im LLVM hat den experimentellen Status schon verloren
und funktioniert ganz passabel. Bis gcc11 da ist ohne AVR hat LLVM-11
oder 12 sicher da weiterhin aufgeholt.
Das lange lamentieren hier hilft eigentlich nur dem LLVM weiter auf die
Sprünge zu helfen. Lasst es einfach aussterben: alles hat seine Zeit.
Frank K. schrieb:> Welche Motivation hast Du eigentlich, Dich so an AVR zu klammern?
Hallo,
die Antwort ist nicht kompliziert. Weil die 8Bitter übersichtlich zum
programmieren sind und man sich nicht im Manual verliert. Ansonsten wie
Wilhelm sagt. Die neue Mega0 und Tiny1 Serie wurden Registermäßig
aufgeräumt und aufgebohrt. Benötigen in den meisten Fällen nur 1 bis 2
Takte für einen Befehl. Damit machen die schon wieder Boden gut im
Vergleich zu vermeintlich schnelleren und der I/O Port ist nicht
entkoppelt vom Kerntakt.
20MHz oder 200MHz? Was schnell ist muss man erst definieren. Es muss
ausreichend schnell sein für sein zu lösendes Problem. Für mich reicht
das was die mit ihren 16/20MHz leisten.
Was ich dazu sagen muss zur besseren Einordnung meiner Aussage(n). Ich
bin kein Entwickler der davon leben muss. Ich habe mich auf die AVR 8Bit
Architektur eingeschossen.
Veit D. schrieb:> der aktuelle Stand vom Spendenkonto steht übrigens schon bei 1110,-> Dollar. Die Hoffnung wächst. Vor kurzem waren es noch knapp über 300,-.
Ich habe gerade auch was zur Bounty dazugegeben.
Wilhelm M. schrieb:> Oliver S. schrieb:>> Ganz blöd gefragt: wie kommt man an einen avr-clang?>> git clone> cmake ...> make -j 8
Nachdem sowohl die Windows- als auch die msys2-Version des 10er
llvm/clang AVR für ein unknown triple halten, und selber compilieren in
meiner Linux-VM an zu wenig Plattenplatz gescheitert ist (da waren „nur“
60GB frei, reicht leider nicht), bleibst da nicht mehr als bei der
Hoffnung, daß das irgendwann einmal kommt.
Oliver
Oliver S. schrieb:> Wilhelm M. schrieb:>> Oliver S. schrieb:>>> Ganz blöd gefragt: wie kommt man an einen avr-clang?>>>> git clone>> cmake ...>> make -j 8>> Nachdem sowohl die Windows- als auch die msys2-Version des 10er> llvm/clang AVR für ein unknown triple halten, und selber compilieren in> meiner Linux-VM an zu wenig Plattenplatz gescheitert ist (da waren „nur“> 60GB frei, reicht leider nicht), bleibst da nicht mehr als bei der> Hoffnung, daß das irgendwann einmal kommt.
Version 11 wird es beinhalten.
Oliver S. schrieb:> selber compilieren in> meiner Linux-VM an zu wenig Plattenplatz gescheitert ist (da waren „nur“> 60GB frei, reicht leider nicht),
Weiß denn jemand wie viel Speicher benötigt wird? 60GB hätte ich in
meinem /home jetzt auch nicht frei.
Malte _. schrieb:> Oliver S. schrieb:>> selber compilieren in>> meiner Linux-VM an zu wenig Plattenplatz gescheitert ist (da waren „nur“>> 60GB frei, reicht leider nicht),>> Weiß denn jemand wie viel Speicher benötigt wird? 60GB hätte ich in> meinem /home jetzt auch nicht frei.
Bei mir sind es ca 80GB.
Oliver S. schrieb:> J. W. schrieb:>> Und 5-6 GB RAM, wenn ich mich nicht täusche.>> 8Gb ohne Swappartition reichen nicht.
Mein Kiste hat 64GB Ram und braucht 30-45min.
Mw E. schrieb:> Was ist der LLVM denn für eine Bloatware?> (ernsthafte Frage)> Den GCC kann ich auf einer Linux VM mit 30GB HDD und 1GB RAM bauen o_O
Kann der GCC dann auch Code für alle von Wilhelm genannten Targets
erzeugen? LLVM ist halt mehr als "nur" ein Compiler. Ich hab's nicht
getestet aber kann gut sein das da auch so Sachen wie clangd,
clang-format und clang-tidy dabei sind.
Oft sind die finalen Binaries auch nicht sooooo groß sondern nur die
Zwischenprodukte. WIMRE braucht man zum übersetzen von Firefox zwingend
einen Compiler/Linker der im 64 Bitmodus läuft auch wenn das exe nachher
unter 100MB hat.
Matthias
Μαtthias W. schrieb:> Kann der GCC dann auch Code für alle von Wilhelm genannten Targets> erzeugen?
Zumindest für den größten Teil (und wahrscheinlich einige Exoten mehr).
Wenn man versucht, ihn für "alle" Target zu compilieren, wird er
vermutlich noch viel "bloatiger" (da man für jedes host-target-Tupel ein
eigenes build directory braucht).
Allerdings ist das beim GCC nicht die primäre Philosophie, sondern man
baut ihn für jeweils eins dieser Tupel.
Jörg W. schrieb:> Μαtthias W. schrieb:>> Kann der GCC dann auch Code für alle von Wilhelm genannten Targets>> erzeugen?>> Zumindest für den größten Teil (und wahrscheinlich einige Exoten mehr).>> Wenn man versucht, ihn für "alle" Target zu compilieren, wird er> vermutlich noch viel "bloatiger" (da man für jedes host-target-Tupel ein> eigenes build directory braucht).>> Allerdings ist das beim GCC nicht die primäre Philosophie, sondern man> baut ihn für jeweils eins dieser Tupel.
Genau auf das wollte ich raus. clang kann das eben schon nach einem
build auch wenn dann dort noch libc und libc++ für die einzelnen
Architekturen fehlen dürften?
Matthias
Mw E. schrieb:> Was ist der LLVM denn für eine Bloatware?
Ich glaube, sowas fällt unter "moderne Softwareentwicklung".
Android ist auch so ein Monster.
Also LLVM baut immer für alle Targets?
Durchaus ein interessantes Konzept, aber bisher brauchte ich nur
x86(_64), MIPS, ARM und AVR ;)
Was will man denn zB mit powerpc und sparc?
Das dürfte doch schon eher ne Nische sein.
Mw E. schrieb:> Also LLVM baut immer für alle Targets?
Grundsätzlich ja, aber man kann natürlich auch beschränkte LLVMs bauen.
Bringt nur wenig.
> Durchaus ein interessantes Konzept, aber bisher brauchte ich nur> x86(_64), MIPS, ARM und AVR ;)
So geht es den meisten, die LLVM nur als Compiler benutzen, aber er
lässt sich auch wunderbar als Bibliothek verwenden, z.B. als
JIT-Compiler für bestimmte Bytecodes...
> Was will man denn zB mit powerpc und sparc?
...und dann braucht man diese Targets wieder, wenn das Programm auf
diesen Architekturen lauffähig sein soll.
Der große Vorteil ist natürlich, dass der Großteil von LLVM
architekturunabhängig ist (Frontend und Optimizier) und wenn man ein
Monster-Binary baut, dann ist das mit allen Backends immernoch kleiner
als fünf Kopien von Frontend und Optimizer rumzuschleppen.
> Das dürfte doch schon eher ne Nische sein.
Naja, ein Vorteil ist, dass man diese Nischen nicht vergisst, weil die
immer "dabei" sind. Da freuen sich alle drüber, die damit arbeiten. In
deinem Fall ist "AVR" so eine Nische...
Mw E. schrieb:> Was will man denn zB mit powerpc und sparc?> Das dürfte doch schon eher ne Nische sein.
Naja, wenn man ein Rechencluster betreibt, dann dürfte man mit PowerPC
oder SPARC weiter kommen als mit AVR aber ja, das sehe ich auch als
Nische.
Mikrocontroller im Allgemeinen und AVR im speziellen sehe ich aber auch
als Nische, auch wenn das aus Sicht dieses Forums vielleicht nicht so
wahrgenommen wird. In der jeweiligen Nische nehmen dann die jeweiligen
Architekturen wieder überproportional viel Platz ein, wie eben AVR im
Embedded-Bereich, wo x86 wiederum eher ein "Nischendasein" fristet.
Wenn man einen Softwareentwickler für Netzwerkhardware fragt ob MIPS
eine "Nische" darstellt, so wird er ganz sicher antworten, dass doch
MIPS allgegenwärtig ist. Selbiges gilt für den Automotive-Softwarespezi
mit seiner Power-Architektur oder eben für den Herr über den Cluster mit
seinen SPARC-Prozessoren.
Ein sehr großer "Treiber" für die Erweiterung von LLVM auf weitere
Targets dürfte die Verbreitung von Rust als Programmiersprache sein.
Gerade im Embedded-Bereich sehe ich da große Stärken gegenüber
Alternativen wie C/C++ (weil weniger fehleranfällig) oder Java/C#/Go
(weil keine GC, keine VM notwendig, kompakte Binaries etc.).
Christopher J. schrieb:> Mw E. schrieb:>> Was will man denn zB mit powerpc und sparc?>> Das dürfte doch schon eher ne Nische sein.>> Naja, wenn man ein Rechencluster betreibt, dann dürfte man mit PowerPC> oder SPARC weiter kommen als mit AVR aber ja, das sehe ich auch als> Nische.>> Mikrocontroller im Allgemeinen und AVR im speziellen sehe ich aber auch> als Nische, auch wenn das aus Sicht dieses Forums vielleicht nicht so> wahrgenommen wird. In der jeweiligen Nische nehmen dann die jeweiligen> Architekturen wieder überproportional viel Platz ein, wie eben AVR im> Embedded-Bereich, wo x86 wiederum eher ein "Nischendasein" fristet.>> Wenn man einen Softwareentwickler für Netzwerkhardware fragt ob MIPS> eine "Nische" darstellt, so wird er ganz sicher antworten, dass doch> MIPS allgegenwärtig ist. Selbiges gilt für den Automotive-Softwarespezi> mit seiner Power-Architektur oder eben für den Herr über den Cluster mit> seinen SPARC-Prozessoren.>> Ein sehr großer "Treiber" für die Erweiterung von LLVM auf weitere> Targets dürfte die Verbreitung von Rust als Programmiersprache sein.> Gerade im Embedded-Bereich sehe ich da große Stärken gegenüber> Alternativen wie C/C++ (weil weniger fehleranfällig) oder Java/C#/Go> (weil keine GC, keine VM notwendig, kompakte Binaries etc.).
Manchmal gibt es auf großen Servern laufende Software, die llvm als
Compiler verwendet. Wenn man dann als HW-Hersteller nicht aus den
Rechenzentren verschwinden will, dann muß man sich um ein llvm-Backend
kümmern. Bei mindestens einem der genannten "Nischenprozessoren" war das
so.
Und ob Fe2O3 da wirklich Einfluß hat, darf man bezweifeln.
Carl D. schrieb:> Manchmal gibt es auf großen Servern laufende Software, die llvm als> Compiler verwendet. Wenn man dann als HW-Hersteller nicht aus den> Rechenzentren verschwinden will, dann muß man sich um ein llvm-Backend> kümmern. Bei mindestens einem der genannten "Nischenprozessoren" war das> so.>> Und ob Fe2O3 da wirklich Einfluß hat, darf man bezweifeln.
Das mit dem Einfluss von Rust war nicht auf SPARC, sondern auf AVR und
MSP430 bezogen und in beiden Fällen bin ich mir relativ sicher, dass das
ein treibender Faktor war.
Für AVR ist hier ein Blog-Artikel von einem der Hauptentwickler des
llvm-avr backends:
https://dylanmckay.io/blog/rust/avr/llvm/2017/02/09/safer-microcontrollers-almost-here.html
Christopher J. schrieb:> Für AVR ist hier ein Blog-Artikel [...]
Du hättest ja dazusagen können, dass
(a) der Artikel von 2017 ist;
(b) der einzige Artikel im gesamten Blog ist;
(c) keine aktuell relevante Information enthält.
Da steht halt drin, welche Patches man 2017 brauchte, um Rust und AVR zu
machen. Mehr nicht.
S. R. schrieb:> Du hättest ja dazusagen können, dass> (a) der Artikel von 2017 ist;> (b) der einzige Artikel im gesamten Blog ist;> (c) keine aktuell relevante Information enthält.> Da steht halt drin, welche Patches man 2017 brauchte, um Rust und AVR zu> machen. Mehr nicht.
Ich fand es durchaus interessant. Weniger wegen den Patches, sondern um
zu sehen warum jemand die Motivation hatte den AVR Support zu
implementieren - und dass es scheinbar wieder ein einziger aus
Eigeninteresse motivierter Entwickler war, keine größere Gruppe, den wir
den Support zu verdanken haben.
Danke für eure Aufkllärung zum LLVM.
@Christopher
Mit Nische wollt ich jetzt nicht sagen, dass ppc und sparc so gut wie
nicht mehr existieren.
Sondern, dass doch eher sehr wenige Compilerbenutzer einen für sparc/ppc
brauchen.
ARM, x86 nutzen ja sehr viele und MIPS sollte durch PIC32 sowie das
ganze Netzwerggerödel auchnoch gut vertreten sein.
S. R. schrieb:> Du hättest ja dazusagen können, dass> (a) der Artikel von 2017 ist;
Der ist halt nicht aktuell, dafür aber "historisch wertvoll". A propos
Historie: Es war eben auch dieser Dylan McKay, der im avr-llvm Repo den
letzten Commit gemacht hat, bevor es in Mainline-LLVM gemerget wurde und
sein letzter Commit im Mainline-LLVM ist jetzt 19 Tage her. Ich denke,
das ist Beweis genug, dass der Kerl keine "Eintagsfliege" ist bzw. war.
Yalu X. schrieb:> Clang 9.0.1 mit -O1, -O2, -O3 oder -Os:>> shl8:> lsl r24> rol r25> lsl r24> rol r25> lsl r24> rol r25> lsl r24> rol r25> lsl r24> rol r25> lsl r24> rol r25> lsl r24> rol r25> lsl r24> rol r25> ret>> Neuere Clang-Versionen habe ich nicht ausprobiert. Gibt es da vielleicht> schon Fortschritte?
Gerade mit Clang 10.0.0 getestet (seit heute in den Arch-Repos). Leider
exakt das gleiche Bild. Das dürfte man durchaus mal als Bug melden.
In LLVM-IR sieht die Funktion ja noch sehr kompakt aus.
Christopher J. schrieb:> Der ist halt nicht aktuell, dafür aber "historisch wertvoll".
Ich wollte nicht meckern, dass du den Link hingestellt hast.
Nur hatte ich irgendwie erwartet, dass ich aufs Blog gehe und da dann
weiterführende Informationen finde (z.B. "was ist seit Version x.y
passiert", "heute Bug xyzzy gefixt", was man halt so in Entwicklerblogs
findet) und wurde jämmerlich enttäuscht. Darum mein Beitrag.
Ziemlich leere Blogs verschwinden meist klanglos wieder. Leider.
Christopher J. schrieb:> Das dürfte man durchaus mal als Bug melden.
Das ist ja kein Bug, sondern eine (noch) nicht implementierte
Optimierung. Als Bug würde ich das höchstens dann sehen, wenn die
Optimierung bereits implementiert wäre, aber aus irgendeinem Grund nicht
zur Anwendung käme.
Deswegen würde ich keinen Bug melden, sondern einen Feature-Request
stellen. Das kommt bei den Entwicklern positiver an als ein Bug-Report,
der implizit immer auch eine Prise Kritik enthält, die in diesem Fall
aber nicht angebracht ist.
S. R. schrieb:> Ich wollte nicht meckern, dass du den Link hingestellt hast.>> Nur hatte ich irgendwie erwartet, dass ich aufs Blog gehe und da dann> weiterführende Informationen finde (z.B. "was ist seit Version x.y> passiert", "heute Bug xyzzy gefixt", was man halt so in Entwicklerblogs> findet) und wurde jämmerlich enttäuscht. Darum mein Beitrag.
Ok, ich werde versuchen in Zukunft "gehaltvollere" Artikel zu verlinken
;)
Yalu X. schrieb:> Das ist ja kein Bug, sondern eine (noch) nicht implementierte> Optimierung.
Da hast du natürlich recht. Die Implementierung ist ja nicht kaputt,
sondern lediglich "nicht optimal".
Wilhelm M. schrieb:> Ja bitte machen: Dylan ist da ganz zugänglich ...
Ich würde es ein bisschen als "anmaßend" empfinden, wenn ich als einer
der von AVR so gut wie keine Ahnung hat, da irgendwelche
Feature-Requests oder Bug-Reports erstellt. Das überlasse ich lieber
Leuten, die sich ein bisschen besser auskennen.
Christopher J. schrieb:> Ich würde es ein bisschen als "anmaßend" empfinden, wenn ich als einer> der von AVR so gut wie keine Ahnung hat, da irgendwelche> Feature-Requests oder Bug-Reports erstellt. Das überlasse ich lieber> Leuten, die sich ein bisschen besser auskennen.
Yalu hats entdeckt, ihm gebührt die Ehre.
Hallo,
Leute, Microchip das den Betrag um satte 5000,- Dollar erhöht. Aktueller
Stand damit bei 7150,- Dollar. Hat scheinbar mein Anschreiben doch noch
etwas umdenken bewirkt. :-)
Der Betrag müßte ja nun für einen Entwickler ausreichend sein denke ich.
Wie geht das nun weiter? Wartet man bis sich Einer meldet oder liegt
schon einer auf der Lauer? Oder ...
PS: ich gehe davon aus das der Nickname vom Firmenname abgeleitet ist
und sich niemand einen Spass erlaubt hat als großzügiger Spender, wie
auch immer
Mit Firma aufkaufen und filetieren. :-) :-)
Unter anderem hatte ich denen versucht klar zu machen, dass sie sich
scheinbar nicht vorstellen können wieviel Leute ihre Controller mit C++
programmieren und das davon jeder profitiert. Scheinbar hat die
Supportabteilung die 'Info' nach oben weitergereicht. Nehme ich jetzt
einmal an. Ist aber jetzt auch egal. Ihre Reaktion war die Einzig
Richtige. :-)
Ich merke auch gerade das im obigen Text das Erste 'das' eigentlich
'hat' lauten soll. :-)
Danke für die Info.
Ich habe aber nicht herausgefunden, wie es jetzt zur Implementierung
kam. Also beispielsweise ob das Fundraising da jetzt einen Ausschlag
gegeben hat.
Beim GCC findet man auch die Optionen (Google hielt die Seiten bei
meinen Suchbegriffen nicht für relevant genug):
https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/AVR-Options.html#AVR-Optionshttps://gcc.gnu.org/install/configure.html#avr
Demnach gibt schon seit GCC 10 die Möglichkeit double als 64 Bit Werte
zu verwenden (war mir neu) :) (Ja das wird auf einem AVR langsam sein,
aber bei manchen Anwendungen spielt die Präzision eine Rolle und die
Geschwindigkeit ist Nebensache).
Malte _. schrieb:> Ich habe aber nicht herausgefunden, wie es jetzt zur Implementierung> kam. Also beispielsweise ob das Fundraising da jetzt einen Ausschlag> gegeben hat.
Mich würde das auch interessieren. Das ist doch jetzt schon die dritte
Implementierung, oder?
Vor allem liest sich dieser Maillist-Eintrag sehr bescheiden: Zu den
ohnehin deutlich schlechteren Ergebnissen der letzten Versionen gibt es
nun nochmals bis zu 3% mehr Verschlechterung - wenn das kein Fortschritt
ist...
Hallo,
wie das mit der Auszahlung ablief davon habe ich keine Ahnung. Die 3
größten Spender sollen ja Einfluss gehabt haben. Das die mich nicht
fragen war mir ja klar. ;-)
Ob die Spendensammlung ausschlaggebend war? Auch hier kann ich nur
mutmaßen. Ich denke schon. Außer irgendjemand von den Profis benötigt
avr-gcc so dringend auch in Zukunft das er es für nass gemacht hätte.
Ich weiß es ehrlich gesagt nicht. Der Reiz des Geldes wird wohl schon
welche angesprochen haben. Ich hoffe nur das sie ihr Bestens getan
haben.
Damit sind wir beim 3. Punkt. Ich hatte ehrlich gesagt mit der Aktion
gehofft bzw. bin davon ausgegangen das damit auch alle Altlasten
entsorgt werden die den kompilierten Code haben anwachsen lassen. Sieht
wohl nicht danach aus. Allerdings können die Leute immer noch daran
feilen. Wir werden sehen.
Wegen double64. Ja das hast du Johann L. hier aus dem Forum zu
verdanken.
Veit D. schrieb:> Damit sind wir beim 3. Punkt. Ich hatte ehrlich gesagt mit der Aktion> gehofft bzw. bin davon ausgegangen das damit auch alle Altlasten> entsorgt werden die den kompilierten Code haben anwachsen lassen. Sieht> wohl nicht danach aus.
Das wichtigste ist, daß jetzt weitere Arbeiten daran eine Zukunft haben.
Bisher wäre da jeder Aufwand, wie Johan ja auch angemerkt hat, beim
nächsten Releasewechsel für die Tonne gewesen.
Oliver
Hallo,
sehe ich jetzt auch so. Erstmal abwarten bis gcc 11 rauskommt und dann
schauen wir was insgesamt für avr dabei rumkam. Bis dahin kann noch viel
passieren.
Lars R. schrieb:> Kurios finde ich an diesem Beitrag nur, dass immer gefordert wird, dass> sich jemand beteiligen möge und wenn derjenige, der genau dies jahrelang> getan hat, praktisch dieselbe Kritik äußert, wird der von denen genau so> belächelt wie ich.>> Diese Geisteshaltung kann ich wirklich nicht nachvollziehen...
Johann hat etwas beigetragen und geleistet. Du nicht. :-)
Johannes F. schrieb:> Wechselt das CMS von PHP5 nach PHP7 kannst alle PlugIns wegwerfen, die> die alte DB-API nutzen. Und das ist ja eine minimale Wartungs-Änderung.> Richtig lustig würde es ja, wenn man gleich auf verteilte Datenbanken> wechseln um richtig schön Wolkig zu sein (skaliert so schön), dann> bricht gleich alles was ACID voraussetzt / annimmt und nicht mit den> Implikationen des CAP-Theorems klarkommt.
99,9 Prozent der Leute, die mir bislang über den Weg gelaufen sind und
über CAP geredet haben, haben es nicht einmal ansatzweise verstanden.
;-)
Sheeva P. schrieb:> Johann hat etwas beigetragen und geleistet. Du nicht. :-)
???
Hast du überhaupt den Beitrag gelesen? Offenbar nicht, denn sonst
würdest du das nicht schreiben. Es ging darum, dass Johann Kritik geübt
hatte und dafür von anderen kritisiert wurde - obwohl er geleistet
hat. Das habe ich angeprangert.
Wenn man deinen Satz so liest, könnte man meinen, dass ich Johann
kritisiert hätte...
Wilhelm M. schrieb:> Ich denke nicht: zwar stelle ich ein gewissen "Atmen" der Codegrößen> fest, also mal kleiner, mal größer, aber ein genereller Trend zu größer> kann ich nicht bestätigen. Gefühlt wird es eher kleiner.
Das kann ich bestätigen.
Veit D. schrieb:> Übrigens werkelt Arduino.cc an einer "Arduino Pro IDE". Momentan noch> alles Betastatus. Aber die nutzen bei der Pro IDE den clang Compiler.> Also auch keinen gcc mehr.
Bei beiden Arduino Umgebungen entsteht bei mir beim compilieren hex-Code
der gleich groß ist. Wo soll es da ein Problem geben?
Hallo,
@ Jens G.
dein Zitat und deine Antwort passen irgendwie nicht zusammen. Ich hatte
bezüglich der Pro IDE doch nur eine Feststellung beschrieben.
Wilhelm M. schrieb:> In gcc-12 ist das backend noch drin.
Was sollte sich hierbei ändern?
Feststellung: Die neue "Arduino Pro IDE" und die alte "Arduino IDE"
verwendet den gleichen Compiler.
Sorry: Bei mir ist der Eindruck entstanden, das es da Unterschiede gibt.
GCC 11.2 compiliert zumindest anstandslos AVR-Code, mit vergleichbarer
Codeeffizienz wie frühere Versionen. (Habe allerdings jetzt nur ein oder
zwei Beispiele hier verglichen.)
Jörg W. schrieb:> GCC 11.2 compiliert zumindest anstandslos AVR-Code
Gibt es irgendwo aktuelle Binaries mit LTO-Support? Dann würde ich es
mir auch einmal anschauen.
Lars R. schrieb:> Gibt es irgendwo aktuelle Binaries mit LTO-Support?
Für Windows? Keine Ahnung, sorry.
Ich baue mir den Compiler eh seit Jahren selbst. ;-) (Eigentlich schon
seit Jahrzehnten.)
Jörg W. schrieb:> GCC 11.2 compiliert zumindest anstandslos AVR-Code, mit> vergleichbarer> Codeeffizienz wie frühere Versionen.
Ist denn überhaupt bestätigt, daß der das neue backend nutzt, oder läuft
da doch noch das alte?
Oliver
Lars R. schrieb:> Gibt es irgendwo aktuelle Binaries mit LTO-Support? Dann würde ich es> mir auch einmal anschauen.
Man muss nur das Flag -flto aktivieren.
Veit D. schrieb:> Man muss nur das Flag -flto aktivieren.
Schon klar, aber LTO muss beim Buildvorgang des Compilers aktiviert
werden bzw. nicht deaktiviert worden sein.
Ich habe schon einige Jahre keine Umgebung mehr um selbst den avr-gcc zu
bauen. Nach avr-gcc 4.6.2 war ich ausgestiegen und nutze diesen bis
heute für die wenigen Projekte, bei denen ich einen avr-gcc benötige.
Lars R. schrieb:> Schon klar, aber LTO muss beim Buildvorgang des Compilers aktiviert> werden bzw. nicht deaktiviert worden sein.
Was eigentlich alle verfügbaren vorkompilierten avr-gcc toolchains
erfüllen.
Oliver
Thread beobachten
Seitenaufteilung abschalten
