Forum: Compiler & IDEs gcc11 könnte das avr Backend verlieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von dragon (Gast)


Bewertung
2 lesenswert
nicht lesenswert

:
von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gustav (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Alfed (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ver Zweifelter (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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 ....

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Ver Zweifelter schrieb:
> Zwanzigster Stock vom Hochhaus ist vermutlich ideal ....

MicroChip wird vermutlich ein Sprungtuch spannen.

von Gustav (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. ;)

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
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 ...

von Gustav (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja, genau deswegen war das der erste Satz.

von Johann L. (gjlayde) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
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

von TriHexagon (Gast)


Bewertung
9 lesenswert
nicht lesenswert
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.

von Gustav (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jemand müsste die ganzen rein AVR-optimierenden Verbesserungen, die im 
neuesten GCC existieren, für den 4.9.2 zurück portieren. ;)

von Boris (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
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?

von Boris (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
Edit: Konkurs

von Sven P. (haku) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
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.

von Sven P. (haku) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von pumuggl (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
> Kooperation mit IAR

Mit IAR macht man ja auch nichts falsch.

von Falk B. (falk)


Bewertung
5 lesenswert
nicht lesenswert
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?

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
4 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
6 lesenswert
nicht lesenswert
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 :)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
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.

von pumuggl (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
> 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.

von Vincent H. (vinci)


Bewertung
6 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Für m68k wird gerade Geld gesammelt, um jemand für die cc0 -> cc_mode 
Taransition anzuheuern :-/

http://gcc.gnu.org/ml/gcc/2019-10/msg00132.html

von Veit D. (devil-elec)


Bewertung
-2 lesenswert
nicht lesenswert
Hallo,

sagt mal Leute könnt ihr alle nicht lesen?

Wo steht hier das AVR komplett aus dem Support rausfliegt?
https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-Dropping-CC0

Es geht erstens um alte µC wie der 68000 (Amiga und Atari Generation) 
und paar andere sehr alte Teile die bestimmt schon lange nicht mehr 
produziert werden. Also erzählt bitte keinen Mist.

Jörg W., irgendwie solltest du das doch besser wissen wenn du in der 
Materie tiefer drin steckst als Entwickler.

Ich vergleiche das mit der Linuxkernelentwicklung. Hornalte Hardware 
fliegt irgendwann raus. Es muss dann ein Entwickler geben der sich um 
die betagten Teile kümmert oder die Community.

Also bitte nicht immer gleich absolute Weltuntergangspanik verbreiten.

Edit:
Jörg und Johann könnten ja einmal bitte auflisten welche alten AVR µC 
das betrifft damit die Leute hier wieder beruhigt schlafen können.  :-)

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
7 lesenswert
nicht lesenswert
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 …).

von Veit D. (devil-elec)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
7 lesenswert
nicht lesenswert
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.

von 2⁵ (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Ein "Target" ist die komplette Unterstützung für eine CPU Familie. Also 
der gesamte AVR Support!

von Veit D. (devil-elec)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ntldr -. (ntldr)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> (wie Johanns Arbeiten für 64-bit-Gleitkomma)

Ab welcher Version ist denn das enthalten?

von Michael F. (michaelfu)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Experte (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Jörg W. schrieb:
>> (wie Johanns Arbeiten für 64-bit-Gleitkomma)
>
> Ab welcher Version ist denn das enthalten?

Hallo Peter,

noch ist es nicht enthalten. Johann und andere arbeiten daran.
Beitrag "64 Bit float Emulator in C, IEEE754 compatibel"

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Ntldr -. schrieb:
> Richtig verstanden.
> ...

Alles klar.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
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".

von 900ss D. (900ss)


Bewertung
6 lesenswert
nicht lesenswert
Beruflich muss ich mit GCC 3.x.x arbeiten :) Allerdings nicht für AVR. 
Ist auch wurscht.

Aber ausgeleierte Bits produziert der nicht ;)

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
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.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:
> Lass mich raten

SPARC V8 :)

Es gibt auch neuere GCC dafür. Aber ich darf als OS RTEMS  verwenden 
welches samt Toolchain genau in dieser Version vorgegeben ist.
Aber der alte GCC tut seinen Dienst. Weshalb sollte er auch nicht.
Kann die Bedenken da oben nicht verstehen. Klar kann man die "neuen 
Features" oder was auch immer nicht verwenden. Ist aber kein Drama.

: Bearbeitet durch User
von Gustav (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Was für Vorgaben. xD Musst du zusätzlich noch im ungeheizten Keller im 
Stehen programmieren oder so? ;)

von Larry (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Markus M. (mmvisual)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Gustav (Gast)


Bewertung
7 lesenswert
nicht lesenswert
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.

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Johann L. schrieb:
> Peter D. schrieb:
>> Jörg W. schrieb:
>>> (wie Johanns Arbeiten für 64-bit-Gleitkomma)
>>
>> Ab welcher Version ist denn das enthalten?
>
> Zunächst müssen Hindernisse aus dem Weg geräumt werden, d.h. dass
> avr-gcc 64-Bit (long) double unterstützt.

Ist upstream, siehe

https://gcc.gnu.org/install/configure.html#avr

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Cool!

Ich bau bei nächstbester Gelegenheit deinen Patch in die avr-libc ein.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ich bau bei nächstbester Gelegenheit deinen Patch in die avr-libc ein.

Hast du eine Idee, wo / wie man -print-multi-lib und 
-print-multi-directory in avr-libc unterstützen könnte?

: Bearbeitet durch User
von Veit D. (devil-elec)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
.macro  ENTRY_LONG_DOUBLE32  name
#if (__SIZEOF_LONG_DOUBLE__ == __SIZEOF_FLOAT__)
  .global  _U(\name)
_U(\name):
#endif /* long double = float */
.endm

...

ENTRY asinf
ENTRY_DOUBLE32 asin
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.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:
> Bin weder Mathematiker noch Informatiker.

Wenn es dich beruhigt: ich auch nicht. ;-) (Bin Elektroniker.)

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Gescheiterter Physiker :-)

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Bin gelernter Industrieelektroniker und als Instandhalter tätig. :-)

von Johann L. (gjlayde) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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
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:
PML=`$CC -print-multi-lib`
foreach MCU
    PMD=`$CC -print-multi-directory -mmcu=$MCU`
    # Map -mmcu=$MCU to -mmcu=$ARCH
    for LINE in $PML
        if LINE.startswith("$PMD;")  # Exactly 1 line must match here.
            ARCH=LINE.extract.mmcu() # May be "" for the avr2 default.

    for LINE in $PML
        if LINE.contains("@mmcu=$ARCH@")
                or LINE.endswith("@mmcu=$ARCH")
                or ($ARCH=="" and not LINE.contains("@mmcu=")
            PATH=LINE.getpath()
            MOPTS=LINE.getoptions().filter-out("-mmcu=...")
            # avr-gcc will patch some multi-opts to align with $MCU,
            # hence the path migh also change.
            PATH=`$CC -mmcu=$MCU $MOPTS -print-multi-directory`
            # Build $PATH/crt$MCU.o
            if not exists $PATH/crt$MCU.o
                $CC -mmcu=$MCU $MOPTS $CFLAGS crt1.S -o $PATH/crt$MCU.o
            if not exists $PATH/lib$MCU.a
                # Builf lib$MCU.a using -mmcu=$MCU $MOPTS $CFLAGS

Gleiches gilt für configure.ac:  Einträge wie die folgenden
AC_CONFIG_FILES([
          avr/lib/avr2/tiny-stack/Makefile
          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".

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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:
PML = `$CC -print-multi-lib`
foreach MCU
    # Map -mmcu=$MCU to -mmcu=$ARCH
    for LINE in $PML
        OPTIONS = options($LINE).replace("-mmcu=*" with "-mmcu=$MCU")
        if path($LINE) == `$CC -print-multi-directory $OPTIONS`
            add $MCU to path($LINE)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Johann L. schrieb:
> gen-avr-lib-tree.sh (oder was auch immer avr/lib/ generiert) darf also
> nicht mehr vor configure laufen, und avr/lib/ muss irgendwo in $builddir
> generiert werden und nicht mehr in $srcdir.

Das finde ich ohnehin sinnvoll.

Mal sehen, ob mir für die crt*.o eine Heuristik einfällt.

Beitrag #6058874 wurde von einem Moderator gelöscht.
von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
CC=`echo "${CC}" | sed 's/-mmcu=avr.//'`

Wozu ist das erforderlich?

http://svn.savannah.nongnu.org/viewvc/avr-libc/trunk/avr-libc/configure.ac?revision=2544&view=markup#l459

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Johann L. schrieb:
> Inzwischen gibt es auch ein Bounty für avr-gcc:

Bounty ist bei $535.

von Johann L. (gjlayde) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Rudolph R. schrieb:
> Experte schrieb:
>> Ist ja auch logisch: Es kommt kein neuer Nutzer zu einer Plattform dazu,
>> wenn er feststellt dass es keinen aktuellen Compiler gibt.
>
> Naja, wann war der mit AS7 ausgelieferte GCC denn mal wirklich aktuell?
>
> Microchip liefert immer noch GCC 5.4.0 aus.
> Der ist aber auch erst etwas über drei Jahre "alt".

und hat Bugs:

https://gcc.gnu.org/PR87695

Zum ersten mal reportiert Ende 2018, also ca. 1 Jahr nachdem Support für 
v5 eingestellt wurde. Erste v5 Release war bereits Frühjahr 2015, 
Entwicklung daran begann Frühjahr 2014. Es war also reichlich Zeit, das 
Problem zu erkennen während v5 supported wurde (insgesamt 4 1/2) Jahre. 
Alle PRs sind aus der Zeit danach (ca 1 Report / Monat).

Die betroffene Version ist eine von Microchip, die für Arduino 
eingesetzt wird.  Der Bug wurde bereits mehrfach gemeldet, als:

https://gcc.gnu.org/PR87695
https://gcc.gnu.org/PR87771
https://gcc.gnu.org/PR88468
https://gcc.gnu.org/PR88665
https://gcc.gnu.org/PR89918
https://gcc.gnu.org/PR90286
https://gcc.gnu.org/PR90429
https://gcc.gnu.org/PR90956
https://gcc.gnu.org/PR91703
https://gcc.gnu.org/PR91904
https://gcc.gnu.org/PR93204

der jüngste PR ist von 2020-01-08.

Es könnte also durchaus sein, dass zumindest 11 Anwender von avr-gcc 
gegen eine neuere Version nix einzuwänden hätten.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Malte _. (malte) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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...

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ist das Thema eigentlich in den Arduino-Foren bekannt?

Ist ja ne aktive Community, vielleicht will da auch jemand zum Bounty 
beitragen?

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das Thema ist ein ganz heißes Eisen. Auch wenn viele bei dem Thema 
weggucken und alles kostenlos nutzen wollen, versuche ich einmal zu 
antworten.

Käufer von originalen Arduinos finanzieren schon die Arduinoentwicklung 
und dessen Forum. Auf Grund der offen gelegten Hard- und Software bauen 
die Chinesen das nach. Viele kaufen die billigen Nachbauten wovon 
Arduino.cc keinen Cent sieht. Problem daran ist auch das niemand 
überhaupt weiß wie alles finanziert wird. Chinaboards sind Spottbillig 
und der Rest ist kostenlos. Beim Download der Arduino IDE kann man 
übrigens auch spenden,  muss ich persönlich nicht machen, weil ich nur 
originale Arduinos kaufe.

Andersherum, wenn Arduino nicht offen wäre, hätte es nicht diese 
Verbreitung die es jetzt hat. Dann hätte auch bestimmt ESP nicht die 
Verbreitung, weil die einfach anwendbare IDE fehlen würde.
Henne - Ei Problem.

Wenn die Arduino IDE nun einmal den avr-gcc nutzt, müßte Arduino.cc von 
jeden verkauften Arduino einen Betrag an "avr-gcc" weiterreichen. Aber! 
Das müßten dann alle machen, nicht nur Arduino.cc. Es kann dann nicht 
sein das nur auf Arduino "rumgehackt" wird. Wenn selbst früher Atmel und 
jetzt Microchip die davon direkt abhängig sind schon keine Lust dazu 
haben "avr-gcc" richtig zu unterstützen.

Was heißt das für mich. Ich habe mehr davon wenn solche echt sinnvollen 
Sachen wir deine/eure 64Bit float Unterstützung Einzug halten statt 
immer neue C++ Sprachfeatures die bestimmt nur die wenigstens bis heute 
nutzen.

Um den Kreis zu schließen. Ich würde wenn dann viel lieber euch direkt, 
den 64Bit float Programmierern, einen Obolus zukommen lassen, als der 
großen avr-gcc Gemeinde. Das ist laut meiner Ansicht Sache der µC 
Hersteller.

Eine Gegenfrage muss noch sein. Bezahlen die Linuxnutzer irgendeinen 
Cent an die Distributationen oder gar Linuxentwickler direkt? Oder an 
die Foren wo sie Hilfe möchten? Bezahlen ESP Käufer an Arduino.cc oder 
"gcc" irgendeinen Cent?

Ich sehe hier nur Johann und Jörg ackern. Bekommt ihr was vom avr-gcc 
Kuchen ab? Ich glaube nicht. Also warum soll ich einen Obolus an 
"avr-gcc" abdrücken und nicht an euch Fleißmeisen?

Auch auf die Gefahr hin das ich bestimmte Zusammenhänge in Sachen 
avr-gcc verwechsel und die Gedankengänge etwas wild wechseln, so sollte 
doch mein Anliegen an die Bezahlproblematik zum Ausdruck gekommen sein.

Doch noch ein "Edit" was ich vermeiden wollte.
Den Usern in den Arduino Foren ist das Thema bestimmt vollkommen egal. 
Weil die sich um solche Internas nicht kümmern. Die sind mit 
Programmieren im allgemeinen voll ausgelastet. Nur ein Bruchteil vom 
Bruchteil guckt tiefer hinter die Front und beschäftigt sich mit dem 
Compiler und Toolchain.
Also ähnlich wie hier wo sich die Leute Atmel Studio installieren und 
einfach glücklich sind und nicht wissen das eine uralte Toolchain drin 
ist. Das hornalte WinAVR wird ja auch heute noch wie warme Semmeln 
angepriesen. Da ist ja mit einem offiziellen Update die Arduino IDE mit 
avr-gcc 7.3 um Welten moderner.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Kaj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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

von Troll (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> gcc11 könnte das avr Backend verlieren

Philosophische Frage: Wenn es keinen kümmert, wen stört es dann?

von Bilderstürmer (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>  ... 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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
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.

von Troll (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:
> nochmal für mich zum Verständnis. Das notwendige AVR Backend neu
> schreiben ist ein einmaliger Vorgang um zukünftig die avr Pflege im gcc
> einfacher bzw. auf dem neuen Stand zu haben? Was dann hoffentlich wieder
> für mehrere gcc Generationen nutzbar ist. Oder fängt das Spiel dann mit
> jeder gcc Version von Neuen an?

Das ist eine einmalige Maßnahme, damit zukünftige Versionen des gcc 
überhaupt noch avr -Code erzeugen können. Ohne die Änderung wird’s 
ansonsten keine aktuellen AVR-gcc mehr geben. Wobei „einmalig“ in der 
Computerwelt nicht „nie wieder“ bedeutet.

Oliver

: Bearbeitet durch User
von Bilderstürmer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Heiko L. (zer0)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jürgen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bilderstürmer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Guest (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Heiko L. (zer0)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Heiko L. schrieb:
> Nee - muss man nur ein Backend für schreiben...

Man könnte auch das alte AVR-Backend des clang reaktivieren.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Heiko L. (zer0)


Bewertung
0 lesenswert
nicht lesenswert
Volker S. schrieb:
> Jürgen schrieb:
>> Wenn die "arme" Firma Microchip keine $5000 für die Controller Familie
>> übrig hat
>
> Die Integration "aller" AVRs in den Microchip XC8 Compiler hat sicher
> mehr gekostet ;-)

Und allein die Lizenzen dafür sicher auch...

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Im Header des Problem Reports ist ein Link zum Bounty:
>
> https:/gcc.gnu.org/PR92729

Korrekte URL:

https://gcc.gnu.org/PR92729

von Bilderstürmer (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Veit D. (devil-elec)


Bewertung
6 lesenswert
nicht lesenswert
Die Gäste legen wieder ein Benehmen an den Tag, unglaublich.

Warum nicht...? Sicherlich weil auf der "Linkseite" noch mehr 
Informationen zum Thema stehen.

Beitrag #6109387 wurde von einem Moderator gelöscht.
von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Heiko L. schrieb:
>> Nee - muss man nur ein Backend für schreiben...
>
> Man könnte auch das alte AVR-Backend des clang reaktivieren.

Das AVR-Backend ist doch im Upstream-LLVM enthalten, auch wenn es vom 
Status als "experimentell" gekennzeichnet ist.

Beitrag #6110305 wurde von einem Moderator gelöscht.
Beitrag #6111390 wurde von einem Moderator gelöscht.
von S. R. (svenska)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
S. R. schrieb:
> Wer sagt denn, dass denen das nicht ganz recht wäre?

Dass sie seit der Übernahme von Atmel massiv in die Entwicklung neuer 
AVRs investiert haben. (Mega 0 und Konsorten) Diese Investition muss 
sich auf jeden Fall für sie amortisieren, d.h. so schnell, wie manch 
einer befürchtet hatte nach der Übernahme werden sie die AVR8-Plattform 
nicht aufgeben.

Warum sie sich dann nicht an der Toolchain-Entwicklung so recht 
beteiligen, erschließt sich einem dabei natürlich nicht. Gemessen an der 
Investition in die neuen AVRs wären USD 100000 für die 
Toolchain-Entwicklung ja fast nur Rauschen.

> Die großen Industriekunden nehmen lieber einen zertifizierten Compiler
> mit bezahltem Support

Hatte sich Atmel früher auch gedacht und ausschließlich auf den IAR 
gesetzt – mit denen sie, schon durch die mentale Nähe zwischen Schweden 
und Norwegen, eine gute Beziehung hatten. Sie haben sich eines besseren 
belehren lassen müssen und nach vielen Jahren irgendwann erkannt, wie 
viel ihnen der AVR-GCC letztlich an Reputation und damit indirekt auch 
Umsatz produziert hat.

: Bearbeitet durch Moderator
von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Okay, danke für die Erläuterung.

von Veit D. (devil-elec)


Bewertung
1 lesenswert
nicht lesenswert
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.
Please find the response from our internal team below

'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.

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.'

von Carl D. (jcw2)


Bewertung
1 lesenswert
nicht lesenswert
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.
.
>
> Please find the response from our internal team below
> 
> '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.
> 
> 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.'
> 

Eine wirklich innovative Strategie.

von S. R. (svenska)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Veit D. (devil-elec)


Bewertung
1 lesenswert
nicht lesenswert
Ne, die schieben den letzten Satz als Grund vor. Die wollen auf einer 
alten gcc Version sitzen bleiben.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Für C++-Anwender können sie sich etwas mehr Zeit lassen, denn C++23 wird 
ja wohl ein (fast) library-only change.

von Gerd E. (robberknight)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
1 lesenswert
nicht lesenswert
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).

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Michael F. (michaelfu)


Bewertung
0 lesenswert
nicht lesenswert
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.
>
>
> 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.'
> 

Ich nehme an, die beziehen sich auf die folgenden beiden Einträge, laut 
denen GCC9 für AVR unter gewissen Umständen signifikant größeren Code 
generiert, als GCC8:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91189

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Auf welcher gcc-Version basiert denn der XC8-AVR?

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.  :-)

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Auf welcher gcc-Version basiert denn der XC8-AVR?

Weiß ich nicht.

von Michael F. (michaelfu)


Bewertung
0 lesenswert
nicht lesenswert
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

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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

von Veit D. (devil-elec)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

habs mal selbst untersucht. Von 20% bin ich Meilenweit entfernt. Sind 
von mir 2 Projekte mit einem ATtiny841. Ich halte es nicht für 
dramatisch, auch wenn der 9er derzeit mit Abstand den größten Code 
erzeugt. Bin mal gespannt auf den 10er.

Nur was bei der Betrachtung komplett untern den Tisch fällt ist, wie der 
Compiler das Programm optimiert. Also wird das Programm vielleicht etwas 
schneller im Vergleich zum alten Compiler und man nimmt etwas mehr 
Codegröße in Kauf?

Was Microchip scheinbar auch komplett nicht betrachtet hat ist, dass man 
ja erst mit C++ seinen Code zur Compilezeit optimieren lassen kann. Da 
ginge sicherlich "mehr" wie derzeit bei mir rauskommt. Vermutlich wissen 
die das überhaupt nicht, weil sie mit C++ nichts machen. Die betrachten 
nur sturr irgendwelche Dateigrößen. Laut deren Logik müßten sie dann 
ihre IDE mit dem gcc 6 oder 8 ausliefern.

Aber warum rege ich mich auf, die machen eh nix.

100% Basis in der Tabelle sind die Werte vom gcc 5.4

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
1 lesenswert
nicht lesenswert
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

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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. :-)

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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 
ex­or­zie­rt.  ;-)

von Veit D. (devil-elec)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

O3 Optimierung ist erledigt. Allerdings klappt das mit dem 2. Projekt 
nicht. Ich erhalte immer folgende Fehlermeldung mit unterschiedlichen 
overlow Byte Angaben.
Error:  ATtiny841_DOGM.elf section `.text' will not fit in region `text'
Worauf sich das bezieht kann ich nicht entnehmen.
Es gibt keine Dateiangabe zum Fehler nur 'Line 1'.
In Zeile 1 ist in allen Dateien entweder eine Leerzeile oder eine 
Kommentarzeile.

Nebenfrage. Was ist der Unterschied zwischen der .hex und der .elf 
Datei? Beide sind zum flashen geeignet und beide enthalten den 
eigentlichen Programmcode. Sind die unterschiedlich komprimiert?

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:
> Error:  ATtiny841_DOGM.elf section `.text' will not fit in region `text'
> Worauf sich das bezieht kann ich nicht entnehmen.

Das sagt eigentlich genau das, was es meint: Das Programm passt nicht in 
den Speicher. Wie du ja auch bei Projekt1 seihst, ist die benötigte 
Flashgröße mit -O3 größer als bei den anderen Versionen.

Die .hex-Datei enthält nur den nackten Programmcode, die .elf-Datei 
zusätlich noch Symbole etc.

Kompilier

: Bearbeitet durch User
von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Jetzt wo ihr es sagt.  :-)
Ich konnte mit 'text' nichts anfangen. Damit ist sicherlich der 
Programmcode gemeint.
Danke.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:
> Ich konnte mit 'text' nichts anfangen. Damit ist sicherlich der
> Programmcode gemeint.

So ist es.

von Johann L. (gjlayde) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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:
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:
call:
  push r28
  push r29
  rcall .
  rcall .
  in r28,__SP_L__
  in r29,__SP_H__
/* prologue: function */
/* frame size = 4 */
/* stack size = 6 */
.L__stack_usage = 6
  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
/* epilogue start */
  pop __tmp_reg__
  pop __tmp_reg__
  pop __tmp_reg__
  pop __tmp_reg__
  pop r29
  pop r28
  jmp f

Es gibt auch nicht-triviale Beispiele und auch welche ohne float.

> Was Microchip scheinbar auch komplett nicht betrachtet hat ist,
> dass man ja erst mit C++ seinen Code zur Compilezeit optimieren
> lassen kann.

Features wie constexpr und Zeugs lassen einen evtl. kompakteren Code 
formulieren, das behebt aber nicht die Bugs an anderer Stelle.  Und ein 
Artefekt, das so krass ist wie das obige, würde ich durchaus als Bug 
bezeichnen.  Bei 'nem Testfall wie dem obigen hilft dir constexpr oder C 
vs. C++ grad garnix.

Wilhelm M. schrieb:
> es handelt sich dabei um Projekte,
> die vollständig aus C++-templates bestehen.

Was über das Programm (außer über seine Wartbarkeit und Anpassbarkeit / 
Portierbarkeit) nix aussagt.

Für jedes Programm mit Templates gibt es ein Progremm ohne Templates, 
das (bei gleichem Compiler, gleichen Optionen, gleichen 
Umgebungsvariablen und abgesehen von Debug-Info) den gleichen Code 
generiert.  Um gekehrt lässt sich jedes Programm ohne Templates so mit 
beliebig vielen Tamplates dekorieren, dass das Programm effektiv das 
gleiche ist und der erzeugte Code der selbe.

Philipp Klaus K. schrieb:
> Es ist wenig verwunderlich, dass bei einem nicht oder kaum maintainten
> Backend der erzeugte Code im Laufe der Zeit langsam etwas schlechter
> wird.
>
> Eigentlich sollte man immer an der Entwicklung dranbleiben, um je nach
> Entwicklung der andere Teile des Compilers (dort ändert sich durch neue
> Optimierungen, Bugfixes etc immer etwas) im Backend Anpassungen
> vorzunehmen.
>
> Leicht kann es ein, dass der Code, der das backend erreicht etwas anders
> (meist etwas besser) ist als zuvor, aber das Backend dann nicht so gut
> damit zurechtkommt, so dass der am Ende erzegte Code doch etwas
> schelchter ist.

Vielleicht ist ja nicht klar, was im GCC ein "Backend" darstellt.

Das Backend ist eine Sammlung von Pattern und Hooks, die bestimmte 
Aufgaben erledigen oder beschreiben.  Organisatorisch besteht es nur aus 
'ner handvoll Dateien (momenten ca. 40), aber die Ausführung ist nicht 
in einem Block oder linear à la Frontend -> Middleend -> Backend.

Jedenfalls ist es nicht so, dass das Backend nach dem Middleend den Code 
"übernimmt" und danach bis zur finalen Assembler-Ausgabe alleinig 
transformiert — oder überhaupt transformiert, das passiert nur an ca. 5 
Stellen für AVR-spezfische Optimierungen oder Built-ins.

> Beispiel: In den letzten Jahren wurde bei SDCC deutlich mehr Arbeit ins
> stm8-Backend als ins mcs51-Backend gesteckt.

Das oben gezeigte Problem ist nicht nur kein Problem des AVR-Backends, 
es ist noch nicht einmal möglich, im AVR-Backend drumrum zu hacken.  So 
ziemlich alle Optimierungen, die halbwegs sinnvoll im AVR-Backend 
implementierbar sind, sind dort implementiert.  Außer 
http://gcc.gnu.org/PR84211

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Bei 'nem Testfall wie dem obigen hilft dir constexpr oder C
> vs. C++ grad garnix.

Schon:
using tt = float;

tt f (const tt& x);

tt call(const tt& x) {
    return f(x);
}

Damit wirds besser.

von Johann L. (gjlayde) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
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.

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Typische AVR-Firmware (*) hat damit kein Problem, weil eher alles in
> Source vorliegt und kaum Sekunden bis Build-Ende braucht. Der Aufwand
> Object-Libraries zu bauen, lohnt da nicht.

Es gibt einen Unterschied zwischen "ich übergebe einen float" und "ich 
übergebe eine konstante Referenz / einen Zeiger auf einen float". Einen 
sehr deutlichen sogar.

Wolltsjanurmaljesachthaben.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.  :-)

von Wilhelm M. (wimalopaan)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:
> Mal ganz naiv gefragt. Welche Programmierfähigkeiten muss man den haben
> um das Backend aufräumen zu können? Ist Assembler die Grundlage? Müssen
> die besagten 40 Dateien "nur" (im vollen Respekt) hier und da abgeändert
> werden oder ist das wirklich alles von Grund auf neu programmieren?

Infosammlung:

https://forum.dronebotworkshop.com/components/for-coders-the-avr-backend-of-gcc-avr-gcc-avr-g-has-been-deprecated-for-gcc-v10/

Oliver

von Wilhelm M. (wimalopaan)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Johann L. (gjlayde) Benutzerseite


Bewertung
6 lesenswert
nicht lesenswert
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:
(set (reg:HI 30)
     (plus:HI (reg:QI 30)
              (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:
(parallel[
    (set (reg:HI 30)
         (plus:HI (reg:QI 30)
                  (const_int 1)))
    (set (reg:CNZV SREG)
         (plus:CNZV (reg:QI 30)
                    (const_int 1)))])

Wobei SREG ein neues Hard-Reg ist und "CNZV" ein neuer Machine-Mode (so 
wie HI oben). "parallel" bedeutet, dass beide Effekte gleichzeitig 
geschehen, nicht nacheinander.

Man muss sich also verschiedene, neue Machine-Modes überlegen, die den 
Effekt auf SREG modellieren: ADIW und SBIW setzen beide C, N, Z, V, aber 
mit unterschiedlicher Semantik.

Und das dann für alle Insns im Backend, wobei es sich für viele nicht 
lohnt, den Effekt auf SREG zu modellieren.  Dann kommt einfach ein 
"(clobber (reg:CVNZ SREG))" hinzu.

> Muss man dabei in völlig anderen bis dahin unbekannten Levels denken als
> was man sonst so für seine Programmierkünste kennt? Naiv gefragt.  :-)

Nö.  Der größte Unterschied ist, dass es nicht linearer Code ist sondern 
eine Sammlung von Hooks und Pattern.


Wilhelm M. schrieb:
> Johann L. schrieb:
>> Außer
>> http://gcc.gnu.org/PR84211
>>
> Wäre das o.g. Problem den mit Deinem Patch beseitigt?

Nein.

Wilhelm M. schrieb:
> Tja, wenn die Deklaration nicht zur Definition passt, bekomme ich
> undefined reference. Compiliert also nicht. Gut so.

Und was soll dann dein Testfall darstellen?

Es ist einfach anderer Code.

Wenn du so um jedes Compiler-Problem rumhacken willst, viel Spaß dabei.

> Aber Du hast meinen Punkt wohl nicht gesehen: bei Input-Parametern habe
> ich die Wahl, zwischen per-value oder per-const-ref. Was ich nehme,
> hängt von den Faktoren ab:
>
> - Muss ich eh eine Kopie machen.
> - Ist die Kopie aufwändig zu erstellen (bei Berücksichtung der
> Plattform)

- Der Compiler hat keinen Bug, die dir das vermiesen.

> In Deinem Beispiel ist es ja eine Optimierung für eine perfektes
> Forwarding eines Parameters. Und natürlich hast Du Recht, dass der
> Compiler das optimieren sollte.

Das ist doch überhaupt nicht der Punkt.

[ ] Ich habe verstanden, was ein Testfall für einen Compiler-Bug ist.

: Bearbeitet durch Moderator
von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Johann,

vielen Dank für die Ausführlichkeit.

von Lars R. (larsr)


Bewertung
-4 lesenswert
nicht lesenswert
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...

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
6 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
7 lesenswert
nicht lesenswert
Lars R. schrieb:
> GCC sorgt doch selbst dafür, dass sich Unternehmen nicht (finanziell)
> beteiligen.

Ah ja.

Sag das mal ARM. ;-)

von Oliver S. (oliverso)


Bewertung
5 lesenswert
nicht lesenswert
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

von Bernd K. (prof7bit)


Bewertung
5 lesenswert
nicht lesenswert
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?

von Christopher J. (christopher_j23)


Bewertung
5 lesenswert
nicht lesenswert
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 ;)

von Veit D. (devil-elec)


Bewertung
4 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Veit D. (devil-elec)


Bewertung
1 lesenswert
nicht lesenswert
Hallo,

der aktuelle Stand vom Spendenkonto steht übrigens schon bei 1110,- 
Dollar. Die Hoffnung wächst. Vor kurzem waren es noch knapp über 300,-.

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Das AVR-Backend des llvm benötigt auch noch etwas Arbeit ;-)

Funktioniert zwar schon ganz gut, aber es gibt noch einige 
Schwachstellen: es sind weniger AVRs spezifiziert (kann man leicht aber 
selbst nachziehen) und PROGMEM mit Nacharbeit geht dann auch. Etwas 
unschöner sind manche fehlenden Optimierungen. Aber insgesamt wenigstens 
schon mal benutzbar.

https://bugs.llvm.org/buglist.cgi?component=Backend%3A%20AVR&list_id=109466&product=libraries&resolution=---

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
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.

von Johannes F. (doppelgrau)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
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).

von Johannes F. (doppelgrau)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lars R. (larsr)


Bewertung
-6 lesenswert
nicht lesenswert
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.

von Kai K. (kai-klenovsek)


Bewertung
0 lesenswert
nicht lesenswert
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

von Oliver S. (oliverso)


Bewertung
2 lesenswert
nicht lesenswert
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

von Lars R. (larsr)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Johannes F. (doppelgrau)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lars R. (larsr)


Bewertung
2 lesenswert
nicht lesenswert
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...

von Johannes F. (doppelgrau)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Johannes F. (doppelgrau)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Roland F. (rhf)


Bewertung
4 lesenswert
nicht lesenswert
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

von S. R. (svenska)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lars R. (larsr)


Bewertung
-2 lesenswert
nicht lesenswert
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!

von Roland F. (rhf)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Lars,
Lars R. schrieb:
> Wer sagt das? In zehn Jahren oder so wird dann vielleicht der
> "cc0"-Nachfolger wieder rausgeworfen, und dann?

Dann gibt es eben wieder eine "Spende", das sind doch keine Beträge für 
solche Firmen. Und sie bekommen ja im Gegenzug auch etwas dafür.

> Dann suche mal einen Lieferanten, der zuverlässiger als MCP ist! Du
> kannst heute noch PIC erhalten, die seit Ewigkeiten im Sortiment sind.
> Die kündigen eigentlich nie etwas ab und falls doch, gibt es einen
> binärkompatiblen Ersatztypen!

Gut, das relativiert meine Kritik zu einem guten Stück.
Trotzdem wirft das Verhalten in Bezug auf den avr-gcc kein gutes Licht 
auf Microchip.

rhf

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Johann L. (gjlayde) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Johannes F. (doppelgrau)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Johannes F. schrieb:
> gibt es Neuerungen nicht mehr für AVR.

Es ist nicht nur AVR betroffen, sondern auch noch andere Backends.

von J. W. (dilbert)


Bewertung
-1 lesenswert
nicht lesenswert
Welche Backends sind denn noch davon betroffen?

von Michael F. (michaelfu)


Bewertung
2 lesenswert
nicht lesenswert
J. W. schrieb:
> Welche Backends sind denn noch davon betroffen?

Steht doch im Link vom Eingangspost...

: Bearbeitet durch User
von Johannes F. (doppelgrau)


Bewertung
-2 lesenswert
nicht lesenswert
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?

Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.