Hallo!
Ich arbeite derzeit an einem kleinen Interpreter/Compiler. Ich denke nun
darüber nach, welche Programmiersprache er ausführen soll. Ich suche
eine Sprache, für die ein möglichst einfacher, schlanker Compiler
geschrieben werden kann.
Was kann man da empfehlen?
Es sei noch angemerkt, dass dieses Projekt eher Experiment- und
Lerncharakter hat. Aber wenn ich schon einen Compiler schreibe, dann
möchte ich nicht eine völlig neue Sprache erfinden ;-)
Wenn es wirklich nur zum Experimentieren ist: Pascal und Oberon von
Niklaus Wirth sind dafür ganz gut geeignet, in seinen Büchern erklärt er
auch einiges dazu.
Nicht wirklich modern (80er), aber als Grundlage taugt es sicherlich
Sven P. schrieb:
> Forth würde sich da mehr als anbieten.
Für einen Interpreter schon. Aber für einen Compiler weniger.
Aber der Tip mit den Wirth'schen Sprachen passt schon. Syntaktisch sind
die viel klarer als alles rund um C.
Würde da auch eher Pascal oder Oberon empfehlen, gerade wenn die
Programme und der Compiler auch noch nach zwei Tagen lesbar sein sollen.
Quelltexte
ftp://ftp.inf.ethz.ch/pub/Oberon/Books/Compilerbau
und das Buch dazu
http://www-old.oberon.ethz.ch/WirthPubl/CBEAll.pdf
> Was kann man da empfehlen?
Es ist seit zwanzig Jahren Tradition das jeder der programmiert
unbedingt mal einen Forthinterpreter schreibt. Frag nicht wieso,
mach es einfach. :-)
Und wenn du damit fertig bist dann bist du geradezu verpflichtet
einen Compiler fuer Smalltalk zu schreiben weil das schon seit
10Jahren die Sprache der Zukunft kurz vor dem Durchbruch ist.
Olaf
> Es ist seit zwanzig Jahren Tradition das jeder der programmiert> unbedingt mal einen Forthinterpreter schreibt. Frag nicht wieso,> mach es einfach. :-)
Naa...hab schon nen Infix-Postfix-Umwandler herumliegen, da kann ich
jetzt nicht zu UPN übergehen ;-)
Versuch Dich an 'nem C-Compiler. Das mag zwar als Produkt nicht sehr
sinnvoll erscheinen, aber es hilft ungemein dabei, C zu lernen.
Ich habe mir mal "Tiny-C" vorgenommen, den Codegenerator für einen
8-Bit-Prozessor angepasst und ein paar Sprachkonstrukte hinzugefügt. Das
Endprodukt war alles andere als brauchbar, aber über C habe ich
erheblich mehr gelernt, als ein typisches Tutorial hätte vermitteln
können.
Rufus t. Firefly schrieb:
> Versuch Dich an 'nem C-Compiler. Das mag zwar als Produkt nicht sehr> sinnvoll erscheinen, aber es hilft ungemein dabei, C zu lernen.
Sicher lernt er was über C. Vor allem auch, dass ein C Parser nicht
formal sauber implementierbar ist, da sich C nur parsen lässt, wenn der
Lexical Analyser für die Typedef-Symbole einen anderen Code liefert als
für andere Symbole. Die Bedeutung von Statements also über Symboltabelle
und Lexer auf den Parser einwirkt.
"Möglichst einfach" geht anders.
Naja, ich bastel immer noch an meinem Infix-Postfix-Konverter. Dieser
generiert aus einer x-beliebigen Expression einen Postfix-Ausdruck, den
man relativ direkt in Maschinensprache übersetzen könnte. Würde ich mal
als Kernstück eines Compilers bezeichnen.
Das funktioniert soweit gut, was noch fehlt ist eine Typisierung und was
völlig fehlt ist irgend eine Syntaxanalyse... :-)
Pferd von hinten aufgezäumt? Immerhin kommt sowas aus dem Parser, also
der Syntaxanalyse, schon fast von selber raus. Das Ergebnis vom Parser
ist typischerweise ein Baum und der Weg vom Baum zum Postfix-Code ist
trivial.
>Naja, ich bastel immer noch
Wenn Du ganz klein aber halbwegs systematisch einsteigen willst:
N. Wirth: Compilerbau. Von 1986, Teubner, nur 118 Seiten.
Keine Ahnung, ob ich hier totalen Mist programmiere - ein Baum
jedenfalls wird nirgends direkt berechnet, es liegt keine entsprechende
Datenstruktur vor. Jedenfalls funktioniert das ganze recht gut und
elegant.
Die Syntaxanalyse könnte man soweit ich es sehe relativ einfach
einbauen, ja.
Compilerbau ist sicherlich interessantes Gebiet.
Ich würde lieber erst kleinere Brötchen backen, zuerst
regex studieren. Dann mit compiler generatoren wie yacc/flex/bison...
arbeiten. Zum Schluss würde ich wohl Python oder Ruby zum Implementieren
nehmen, but who knows ... vielleicht würde auch mit der generierten
Version zufrieden sein.
Ojee.
Da gab es doch viel kleinere nette Sprachen, wo der Interpreter richtig
winzig war.
LISP?
BASIC Dialekte?
FORTH (wurde schon erähnt)?
Übrigens: Sehr interessant weil mächtig und selten benutzt: REXX (Siehe
"REGINA" für Linux/Windows)
Grüße,
Mike
REXX, ja. Wieder so eine Sprache in der man fast nichts wirklich falsch
schreiben kann, weil der Interpreter auch im grössen syntaktischen Mist
noch irgendeinen Sinn sieht, statt zu meckern.
Hm, wie möchtest Du denn eigentlich den übersetzten Code ausführen? Hast
Du Dir schon mal Gedanken gemacht, ob das eine reale oder eine virtuelle
Maschine werden soll?
Stephan
> Hm, wie möchtest Du denn eigentlich den übersetzten Code ausführen? Hast> Du Dir schon mal Gedanken gemacht, ob das eine reale oder eine virtuelle> Maschine werden soll?
Bislang generiere ich einen Zwischencode, den man relativ direkt in in
Assembler übersetzen könnte oder auf einer virtuellen Maschine ausführen
kann. Ich spiele schon länger mit dem Gedanken, in einen FPGA einen
einfachen Prozessor zu implementieren, eventuell wird das die
Fortsetzung des Projekts ;-)
Derzeit lese ich aber ein bisschen etwas über die ganze Theorie des
Compilerbaus, um bei der Spielerei wenigstens ein weni theoretisches
Fundament zu haben.
babygcc schrieb:
> Ich spiele schon länger mit dem Gedanken, in einen FPGA einen> einfachen Prozessor zu implementieren, eventuell wird das die> Fortsetzung des Projekts ;-)
Uiui, da hat jemand aber viel vor :-)
Wenn Du entsprechenden Zwischencode hast, versuch doch mal, den in
möglichst einfaches x86-Assembler zu transformieren. Der Vorteil liegt
ja nun auf der Hand: Du brauchst keinen Simulator (und wenn doch gibts
sowas ja schon) und einen Debugger und das ganze restliche
Toolchain-Zeugs gibts ja auch schon.
Zur Not degradierst Du Deinen Pentium/Athlon/sonstwas halt zur
stackbasierten Maschine, außer Du willst es Dir umbedingt antun, einen
Register Allocator und das ganze Zeug zu basteln. Egal wie, aber wenn
das ganze irgendwie z.B. auf einer x86-Maschine läuft, bist Du eh schon
sehr weit und hast viel gesehen und gelernt.
Na dann mal ran... :-D
Stephan
Das Projekt ist mittlerweile etwas fortgeschritten: Es kann mittlerweile
anhand einer kontextfreien Grammatik eine Syntax formuliert werden, die
dann geparst wird. Eine kontextfreie Grammatik einzulesen und daraus
eine Zustandsmaschine zu bauen, die einen Input parsen kann, ist
natürlich ziemlich tricky, aber man bekommt dafür auch eine
Universalwaffe.
Nächster Schritt ist nun, dass die Syntax auch eine Semantik tragen
kann, die dann umgesetzt wird.
babygcc schrieb:
> Eine kontextfreie Grammatik einzulesen und daraus> eine Zustandsmaschine zu bauen, die einen Input parsen kann, ist> natürlich ziemlich tricky, aber man bekommt dafür auch eine> Universalwaffe.
Hätte da nicht auch bison/yacc gereicht?
Stephan
> Hab auch grad gedacht
Hey! War auch mein Gedanke.
Garnicht davon zu reden das man dann seine Sprache beliebig
erweitern kann und jedesmal nur make aufruft und der neue
Source wird erzeugt.
Olaf
Wenn Dich sowas ernsthaft interessiert ist natürlich das Büchlein von
Prof. Niklaus Wirth "Compilerbau" interessant. Compiler in einen
Zwischencode und einen passenden Interpreter. Das ist ja zur Zeit sogar
wieder modern, es nennt sich nur JAVA. In diesem Umfeld gab es sogar
einen fertigen PASCAL-Compiler, irgendwo müsste der sogar bei mir noch
zu finden sein, sei es auch nur als Assemblerquelle auf einer 5-1/4-Zoll
Diskette.
Den anderen Hinweis kannst Du auch mal suchen: Prof. Wippermann
Compilerbau Uni Kaiserslautern;
Und da ist dann auch noch das Standardwerk von Aho, Sethi und Ullman,
gibt es in jeder Universitätsbibliothek oder gerade auch bei Amazon, ist
aber in english und besteht aus mehreren Bänden...