www.mikrocontroller.net

Forum: Compiler & IDEs Wie funktionniert ein Compiler?


Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß!

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke Euch. Werde mir das "Basics of Compiler Design" Buch mal 
durchlesen.

Man ließt auch immer wieder mal was vom "Drachenbuch: Principles of 
Compiler Design".
Da gibt es eine deusche Ausgabe: 
http://www.amazon.de/o/ASIN/3486252941/ref=s9_asin...
und eine englische: 
http://www.amazon.de/o/ASIN/0321486811/ref=s9_asin...

Sofern jemand die Bücher kennt, welche Ausgabe würdet Ihr empfehlen? 
Beides soll die zweite Ausgabe sein, wobei das deutsche Buch (2 Bände) 
von 1999 ist und die orginalausgabe von 2006 (?). Oder ist das deutsche 
Buche keine Übersetzung der englischen Ausgabe? Dafür ist es auch 20€ 
billiger.

Grüße,
Bernd

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups, das Wort Dataset bedeutet ja doch etwas anderes. Bitte wegdenken.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nu ja,

dann werde ich mich da jetzt wohl erst mal ein Stückchen reinarbeiten 
müssen.

Danke Jungs,
Bernd

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein paar der gut lesbaren Grundlagenbücher von Wirth sind auch im Netz 
verfügbar.
http://www.oberon.ethz.ch/WirthPubl/CBEAll.pdf
http://www.cs.inf.ethz.ch/~wirth/books/Compilerbau1/

Für die "interessanteren" Sachen:
Advanced Compiler Design and Implementation, Steven Muchnick
http://books.elsevier.com/us//computerscience/us/s...

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: G. L. (sprintersb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
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/

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ;-)

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?).

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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/T...).

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Horn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Julian Von mendel (jvm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei 25 = (4 + x)^2 kommt nicht x = 3 heraus, sondern x[1] = -9 und x[2] 
= 1.

Autor: Wolfgang Horn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, Julian,

der Kandidat hat 100 Punkte! :-)

ciao
Wolfgang Horn

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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, ...).

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> (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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 :-)

Autor: Realpotter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Ingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Jacek Wikiera (gastarbeiter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.