Thema: Eigene Bytecodebasierte Sprache

[SSJ7Gohan]

Hi,
IMHO gibt es heute keine wirklich gute universelle Bytecode basierte Sprache. Java ist ganz gut, aber es hat keine Structs und keine unsigned Typen. Daher muss man bei der Eingabe/Ausgabe immer zwischen signed und unsigned umwandeln und verbraucht unötig viel Speicherplatz. .NET/C# behebt diese Probleme, jedoch hat es nur eine kleine Standardbibliothek und man muss häufig nativen Code einsetzen, was ich verhindern möchte. Ausserdem ist es intern nicht wirklich gut aufgebaut, .NET baut auf eine Art PE auf. .NET sollte zwar portabel sein, aber große Teile der Bibliotheken funktionieren nur unter Windows und sind proprietär. Hinzukommt, dass alle Sprachen bisher noch Wünsche beim Multithreading und bei der Speicherverwaltung offen lassen.

Deshalb habe ich mich entschlossen ein eigenes Bytecode Format und eine eigene Sprache zu entwickeln, das diese Features ergänzt.

Bei der Syntax hatte ich an eine Art C/C++/Java gedacht, da diese Syntax den meißten bekannt sein sollte.

Ich wollte jetzt mit einem Compiler für eine solche Sprache anfangen (der Compiler wird warscheinlich in Java geschrieben sein), und wollte fragen, ob jemand schon Erfahrungen im Compilerdesign hat. Wenn sich jemand beteiligen möchte, würde ich mich sehr freuen. Ich aber im Moment aber nicht so viel Zeit, da ich hauptsächlich an Legends und meinen Java-JIT Compiler arbeite. Dieser JIT ist ausserdem so flexibel, das meine eigene Sprache später, wenn der Compiler funktioniert, darin eingebettet werden könnte.

Naja, wie gesagt, hat jemand schon Erfahrungen im Compilerbau oder möchte jemand mitmachen?

[DarkThing]

Hört sich interessant an! Ich hatte mich mal mit Compilern, Interpretern, Bytecodes usw. beschäftigt - aber nicht wirklich viel.

Ein recht interessantes und gutes Tutorial dazu ist das hier (sind mehrere Teile, Links zu den anderen Teilen sind weiter untem im Tutorial) : http://www.flipcode.com/articles/scripting_issue01.shtml
Dort geht es eigentlich um die Implementierung einer Scriptsprache für eine eigene 3D-Engine, aber es lässt sich ziemlich gut auf alles andere übertragen.

[joachim_neu]

Naja, wie gesagt, hat jemand schon Erfahrungen im Compilerbau oder möchte jemand mitmachen?

Mitmachen will ich nicht, aber ich hab schonmal damit Kontakt gehabt. Am besten gehste zu einer Bibliothek und leihst dir Bücher drüber aus, z.B. vom Nikolaus.

[n3Ro]

Von Aho/Sethi/Ullmann gibts ein sehr gutes Buch über Compilerbau (Dragonbook).Ich hab es mir für einen Compiler/Interpreter für eine C-Ähnliche Sprache besorgt, den ich vor 2 Monaten geschrieben habe. Ansonsten ist auch Slonneger/Kurtz "Formal Syntax and Semantics of Programming Languages - A Laboratory Approach" aus dem Addison-Wesley Verlag ganz gut.

[Legend]

Ja, an sowas hab ich auch schon gedacht, wollte es aber nicht beginnen da es selber ein riesiges Thema ist und Java/C# good enough(tm) für mich sind (bislang)!

[joachim_neu]

Addison-Wesley haben viele gute Bücher. Da hab ich schon einige gute von gesehen..

[SSJ7Gohan]

Hm, ja, ich werde mal sehen, ob ich mir ein Buch kaufe.
Am meisten Probleme macht mir eigentlich der Parser, die Codegenerierung, die lexikalische Analyse usw. ist kein Problem.
Ich denke aber, das ich mit dem Projekt erst in einem Monat oder so anfangen werde.

[Legend]

Ja, lex und yacc war kein Spass in Informatik I bei uns.

[n3Ro]

Ach ,wer benutzt denn sowas ,  hab mir lieber einen Recursive-Descent Parser geschrieben, hat sich besser angeboten, und die 100 Zeilen des Scanners waren auch schneller geschrieben, als eine Einarbeitung in Lex gedauert hätte.

[SSJ7Gohan]

Ja, ich hatte auch daran gedacht, einen eigenen Parser zu schreiben.
Ich verstehe aber noch nicht ganz, wie das jetzt funktionieren soll. Kannst du mir das Prinzip eines Recursive-Descent Parsers erklären, oder hast du irgentein Dokument, das es beschreibt?
EDIT: Ich habe bei Google eine ganz gute Beschreibung gefunden, ich werde sie mir mal ansehen

[C#ris]

Hi,
Deshalb habe ich mich entschlossen ein eigenes Bytecode Format und eine eigene Sprache zu entwickeln, das diese Features ergänzt.

Grundsätzlich find ich deine Idee gut, aber würde an deiner Stelle den Bytecode nicht so stark mit einer höheren Programmiersprache verknüpfen, sondern flexibel und offen gestalten, sodass man zB C# oder Java Compiler für deinen Bytecode schreiben könnte.

Da ich ja grade an ner Java VM schreibe finde ich das Thema sehr interessant und würde mich auch einer Entwicklung beteiligen (soweit das mein knapper Zeitrahmen zulässt...:/).

Gruß,
C#ris

[SSJ7Gohan]

Ne, mein bytecode wird etwa so aussehen, wie der Zwischencode meines JIT Compilers, und mehrere Sprachen unterstützen.

Einen Assembler für den Bytecode habe ich schon mehr oder weniger fertig, der Hochsprachencompiler kann bisher aber noch keine Funktionsaufrufe kompilieren.

[SK-Genius]

Hi,
IMHO gibt es heute keine wirklich gute universelle Bytecode basierte Sprache.

das denk ich auch, aber ich bin noch nicht so tief im thema drinn

Java ist ganz gut, aber es hat keine Structs und keine unsigned Typen. Daher muss man bei der Eingabe/Ausgabe immer zwischen signed und unsigned umwandeln und verbraucht unötig viel Speicherplatz.

das schlüsselwort Struct wird vollkommen von class abgedeckt. du must nur ne klasse ohne methoden erstellen und alle eigenschaften public machen. class ist im grunde nur eine erweiterung von struct welche es erlaubt auch proceduraufrufe in einer "struktur" zu speichern.

unsigned datentypen werden komplet von signed typen abgedeckt solange man darauf achtet das weder nach oben die bereichsgrenze überschreitet noch nach unten über die null hinaus geht. man kann also fast problemlos auf die unsigned typen verzichten. das bissel was du dir an rechenzeit einsparst wenn du unsigned typen einführst verlierst du wieder durch die dadurch etwas komplexer gewordene vm welche dann diverse fallunterscheidungen beachten muss.

.NET/C# behebt diese Probleme, jedoch hat es nur eine kleine Standardbibliothek ...

du weisst aber, dass das umsetzen einer grosse standardbibliothek eine extrem grosse fleisaufgabe ist???

ich hoffe du hast mehr vor als nur das einführen des überflüssigen struct-schlüsselwortes und der unsigned typen die keiner vermisst und durch die wahrscheinlich nur zu einer fehleranfälligeren sprache verhilft (<- denkaufgabe).

gruss SK

[Legend]

unsigned datentypen werden komplet von signed typen abgedeckt solange man darauf achtet das weder nach oben die bereichsgrenze überschreitet noch nach unten über die null hinaus geht. man kann also fast problemlos auf die unsigned typen verzichten. das bissel was du dir an rechenzeit einsparst wenn du unsigned typen einführst verlierst du wieder durch die dadurch etwas komplexer gewordene vm welche dann diverse fallunterscheidungen beachten muss.

Na ja, beim Speicher und Laden von Dateien könnte das wirklich recht störend sein.

.NET/C# behebt diese Probleme, jedoch hat es nur eine kleine Standardbibliothek ...

du weisst aber, dass das umsetzen einer grosse standardbibliothek eine extrem grosse fleisaufgabe ist???

Hmm, nun ja, das andere extrem wäre sicher C++, wo die STL erst später hinzugekommen ist und z.B. Qt eine eigene Stringklasse hat. Das ist schlimmer als eine grosse Fleisaufgabe und dann funktioniert ist.

[SSJ7Gohan]

unsigned Datentypen sind oft nützlich, wenn man einen großen Zahlbereich hat, aber keine negativen Zahlen für etwas verwendet. Klar kann man das immer umrechnen, aber das verbraucht Rechenzeit. Wenn man einen unsigned Wert speichern muss und man nur signed Datentypen zur Verfügung hat, muss man entweder immer umrechnen, oder mehr Speicher nutzen, als eigentlich benötigt wird. Die leichtere Implementation ist kein Argument, da meinen Just-In-Time Compiler eh irgentwann man .NET unterstützen sollte, und ich so überhaupt keinen Arbeitsaufwand spare.

Ausserdem fehlt mir die Stackallokation, z.B. für Strings, die nur eine kurze Lebensdauer haben. Realisiert wird das in meiner Hochsprache durch ein Schlüsselwort local, das bewirkt, das eine Variable oder ein Parameter auf dem Stack allokiert wird, und nicht in ein Feld geschrieben werden darf.

Wünschenswert wären auch Strukturen, die anders als Klassen keine Laufzeitinformationen speichern. Wenn man ein Array von 10000 Objekten hat, und jedes muss 4 Bytes für die Klasse, der es angehört mitspeichern, verbrauche ich schonmal 40000 wenn jede Struct nur aus zwei Byte besteht, sind das 200% mehr verbrauchter Speicher. Ausserdem kann ich so leichter auf Daten im Speicher zugreifen, die keine Objektinformationen enthalten. In meiner Hochsprache ist etwa sowas möglich: "byte[] array = unsafe(<Speicheraddresse>);", um einfach auf Speicherstellen zugreifen zu können, ohne zusätzliche Pointer Datentypen einzuführen, welche in ihrer von C bekannten Syntax auch das Parsen sehr viel schwerer machen würden.

Eine große Standardbibliothek ist eigentlich unvermeindlich für eine portable Sprache, die auf Bytecode basiert. Normale Anwendungen werden bei in meinem Just-In-Time Compiler definitiv nicht nativen Code nutzen dürfen, da der Compiler im Kernel läuft, und eine Anwendung sonst das gesammte System zerstören könnte. Daher braucht die Sprache eine Bibliothek, die alle Funktionen des Betriessystems abdeckt, darunter Threads/Prozesse, verschiedene Sachen wie Zeitzonen, länderspezifische Codierungen von verschiedenen Sachen, E/A für Netzwerk, Dateien und Grafik (naja, das zählt man normalerweise nicht zu den I/O Funktion), usw.

[Legend]

Kurzum, mindestens alles was man braucht um alles andere darauf aufbauen zu können ...

[Legend]

Ausserdem fehlt mir die Stackallokation, z.B. für Strings, die nur eine kurze Lebensdauer haben. Realisiert wird das in meiner Hochsprache durch ein Schlüsselwort local, das bewirkt, das eine Variable oder ein Parameter auf dem Stack allokiert wird, und nicht in ein Feld geschrieben werden darf.

Wobei mir einfällt, sowas wird glaub ich auch in die Sun JVM Einzug halten. Das magische Stichtwort scheint "Escape Analysis" zu heissen ...

[SSJ7Gohan]

Ja, das ist zwar möglich, aber dazu muss sehr viel Code analysiert werden, und das ist ja bei der Just-In-Time Kompilierung nicht sehr erfreulich.

[Legend]

Deswegen kompiliert Hotspot auch nicht jeden Code direkt mit maximaler Optimierung.

Und ja, man kann das natürlich schneller machen wenn man dem Compiler mehr Informationen zur Verfügung stellt. Aber je mehr man ihm zur Verfügung stellen muss, desto schwieriger wird es wieder für den Programmierer und nun ja, ich finde es etwas dumm dem Programmierer es z.B. dank GC zu erleichtern und "dank" sowas gleichzeitig wieder genausoschwer wie vorher zu machen.

[SSJ7Gohan]

Naja, man kann sich streiten, wie komplex die Sprache sein sollte. IMHO ist es dem Programmierer zumutbar, Variablen, die nur in einer Funktion verwendet werden, als lokal zu deklarieren, wenn ich mir dafür aufwendige Analysen der gesammten Anwendung ersparen kann. Der Programmierer muss ja nicht alle Möglichkeiten nutzen, die er hat, wenn er suboptimalen Code haben will. Der just-in-time Compiler kann ja immernoch optimieren, wenn das erwünscht ist. (Als JIT kommt natürlich ubcc zum Einsatz ) Ausserdem kann der Hochsprachenkompiler bei Anweisungen wie System.out.println("ein" + "string" + "wird" + "aus temporären strings erstellt und ausgegeben"); so viel besser kompilieren.