Hallo, Ich bin mit dem Auftauchen der neuen Toolchain für das AVR-Studio ziemlich verwirrt, alles redet (noch?) von WinAVR, oder gar Eclipse, oder AVR-GCC. Soweit ich glaube zu überblicken, ist die Toolchain zusammen mit AVR-Studio neuerdings eine eigenständige Alternative zu WinAVR oder Eclipse? Vielleicht sollte man ein paar Worte dazu im AVR-Tutorial und AVR-GCC-Tutorial an den Anfang setzen. Es wird auch meißt von AVR-GCC geredet, ich vermute damit ist "die Toolchain" von Atmel gemeint? Mein AVR-Studio scheint neben der Toolchain eben auch WinAVR, falls installiert, verwenden zu können, was die Frage aufwirft, welche der beiden Optionen ist für die verschiedenen Benutzergruppen/Anwendungsbereiche vorzuziehen, z.b. was ist Einsteigerfreundlicher, was ist flexibler (in der Anpassung, Konfiguration)? Zwei, drei Sätze dazu würden zu Beginn der genannten Tutorials auch sehr helfen. Ich würd gern helfen die Tutorials upzudaten, im Moment habe ich aber noch zuwenig durchblick. Ich habe schon frühere Anläufe mit WinAVR und Eclipse hinter mir, aber allein das Makefile-Voodoo hat mich ziemlich schnell abgeturnt, wenn das mit der integrierten Toolchain nun alles Out-of-the-Box laufen sollte, wäre das doch die beste Grundlage für das AVR-GCC Tutorial (anstelle des für den Einsteiger schwierigsten Weg über Ecplipse)
Die Atmel-Toolchain soll wohl WinAVR ablösen. Hintergrund dabei ist, dass Eric Weddington (derjenige, der nun über Jahre WinAVR zusammen- gestellt hat) ja seit einigen Jahren von Atmel bezahlt wird, sodass man lieber ein "Atmel-Produkt" sehen möchte. Außerdem ist es wohl der Versuch, AVR (8-bit) und AVR32 unter einen Deckel zu bekommen. AVR-GCC ist ein GCC, der für das "target" AVR konfiguriert worden ist. Dieser ist einer der Bestandteile, die WinAVR (bzw. die AVR Toolchain) bilden. Weitere wesentliche Bestandteile sind die GNU binutils (Assembler, Linker und paar Tools darum herum, ebenfalls für den AVR konfiguriert), die avr-libc (Standardbibliothek) und AVRDUDE (Programmierwerkzeug).
Jörg Wunsch schrieb: > AVR-GCC ist ein GCC, der für das "target" AVR konfiguriert worden ist. Ist was über die Atmel-Strategie bezüglich avr-gcc bekannt? D.h. werden sie, wie es bisher mit WinAVR war, auf (gepatchte) FSF-Quellen aufsetzen, oder analog wie bei AVR32, der ja im Gegensatz zu AVR keine "offizielle" GCC-Architektur ist, eine eigene Linie aufziehen mit separaten (Quell-)Downloads?
Johann L. schrieb: > D.h. werden > sie, wie es bisher mit WinAVR war, auf (gepatchte) FSF-Quellen > aufsetzen, Davon kann man ausgehen. Ungepatchte wäre schöner ;-), aber die Entwicklung der Halbleiterindustrie ist leider etwas schneller, als die Release-Policy des Kolosses namens GCC es gestatten würde, das alles "upstream" zeitnah aufgenommen zu bekommen. > oder analog wie bei AVR32, der ja im Gegensatz zu AVR keine > "offizielle" GCC-Architektur ist, eine eigene Linie aufziehen mit > separaten (Quell-)Downloads? Dass AVR32 hier ausschert, ist meines Wissens nicht unbedingt Absicht, sondern hängt mit diversen juristischen Querelen zusammen. Du weißt ja wohl am besten, wie schwierig es ist, dieses vermaledeite copyright assignment unter Dach und Fach zu bekommen — nun stell' dir das mal für einen Laden wie Atmel vor, bei dem noch eine Rechtsab- teilung mit ins Spiel kommt... Ich würde mal hoffen, dass über kurz oder lang auch AVR32 seinen Weg ins offizielle Repository findet, aber nichts genaues weiß ich da auch nicht.
Jörg Wunsch schrieb: > Johann L. schrieb: > >> D.h. werden >> sie, wie es bisher mit WinAVR war, auf (gepatchte) FSF-Quellen >> aufsetzen, > > Davon kann man ausgehen. Ungepatchte wäre schöner ;-), aber die Ja, fürwahr. Die Testbasis wäre damit etwas größer und die Entwicklung einfacher. IMHO sollte Atmel die non-GPL Patches vergessen und jemand anheuern, der GPL-kompatible Patches für die Bugs einbringt. Das wär wahrscheinlich billiger und auch für Erik deutlich nervensparender als diesen Sack voll Flöhe zu verwalten anstatt ihn einfach los zu werden. Und was Testbasis angeht... ich überfliege gerade die avr-bugs und solche Klopper wie http://gcc.gnu.org/PR45291 wären bestimmt schon viel früher aufgefallen. Keine Ahnung, wie lange das schon drinne ist. Schätze mal 4.2 oder 4.3 oder noch älter. > Entwicklung der Halbleiterindustrie ist leider etwas schneller, > als die Release-Policy des Kolosses namens GCC es gestatten würde, > das alles "upstream" zeitnah aufgenommen zu bekommen. Ach komm, wenn Atmel ein neues Derivat auf den Markt wirft, dann wissen die das doch im Voraus und würden besser ne Co-Entwicklung anstreben als immer hinterher zu hecheln. Nach dem Motte "um Gottes Willen, in 2 Wochen ist Weihnachten/Messe/was-auch-immer. Gaaanz plötzlich!". Ich denk die haben inzwischen erkannt wie wichtig GCC für ihre Käfer ist, auch und gerade für AVR. >> oder analog wie bei AVR32, der ja im Gegensatz zu AVR keine >> "offizielle" GCC-Architektur ist, eine eigene Linie aufziehen mit >> separaten (Quell-)Downloads? > > Dass AVR32 hier ausschert, ist meines Wissens nicht unbedingt > Absicht, sondern hängt mit diversen juristischen Querelen zusammen. > Du weißt ja wohl am besten, wie schwierig es ist, dieses vermaledeite > copyright assignment unter Dach und Fach zu bekommen — nun stell' dir > das mal für einen Laden wie Atmel vor, bei dem noch eine Rechtsab- > teilung mit ins Spiel kommt... ARGL, ja. Ist wohl auch einer der Gründe, warum PIC nicht offiziell ist. Ich hab da einmal in die Quellen geschaut... heidenei. Die Jungs entwickeln GCC offenbar unter Windows und sind wohl recht hart im Nehmen... ;-) Was die Rechtsabteilungen angeht ja, da sind manche Firman echt paranoid. Ich kenn da welche, die ihr proprietäre Software mit gcc entwickeln, aber noch nichtmal gegen die libgcc linken aus Panik, sie müssten ihre Quellen offenlegen (wo man, beim Reinschauen denkt: bei 5% "Hut ab", bei den restlichen 95% "wir werden alle sterben!"). > Ich würde mal hoffen, dass über kurz oder lang auch AVR32 seinen Weg > ins offizielle Repository findet, aber nichts genaues weiß ich da > auch nicht. Die Frage ist auch, inwieweit bei der Implementierung das Backend verlassen werden musste/wurde. Wenn Atmel das gemacht hat -- warum auch immer -- wird's doppelt schwer.
Jörg Wunsch schrieb: > Johann L. schrieb: > >> D.h. werden sie, wie es bisher mit WinAVR war, >> auf (gepatchte) FSF-Quellen aufsetzen, > > Davon kann man ausgehen. Das bedeutet im Endeffekt also einen Fork. Das wird doch für Atmel allenfalls kurz- oder mittelfristige Vorteile bringen. Auf lange Sicht wird es den mainline gcc ausbremsen (was effektiv schon seit längerem geschieht) und früher oder später wahrscheinlich auch den Atmel-Fork. Selbst wenn sich Entwickler für avr-gcc fänden wird das die Situation nicht auflösen, wenn die Weiterentwicklung der mainline die Weiterentwicklung des Atmel-Forks erschwert -- was sie aber zwangsläufig tun wird. Eine Weiterentwicklung dürfte also nicht ganz im Interesse von Atmel sein. Sehr interessant in dem Zusammenhang finde ich auch folgenden Artikel. http://linux.sys-con.com/node/33898 Der Artikel ist von 2003, aber heute wohl noch deutlich aktueller als damals, weil sich gcc im kommerziellen Bereich weiter etabliert hat und vermutlich noch weiter etablieren wird. Das Image von zusammengeschusterter, unsicherer Software stimmt eben immer weniger (wenn es je gestimmt hat) und das ist eben auch in der Industrie angekommen.
Johann L. schrieb: >> Davon kann man ausgehen. Ungepatchte wäre schöner ;-), aber die > > Ja, fürwahr. Die Testbasis wäre damit etwas größer und die Entwicklung > einfacher. Naja, das wage ich zu bezweifeln, dass sich davon die Testbasis in irgendeiner Weise nennenswert vergrößert. Die mit Abstand größte Testbasis stellen derzeit eindeutig die WinAVR- (bzw. künft Atmel AVR Toolchain-)Nutzer dar. > IMHO sollte Atmel die non-GPL Patches vergessen Welche bitte? Es gibt praktisch drei Sorten Patches: . Bugfixes, die aus dem GCC-Trunk rückportiert worden sind auf eine ältere Compilerversion. Mit dem Trunk bzw. selbst mit dem jüngsten Release will man in der Regel nicht sofort in die Produktion springen. . "new devices" Patches der simplen Sorte, also im Wesentlichen ein Patchen der internen specs und dergleichen; unterhalb eines irgendwie copyright-mäßig interessierenden Niveaus anzusiedeln. . Aufwändige Patch-Suites wie Xmega oder mittlerweile wohl tiny10; hier genügt es einfach mal nicht, dass man da eine GPL drüber schreibt, sondern du hast wieder das gleiche Dilemma wie auch schon beim AVR32: GCC besteht auf diesem blöden Copyright-Assignment, und wenn Atmel das Copyright hält, weil der Patch in deren Auftrag und mit deren Geld kreiert worden ist, dann bist du wieder bei der Rechtsabteilung... >> Entwicklung der Halbleiterindustrie ist leider etwas schneller, >> als die Release-Policy des Kolosses namens GCC es gestatten würde, >> das alles "upstream" zeitnah aufgenommen zu bekommen. > > Ach komm, wenn Atmel ein neues Derivat auf den Markt wirft, dann wissen > die das doch im Voraus und würden besser ne Co-Entwicklung anstreben als > immer hinterher zu hecheln. Der Release-Prozess eines GCC bleibt dennoch zu langsam, bzw. die Zeit, bis man das Risiko eingehen möchte, einen Release auch wirklich produktiv zu nutzen. Kommt noch hinzu, dass es da sicher auch firmenintern Befindlichkeiten gibt, die man respektieren muss: bevor der Name eines neuen Modells in die Öffentlichkeit "transpiriert" (sodass ihn ja u. a. dann auch die Konkurrenz mitbekommt und sich einen Reim drauf machen kann), möchte man sich schon sicher sein, dass es dafür auch in absehbarer Zeit benutzbares Silizium geben wird und das Ding nicht "Vaporware" wird. Damit fällt schon mal die Möglichkeit aus, das bereits zum Beginn des Planungsprozesses öffentlich irgendwo einzukippen. > Was die Rechtsabteilungen angeht ja, da sind manche Firman echt > paranoid. Ich kenn da welche, die ihr proprietäre Software mit gcc > entwickeln, aber noch nichtmal gegen die libgcc linken aus Panik, sie > müssten ihre Quellen offenlegen Hatte ich bis vor kurzem auch für bekloppt gehalten. Allerdings hat GCC zeitgleich mit dem Umstellen der Lizenz auf GPLv3 die Lizenzbedingungen für die libgcc (die "runtime") auch umformuliert, und das Ergebnis ist nun leider für die Rechtsverdreher derartiger Firmen ein gefundenes Fressen, da es keinesfalls mehr so eindeutig und problemlos nachnutzbar ist, wie das noch zu GPLv2-Zeiten der Fall war. Ich denke, dass das eigentliche Ziel der GCC-Leute lediglich war, dass der runtime-Code nicht durch andere (nicht-GPL) Compiler nachgenutzt werden darf (keine Ahnung, ob das überhaupt eine reale Gefahr war), aber die Formulierungen sind leider nunmehr alles andere als eindeutig. Johann L. schrieb: >>> D.h. werden sie, wie es bisher mit WinAVR war, >>> auf (gepatchte) FSF-Quellen aufsetzen, >> >> Davon kann man ausgehen. > > Das bedeutet im Endeffekt also einen Fork. Das verstehe ich nicht.
Jörg Wunsch schrieb: > Johann L. schrieb: > >>> Davon kann man ausgehen. Ungepatchte wäre schöner ;-), aber die >> >> Ja, fürwahr. Die Testbasis wäre damit etwas größer und die Entwicklung >> einfacher. > > Naja, das wage ich zu bezweifeln, dass sich davon die Testbasis in > irgendeiner Weise nennenswert vergrößert. Die mit Abstand größte > Testbasis stellen derzeit eindeutig die WinAVR- (bzw. künft Atmel AVR > Toolchain-)Nutzer dar. Genau deshalb. Wieviel Windows-Anwender setzen einen avr-gcc-4.5.1 ein, was glaubst du? Ja, da sind Fehler drinne, die machen ihn unbenutzbar. Warum? Weil sich alles ewig aufgestaut hat. Nen erfahrenen GCC-Entwickler anzuheuern, der gemeldete Fehler zeitnah fixt, würde Atmel aus der Portokasse bezahlen. Momentan ist eben ein riesiger Berg entstanden, und es wird ewig dauern, den abzutragen. > >> IMHO sollte Atmel die non-GPL Patches vergessen > > Welche bitte? > > Es gibt praktisch drei Sorten Patches: > > . Bugfixes, die aus dem GCC-Trunk rückportiert worden sind auf eine > ältere Compilerversion. Mit dem Trunk bzw. selbst mit dem jüngsten > Release will man in der Regel nicht sofort in die Produktion > springen. Das geht für andere Tatgets doch auch. Und backports müssen ja nicht extern sein, sie können genauso intern sein wie die eigentlichen fixes. Ein Großteil der "Bugs" sind doch "performance regressions". Nur ein relativ kleiner Teil sind echte Bugs (die sich, wie gesagt, über einige Zeit ansammeln durften) oder Anwendungsfehler (zB falsche Anwendung globaler Register) > . "new devices" Patches der simplen Sorte, also im Wesentlichen ein > Patchen der internen specs und dergleichen; unterhalb eines > irgendwie copyright-mäßig interessierenden Niveaus anzusiedeln. IdR sind das copy-and-past-patches. Einen attiny2313a hinzuzufügen macht Eric doch schon. Erweiterungen wie 3-byte-pc brauchen natürlich mehr Arbeit und auch mehr Tests. >>> Entwicklung der Halbleiterindustrie ist leider etwas schneller, >>> als die Release-Policy des Kolosses namens GCC es gestatten würde, >>> das alles "upstream" zeitnah aufgenommen zu bekommen. >> >> Ach komm, wenn Atmel ein neues Derivat auf den Markt wirft, dann wissen >> die das doch im Voraus und würden besser ne Co-Entwicklung anstreben als >> immer hinterher zu hecheln. > > Der Release-Prozess eines GCC bleibt dennoch zu langsam, bzw. die > Zeit, bis man das Risiko eingehen möchte, einen Release auch wirklich > produktiv zu nutzen. Kommt noch hinzu, dass es da sicher auch Das Problem ist teilweise doch, daß jeder immer die neueste (verfügbare) Release aufspielt ohne nachzudenken und überall die Ansprüchlichkeit ist, daß das ohne den kleinsten Hickser geht. Alles ist performance-geil (ok, ich auch manchmal, ich geb's ja zu) und denkt keine Sekunde darüber nach, ob es nicht vielleicht besser ist, erst mal anzugucken was da neues verfügbar ist oder auf der alten, bewährten Version zu bleiben. Eine neue Version bedetet doch nicht, daß man die nutzen muss, und für die copy-and-paste-Targets könnte Atmel die bewährte Version mit updates zur Verfügung stellen, bis das in ne offizielle gcc release drinne ist. > das Ding nicht "Vaporware" wird. Damit fällt schon mal die > Möglichkeit aus, das bereits zum Beginn des Planungsprozesses > öffentlich irgendwo einzukippen. Es könnte sich jemand anschauen wie das in gcc (bzw, binutils, gdb) umsetzbar wäre, zB ein Atmel-Mitarbeiter. Wenn es irgendwo gründlich hakt, ist es in phase 1 oft noch möglich, in die entwicklung einzugreifen, indem man zB in den MLs Probleme bespricht. Da geht es garnicht um Patches, sondern daß Hänfling avr nicht hinten runterfällt. Oft wird nur was übersehen, und wenn sich keiner beschwert, wird auch nix geändert (middle und frontend), wo es garkein avr-Entwickler bräuchte. Dinge wie zB http://gcc.gnu.org/PR46278 würden viel früher erkannt. Konkret in diesem Falle lügt zwar das Backend, weil es falsche Kosten angibt, aber wenn ich es recht sehe hat IRA überhaupt nicht die Möglichkeit, das avr sich da reinhängt und die Kosten überhaupt beschreibt. D.h. das avr-Backend hätte überhaupt nicht die Basis, da groß was zu ändern. Oft geht es "nur" um diese Basis, die garnix direkt mit avr zu tun hat. > Johann L. schrieb: > >>>> D.h. werden sie, wie es bisher mit WinAVR war, >>>> auf (gepatchte) FSF-Quellen aufsetzen, >>> >>> Davon kann man ausgehen. >> >> Das bedeutet im Endeffekt also einen Fork. > > Das verstehe ich nicht. Wenn heute jemand ein Fehler behebt dann ist das für 4.6.0 und evtl. backports; ein neues Feature oder Optimierung nicht vor 4.7. Nehmen wir mal an, es fixt jemand nen Bug, für den Eric ein Patch hat. Derjenige wird sich den PR anschauen und was zu machen ist und wird einen Teufel tun, den Patch abzukäsen. D.h. Eric muss ab irgendeinem Zeitpunkt anfangen, alle Patches, die auf dem besagten PR sind zu portieren, und sozusagen mitten aus dem Stapel ein Patch rausziehen. Die Darüberliegenden Pflasterchen braucht er idealerweise nicht anzufassen (wie zB das Ada-Zeug) aber das ist keinswegs selbstverständlich, und je mehr Sachen in mainline behoben werden, desto stressiger wird es für Eric, auf ne neue Version zu gehen. Irgendwann wird er (bzw. Atmel) den Weg des geringsten Widerstands nehmen, d.h. sich von der mainline komplett abkoppeln und atmel-fork und mainline folgen unabhängigen Entwicklungen.
Jedenfalls scheint es momentan in diese Richtung zu laufen. Weil keine avr-Entwickler weit und breit... Andrew Pinski macht hin und wieder was, ok. Und es gab mal jemand, der nen pattern-Generator für peephole2 schreiben wollte. Das war das einzige mal, daß ich mitbekommen hatte, daß sich jemand für avr-Entwicklung interessiert oder Gedanken darüber macht und versucht was beizutragen (blieb aber wohl aus technischen Gründen bei der Idee, und ich hatte damals davon abgeraten sowas zu machen). Und A.K. hat zumindest ein paar Hacking-Skills, aber wohl kein Interesse. Adacore scheint auch keine Ambitionen zu haben. BTW, was um aller Welt macht man mit Ada auf 'nem AVR? Im saftety-Bereich sind Compiler-Bugs bestimmt auch eher ungern gesehen ;-) Aber ok, vielleicht machen die ebenfalls ihre eigene Distribution.
Johann L. schrieb: > Genau deshalb. Wieviel Windows-Anwender setzen einen avr-gcc-4.5.1 > ein, was glaubst du? Keiner. Der Grund ist, weil es keinen vorcompilierten gibt, und Windows-Nutzer nun mal nur mit vorcompilierten Dingen wirklich arbeiten wollen. Das liegt aber nicht so sehr an den Patches (ja, die brauchen auch manpower, damit man sie pflegt), sondern vor allem daran, dass WinAVR bzw. dessen Nachfolger schlicht gar keine Möglichkeit haben, mehr als eine Version des Compilers zu installieren (geschweige denn, zur Laufzeit zwischen zweien umzuschalten). Daher, und natürlich vor allem, weil diese Tools von vielen Leuten für produktiven Code genutzt werden, hinkt die populärste der AVR-Toolchains halt immer so um die zwei minor versions hinter dem aktuellen Release hinterher. Ich habe in meinen FreeBSD-Ports zwar die Möglichkeit, mehr als eine Version überhaupt anzubieten, aber auch da kostet es man power, das zu pflegen, und es bleibt eine Entscheidung zur Installationszeit, nicht zur Laufzeit. > Nen erfahrenen > GCC-Entwickler anzuheuern, der gemeldete Fehler zeitnah fixt, würde > Atmel aus der Portokasse bezahlen. Wenn du einen kennst, dann schick ihn nach Colorado Springs. Eric hat händeringend versucht, jemanden anzuheuern (zumindest eine zeitlang, keine Ahnung, ob der Job nach wie vor zu haben wäre). Ergebnis: über Jahre hat niemand Interesse gezeigt. Der einzige so einigermaßen aktive AVR-GCC-Entwickler ist und bleibt Anatolij Sokolov, und der will und kann das lediglich als Hobbyarbeit machen. (Mittlerweile scheint Atmel wohl mindestens einen zu haben, der sich um sowas kümmert, siehe Unterstützung für den ATtiny10.) > Das geht für andere Tatgets doch auch. Und backports müssen ja nicht > extern sein, sie können genauso intern sein wie die eigentlichen > fixes. Das braucht auch wieder jemanden, der bei GCC die nötigen Rechte hat, dass er das ins SVN committen darf (und der natürlich die Zeit dafür hat). > Das Problem ist teilweise doch, daß jeder immer die neueste > (verfügbare) Release aufspielt ohne nachzudenken und überall die > Ansprüchlichkeit ist, daß das ohne den kleinsten Hickser geht. Alles > ist performance-geil (ok, ich auch manchmal, ich geb's ja zu) und > denkt keine Sekunde darüber nach, ob es nicht vielleicht besser ist, > erst mal anzugucken was da neues verfügbar ist oder auf der alten, > bewährten Version zu bleiben. Genau deshalb bleibt aber WinAVR bei einer etwas älteren Version, was dazu führt, dass die jeweils neueste in den Tests komplett "unterbelichtet" ist. > Da geht es garnicht um Patches, sondern daß Hänfling avr nicht > hinten runterfällt. Erics Ziel seit langem ist es, einen Simulator so verfügbar zu haben, dass ihn jeder X-beliebige GCC-Entwickler bei sich installieren und damit das AVR-Target testen kann. Erst dann wäre er in der Lage, den AVR als "2nd tier"-Target aufwerten zu lassen, sodass er stärker in automatisierten Tests aufschlägt, was wiederum "lack of optimization" Fehler den GCC-Entwicklern früher gewahr machen würde. Bislang drehen praktisch all diese Dinge erst eine komplette Runde über einen "mature release" zu den Anwendern, und von da zurück als PR. Keine Ahnung, wie weit Eric mit diesem Ansinnen mittlerweile vorwärts kommen konnte. Ein Opensource-Simulator wird halt für Atmel keine große Priorität genießen (sprich: kaum bezahlte man power locker machen), weil die sich natürlich hinstellen: "AVR Studio hat doch einen prima Simulator, wofür sollten wir einen zweiten bezahlen?" > D.h. Eric muss ab irgendeinem > Zeitpunkt anfangen, alle Patches, die auf dem besagten PR sind zu > portieren, und sozusagen mitten aus dem Stapel ein Patch rausziehen. Ja, das ist so. Lässt sich derzeit nicht ändern, hat aber seit Jahren nun bereits nicht zu einem fork geführt sondern nur dazu, dass halt WinAVR & Co. jeweils ein gutes Stück hinter dem aktuellen GCC-Release hinterher hängen. S. o. ... Johann L. schrieb: > Weil keine avr-Entwickler weit und breit... Anatolij halt. Ja, mehr AVR-Entwickler mit GCC-Fähigkeiten (und mit dem Sche*** copyright assignment) wären sehr nützlich. Erst hamm, sprach Schramm, und dann ein Stück fort damit sein. > Adacore scheint auch keine Ambitionen zu haben. BTW, was um aller Welt > macht man mit Ada auf 'nem AVR? Ist allemal eine schönere Sprache als C. ;-) Wenn ich heute nochmal anfangen würde als Programmierer, könnte ich mir gut vorstellen, lieber Ada als C zu nehmen.
>copyright assignment
Kannst du für die ahnungslosen Mitleser wie mich mal in wenigen Worten
erklären was es mit diesem "Dings" auf sich hat? Google spuckt irgendwie
keine kurze verständliche Erklärung aus.
Mitleser schrieb: >>copyright assignment > Kannst du für die ahnungslosen Mitleser wie mich mal in wenigen Worten > erklären was es mit diesem "Dings" auf sich hat? Die FSF besteht für alle dem GNU-Projekt zugehörigen Projekte (also insbesondere GCC, binutils und GDB) darauf, dass man für alle Änderungen, die aus Copyright-Sicht relevant sind (also alles ab Patches, die nicht trivial sind, bis hin natürlich zu komplett neuen Dingen) ihnen das Copyright überträgt. Vorgeblich möchten sie auf diese Weise in die Lage versetzt sein, Copyright-Verstöße selbstständig verfolgen zu können. Die ganze Prozedur erfolgt aber in Schriftform, wobei sie lediglich über eine Art Halbtags-Sekretöse verfügen (eher noch viel weniger) und ganz offenbar mit der Abhandlung des selbst auferlegten Papierkriegs völlig überfordert sind (wovon Johann ein leidvolles Lied singen kann). Bevor der Mift aber nicht bei ihnen unterschrieben wieder auf dem Tisch liegt, akzeptieren sie prinzipiell keine copyright-relevanten Beiträge von irgendjemandem. Ich selbst habe den Kram vorsorglich mal vor Jahren für mich eingereicht und auch einigermaßen im zeitlichen Rahmen durch bekommen (damals hatte ich eigentlich vor, den COFF-AVR-Patch für die binutils offiziell beizusteuern, aber mittlerweile ist dieses Datei- format ja glücklicherweise irrelevant geworden), habe den Papierkram aber gleich für GCC, binutils und GDB komplett erledigt. Das Lustige für uns Deutsche ist dabei, dass wir prinzipiell gar nicht in der Lage sind, ein Copyright abzutreten, da dieses nach deutscher Rechtsauffassung ein unveräußerliches Recht des Copyright-Inhabers ist, das lediglich vererbbar ist. Der ganze Papierkrieg ist für unsereins daher eigentlich komplett verschwendete Zeit, aber die FSF besteht darauf.
@Jörg Wunsch Und das ist natürlich eine Hemmschwelle für alle die da prinzipiell gerne mitmachen würden, verstehe. Danke für die Erklärung und Hut ab vor euch Compiler-bauenden und Freizeit-in-Open-Source-Projekte-steckenden Menschen!
Jörg Wunsch schrieb: > Johann L. schrieb: > >> Genau deshalb. Wieviel Windows-Anwender setzen einen avr-gcc-4.5.1 >> ein, was glaubst du? > > Keiner. Der Grund ist, weil es keinen vorcompilierten gibt, und > Windows-Nutzer nun mal nur mit vorcompilierten Dingen wirklich > arbeiten wollen. > > Das liegt aber nicht so sehr an den Patches (ja, die brauchen auch > manpower, damit man sie pflegt), sondern vor allem daran, dass WinAVR > bzw. dessen Nachfolger schlicht gar keine Möglichkeit haben, mehr als > eine Version des Compilers zu installieren (geschweige denn, zur > Laufzeit zwischen zweien umzuschalten). Hä? Da wär doch nur nen anderer Pfad anzugeben bei der "Installation" bzw. dem Aufruf. Für ne "Installation" bräuchte man nurn Archiv zu entpacken und das wars, das ganze Registry-Geraffel ist doch nur, damit astudio den gcc findet (denk ich mal, verwende kein astudio). Oder sind die neuen astudio-Releases dermassen mit gcc verdongelt, daß man nicht mal mehr auswählen kann, wohin die Tools installiert werden? Oder für jede Version von avr-gcc auch ne neue/andere Version von astudio installiert werden muss? Ich bin ja nicht in der astudio-Szene... > Daher, und natürlich vor > allem, weil diese Tools von vielen Leuten für produktiven Code genutzt > werden, hinkt die populärste der AVR-Toolchains halt immer so um die > zwei minor versions hinter dem aktuellen Release hinterher. > > Ich habe in meinen FreeBSD-Ports zwar die Möglichkeit, mehr als eine > Version überhaupt anzubieten, aber auch da kostet es man power, das zu > pflegen, und es bleibt eine Entscheidung zur Installationszeit, nicht > zur Laufzeit. Ok, klar. Ohne Installer geht wohl auch wegen des Lizenz-Clicks nicht oder Nicht-Installer-Distris nicht akzeptiert werden. >> Nen erfahrenen >> GCC-Entwickler anzuheuern, der gemeldete Fehler zeitnah fixt, würde >> Atmel aus der Portokasse bezahlen. > > Wenn du einen kennst, dann schick ihn nach Colorado Springs. Eric hat > händeringend versucht, jemanden anzuheuern (zumindest eine zeitlang, > keine Ahnung, ob der Job nach wie vor zu haben wäre). Das überrascht mich jetzet. Ich weiß, daß gcc-Entwickler auch im kommerziellen Bereich rar sind. Aber daß sie sooo rar sind, daß noch nichtmal Atmel einen bekommt, wundert mich schon. Oder es stimmt was nicht mit den Randbedingungen". Davon ab ist Eric Maintainer, und manche Bugs zu finden (wenn sie denn gemeldet sind) dauert ein paar Minuten, dito sie zu beheben. Er könnte sich mit Kollegen beratschlagen und jemend anders macht dafür die etwas der zeitintensiven Support-Arbeit. Wo ein Wille ist, ist auch ein Weg. Wenn Atmel allerdings in lines-of-code/hour abrechnet, und sieht, daß eine gcc-Zeile auch mal $1000 kosten kann... naja. > Ergebnis: über Jahre hat niemand Interesse gezeigt. Der einzige so > einigermaßen aktive AVR-GCC-Entwickler ist und bleibt Anatolij > Sokolov, und der will und kann das lediglich als Hobbyarbeit machen. Ok, er hat also ne Kaffee-Rechnung wie Hölle ;-) >> Das geht für andere Tatgets doch auch. Und backports müssen ja nicht >> extern sein, sie können genauso intern sein wie die eigentlichen >> fixes. > > Das braucht auch wieder jemanden, der bei GCC die nötigen Rechte hat, > dass er das ins SVN committen darf (und der natürlich die Zeit dafür > hat). Stop. Mal ganz langsam und von vorne. Ein FSF-CA genügt nicht ? Braucht man da noch svn write access? Dachte immer das geht so: patch->review->maintainer macht den svn-kram. >> Das Problem ist teilweise doch, daß jeder immer die neueste >> (verfügbare) Release aufspielt ohne nachzudenken und überall die >> Ansprüchlichkeit ist, daß das ohne den kleinsten Hickser geht. Alles >> ist performance-geil (ok, ich auch manchmal, ich geb's ja zu) und >> denkt keine Sekunde darüber nach, ob es nicht vielleicht besser ist, >> erst mal anzugucken was da neues verfügbar ist oder auf der alten, >> bewährten Version zu bleiben. > > Genau deshalb bleibt aber WinAVR bei einer etwas älteren Version, was > dazu führt, dass die jeweils neueste in den Tests komplett > "unterbelichtet" ist. Das meinte ich mit "es verkleinert die Testbasis" >> Da geht es garnicht um Patches, sondern daß Hänfling avr nicht >> hinten runterfällt. > > Erics Ziel seit langem ist es, einen Simulator so verfügbar zu haben, > dass ihn jeder X-beliebige GCC-Entwickler bei sich installieren und > damit das AVR-Target testen kann. Erst dann wäre er in der Lage, den > AVR als "2nd tier"-Target aufwerten zu lassen, sodass er stärker in > automatisierten Tests aufschlägt, was wiederum "lack of optimization" > Fehler den GCC-Entwicklern früher gewahr machen würde. Bislang drehen > praktisch all diese Dinge erst eine komplette Runde über einen "mature > release" zu den Anwendern, und von da zurück als PR. Ich hatte Eric schon gefragt, wie man ne Testumgebung (dejagnu) sinnigerweise aufsetzt. Keine Antwort. Vemutlich ist da die Ansprüchlichkeit bei Atmel viel zu hoch. Ein Simulator für diesen Zweck braucht doch nicht die komplette (interne) Peripherie zu simulieren mit allen Weiß-der-Teufel-was-für-Features. Es geht doch nur um den Kern, und wenn ein Testfall wegen des Simulators failt und bekannt ist, wär ds ein Drama? Es geht doch vor allem um Regressions, die in neuen Versionen auftreten, nicht um den Absoutstand an Fehlern. Stacküberlauf, mangelnd RAM und avr fliegt raus, Trampolines werden nicht unterstützt, Exceptions, etc. Ist doch kein Drama. Ein Simulator für den Kern reicht doch, und was in der testsuite unterhalb von gcc/testsuite/gcc.target/avr passiert ist für den Rest der gcc-Welt eher uninteressant. Und was gcc.target/avr angeht, da gibt's genau 3 (in Worten: drei) Testfälle, von denen 2 den vielversprechenden Namen "trivial.c" haben. Nix mit SFRs oder Interrupts oder was zur Laufzeit target-spezifisch wäre, noch nichmal zur Compilezeit: _attribute_? Fehlanzeige. > Keine Ahnung, wie weit Eric mit diesem Ansinnen mittlerweile vorwärts > kommen konnte. Ein Opensource-Simulator wird halt für Atmel keine > große Priorität genießen (sprich: kaum bezahlte man power locker > machen), weil die sich natürlich hinstellen: "AVR Studio hat doch > einen prima Simulator, wofür sollten wir einen zweiten bezahlen?" Hehe, Atmel macht astudio als gdb-server übers Netz verfügbar :-) >> D.h. Eric muss ab irgendeinem >> Zeitpunkt anfangen, alle Patches, die auf dem besagten PR sind zu >> portieren, und sozusagen mitten aus dem Stapel ein Patch rausziehen. > > Ja, das ist so. Lässt sich derzeit nicht ändern, hat aber seit Jahren > nun bereits nicht zu einem fork geführt [...] Ok, man wird sehen, was die Zukunft bringt... Wieso bereits?
Johann L. schrieb: > Hä? Da wär doch nur nen anderer Pfad anzugeben bei der "Installation" > bzw. dem Aufruf. Für ne "Installation" bräuchte man nurn Archiv zu > entpacken und das wars, ... Ach, das fasst doch kein Windows-Nutzer an. Man müsste doch automatisch $PATH ändern etc. pp., und man braucht ein schickes Tool mit der Auswahl. Hast du jemals einen Windows Installer für irgendwas geschrieben? Ich nicht, aber ich würde auch freiwillig keinen schreiben wollen. Falls man die Entscheidung in AVR Studio machen können soll (ist ja schließlich deren IDE), dann müsste man wohl dort noch eine Mimik einbauen, wie man unterschiedliche Compiler aufrufen kann (PATH ändern oder epxlizit aufrufen). > das ganze Registry-Geraffel ist doch nur, damit > astudio den gcc findet (denk ich mal, verwende kein astudio). Meiner Meinung nach ersetzt das die unter Unix typischen festen (via --prefix bei ./configure eingebauten) Pfade für die Komponenten (also cpp, cc1 etc.). Ich hatte da irgendwann mal reingeguckt, ich glaube, da gibt's zumindest schon eine Versionierung, d. h. man könnte mehrere verschiedene GCC-Versionen parallel installieren. Das Problem dabei ist, dass du für derartige Mimiken bei Entscheidern wohl keine Zeit locker gemacht bekommst, weil sie darin keinen Mehrwert sehen. Wenn Eric sowas während seiner Arbeitszeit einbauen wöllte, müsste er also wohl erstmal genügend Motive vorweisen können, warum das gut ist und gebraucht wird. > Stop. Mal ganz langsam und von vorne. Ein FSF-CA genügt nicht ? > Braucht man da noch svn write access? Dachte immer das geht so: > patch->review->maintainer macht den svn-kram. Maintainer muss halt auch Zeit haben dafür, den SVN-Kram zu machen. Ich glaube, Eric ist mittlerweile Co-Maintainer, insofern müsste er den AVR betreffende Dinge auch selbst ins SVN schreiben können. So ganz genau kenne ich mich damit aber auch nicht aus, da ich noch nie selbst in dieser Verlegenheit war ;-) (und sicher auch nicht kommen werde). Da braucht er dann halt nur noch behördlicherseits eine Bewilligung für die entsprechende Arbeitszeit... > Ich hatte Eric schon gefragt, wie man ne Testumgebung (dejagnu) > sinnigerweise aufsetzt. Keine Antwort. Wird er auch noch nicht gemacht haben. Ja, ich habe deine Frage gelesen. > Vemutlich ist da die Ansprüchlichkeit bei Atmel viel zu hoch. Ein > Simulator für diesen Zweck braucht doch nicht die komplette (interne) > Peripherie zu simulieren mit allen Weiß-der-Teufel-was-für-Features. Ist ihm schon klar, und es gibt wohl auch einen einfachen Simulator für ebendiesen Zweck bereits. Keine Ahnung, ob der schon komplett und bugfrei genug ist, dass man ihn auch auf nicht-AVR-Entwickler loslassen kann. > Hehe, Atmel macht astudio als gdb-server übers Netz verfügbar :-) Wäre auch mal eine Idee. ;-) Das wird vermutlich dann wieder an irgendeiner IT-Abteilung scheitern...
> Ein Simulator für den Kern reicht doch
Müßte der "stand-alone" sein? Es gibt ja inzwischen auch noch den in GDB
integrierten Simulator (zumindestens in der GDB-Version, die Adacore als
Bestandteil von Gnat GPL 2010 verteilt. Keine Ahnung, ob der in dem
"offiziellen" GDB inzwischen auch drin ist).
MR schrieb: >> Ein Simulator für den Kern reicht doch > > Müßte der "stand-alone" sein? Es gibt ja inzwischen auch noch den in GDB > integrierten Simulator Da hab' ich keine Ahnung.
MR schrieb: > Es gibt ja inzwischen auch noch den in GDB > integrierten Simulator (zumindestens in der GDB-Version, die Adacore als > Bestandteil von Gnat GPL 2010 verteilt. Keine Ahnung, ob der in dem > "offiziellen" GDB inzwischen auch drin ist). Ich habe jetzt mal in den letzten GDB-Versionen nachgesehen: Ein AVR-Simulator ("target sim") ist seit Version in 7.0 in GDB enthalten...
MR schrieb: >> Ein Simulator für den Kern reicht doch > > Müßte der "stand-alone" sein? Nö, das nicht. Aber Testsuite-Ergebnisse sollten untereinander vergleichbar sein. Wenn unterschiedliche Simulatoren unterschiedliche Ergebnisse liefern (zB weil einer ein bestimmtes SFR unterstützt, ein anderer jedoch nicht), dann sind Testsuite-Ergebnisse schlecht, d.h. nur nur erhöhtem Zeitaufwand vergleichbar. Daher ist es vorteilhaft, einen "Standard"-AVR-Simulator zu haben, auch wenn dieser evtl. hinter einem anderern Simulator zurückliegt. Ein Vergleich der Testsuite-Ergebnisse ist dann i.W. ein diff auf die Ausgabe. Zudem: GCC-Entwicklung geschieht unter Linux, ein Simulator, der nur in Nicht-Linux-Umgebung funktioniert, bedeutet ebenfalls Aufwand. Und alles, was Atmel an Aufwand externalisiert (etwa einen Sim nur für Win32 zu machen, der nicht unter Linux läuft), verlangsamt die Entwicklungsprozesse spürbar, weil die meisten avr-tools Entwickler die Entwicklung in der Freizeit machen (oder eben bei Atmel sitzen und wegen nicht-vorhandenem Copyright-Assignment nix zur Entwicklung beitragen können bzw. dürfen). Übrigens ist "die Testsuite" Teil von GCC, d.h. ein Entwickler ohne FSF-Assignment kann noch nichtmal ein Testprogramm zur Testsuite hinzufügen. Möglicherweise gibt es auch andere Testsuites, die auf C für AVR zielen, zB welche von IAR, Adacore, etc. MR schrieb: > MR schrieb: >> Es gibt ja inzwischen auch noch den in GDB >> integrierten Simulator (zumindestens in der GDB-Version, die Adacore als >> Bestandteil von Gnat GPL 2010 verteilt. Keine Ahnung, ob der in dem >> "offiziellen" GDB inzwischen auch drin ist). > > Ich habe jetzt mal in den letzten GDB-Versionen nachgesehen: Ein > AVR-Simulator ("target sim") ist seit Version in 7.0 in GDB enthalten... Momentan hab ich leider nicht die Resource, das mal näher anzuschauen oder irgendwas zu avr-gcc beizutragen... "target sim" bedeutet, daß es ein Protokoll zum Reden mit einem Simulator gibt -- das kann ein Pseudo-Protokoll sein, das auf einen integrierten Simulator abbildet oder ein tatsächliches Protokoll, das ein definiertes Protokoll zu einem bestimmten Simulator implementiert. Letzteres wäre eine Arbeitsweise ähnlich zu AVR-Studio, das "nur" eine Schnittstelle zu einem C-Compiler (avr-gcc) hat, selbst aber keinen C-Compiler implementiert.
Und wenn ich früher(tm) mal gesagt hab, GCC ist kaum mehr zu pflegender Clusterf*ck in Reinkultur, und die FSF dreht hier und da recht aktionistisch am Rad, hat man mich schief angeschaut... Ich hab auch schon mal versucht, irgendein kleineres Problem "im GCC" aufzuspüren und zu beheben. Danach hab ich voll und ganz verstanden, wieso Entwickler so rar sind und, salopp gesagt, kein Schwein Bock hat, sich in den Clusterf*ck einzuarbeiten. Wenn nicht schon so viele Mannstunden im GCC stecken würden, wärs vielleicht noch Zeit, woanders anzubauen. Vielleicht LLVM oder sowas.
BTW, nachdem ich WinAVR gegen die Atmel Toolchain ausgetauscht habe, zeigt avr-objdump keine "Chip-Belegung in %" mehr an. Liegt das an Atmel oder an mir? Grüsse, Jürgen
Bitte um Unterstützung ! Ich möchte das AVR studio4 gemeinsam mit dem AVR Dragon zum JTAG proggen (C/ASM) und debuggen eines ATmega169P verwenden. 1. Im Forum (fragt mich nicht welcher draht ;-) habe ich gelesen, dass die Atmel AVR Toolchain nicht alle Elemente/tools wie sie WinAVR hat, beinhaltet. Nun bin ich als Neuling verwirrt ob ich nun winavr2010 oder die avr-toolchain-installer-3.0.0.240-win32.win32.x86 verwenden soll. 2. Weiters gibt es angeblich eine neuere Toolchain avr8-gnu-toolchain-3.1.0.206 http://distribute.atmel.no/tools/avr32/beta/avr8-gnu-toolchain-3.1.0.206-readme.pdf, die aber so nirgends gefunden habe... Angeblich soll sie hieraus http://distribute.atmel.no/tools/avr32/beta/as4e-ide-2.7.0.851-win32.win32.x86.zip zu extrahieren sein ... für mich als Neuling jedenfalls nicht so ohne Weiteres ....
Sven P. schrieb: > Und wenn ich früher(tm) mal gesagt hab, GCC ist kaum mehr zu pflegender > Clusterf*ck in Reinkultur, und die FSF dreht hier und da recht > aktionistisch am Rad, hat man mich schief angeschaut... Ja. GCC ist kein Ponyhof. Die Komplexität und Allgemeinheit der Software findet eben Niederschlag in der Quelle. Paradoxerweise genügt die Quelle nicht, um ein wirklich gutes Verständis vom GCC zu bekommen. Hierzu ist auch lange Einarbeitung/Erfahrung nötig und die Möglichkeit, sich mit erfahrenen Entwicklern austauschen zu können. Davon zu trennen ist die FSF. GCC ist nicht die FSF und die FSF ist nicht GCC. Jeder, der irgendeine Ausprägung von GCC oder von Linux verwendet -- ob direkt auf seinem Rechner oder via Server im Internet -- profitiert von GCC und von seiner freien, aber auch sehr strikten Lizenz. Freilich braucht man etwas Sitzfleisch um erst mal rein formal beim GCC mitspielen zu dürfen. Zumindest war das bei mir der Fall. Und der Entwicklungsprozess ist eben auch mit Aufwand verbunden. Ich glaube aber nicht, daß es ohne Richtlinien möglich ist, ein so großes Projekt erfolgreich übers Internet zu entwickeln. In meinem Job würd ich an vielen Stellen die Stringenz von z.B. GCC dem "Wildwuchs der kurzen Wege" vorziehen, auch wenn es die "eigentliche" Arbeit verlangsamt. > Ich hab auch schon mal versucht, irgendein kleineres Problem "im GCC" > aufzuspüren und zu beheben. Danach hab ich voll und ganz verstanden, > wieso Entwickler so rar sind und, salopp gesagt, kein Schwein Bock hat, > sich in den Clusterf*ck einzuarbeiten. Ja, es ist ne Ochsentour. Kein Ponyhof eben. Aber ich denke, es kann auch Spaß machen, was beizutragen. Die Tage hab ich meine ersten einfachen Patches abgesetzt und bin gespannt, wie es denen ergehen wird :-) > Wenn nicht schon so viele Mannstunden im GCC stecken würden, wärs > vielleicht noch Zeit, woanders anzubauen. Vielleicht LLVM oder sowas. LLVM hat doch auch ein AVR-Backend (oder wie auch immer die dortige Diktion ist) an welchem man mitarbeiten kann. Und ob LLVM, wenn er das Alter -- also weit über 20 Jahre -- und die Allgemeinheit von GCC erreicht hat (unterstützte Maschinen und Derivate, Plattformen und Sprachen, Plugins, Debug-Möglichkeiten, Maschinenbeschreibung, etc.) immer noch so unbeschwert daherkommt wie heute, sei mal dahingestellt. Was GCC 4 angeht, kann ich nur sagen, daß die Internals, also die Dokumentation, viel näher an der Funktionalität und vollständiger ist als dies noch bei GCC 3 der Fall war, und daß es viele Erweiterungen gibt, die eine Maschinenbeschreibung wesentlich übersichtlicher machen.
Richard G. schrieb: > Bitte um Unterstützung ! > > Ich möchte das AVR studio4 gemeinsam mit dem AVR Dragon zum JTAG proggen > (C/ASM) und debuggen eines ATmega169P verwenden. > > 1. Im Forum (fragt mich nicht welcher draht ;-) habe ich gelesen, dass > die Atmel AVR Toolchain nicht alle Elemente/tools wie sie WinAVR hat, > beinhaltet. > Nun bin ich als Neuling verwirrt ob ich nun winavr2010 oder die > avr-toolchain-installer-3.0.0.240-win32.win32.x86 verwenden soll. > Wenn du AVR Studio benutzen willst, brauchst du kein WinAVR mehr, allerdings die Toolchain schon. Dazu also Toolchain fürs Studio laden und installieren (siehe Seite von AVR Studio 4 auf Atmel), dann das Studio installieren. In der aktuellen Version wüsste ich jetzt nicht was du großes vermissen würdest, du kannst dort in C bauen, proggen, und simulieren. Das ganze Betazeugs würd ich garnicht erst anfassen, bevor nicht irgendein Bug oder Problem oder Unzulänglichkeit im offiziellen Release dir einen konkreten Grund gibt. Zumal der Link den du unten angabst in einem Fall schon ein Jahr alt ist, und im zweiten Fall sich auf das AVR32 Studio bezieht, nicht AVR Studio 4. Hier findet sich alles was du brauchst: http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725&category_id=163&family_id=607&subfamily_id=760
Moritz E. schrieb: > Richard G. schrieb: >> Bitte um Unterstützung ! >> >> Ich möchte das AVR studio4 gemeinsam mit dem AVR Dragon zum JTAG proggen >> (C/ASM) und debuggen eines ATmega169P verwenden. >> >> 1. Im Forum (fragt mich nicht welcher draht ;-) habe ich gelesen, dass >> die Atmel AVR Toolchain nicht alle Elemente/tools wie sie WinAVR hat, >> beinhaltet. >> Nun bin ich als Neuling verwirrt ob ich nun winavr2010 oder die >> avr-toolchain-installer-3.0.0.240-win32.win32.x86 verwenden soll. >> > > Wenn du AVR Studio benutzen willst, brauchst du kein WinAVR mehr, > allerdings die Toolchain schon. Dazu also Toolchain fürs Studio laden > und installieren (siehe Seite von AVR Studio 4 auf Atmel), dann das > Studio installieren. In der aktuellen Version wüsste ich jetzt nicht was > du großes vermissen würdest, du kannst dort in C bauen, proggen, und > simulieren. Das ganze Betazeugs würd ich garnicht erst anfassen, bevor > nicht irgendein Bug oder Problem oder Unzulänglichkeit im offiziellen > Release dir einen konkreten Grund gibt. Die Atmel-Toolchain würde ich mit Vorsicht geniessen; Atmel scheint den Fokus eher auf neue Features zu legen als auf das Beheben von Fehlern. Mit der lezten Version von WinAVR sollte man gut versorgt sein, die Priorität würde ich nicht beim "Alter der Toolchain" oder "Aler von Links" festmachen. Gleich, welche Version von avr-gcc man verwendet (WinAVR, Atmel-Tools, Linux-Distribution, eigene Builds), sollte man zwei Dinge beachten 1. -fno-split-wide-types zu den Compileroptionen hinzufügen, auch wenn das hie und da etwas schlechteren Code gibt. 2. Keine 64-Bit Typen wie long long oder [u]int64_t verwenden. Hier kann es zu schwer auffindbaren und schwer zu lokalisierenden Fehlern kommen, d.h. es wird falscher Code erzeugt -- auch mit gepatchten Versionen wie WinAVR! Jeder, der mit avr-gcc arbeitet, sollte diese beiden Punkte beherzigen. Zum Glück werden 64-Bit Typen recht selten verwendet, und eine Option wie -fno-split-wide-types zu setzen ist kein Aufwand. > Zumal der Link den du unten angabst in einem Fall schon ein Jahr alt > ist, und im zweiten Fall sich auf das AVR32 Studio bezieht, nicht AVR > Studio 4. AVR32-Studio bringt nach der Atmel-Website auch AVR-Tools mit. Wobei ich nicht nachvollziehen kann, warum man AVR mit AVR32 verbäckt, was ja bereits bei jüngeren Releases won WinAVR der Fall war.
Johann L. schrieb: > Die Atmel-Toolchain würde ich mit Vorsicht geniessen; Atmel scheint den > Fokus eher auf neue Features zu legen als auf das Beheben von Fehlern. Naja, das kannste so auch nicht sagen. Der sagenumwobene Bug mit dem delay.h geht nun nicht auf deren Konto, das wäre mit der nächsten WinAVR-Version (wenn es sie gegeben hätte) ganz genauso passiert.
Jörg Wunsch schrieb: > Johann L. schrieb: >> Die Atmel-Toolchain würde ich mit Vorsicht geniessen; Atmel scheint den >> Fokus eher auf neue Features zu legen als auf das Beheben von Fehlern. > > Naja, das kannste so auch nicht sagen. Der sagenumwobene Bug mit > dem delay.h geht nun nicht auf deren Konto, das wäre mit der > nächsten WinAVR-Version (wenn es sie gegeben hätte) ganz genauso > passiert. hmmm... ich bin da vielleicht zu sehr auf den Compiler fixiert. Fehler in der delay.h finde ich nicht sooo schlimm. Es ist ja ein leichtes, die Datei gegen eine funktionierende Auszutauschen. Das Problem ist eher, überhaupt mitzubekommen, daß die delay.h buggy ist. Mit dem 64-Bit Problem ist das nicht so einfach: hier reicht es nicht, eine Datei auszutauschen oder auf eine andere Compiler-Version zu wechseln. Mir ist erst die Tage klar geworden, daß 64-Bit auf avr-gcc überhaupt nicht zuverlässig funktionieren kann und ich hab keine Idee, wie das Problem aus der Welt geräumt werden kann. long long finden zwar keine so große Verwendung, aber hier gibt es ja auch einen Image-Schaden, wenn gewisse Basistypen überhaupt nicht verwendbar sind.
Johann L. schrieb: > Mir ist erst die Tage klar geworden, daß 64-Bit auf avr-gcc > überhaupt nicht zuverlässig funktionieren kann und ich hab keine Idee, > wie das Problem aus der Welt geräumt werden kann. Ich glaube, ich habe da auch seit Urzeiten noch einen Bug offen dafür.
Johann L. schrieb: > Jörg Wunsch schrieb: > wechseln. Mir ist erst die Tage klar geworden, daß 64-Bit auf avr-gcc > überhaupt nicht zuverlässig funktionieren kann und ich hab keine Idee, > wie das Problem aus der Welt geräumt werden kann. long long finden zwar > keine so große Verwendung, aber hier gibt es ja auch einen > Image-Schaden, wenn gewisse Basistypen überhaupt nicht verwendbar sind. Nun bin ich neugierig: Kannst Du kurz beschreiben, warum 64 bit nicht funktionieren kann ? Oder wo man mehr info darueber finden kann ? Danke, ZigZeg
Kai S. schrieb: > Johann L. schrieb: >> Jörg Wunsch schrieb: > >> wechseln. Mir ist erst die Tage klar geworden, daß 64-Bit auf avr-gcc >> überhaupt nicht zuverlässig funktionieren kann und ich hab keine Idee, >> wie das Problem aus der Welt geräumt werden kann. long long finden zwar >> keine so große Verwendung, aber hier gibt es ja auch einen >> Image-Schaden, wenn gewisse Basistypen überhaupt nicht verwendbar sind. > > Nun bin ich neugierig: Kannst Du kurz beschreiben, warum 64 bit nicht > funktionieren kann ? Oder wo man mehr info darueber finden kann ? Momentan hab ich da noch Klärungsbedarf mit anderen gcc-Entwicklern bezüglich der Semantik bestimmter internet GCC-Konstrukte. Ich bin dabei die Bugliste durchzugehen und Fehler nachzuvollziehen und zu lokalisieren und zu fixen falls sie im AVR-Teil sind. Es sieht nun so aus, daß einige Fehler, die gegen das avr-Backend gemeldet wurden, tatsächlich Probleme im maschinenunabhängigen Teil sind, die sich nicht einfach beheben lassen. Das alles ist für 32-Bit-Maschinen kein Thema, und daher dort auch nicht aufgetreten bzw. aufgefallen. In ein paar Tagen weiß ich hoffentlich mehr und kann das alles besser bewerten. Zumindest sind PR45291 und PR46779 keine Fehler in der AVR-Maschinenbeschreibung.
Johann L. schrieb: > Das alles ist für 32-Bit-Maschinen kein Thema, > und daher dort auch nicht aufgetreten bzw. aufgefallen. Zu GCCs Rechtfertigung muss man dabei natürlich einwenden, dass dieser seinerzeit mal angetreten war, auf beliebige 32-bit-CPUs portabel zu sein. Dass man ihn überhaupt (und das doch noch recht sinnvoll) auf einer 8-bit-CPU als Ziel zum Arbeiten bekommt, ist in diesem Lichte eigentlich schon eine große Leistung.
Jörg Wunsch schrieb: > Johann L. schrieb: >> Das alles ist für 32-Bit-Maschinen kein Thema, >> und daher dort auch nicht aufgetreten bzw. aufgefallen. > > Zu GCCs Rechtfertigung muss man dabei natürlich einwenden, dass > dieser seinerzeit mal angetreten war, auf beliebige 32-bit-CPUs > portabel zu sein. Dass man ihn überhaupt (und das doch noch recht > sinnvoll) auf einer 8-bit-CPU als Ziel zum Arbeiten bekommt, ist > in diesem Lichte eigentlich schon eine große Leistung. Im konkreten Fall hängt es davon ab, was ein "word" ist... Ich hoffe mal, daß in dem o.g. Zusammenhang 8 Bits gemeint sind.
Johann L. schrieb: > Jörg Wunsch schrieb: >> Johann L. schrieb: >>> Das alles ist für 32-Bit-Maschinen kein Thema, >>> und daher dort auch nicht aufgetreten bzw. aufgefallen. >> >> Zu GCCs Rechtfertigung muss man dabei natürlich einwenden, dass >> dieser seinerzeit mal angetreten war, auf beliebige 32-bit-CPUs >> portabel zu sein. Dass man ihn überhaupt (und das doch noch recht >> sinnvoll) auf einer 8-bit-CPU als Ziel zum Arbeiten bekommt, ist >> in diesem Lichte eigentlich schon eine große Leistung. > > Im konkreten Fall hängt es davon ab, was ein "word" ist... Ich hoffe > mal, daß in dem o.g. Zusammenhang 8 Bits gemeint sind. So, ich hab's abgeklärt. Für 64-Bit Typen gibt's Entwarnung :-)) Für das -fsplit-wide-types (das standardmässig für Optimierung > O1 gesetzt ist), leider noch nicht. Wobei das Problem erst in einem späteren Pass ist, der sich am mit -fsplit-wide-types erzeugten Code verschluckt.
Jörg Wunsch schrieb: > Erics Ziel seit langem ist es, einen Simulator so verfügbar zu haben, > dass ihn jeder X-beliebige GCC-Entwickler bei sich installieren und > damit das AVR-Target testen kann. Erst dann wäre er in der Lage, den > AVR als "2nd tier"-Target aufwerten zu lassen, sodass er stärker in > automatisierten Tests aufschlägt, was wiederum "lack of optimization" > Fehler den GCC-Entwicklern früher gewahr machen würde. Bislang drehen > praktisch all diese Dinge erst eine komplette Runde über einen "mature > release" zu den Anwendern, und von da zurück als PR. MR schrieb: > Ich habe jetzt mal in den letzten GDB-Versionen nachgesehen: Ein > AVR-Simulator ("target sim") ist seit Version in 7.0 in GDB enthalten... Ich hab avr-gdb 7.2 angetestet: Funktioniert out of the Box, zumindest für einzelne Programme. Damit gibe es doch einen Brauchbaren Simulator, der zudem noch einfach enzuwenden ist. Leider finde ich keine Doku, was alles (nicht) unterstützt wird und in welchem Zustand der Simulator ist. Das einzige was fehlt, ist eine brauchbare Implementierung von _exit (macht momentan CLI+Endlosschleife, in libgcc) und abort (springt zu _exit, aus avr-libc.) D.h. man müsste _exit ändern, abort in der libgcc implementieren und es in beiden irgendwie schaffen, den Simulator anhalten zu lassen, falls es kein BREAK gibt. Illegal Opcode ist hässlich und führ bei reales Programmausführung zu undefiniertem Verhalten :-( Vielleicht kamm man auch in den Sim was einbauen, daß er bei einer "sinnlosen" Sequenz wie CLI CLH CLH CLH stoppt. Notfalls müsste man die Testsuite auf ATmega128 oder so festnageln, wo es ein BREAK gibt.
Johann L. schrieb: > Die Atmel-Toolchain würde ich mit Vorsicht geniessen; Atmel scheint den > Fokus eher auf neue Features zu legen als auf das Beheben von Fehlern. > Mit der lezten Version von WinAVR sollte man gut versorgt sein, die > Priorität würde ich nicht beim "Alter der Toolchain" oder "Aler von > Links" festmachen. > Gleich, welche Version von avr-gcc man verwendet (WinAVR, Atmel-Tools, > Linux-Distribution, eigene Builds), sollte man zwei Dinge beachten > 1. -fno-split-wide-types zu den Compileroptionen hinzufügen, auch wenn > das hie und da etwas schlechteren Code gibt. > 2. Keine 64-Bit Typen wie long long oder [u]int64_t verwenden. > Hier kann es zu schwer auffindbaren und schwer zu lokalisierenden > Fehlern kommen, d.h. es wird falscher Code erzeugt -- auch mit > gepatchten Versionen wie WinAVR! Jeder, der mit avr-gcc arbeitet, sollte > diese beiden Punkte beherzigen. > > Zum Glück werden 64-Bit Typen recht selten verwendet, und eine Option > wie -fno-split-wide-types zu setzen ist kein Aufwand. > AVR32-Studio bringt nach der Atmel-Website auch AVR-Tools mit. Wobei ich > nicht nachvollziehen kann, warum man AVR mit AVR32 verbäckt, was ja > bereits bei jüngeren Releases won WinAVR der Fall war. Vielen Dank für eure Infos... werde dann bei der WinAVR2010 Toolchain bleiben. Aus der Unwissenheit heraus gefragt ... Würde es Sinn machen nur einen aktuelleren Compiler bzw. GCC einzusetzen. Ich habe allerdings trotz Hinweise auf der GCC-Webpage keine GCC binaries für Windoof gefunden...
Richard G. schrieb: > Vielen Dank für eure Infos... werde dann bei der WinAVR2010 Toolchain > bleiben. > Aus der Unwissenheit heraus gefragt ... Würde es Sinn machen nur einen > aktuelleren Compiler bzw. GCC einzusetzen. Ich habe allerdings trotz > Hinweise auf der GCC-Webpage keine GCC binaries für Windoof gefunden... http://sourceforge.net/projects/winavr/files/WinAVR/ Die WinAVR-20100110 ist wohl die am häufigsten eingesetzte Version von WinAVR. Auch wenn es gegen diese Version noch Bugreports gibt, so scheinen die in der Praxis nur sehr selten zuzuschlagen. Ansonsten würden sich hier die Beschwerden garantiert häufen ;-) Um ne neuere Version zu erhalten, müsstest du die selber generieren...
Johann L. schrieb: > Die WinAVR-20100110 ist wohl die am häufigsten eingesetzte Version von > WinAVR. Auch wenn es gegen diese Version noch Bugreports gibt, so > scheinen die in der Praxis nur sehr selten zuzuschlagen. Ansonsten > würden sich hier die Beschwerden garantiert häufen ;-) Moment mal, hat Eric nicht die ganzen Tracker zugemacht, sodass man keine neue mehr posten kann?
Johann L. schrieb: > 1. -fno-split-wide-types zu den Compileroptionen hinzufügen, auch wenn > das hie und da etwas schlechteren Code gibt. > 2. Keine 64-Bit Typen wie long long oder [u]int64_t verwenden. kann bitte jemand die beiden Probleme noch mal erläutern? (bzw warum Entwarnung) Johann L. schrieb: > So, ich hab's abgeklärt. Für 64-Bit Typen gibt's Entwarnung :-)) hängt das zweite mit dem ersten zusammen? wass muss ich tun, wenn ich doch uint64_t verwenden will? eigene Operationen schreiben?
Vlad Tepesch schrieb: > Johann L. schrieb: >> 1. -fno-split-wide-types zu den Compileroptionen hinzufügen, auch wenn >> das hie und da etwas schlechteren Code gibt. >> 2. Keine 64-Bit Typen wie long long oder [u]int64_t verwenden. > > kann bitte jemand die beiden Probleme noch mal erläutern? > (bzw warum Entwarnung) 1. -fsplit-wide-types bewirkt ein s.g. Subreg-Lowering, d.h. es wird versucht, größere Datentypen wie DI (64-Bit), SI (32-Bit) oder HI (16-Bit) in Maschinenworte, also QI (8-Bit), zu zerbröseln. Dagegen ist zunächst nix einzuwenden. Aufgrund älterer, fragwürdiger Patches darf Y-Reg keine QI speichern, was schliesslich dazu führt, daß es in seltenen Fällen zu falschem Code kommt. Nämlich eben dann, wenn der Register-Allokator ein QI-Stückchen nach Y allokieren will. In dem Falle wird das erste QI-Stückchen überschrieben, weil der Allokator einen 16-Bit Zugriff macht (andere sind ja nicht erlaubt). Mit -fno-split-wide-types werden weniger solcher QI-Schnipsel erzeugt als mit -fsplit-wide-types (default). Allerdings verbleiben andere Stellen, die QIs erzeugen wie in http://gcc.gnu.org/PR41894 Auch da soll ein QI nach Y gespeichert werden. 2. beruhte auf einer Unklarheit in der internen GCC-Doku, die aber inzwischen geklärt ist. > Johann L. schrieb: >> So, ich hab's abgeklärt. Für 64-Bit Typen gibt's Entwarnung :-)) 2. ist kein Problem und hat nix mit 1. zu tun. 64-Bit-Typen können problemlos verwendet werden -- zumindest was die Korrektheit des Codes angeht. Die Effizienz von DI ist nicht dolle, und daran wird sich in näherer Zukunft auch kaum was ändern. Zumindest ich hab nicht vor, eine Unterstützung für DI zu schreiben. Das ist tierisch viel Arbeit (auch das Testen), fehleranfällig, und DI wird sehr selten in AVR-Anwendungen verwendet (zumindest ist das mein Eindruck) und avr-gcc hat momentan andere Probleme als eine effizientere DI-Implementierung. > hängt das zweite mit dem ersten zusammen? Nein. > wass muss ich tun, wenn ich doch uint64_t verwenden will? eigene > Operationen schreiben? Nein. Jörg Wunsch schrieb: > Johann L. schrieb: > >> Die WinAVR-20100110 ist wohl die am häufigsten eingesetzte Version von >> WinAVR. Auch wenn es gegen diese Version noch Bugreports gibt, so >> scheinen die in der Praxis nur sehr selten zuzuschlagen. Ansonsten >> würden sich hier die Beschwerden garantiert häufen ;-) > > Moment mal, hat Eric nicht die ganzen Tracker zugemacht, sodass man > keine neue mehr posten kann? Keine Ahnung. Ich poste Fehler gegen den jeweiligen primus motor ;-) also gcc, binutils, etc. Jedenfalls gibt es nicht für alle Bugs Patches (s.o.). Wie es mit Linux-Distributionen aussieht weiß ich net. In WinAVR-20100110 gibt es ca. 20 Patches (einige davon sind "nur" Erweiterungen für Ada oder so), also deutlich weniger als die etwas längere Bugliste von avr-gcc [1]: Wie ist die avr-libc Liste [2] eigentlich entstanden? Scheint nur ein copy & paste aus den Origninal-Bugzillas zu sein. Oder wird die automatisch generiert? Jedenfalls ist http://sourceware.org/PR12494 nicht drinne. Also handgeklöppelt? Johann -- [1] http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_gcctarget=avr&cf_gcctarget_type=allwordssubstr&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&product=gcc&query_format=advanced&order=bug_id%20DESC&query_based_on= [2] http://www.nongnu.org/avr-libc/bugs.html
Johann L. schrieb: > [...] Danke für die Erklärungen. Also kann man ohne Bedenken (abgesehen von Effizienz) 64bit-Berechnungen durchführen.
Johann L. schrieb: > Wie ist die avr-libc Liste [2] eigentlich entstanden? Scheint nur ein > copy & paste aus den Origninal-Bugzillas zu sein. Ja, die hat Eric wohl mit der Hand gepflegt.
Jörg Wunsch schrieb: > . Aufwändige Patch-Suites wie Xmega oder mittlerweile wohl tiny10; > hier genügt es einfach mal nicht, dass man da eine GPL drüber > schreibt, sondern du hast wieder das gleiche Dilemma wie auch schon > beim AVR32: GCC besteht auf diesem blöden Copyright-Assignment, und > wenn Atmel das Copyright hält, weil der Patch in deren Auftrag und > mit deren Geld kreiert worden ist, dann bist du wieder bei der > Rechtsabteilung... Gute Nachrichten: Eric hat vor einigen Stunden den Xmega-Patch in die GCC-Codebasis eingepflegt. Offenbar ist also der Segen von Atmels Rechtsabteilung nun wirklich endlich amtlich.
Jörg Wunsch schrieb: > Gute Nachrichten: Eric hat vor einigen Stunden den Xmega-Patch in > die GCC-Codebasis eingepflegt. Sorry, hab' ich vermasselt. Nicht GCC, sondern erstmal binutils. > Offenbar ist also der Segen von > Atmels Rechtsabteilung nun wirklich endlich amtlich. Das bleibt aber trotzdem richtig.
Jörg Wunsch schrieb: >> Gute Nachrichten: Eric hat vor einigen Stunden den Xmega-Patch in >> die GCC-Codebasis eingepflegt. > > Sorry, hab' ich vermasselt. Nicht GCC, sondern erstmal binutils. Bei avr-gcc ist's auch am brodeln -- zumindest unter der Oberfläche. Eric ist dabei die builtin-Unterstützung vorzubereiten :-) (Hatte schon in meinen Patches gekramt und überlegt die dortige Builtin-Unterstützung zu posten, weil ich das von Atmel nicht mehr erwartete)
Guckguck. Da WinAVR 20100110 jetzt mittlerweile auch gut 1,5 Jahre alt ist, wollte ich mal fragen, ob es schon weitere Fortschritte in der AVR-Toolchain zu verzeichnen gibt? Ich habe sie letztens mal drauf gehabt, aber WIMRE war der delay-bug immer noch vorhanden. Auf mich macht es ein wenig den Eindruck eines toten Pferdes. Täuscht mich meine Wahrnehmung? Werde ich wohl weiterhin den 20100110 benutzen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.