spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ist ja gerade so Mode, da dachte ich mir, ich präsentiere meine kleine Sprache auch mal. Sie nennt sich Alpha, beschränkt sich bisweilen auf nur einen Datentypen und kann bisher Variablen halten, Terme berechnen (bis auf Div/Mod Operatoren) und etwas ausgeben.
Nachdem sich meine BA auf Transcompiler beschränkte, wollte ich, wie wahrscheinlich viele hier, auch endlich mal eine "wirkliche" Sprache verfassen. Angefangen habe ich dabei mit dem schönen Tutorial hier: http://magazin.c-plusplus.de/artikel/Compilerbau
Allerdings ist es IMO schon etwas in die Jahre gekommen und schon etwas quick and dirty. Aber das kann man ja niemanden verübeln, ist ja auch ein riesen Thema.
Ich habe jedenfalls darauf aufgebaut und es kam mein Repo 'Compiler' (https://github.com/Dgame/Compiler) dabei heraus. Das war erstmal ein fixer Versuch, das ganze gelernte besser umzusetzen. Allerdings hab' ich dann doch schnell gemerkt, dass meine Planung nicht ausreichend war und ich immer wieder auf Hindernisse stieß. Also habe ich schließlich aufgehört und nun nochmal von vorne begonnen, mit einem hoffentlich besser durchdachten Aufbau. Herausgekommen ist dabei jedenfalls Alpha: https://github.com/Dgame/Alpha

Mein Ziel ist es, genau wie in dem obigen Tutorial, eine mehr oder minder vollständig funktionierende und zu gebrauchende Sprache zu entwickeln und dann daraus ein paar Schritt für Schritt Tutorials zu machen und auf meinem Blog zu posten. Es gibt sicher noch andere, die auch den Traum haben, mal eine eigene Sprache gemacht zu haben und vllt. hilft denen das ja weiter.

Die Sprache selbst wird in Assembler übersetzt (genauer gesagt GAS) und unterstützt theoretisch 16, 32 und 64 Bit Systeme, wobei bisher nur 32 Bit getestet wurden.

Genau, GAS ist GNU Assembler. Damit wurde in dem Compilerbau-Tutorial ebenfalls gearbeitet, also hatte ich dort die meisten aktuellen Kenntnisse.
Snippets kannst du dir in der main ansehen, die sind momentan einfach noch fest verdrahtet für einen kompletten Testdurchlauf, was sich mit dem nächsten Commit aber ändern wird:
https://github.com/Dgame/Alpha/blob/master/main.cpp
Der Output jeder dieser Einträge findest du im Output Ordner: https://github.com/Dgame/Alpha/tree/master/Output
Und sofern es dich interessiert, hier ist die äußerst schlanke Runtime: https://github.com/Dgame/Alpha/blob/master/rt.c

Das mit dem Tutorial rührt daher, dass ich selbst echt viel gesucht habe, aber kaum etwas gefunden habe, das wirklich gut ist. Sogar das Beispiel welches im Drachenbuch entwickelt wird, ist dagegen nicht so prall.
Also warum nicht diese Lücke schließen.

edit:
Als kleine Snippet Zusammenfassung:

Zitat

var a = 42
print a
print 23
print 1 + 2 * 3

Pro Zeile also ein Befehl sozusagen und kein Comma Operator.

So, nun sind die Testdateien extern und werden geladen. Snippets/Testdateien sind jetzt unter dem Ordner 'Input' zu finden.

Und die ersten Probleme rollen an.
Ich implementiere gerade die Div und Modulo Operationen (sind ja beides nahezu identische Abläufe) allerdings habe ich ein kleines Problem: Division ist ja genau wie Subtraktion nicht assoziativ, also müssen die Operanden in der umgedrehten Reihenfolge hinein. Hat jemand eine Idee, wie sich das am schönsten bewerkstelligen lässt oder wie man das direkt in Assembler umsetzt?
Für print 4 / 2 sieht mein Code bisher so aus:


Aber es müssten natürlich zuerst die 2 und dann die 4 kommen. Theoretisch müsste ich also jeden Term einmal darauf untersuchen, und wenn ein Op::Div darin vorkommt, müsste ich die vorherigen beiden Operanden vertauschen. Eine nicht gerade schöne Lösung, da ich dann jeden Term zweimal anfassen/durchlaufen muss.
Für Subtraktion war das Problem durch die Umdrehung der Operanden lösbar, aber das scheint wohl nicht der Fall zu sein für Division.

Zur Vollständigkeit: Der obige Term wird in folgender Form/Reihenfolge gespeichert: 4 2 /

Ok, gelöst durch eine kleine Umstellung:
Wenn der übernächste Parameter ein Op::Div oder Op::Mod ist, dann wird nichts gepusht und der nächste Wert nicht im AX Register, sondern in BX Register gespeichert. Der Div/Mod Operator muss demnach auch das Register AX nicht mehr in das Register BX moven. Nun klappt es und sieht folgendermaßen aus:

Noch ein kleines Update: Habe die Print Ausgabe ein wenig optimiert. Vorher wurden auch einzelne Ergebnisse, wie z.B. bei print 42 oder print a, erstmal ins AX Register gemoved und dann dieses Register gepusht. Besteht der Term jedoch nur aus einem Element, kann er direkt gepusht werden. Das geschieht jetzt auch.

Zum Vergleich:
Vorher:

Nachher (jetzt):