[Projekt] C-P Compiler

[antisteo]

Wie abgesprochen, stelle ich das C-P Compiler-Projekt jetzt hier auf ZFX offiziell vor. Auch alle deutschen News und Quasi-Blog werde ich auf ZFX veröffentlichen.

Die Idee hinterm C-P Compiler ist, ein neues Kapitel der Compiler-Optimierungen zu öffnen. Moderne Software wie Eclipse, Wordpress, Visual Studio&co sind quasi gar keine Sammlung von Klassen mit Methoden und Attributen mehr, sondern eine Sammlung von Hooks, Filter, Plugins und Konfigurationen. Je dynamischer Software wird, desto weniger können statische Compiler optimieren.

Zum Github-Repository: https://github.com/carli2/cpcompiler

Im Zentrum des C-P Compilers steht der sog. CodeTree, ein binärer Baum, der sowohl Daten als auch Code darstellen kann. Beispiel: object(property("x", 100), property("y", 50)) kann sowohl als Objekt-Literal im Code vorkommen, als auch im Objektspeicher z.B. einer Spielfigur. Des weiteren sind alle Datenstrukturen immutabel, wodurch Optimierung und Parallelisierung sehr leicht möglich werden. Ausnahmen von der Immutabilität sind "var"-Knoten. Sie sind bewusste Unterbrechungen der Immutabilität. Ein JavaScript-Objekt besteht z.B. aus einem var(content...), sprich: es ist veränderbar. Der Optimierer wird nun prüfen, ob das Objekt tatsächlich geändert wird und kann somit den Var-Zwischenknoten entfernen.

Ansonsten sollen jede Menge neue Optimierungen gefunden werden:
- Automatisches Einfügen von Result-Caches in Funktionen
- massives Constant Folding (z.B. Verheiraten der IDE mit ihrer Konfigurationsdatei; oder Compiler und std-Lib)
- Optimierung von Marshalling/Unmarshalling-Orgien (net.send(socket, JSON.stringify({x: getX(), y: getY()}) wird zu: net.send('{"x":' + getX() + ',"y":' + getY() + "}")

[Edit:]Yay! Beitrag nø 777

[antisteo]

Erster Blogeintrag:

Heute läuft

Code: Alles auswählen

(function (x) { return x + 1; })(5)

also sprich: Erstellung eines Funktion-Wertes per function-Literal und anschließender Aufruf.

Die Schwierigkeit: Für JavaScript sind Funktions-Parameter nicht einfach nur ein paar Plätze auf dem Stack. Es wird ein Objekt namens "arguments" angelegt, das als sog. "Quasi-Array" (erbt nicht von Array, hat aber Properties von 0, 1, 2, ... nummeriert, sowie length). Außerdem sind die Parameter gleichzeitig Variablen, die man manipulieren kann. Zum einen will man das Verhalten nachbilden, zum anderen will man schnellen Code erhalten. Die Lösung: der Parser muss erst einmal den generischen Code erzeugen: Das Arguments-Array wird angelegt, anschließend werden für jede benannten Parameter eine Variable angelegt und der Wert des Arguments-Array damit gekoppelt.

Der Optimierer hat dann die ehrvolle Aufgabe, je nach Verwendung der Bezeichner (arguments, Namen der Parameter) den CodeTree einzukürzen und die ein- oder andere Anweisung zum Einkapseln oder zum Mutabel-machen wegzuschmeißen.

Interessant wird die Chose dann, wenn gefaltete Argumente deklariert werden. Diese müssen nach EcmaScipt in ein Array gepackt werden. Hier gibt es wieder tausende Randfälle von der Durchreichung des Arrays an eine genau so gefaltete Funktion bis hin zum Entfalten eines Arrays vom Aufrufer.

Ich denke, spätestens hier rentiert sich der CodeTree-Ansatz, denn es wird nicht zuerst das spezifizierte Standard-Verhalten im CodeTree ausgespuckt. Anstatt tausende Randfälle von Hand zu implementieren, schmeißt man einfach die CodeNodes aus dem Tree hinaus. Jeder CodeNode ist quasi ein Overhead-erzeugendes Standard-Verhalten von JS, das man bei Nicht-Bedarf auch entfernen kann.