Verständnisfrage: Woher kennt gcc den AVR32?

[Moritz E. (devmo)]

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

[(prx) A. K. (prx)]

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.

[didi (Gast)]

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

[Moritz E. (devmo)]

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?

[(prx) A. K. (prx)]

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.

[Johann L. (gjlayde)]

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

[Moritz E. (devmo)]

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?

[(prx) A. K. (prx)]

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.

[Moritz E. (devmo)]

wegen des dateinamens.. nahm ich an das avr-gcc mehr/besonders ist 
gegenüber anderen gcc's für target xy

[Stefan E. (sternst)]

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

[Jörg W. (dl8dtl) (Moderator)]

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

[Johann L. (gjlayde)]

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.