Ich will mich in den AVR32 einarbeiten, der wird ja auch mit der Gnu-Toolchain gefüttert. Ich frage mich aber an welcher Stelle der GCC bzw der AS den Code speziell für AVR32 umsetzt. Es gibt da ja kein Crosscompiler wie avr-gcc. Ist die AVR32 Architektur schon im GCC von Haus aus bekannt? Woher kommt die architekturspezifische Implementierung, von Atmel, und steckt sie im GCC oder im AS? Soweit ich das verstehe, muss entweder der GCC doch alle gängigen Targets von haus aus bedienen können, oder es muss an irgendeiner Stelle der Toolchain architekturspezifische Erweiterungen geben? Bei den AVRs gibt es ja avr-gcc...
Von allein passiert da garnichts. Der Compiler der sich komplett selbst schreibt ist noch nicht erfunden worden. GCC und mindestens Teile der Binutils werden für jede Zielarchitektur getrennt übersetzt. Ob die als Crosscompiler oder auf dem Zielsystem laufen, ist wählbar - letzteres bei AVR hingegen etwas schwierig.
Gast
#1072995
du kannst beim Compilieren deiner Toolchain festlegen, welche Architekturen der Compiler unterstützen soll. Dadurch wird natürlich deine Toolchain auch größer. Wie A. K. schon gesagt hat, von alleine passiert da nix
Also der gcc, der bei der AVR32 Toolchain mitgeliefert wurde, wurde schon für den AVR32 übersetzt und könnte kein x86 Programm erzeugen? Soweit ich bisher gelesen habe gibt es einen Maschinenunabhängigen und einen Abhängigen Teil, dann würde der Maschinenabhängige Teil von Atmel geliefert worden sein? Was mich verwirrt ist die spärliche Versionsangabe, weder bei gcc -versiondump (oder so) noch in der info Datei noch in der AVR32 Studio Help ließ sich entnehmen, um was für ein gcc es sich da handelt. Der Maschinenabhängige Teil von Atmel sollte dann ja auch opensource sein, wird er auch von nicht-Atmel Opensource-Programmierern gepflegt?
Moritz E. wrote: > Also der gcc, der bei der AVR32 Toolchain mitgeliefert wurde, wurde > schon für den AVR32 übersetzt und könnte kein x86 Programm erzeugen? Korrekt. > Soweit ich bisher gelesen habe gibt es einen Maschinenunabhängigen und > einen Abhängigen Teil, Ja, aber das beschreibt die Organisation des Quellcodes. Mit der Auswahl der Zielmaschine wird beim Übersetzen des Compilers genau einer der maschinenabhängigen Teile ausgewählt. > dann würde der Maschinenabhängige Teil von Atmel > geliefert worden sein? Wahrscheinlich. Microchip macht das beim PIC30 auch nicht anders. Beim PIC32 war es einfacher, da der GCC schon seit 2 Jahrzehnten für MIPS32 existiert. > Der Maschinenabhängige Teil von Atmel sollte dann ja auch opensource > sein, Muss er.
Da GCC unter GPL steht, müssen alle Teile, auch die maschinenabhängigen, unter GPL stehen. avr32 gehört jedoch nicht zu den offiziellen Backends wie i386 etc. http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=4118
warum ist es denn anders beim avr-gcc, wurde da auch der unabhängige Teil angepasst? Wie ich las leidet der jedoch auch unter auf herkömliche 32bit Architekturen abziehlenden Optimierungstollheiten?
Was ist beim avr-gcc deiner Ansicht nach anders als bei was? AVR ist immerhin im offiziellen GCC Code drin, insofern ist da ziemlich sicher nichts AVR-spezifisches im maschinenunabhängigen Teil.
wegen des dateinamens.. nahm ich an das avr-gcc mehr/besonders ist gegenüber anderen gcc's für target xy
Nein, der Name ist hier nur ein Hinweis darauf, dass es ein Cross-Compiler ist. gcc -> produziert Code für den Prozessor, auf dem er selber auch läuft avr-gcc -> produziert Code für den AVR, läuft aber selber auf einem anderen Prozessor
A. K. wrote: > Ob die als Crosscompiler oder auf dem Zielsystem > laufen, ist wählbar - letzteres bei AVR hingegen etwas schwierig. Hier geht's aber um AVR32, da ist das schon denkbar (zumindest beim AP7000).
Moritz E. wrote: > warum ist es denn anders beim avr-gcc, wurde da auch der unabhängige > Teil angepasst? Klar, ein (Cross)Compiler fällt nicht vom Himmel. Damit ein Backend -- bzw. Änderungen an GCC im allgemeinen -- in die offizielle Version reinkommen, müssen bestimmte Bedinungen erfüllt sein. -- Jemand muss die Änderungen machen/zur Verfügung stellen -- Die Änderungen müssen bestimmten Formalitäten (auch rechtlichen) genügen -- Die Änderungen müssen akzeptiert und übernommen werden -- Ein offizieller Maintainer für das Backend muss her (viel Arbeit) > Wie ich las leidet der jedoch auch unter auf herkömliche > 32bit Architekturen abziehlenden Optimierungstollheiten? Jo, leider. Selbst wenn man ein gcc-Backend anpackt kann man damit immer weniger steuern, wie der erzeugte Code im Endeffekt aussieht, obwohl das Backend ja "am nächsten" an der Maschine dran ist. Jedenfalls find ich die gcc 4.4 noch seltsamer als den 4.3. Aber gcc ist ja ständig im Fluß, kommt vielleicht noch? Das Middleend von GCC (der maschinen- und sprachunabhängige Teil) hat eine immer ununstösslichere Vorstellung dessen, wie "guter" Code aussieht... Dabei sind nur sehr wenige Optimierungen wirklich absolut maschinenunabhängig. Selbst DCE (dead code elimination, das Entfernen nicht-verwendeten Codes) kann in Sonderfällenfällen zu einer Verschlechterung der Codegüte führen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.