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ß!
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_image_1-1966_g1/028-5946340-0757368?pf_rd_m=A3JWKAKR8XB7XF&pf_rd_s=center-1&pf_rd_r=10MV3J7WXG08CYMF3GP8&pf_rd_t=101&pf_rd_p=139524491&pf_rd_i=301128 und eine englische: http://www.amazon.de/o/ASIN/0321486811/ref=s9_asin_image_1-1966_g1/028-5946340-0757368?pf_rd_m=A3JWKAKR8XB7XF&pf_rd_s=center-1&pf_rd_r=1MHG2Z192V1K5390RKV1&pf_rd_t=101&pf_rd_p=139524491&pf_rd_i=301128 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
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
Ups, das Wort Dataset bedeutet ja doch etwas anderes. Bitte wegdenken.
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.
Nu ja, dann werde ich mich da jetzt wohl erst mal ein Stückchen reinarbeiten müssen. Danke Jungs, Bernd
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/subindex.asp?maintarget=&isbn=9781558603202
> 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.
Bei 25 = (4 + x)^2 kommt nicht x = 3 heraus, sondern x[1] = -9 und x[2] = 1.
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/
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.