Hi,
diese Frage ist vielleicht ein bischen Off-Topic, aber mich würde
wirklich mal interessieren, was da so abläuft.
Lexical Analyer, Parser, Code Generator... Compilerbau allgemein.
Weiß jemand, ob es irgendwo "leichtverständliche" Beschreibungen zum
Thema Compiler gibt. Vielleicht als pdf. Oder auch Diplomarbeiten oder
so?
Bin neu in der Materie und studiere KEIN Informatik :-)
P.S. Habe auch schon gegooglet, aber alles was man da so findet iar ehr
was für Leute, die Informatik studieren. Ich suche ehr so etwas wie
"Compilerbau for Dummies".
Grüße,
Bernd
Uh, Compilerbau ist aber schon etwas für Fortgeschrittene ;-)
Es gibt im Netz eigentlich jede Menge Startpunkte. Wenn Dich erstmal
Parsing, Semantik etc interessieren kannst Du mal nach einfachen
Scribt-Sprachen bzw. Script-Interpretern suchen. Im Prinzip nicht viel
anderes, als beim "richtigen" Compiler-Bau, allerdings ohne reele
Code-Generation. Man kann es folt leichter nachvollziehen und vor allem
ohne viel Auffwand ans laufen bekommen.
Wenn es weiter gehen soll, must Du Dir Wohl oder Übel ein paar
Grundlagen anlesen. Im Netz findet sich so manches Tutorial. Ich bin
neulich über --> Basics of Compiler Design by Torben Mogensen
(http://www.lulu.com/content/822069 bzw.
http://www.diku.dk/~torbenm/Basics/index.html) gestolpert, hatte aber
bis jetzt keine Zeit darin zu lesen. Hier sind auch Fulltext-Bücher
verlinkt: http://homepages.cwi.nl/~steven/pascal/ bzw.
http://de.wikipedia.org/wiki/Niklaus_Wirth#B.C3.BCcher
Viel Spaß!
Der Drachentöter ist das Standardwerk für Informatik-Studenten. Bevor du
viel Geld darin versenkst, solltest du wissen wie ernsthaft du dich
damit beschäftigen willst. Und bist evtl. mit einer gebrauchten Version
auch ganz gut bedient, zumal für einen Überblick auch die
Originalversion von 1977 völlig ausreichen dürfte.
Was die Ausgaben angeht: Wenn die englische 2. Ausgabe von 2006 ist,
kann die deutsche von 1999 eigentlich nur von der 1. Ausgabe des
Originals abstammen, wie auch immer erweitert/verbessert sie sein
sollte.
Generell sind englische Originale den Übersetzungen vorzuziehen. In
diesem Fachgebiet ist die gesamte Literatur nahezu ausnahmslos englisch.
Sich da auf die deutsche Sprache zu versteifen ist folglich nicht
empfehlenswert und erschwert weitere Informationssuche.
Nun ja, ich wollte schon meinen eigenen Compiler schreiben. Einen ersten
Anlauf habe ich ja auch bereits hinter mir.
Siehe hier: http://home.arcor.de/bernhard.michelis/Amadeus%20UPAL.pdf
Nachdem das eigentlich schon ganz gut geklappt hat, wollte ich mal eine
eigene Programmierumgebung, und hier insbesondere die Codeerzeugung aus
einer Skriptsprache heraus schreiben.
Bevor ich allerdings damit anfange, würde ich allerding schon noch gern
etwas mehr über die Materie erfahren, da mein erster Versuch zwar
funktionniert, aber schwer zu warten ist und nicht wirklich sauber
programmert ist.
Nun brauch ich halt ein Buch, dass auf der einen Seite möglichst gut in
die Thematik eintaucht und auf der anderen Seite auch für
Nichtinformartiker verständlich geschreiben ist. Englisch ist ok.
Nur kenne ich Bücher, die für normale Menschen geschreiben sind
(verständliche Wortwahl) und welche, wo die Autoren (häufig irgendwelche
Profs.) der Meinung sind, man müsse alles so präzise beschreiben, dass
man für alles einen Fachausdruck gebrauchen muss, und dann macht das
lesen keinen Spaß mehr, insbesondere, wenn man die Fachausdrücke der
Informatik als bekannt vorausgesetzt werden. So Begriffe wie "Atome"
oder "Vektor" muss man halt erst mal kennenlernen. Für mich ist "Array"
halt verständlicher als "Vektor" und "Pointer" verständlicher als
"Referenz" oder "Record" oder "Dataset" oder "Object" verständlicher als
"Tupel".
Wahrscheinlich wird's immer dann unverständliche, wenn die Autoren
probieren Fachausdrücker der Mathematik zu verwendne.
Grüße,
Berne
Im Deutschen gilt komplizierte Ausdrucksweise als Zeichen für Bildung.
Amerikaner pflegen sich in Fachliteratur daher meist verständlicher
auszudrücken als Deutsche.
Im Compilerbau der letzten Jahrzehnte kommst du um ein gewisses Mass an
Theorie schlecht herum. Man kann zwar eine Sprache entwickeln (leider)
oder einen Parser schreiben ohne jemals etwas von formalen Sprachen
gehört zu haben, aber man kann kein Buch drüber schreiben und hoffen von
Fachleuten ernst genommen zu werden.
Insofern sind Querverbindungen zum Fachgebiet "Automatentheorie und
Formale Sprachen" nur natürlich. Personell übrigens auch, in einem
dortigen Standardwerk steckt der gleiche Autor drin wie im Drachentöter:
Ullman.
Wenn man den Parser mit einem entsprechenden Tool wie beispielsweise
Yacc/Bison bauen und nicht einfach blind durchwursteln sondern das
einigermassen verstehen will, ist ein Ausflug in dieses Fachgebiet
unvermeidlich. Bei einem recursive descent parser geht's indes auch
gänzlich ohne Theorie.
Ähnlich bei der lexikalischen Analyse: Verwendet man dafür Tools wie
Lex/Flex, grinst einem ein anderer Abschnitt dieses Fachgebiets
entgegen. Auch hier kann man ohne Theorie rangehen, aber wenn man
verstehen will was man da tut...
> Wahrscheinlich wird's immer dann unverständliche, wenn die> Autoren probieren Fachausdrücker der Mathematik zu verwendne.
Das liegt in der Natur der Sache. Compilerbau gehört zur Informatik und
Informatik ist eng verwandt mit Mathematik. Die Autoren zu diesem Thema
dürfen davon ausgehen, dass man ebenfalls mit zum Club gehört, denn ein
massentaugliches Thema für populärwissenschaftliche Literatur ist das ja
eher nicht. Wer sich mit mathematischer Ausdrucksweise schwer tut ist da
folglich falsch.
Kann einem übrigens auch in anderem Kontext begegnen: Das Fundament im
Bereich "Formale Sprachen" hat Chomsky geschaffen, ein Linguist ohne
jeden Bezug zur Informatik. Trotzdem ist dieses Thema reichlich
mathematisch besetzt.
Na ja, ein Array ist eben nur eine Möglichkeit, ein n-Tupel
darzustellen ;-)
Compilerbau ist halt eine komplizierte Sache. Das mit der Fachsprache
ist zwar am Anfang nervig, am Ende erkennt man aber, dass man damit
besser klar kommt denn es beschreibt in der Regel Prinzipien statt
Implementierungen. Wie man eine Sache praktisch realisiert ist dann was
anderes [Mathe ist auch was anderes als rechnen ;-)]
Zu den Dragon-Books: Es gibt IMHO eine neue englische Auflage (2nd
Edition):
"Compilers: Principles, Techniques and Tools, known to professors,
students, and developers worldwide as the "Dragon Book," is available in
a new edition. Every chapter has been completely revised to reflect
developments in software engineering, programming languages, and
computer architecture that have occurred since 1986, when the last
edition published. The authors, recognizing that few readers will ever
go on to construct a compiler, retain their focus on the broader set of
problems faced in software design and software development. New chapters
include: Chapter 10 Instruction-Level Parallelism Chapter 11 Optimizing
for Parallelism and Locality Chapter 12 Interprocedural Analysis"
Ich habe die deutsche Ausgabe im Regal. Ist das Standard-Werk, aber
ohne Vorkenntnisse schwer zu verstehen. Es sind 2 Bände da "aus
technischen Gründen " nicht die Gesamtausgabe in einem Band erscheinen
konnte. Kostet neu so ~70€. Mit den kostenlosen PDF's oben bist Du schon
mal gut bedient. Wenn es Dich dann noch weiter interessiert, Bücherreien
haben das Dragon-Book. Für weitere Fragen gibt's ja dieses Forum :-)
Gruß, Michael
> Das mit der Fachsprache ist zwar am Anfang nervig, am Ende erkennt> man aber, dass man damit besser klar kommt denn es beschreibt in> der Regel Prinzipien statt Implementierungen.
Besonders krass war mir das damals in der Vorlesung "Betriebssysteme"
begegnet. War von vorne bis hinten mathematisch. Sieht man dem Thema von
aussen garnicht an.
> Im Deutschen gilt komplizierte Ausdrucksweise als Zeichen für Bildung.
Es gibt vor allem auch deutsche Autoren/Übersetzer, die zwanghaft
jeden englischen Fachausdruck ins Deutsche übersetzen. Das Resultat
ist ein unverständliches Kauderwelsch, und wenn man mit so einem Buch
lernt, wird man nachher auch nicht verstanden.
Je nachdem, was du mit deinem Compiler bezweckst, kannst du dir ja
(und da sind wir wieder on-topic :) auch als Alternative überlegen,
ob du nicht statt eines kompletten Compilers eher ein language
frontend für den GCC schreiben willst. Dann profitierst du vom
kompletten middleend und backend des GCC, d. h. musst dich nicht
um Optimierung und Codegenerierung für die Zielmaschine kümmern.
Für 'ne Scriptsprache eignet sich der Ansatz allerdings wohl eher
nicht.
@Rolf Magnus:
> Es gibt vor allem auch deutsche Autoren/Übersetzer, die zwanghaft> jeden englischen Fachausdruck ins Deutsche übersetzen
Soche Bücher kenne ich auch, z.B. die deutsche Übersetzung von "C++
Programmiersprache/Bjarne Stroustrup" zumindest in der 2. Auflage.
@Jörg Wunsch:
Das mit dem Frontend pass nicht so ganz in meine Planung, da es mir mehr
auf Kompaktheit und Vollständigkeit und Einfachheit in der Handhabung
ankommt, und weniger auf optimale Programmperformance.
Ein weiteres Problem von mir scheint zu sein, dass ich mich in der Open
Source Welt nicht so ganz zurecht finde. Ich hahe mir letztens z.B. Flex
bzw. "Quex - Mode Oriented Lexical Analysis" herunter und wusste michts
mit den Sourcen anzufangen. :-(
Das ist auch der Grund, wieso ich lieber mein eigenes Ding mache, da
weiß ich wenigstens was ich mache.
Es wäre allerdings durchaus interessant Tools wie Flex oder Quex zu
benutzen.
Grüße,
Bernd
Hi Bernd,
zwei wichtige Bestandteile eines Compilers hast du schon genannt: Lexer
und Parser. Die Aufgaben dieser Teile sind recht gut vom Rest eines
Compilers separierbar und es gibt Lexer/Parser, die man beim Compilerbau
"einfach" ranstöpseln kann.
Als Lexer zB flex (C), jflex (Java) und als Parser zB bison, yacc (C)
und CUP (Java).
Nachdem der Parser für vom Lexer gelieferten Tokens interne
Darstellungen erzeugt hat, geht's aber erst richtig los.
Interessant ist vielleicht GCC, weil GCC einerseits weit verbreitet ist
und andererseits die Quellen zugänglich sind. Man kann also einem
Compiler beim Arbeiten "zuschauen".
Die internen Darstellungen im GCC sind TREE und RTL, ab GCC 4.x auch
SSA.
TREE und SSA (static single assignment) dienen als Darstellungen, auf
denen sich gut algebraische Transformationen ausführen lassen.
Grundbedungung für jede Optimierung.
RTL (register transfer language) ist schon recht nahe am Assembler (der
Ausgebe von GCC). Auch RTL erlaubt -- vor allem maschinenabhängige --
Transormationen und Optimierungen. RTL unterteilt sich wiederum in zwei
Untermengen: nonstrict-RTL und strict-RTL. Während in nonstrict-RTL die
Operanden noch lax formuliert sind (zB "ein 16-Bit-Register", es gibt
noch unbegrenzt viele Pseudo-Register), muss in strict-RTL jedes der
prinzipiell unendlich vielen Pseudos einem Register der Maschine oder
einem Stck-SLot zugeordnet worden sein.
Neben diesen Darstellungen ist es essenziell, Infos über das Programm
selbst zu bekommen, also Daten- und Kontrollflußanalysen zu machen und
immer aktuell zu halten.
Konkret bekommst du bei gcc für ein Programm alle RTL-Dumps und ein mit
Infos gespickte asm-Ausgabe mit
1
gcc foo.c -S -save-temps -fverbose-asm -dP -da
"Compilerbau allgemein" ist sehr theoretisch, ob dir das was bringt
ohne Studium und vor allem für ne eigene Implementierung ist fraglich...
Eher aus der Praxis des Compilerbaus sind die GCC Internals, die du in
http://gcc.gnu.org/onlinedocs/
findest (ganz unten unter unter "Internals Documentation").
Für nen Bastel-Compiler kommt man wie gesagt auch mit Java flott
zurande, und für Compier gibt's ganz einfache Implementierungen, die zB
nen Taschenrechner implementieren. Hier ein Java-Parser, bzw.
Parser-Generator mit einfachen Beispielen:
http://www.cs.princeton.edu/~appel/modern/java/CUP/
Und wieder zurück zu C. GCC ist zugegebenermasen recht komlpex mit über
4E6 Zeilen Quellcode...
Für C hat's noch den Open Source Compiler "tiny C compiler", der auch in
gewissem Maße anpassbar ist -- nicht so flexibel wie GCC, dafür aber
wesentlich besser überschaubar.
http://fabrice.bellard.free.fr/tcc/
Nun ja, habe mir gestern die "Drachenbücher" aus der Bibliothek geholt.
Da werde ich jetzt wohl erst mal einen Monat dran zu knabbern haben :-)
Danach werde ich mich dann wohl mal mit Scanner und Parser Gerneratoren
beschäftigen.
Grüße,
Bernd
Wenn du Zugang zu einer Bibliothek hast, schau nach ob sie
vom Wirth 'Compilerbau' haben. Das enthält eine leicht verständliche
Einführung zu dem Thema und Source Code. Die Drachenbücher sind
dann doch schon etwas 'heftige Kost'.
Edit: Seh gerade, das Teil wurde schon erwähnt.
Anyway. Das Buch gibts auch zum download:
http://www.oberon.ethz.ch/WirthPubl/CBEAll.pdf
> Es gibt vor allem auch deutsche Autoren/Übersetzer, die zwanghaft>_jeden_ englischen Fachausdruck ins Deutsche übersetzen.
Habe hierzu gerade ein absulut brilliantes Bespiel gefunden. Wer weiß,
was ein "Kontroll-Keller" ist?
(zu finden in der deutschen Ausgabe von Compilerbau Kapitel 7.1 (Aho,
Sethi, Ullman).
...
...
...
...
Ist doch ganz einfach: Kontroll-Keller ist die anspruchsvolle
Übersetzung von Controll-Stack. Dachte eigentlich immer das Stack im
Deutschen Stapel heißt, aber man lehrt ja nie aus ;-)
> Habe hierzu gerade ein absulut brilliantes Bespiel gefunden. Wer> weiß, was ein "Kontroll-Keller" ist?
Naja, immerhin ist die Übersetzung nur zu 50% wörtlich, was schon ein
beachtliches Ergebnis ist.
"Control" mit "Kontrolle" zu übersetzen ist wie die vielzitierte
"Bush-Administration": wörtlich und in den meisten Fällen (wie auch in
diesem hier) Blödsinn.
Der Begriff "Keller" ist aber nicht wörtlich und völlig richtig: Den
gab's in diesem Zusammenhang schon von dem Anglizismuszeitalter und
stammt auch nicht von Microsoft. Die wörtliche Übersetzung "Stapel"
wäre in diesem Fall sicher treffender, aber bei einem Stapel dachten
die früheren Computerfritzen meist an einen Lochkartenstapel (engl.
"Batch"), deswegen musste ein anderer Begriff her.
Also: Die richtige Übersetzung von "control stack" ist
"Steuerkeller" :-)
In wessen Ohr das vielleicht etwas zu sehr nach Finanzministerium
klingt, der kaufe (oder leihe) sich die englische Version des Buchs
(damit wäre auch wieder Return zum Topic gemanaget), die zudem bei
gleichem Inhalt mit deutlich weniger Papier auskommt (ist sie nicht
auch billiger?).
> Ist doch ganz einfach: Kontroll-Keller ist die anspruchsvolle> Übersetzung von Controll-Stack.
Das schöne daran ist, dass sich im Deutschen beide Begriffe eingebürgert
haben und wild durcheinander verwendet werden. So ist zwar wegen der
sprachlichen Ableitung der Stapelspeicher recht gängig (klingt ja auch
wirklich ein bischen blöd, etwas oben auf den Keller zu legen), aber
andererseits guckt jeder Informatiker beim Stapelautomaten nur blöd,
weil er den allenfalls als Kellerautomat kennt.
Das führt dann leicht zu Stilblüten wie "In der hier angenommenen
Version eines Kellerautomaten hat der Stapel zu Beginn das
Start-Keller-Zeichen '#' (Doppelkreuz)."
(http://www.fbmnd.fh-frankfurt.de/~doeben/I-THINF/TH-THINF/VL11/i-thinf-th11.html).
Wie schon gesagt, ich studire kein Informatik.
Und obwohl ich mich schon mit VC20, C64, Amiga, Atari ST, Macintosh und
Windows-PC, 68000'er, PIC, AVR, ARM herumgeschlagen habe, muss ich
sagen, dass ich den Begriff Keller in diesem Zusammenhang heute zum
ersten mal gehört habe. Alle Bücher und Dokumentationen haben sich bis
heute fein an den Begriff Stack gehalten. Ein Glück, dass ich mir auch
gleich noch die englische Ausgabe mit ausgeliehen habe.
Grüße,
Bernd
Hi, Bernd,
Deine Frage "Wie funktionniert ein Compiler?" ist nicht trivial.
Auf der Suche nach der kompaktesten Antwort fand ich: "Wie funktioniert
Dein Gehirn, wenn es eine mathematische Aufgabenstellung liest wie "wenn
ein Hahn pro Tag 2 Eier legt, wieviele Eier legen dann 10 Hähne in 10
Tagen?"
Oder etwas weniger bescheuert: "Wie funktioniert Dein Gehirn, wenn es
eine Formel sieht wie 25 = (4 + x)^2?"
Im Gehirn reservierst Du für "x" eine Speicherstelle. Wenn Du den
Lösungsweg kennst, dann formulierst Du die Gleichung zu einem "x =..."
um, greifst mental die Zahlen 25, 4 und 2 in der richtigen Reihenfolge,
rechnest schrittweise, bis x = 3 bei herauskommt.
So, und nun übertrage die Vorgehensweise, die Du in der Unterstufe schon
beherrscht hast, auf einen Prozessor und sein Programm.
Und diese bescheuerte Frage mit den Hähnen habe ich gewählt für die
Schwachstelle "garbage-in, garbage out" - der Compiler sieht "Huhn" und
"Hahn" nur als unterschiedliche Namen, kennt keinen Unterschied und
berechnet eine Zahl, die nicht stimmen kann.
Ciao
Wolfgang Horn
Den Begriff "Kellerspeicher" kenne ich schon länger, finde ihn aber
immer noch dämlich. Unser Lehrer am Technischen Gymnasium nannte ihn
(eher scherzhaft) "Pfannkuchenspeicher", weil man wie bei einem Stapel
Pfannkuchen immer das frischeste Element zuerst wieder bekommt.
Hi Bernd,
Compilerbau ist wirklich fortgeschritten. Und um die Grundlagen wie
Automatentheorie (insb. deterministische/nichtdeterministische Endliche
Automaten und Kellerautomaten) wirst Du nicht umherkommen. Ferner musst
Du Dich mit formalen Sprachen und Grammatiken (ausfuehrlich) befassen
sonst kannst Du kein Buch ueber Compilerbau lesen, da Dir die Grundlagen
fehlen. Such mal nach dem Buch "Hopcroft - Einfuehrung in die
Automatentheorie". Wenn Du das Thema sozusagen abgehandelt hast kannst
Du weiterschauen.
Gruesse,
Michael
Soo wild ist das nun auch wieder nicht.
Einen kleinen Recursive Descend Parser kriegt man auch so hin => z.B.
"Taschenrechner" mit Klammerung etc., schöne Übungsaufgabe für
Erstsemester...
Und auch ohne den geringsten Schimmer von Kompilerbau, Formalen
Sprachen, Gramatiken, Scoping, ... kann man eine erfolgreiche
Programmiersprache entwickeln: Siehe PHP, vorzugsweise die älteren
Versionen. (Obwohl viele von den Hämmern immernoch drin sind, soll ja
kompatibel bleiben...)
Naja sich bei solchen Sachen halbherzig damit zu befassen halte ich fuer
vollkommen unzureichend. Und ein primitiver Parser fuer einen
Taschenrechner ist alles aber kein Compiler...
> Und auch ohne den geringsten Schimmer von Kompilerbau, Formalen> Sprachen, Gramatiken, Scoping, ... kann man eine erfolgreiche> Programmiersprache entwickeln:
Dass man das kann ist unstrittig. Leider ist es recht oft auch so
geschehen, was man dem Programmierprachen-Zoo ansehen kann. Erfolg ist
übrigens kein Massstab für Qualität (8086, DOS, ...).
Und da der Fragesteller ja ausdrücklich nach Informationsquellen sucht,
kann man ihm auch ruhig den richtigen Weg empfehlen. Ignorieren kann
er's dann auch selber.
> Such mal nach dem Buch "Hopcroft - Einfuehrung in die> Automatentheorie". Wenn Du das Thema sozusagen abgehandelt hast kannst> Du weiterschauen.
Übertreib mal nicht. Das Thema ist durchaus hilfreich, aber bis zum Hals
drin stecken muss man nun auch wieder nicht. Er will ja einen Compiler
bauen, keinen Parser-Generator.
hallo leuts,
muß auch mal eben eine frage zum thema compiler (speziell c compiler)
stellen. und zwar : gibt es irgendwo eine "art" compiler der aus c-code
einen zwischencode erzeugt der unviersell portierbar ist (also quasi
eine art p-code). selbst wenn es von optimiertem code weit entfernt ist
..
wenn man beispielsweise einen selbstgebauten prozessor hat, für den es
nunmal keinen c compiler gibt, muß man sich immer erst so tief in die
materie einsteigen oder gibt es da andere lösungen (wie z.b. mit dem
zwischencode, welcher sich einfacher auf eine "unbekannte" plattform
portieren lässt, selbst wenn mit dem erzeugten "code" keinerlei
optimierung möglich ist).
gruß
rene
Informatik ist der Krampf aus einer Technologie eine Wissenschaft machen
zu wollen (ex post). In Zukunft ist es sicher eine Wissenschaft
heuzutage ist es noch eine Technologie.
@Bernd
Schreib einfach einen C++ Compiler, du hast 2 Monate Zeit. gcc (benutze
ich gerne) ist längst auch nicht perfekt. Denk daran Turbo Pascal 3.01
war nur 38000 Bytes gross als .com-Datei. Mit Krüppelsprachen brauchst
du gar nicht anfangen.
> gibt es irgendwo eine "art" compiler der aus c-code> einen zwischencode erzeugt der unviersell portierbar ist
So ähnlich arbeitet der GNU-Compiler. Er erzeugt eine Art internen
Zwischencode, der vom Backend dann in den jeweiligen Maschinencode
umgesetzt wird. Was bedeutet, dass man nichts von Compilerbau verstehen
muss, um dem GCC eine neue Zielarchitektur beizubringen.
> Informatik ist der Krampf aus einer Technologie eine Wissenschaft machen> zu wollen (ex post).
Schöner Satz. Aber als Turing und Von Neumann die Grundlagen der
Informatik schufen, waren sie der Technologie ein grosses bischen
voraus. Während Galileis Jupiter-Monde schon lange vor ihm existierten.
@andreas kaiser
danke schön. ich hab mich nämlich schon gefragt ob jeder der einen
gcc-port für eine zielarchitektur schreibt den compiler von der pike auf
neu schreibt (abgesehen vielleicht von tools wie lexer/yacc/bison und
dergleichen) und ein abgeschlossenes studium richtung compilerbau inne
hat plus noch eine brain-extension um den mathematischen background des
optimierens im "arbeitsspeicher" halten zu können.
ich habe damals an der fh selbst compiler-bau gehabt, und es ist auch
eine menge haften geblieben (habe mir selbst einen kleinen parser [die
bezeichnung ist nicht korrekt, müsste eher tokenizer heißen] für
mikrocontroller geschrieben der minimalste ressourcen benötigt), aber
bei dem gedanken einen c compiler zu schreiben mache ich immer noch
dicke backen und ein dummes gesicht .. :-)
gruß
rene
Grundsätzlich ähnelt der GCC dem, was ich früher in Form des Portable C
Compilers genauer kennengelernt habe, nur ein "bischen" komplexer. Der
grösste Teil des Compilers ist immer gleich. Grob vereinfacht stellt
sich mir das so dar:
Es existiert eine Maschinenbeschreibung, die beispielsweise die Grösse
der Datentypen angibt, die Registersätze beschreibt und dergleichen
mehr. Bei gut optimierenden Compilern wie GCC werden auch Kosten von
Operationen beschrieben, um Optimierungsstrategien wie Umordnung von
Operationen möglichst maschinenunabhängig formulieren zu können.
Für die Umsetzung in Assembler-Code (GCC erzeugt keinen Maschinencode)
sorgt dann eine Art Umsetztabelle, die interne Operationen oder auch
komplexere Ausdrücke davon erfasst, und in passende Befehle oder kleine
Befehlssequenzen übersetzt. Und allerlei Hilfsroutinen für Fälle in
denen das mit Templates nicht so simpel ist (function frame, switch
statement, ...).
sowas in der richtung hatte ich erwartet. das man dem gcc nur die
grunlegendsten informationen mit auf dem weg gibt, und der mir einen
zwischen-code ausspuckt, den man dann nach festen regeln in einen (wenn
auch unoptimierten) assembler-code übersetzen kann.
danke erstmal. wenn ich mit meinem selbstbau-prozessor soweit bin werd
ich mir das mal anschaun :-)) (vielleicht auch schon vorher, das gebiet
compiler-bau/scripting finde ich sehr interessant, vor allem auch für
mikrocontroller, sofern es machbar ist)
gruß
rene
> (wenn auch unoptimierten) assembler-code übersetzen kann.
Nope. Was dir bei einem einfachen Backend am Optimierung entgeht, ist
beispielsweise 8-Bit Operationen auch nur 8-bittig durchzuführen. GCC
geht halt davon aus, dass die Maschine 16-Bit am Stück kann. Ein
wohlbekanntes AVR-Problem, die AVR-Version hat zwar einige solcher
Optimierungen in den Templates drin, aber eben nicht überall.
Viele Optimierungen sind jedoch maschinenunabhängig und daher auch ohne
dein Zutun schon drin. Beispielsweise Daten in Registern zu halten,
überflüssige Operationen aus Schleifen rauszuwerfen usw.
> sowas in der richtung hatte ich erwartet. das man dem gcc nur die> grunlegendsten informationen mit auf dem weg gibt, und der mir einen> zwischen-code ausspuckt,
Naja, direkt ausspucken tut er ihn nur in Form von Debugging-Info (davon
gibt's zenterweise, ist aber nicht wirklich leicht lesbar). Der
Codegenerator ist Bestandteil des Compiler-EXEs und arbeitet auf
internen Datenstrukturen. Abgetrennt ist er nur, was die Organiation des
Quellcodes des Compilers angeht.
>Viele Optimierungen sind jedoch maschinenunabhängig und daher auch ohne>dein Zutun schon drin. Beispielsweise Daten in Registern zu halten,>überflüssige Operationen aus Schleifen rauszuwerfen usw.
schön das der das macht. bin jetzt erstmal nicht davon ausgegangen, aber
schon schön wenn ein konstrukt wie : if (3 == 4) { blablabla(); }
erstmal "links" liegen gelassen wird :-)
Ernst Bachmann:
>Und auch ohne den geringsten Schimmer von Kompilerbau, Formalen>Sprachen, Gramatiken, Scoping, ... kann man eine erfolgreiche>Programmiersprache entwickeln: Siehe PHP, vorzugsweise die älteren>Versionen. ...
gerade PHP ist der Superkrampf. Von ein paar Bastlern mit wenig Ahnung
zusammengehaemmert. Das es sich solange gehalten ist ist weniger dem
perfekten Aufbau zuzuschreiben als den Problemen mit seinen
Mitbewerbern.
Interessant, wie sich der Thread so entwickelt. Habe schon garnicht mehr
mitgelesen.
Nun ja, die Sache mit dem "Taschenrechner" habe ich ja schon in meinem
ersten Anlauf erschlagen. Siehe Link weiter oben.
Nun soll es etwas tiefer in die Materie gehen. Ich habe es aber nicht so
eilig. Wenn ich irgendwann nächstes Jahr im Sommer etwas brauchbares
habe, ist es OK.
Die nächsten beiden Semester werden sowieso etwas anstrengender.
Grüße,
Bernd
> Der Codegenerator ist Bestandteil des Compiler-EXEs und arbeitet auf> internen Datenstrukturen.
... die er auch als Datei rausschreiben kann.
Bei GCC kann man eigentlich so ziemlich jeden Schritt der Übersetzung
auch einzeln durchführen lassen.
> Für mich ist "Array" halt verständlicher als "Vektor"
Ja, aber ein Array ist nicht unbedingt ein Vektor.
> und "Pointer" verständlicher als "Referenz" oder "Record" oder "Dataset" oder
"Object" verständlicher als "Tupel".
Ein Tupel ist eine Gruppe. Records, Datasets sind etwas anderes als
Objekte und sowohl das eine, wie auch das andere ist etwas anderes als
ein Tupel.
Und da eben benötigt man Fachausdrücke, denn anders kann man eben nicht
schnell aussagen, was man wirklich sagen möchte.
I can recommend a text by Jack Crenshaw, a great author (often featured
in Embedded Systems Design):
Let's Build a Compiler:
http://compilers.iecc.com/crenshaw/
