GNU Compiler Collection

aus Wikipedia, der freien Enzyklopädie

GNU Compiler Collection
Das GCC-Logo
Basisdaten
Entwickler:	Das GCC-Team
Aktuelle Version:	4.3.1 (6. Juni 2008)
Betriebssystem:	UNIX, Linux, Windows, Mac OS X, u. a.
Kategorie:	Compiler
Lizenz:	GPL
Deutschsprachig:	ja
Website:	gcc.gnu.org

GCC ist der Name der Compiler-Suite des GNU-Projekts. GCC steht ursprünglich für GNU C Compiler (analog zu dem UNIX-Kommando cc für C Compiler). Da GCC heute aber außer C noch einige andere Programmiersprachen übersetzen kann, hat GCC inzwischen die Bedeutung GNU Compiler Collection erhalten (engl. für GNU-Compilersammlung). Das Kommando gcc (in Kleinbuchstaben) steht weiterhin für den C-Compiler.

[Bearbeiten] Überblick

Die Sammlung enthält Compiler für die Programmiersprachen C, C++, Java, Objective-C, Fortran 95 und Ada. Die Compilersammlung unterliegt den Bedingungen der GNU General Public License.

Die erste öffentliche Version (0.9) des GCC wurde am 22. März 1987 von Richard Stallman für das GNU-Projekt freigegeben (Version 1.0 erschien am 23. Mai desselben Jahres) und wird heute von Programmierern auf der ganzen Welt weiterentwickelt. Die Erweiterung des C-Compilerpakets zur Compiler-Collection erfolgte im Rahmen des EGCS-Projektes, das eine Weile parallel zum GCC existierte und schließlich zum offiziellen GCC wurde.

GCC besteht aus über 25.000 Dateien mit über 2,1 Millionen Zeilen Code.

GCC wird von einer Reihe von Systemen als Standardcompiler benutzt, darunter viele Linux-Distributionen, BSD, Mac OS X, NextStep, und BeOS bzw. ZETA. Er wurde auf mehr Systeme und Rechnerarchitekturen portiert als jeder andere Compiler und bietet sich besonders für Betriebssysteme an, die auf verschiedenen Hardware-Plattformen laufen sollen.

[Bearbeiten] Zielsysteme

GCC 4.1.3 in einem Kommandozeile-Fenster unter Ubuntu 7.10 mit GNOME 2.20

Das GCC-Projekt entschied sich, einige Plattformen offiziell als primäre und andere als sekundäre Evaluationsplattformen zu bezeichnen. Vor jeder Veröffentlichung einer neuen Version werden insbesondere diese beiden Gruppen getestet. Zu den Prozessoren, für die GCC Programme erzeugen kann, gehören (primäre und sekundäre Evaluationsplattformen sind markiert):

Alpha
ARM-Architektur (sekundär, unter Linux)
H8/300
S/370, S/390
x86 und AMD64
IA-64 „Itanium“
Motorola 68000 und Motorola Coldfire
Motorola 88000
MIPS-Architektur (primär unter IRIX)
PA-RISC (primär unter HP-UX)
PDP-11
PowerPC
SuperH
Sun SPARC (primär unter Solaris, sekundär unter Linux)
VAX

Dazu kommen noch eine Reihe von Prozessoren aus dem Bereich eingebetteter Systeme, wie

Motorola 68HC11
A29K
ARC
Atmel AVR
C4x
CRIS
D30V
DSP16xx
FR-30
FR-V
Intel i960
IP2000
M32R
MCORE
MicroBlaze
MMIX
MN10200, MN10300
NS32K
ROMP
Stormy16
V850
Xtensa
Microchip PIC24, dsPIC und PIC32

Insgesamt unterstützt der GCC mehr als 60 Plattformen.^[1]

[Bearbeiten] Struktur

Design Flow von GCC

Das externe Interface des gcc entspricht dem eines Standard-Unix-Compilers.

Der Benutzer ruft ein Hauptprogramm mit dem Namen gcc auf.
GCC interpretiert das Kommandozeilen-Argument
GCC stellt die Programmiersprache der vorliegenden Eingabedatei fest.
Der entsprechende Sprach-Compiler wird aufgerufen.
Die Ausgabe wird dem Assembler übergeben.
Schließlich wird der Linker aufgerufen.
Ein komplettes Programm wurde erstellt.

Jeder Sprachcompiler ist ein separates Programm, das Quellcode entgegennimmt und Assemblersprache produziert. Im Schema auf der rechten Seite sind Beispiele für C und Assembler gegeben, welche sich beide dem Preprocessing unterziehen müssen, bei dem Compilermakros, eingebundene Header-Dateien und ähnliches umgewandelt werden, um reinen C-Code bzw. Assembler zu erhalten. Jenes sprachabhängige Frontend parst die entsprechende Sprache und erzeugt einen abstrakten Syntaxbaum, der an ein Backend übergeben wird, das den Baum in GCCs Register Transfer Language (RTL) überführt (im Diagramm nicht gezeigt), verschiedene Codeoptimierungen durchführt und zum Schluss Assemblersprache erzeugt.

Fast alle Bestandteile des GCC sind in C geschrieben. Eine Ausnahme bildet das Ada-Frontend, das zum größten Teil in Ada geschrieben ist.

[Bearbeiten] Frontends

Frontends müssen Bäume produzieren, die vom Backend verarbeitet werden können. Wie sie dies erreichen, bleibt ihnen überlassen. Einige Parser benutzen Yacc-ähnliche Grammatiken, andere verwenden handgeschriebene, rekursive Parser.

Bis vor kurzem war die Baumrepräsentation des Programms nicht völlig vom Zielprozessor unabhängig. Die Bedeutung eines Baums konnte für unterschiedliche Sprachfrontends unterschiedlich sein, und Frontends konnten ihren eigenen Baumcode zur Verfügung stellen.

Mit dem Tree-SSA-Projekt, das in die Version GCC 4.0 integriert wurde, wurden zwei neue Formen von sprachunabhängigen Bäumen eingeführt. Diese neuen Baumformate wurden GENERIC und GIMPLE getauft. Parsing wird nun durchgeführt, indem ein temporärer sprachabhängiger Baum nach GENERIC konvertiert wird. Der so genannte „Gimplifier“ überführt diese komplexe Form in die SSA-basierte GIMPLE-Form, von der ausgehend eine Reihe neuer sprach- und architekturunabhängiger Optimierungen durchgeführt werden können.

Optimierung an Bäumen passt eigentlich nicht in das Schema von „Frontend“ und „Backend“, da sie nicht sprachabhängig ist und kein Parsen beinhaltet. Die GCC-Entwickler haben diesem Teil des Compilers daher den Namen „Middleend“ gegeben. Zu den gegenwärtig am SSA-Baum durchgeführten Optimierungen gehören Dead Code Elimination, Partial Redundancy Elimination, Global Value Numbering, Sparse Conditional Constant Propagation, und Scalar replacement of Aggregates. Array-basierende Optimierungen wie zum Beispiel automatische Vektorisierung, wie sie der Intel-Compiler anbietet, werden gegenwärtig entwickelt. ^[2]

[Bearbeiten] Backend

Das Verhalten des GCC-Backends wird teilweise durch Präprozessor-Makros und architekturspezifische Funktionen bestimmt, mit denen zum Beispiel die Endianness, Wortgröße und Aufrufkonventionen definiert werden. Unter Verwendung dieser Informationen generiert das Backend die Register Transfer Language (RTL). Obwohl diese dem Namen nach prozessorunabhängig ist, ist die Sequenz an abstrakten Instruktionen daher bereits an das Ziel angepasst.

Die Art und Anzahl der vom GCC an der RTL durchgeführten Optimierungen werden mit jeder Compiler-Version weiterentwickelt. Seit der kürzlichen Einführung von globalen SSA-basierten Optimierungen an GIMPLE-Bäumen haben die RTL-Optimierungen leicht an Bedeutung verloren, da in der RTL-Repräsentation des Programms weit weniger der für viele Optimierungen wichtigen High-Level-Informationen enthalten sind.

In einer „Reload“-Phase werden abstrakte Pseudo-Register durch echte Maschinenregister ersetzt, wobei Daten aus Strukturen verwendet werden, die den Befehlssatz des Ziels beschreiben. Diese Phase ist recht kompliziert, da die verschiedenen Eigenheiten der jeweiligen Zielarchitektur hier besonders berücksichtigt werden müssen.

Die letzte Phase ist relativ unspektakulär. Aus der bereits recht maschinennahen Umsetzung der RTL wird Assemblercode generiert, indem die Namen von Registern und Adressen in Strings umgesetzt werden, die die Instruktionen spezifizieren.

[Bearbeiten] EGCS

EGCS (Experimental/Enhanced GNU Compiler System, zu dt. experimentelles/erweitertes GNU Compiler System) war ein Abspaltung von GCC (1997) und wurde 1999 wieder in GCC eingefügt.

GCC 1.x hatte 1991 eine gewisse Stabilität erreicht, aber architekturbedingte Einschränkungen verhinderten viele Verbesserungen, sodass die Free Software Foundation begann, an GCC 2.x zu arbeiten. Aber in der Mitte der 1990er kontrollierte die FSF sehr genau, was und was nicht zu GCC 2.x hinzugefügt wurde, so dass GCC als Beispiel für das „cathedral“-Entwicklungsmodell benutzt wurde, welches in Eric S. Raymonds Die Kathedrale und der Basar beschrieben wurde.

Da GCC freie Software war, war es Programmierern, die in andere Richtung arbeiten wollten, erlaubt, eine Abspaltung zu entwickeln. Viele Abspaltungen erwiesen sich als ineffizient und unübersichtlich, und die Schwierigkeiten, dass ihre Arbeit vom offiziellen GCC-Projekt akzeptiert wurden, frustrierten viele.

1997 gründete eine Gruppe von Entwicklern EGCS, um mehrere experimentelle Abspaltungen in einem einzigen Projekt zu vereinen. Dazu gehörten g77 (Fortran), PGCC (Pentium-optimierter GCC), viele C++-Verbesserungen und neue Architekturen.

Die Entwicklung von EGCS war schneller und besser als die GCC-Entwicklung, sodass die FSF 1999 offiziell die Weiterentwicklung von GCC 2.x einstellte, stattdessen EGCS als die offizielle GCC-Version übernahm und die EGCS-Entwickler zu den GCC-Maintainern erklärte. Von da an wurde das Projekt explizit mit dem „Basar“-Modell entwickelt und nicht mit dem „Cathedral“-Modell. Mit der Veröffentlichung von GCC 2.95 im Juli 1999 waren beide Projekte wiedervereint.