Thema: Meine Programmiersprache - Haze

[Cjreek]

Hi,

Also ich habe ja versprochen ein paar Infos über meine werdende Programmiersprache zu posten. Hier sind sie!

Die Syntax von "Haze" ähnelt der von Pascal SEHR, was ihr auch gleich sehen werdet. Der Grund dafür ist einfach, dass ich mit dieser Art von Syntax "aufgewachsen" bin und damit am besten zurecht komme.
Einige Syntaxelemente sind allerdings an die Syntax von C angelehnt. Z.B. die Art wie Arrays deklariert werden oder die Darstellung von Hex-Zahlen.

Hier ein kleines (mehr oder weniger sinnvolles) Codebeispiel. Dieser Code ist zurzeit alles andere als compilierbar. Der Code soll nur einen Eindruck vermitteln, wie es später mal ungefähr aussehen wird.
Große Teile der Syntax die zu sehen ist, habe ich bereits per EBNF festgehalten. Einige Dinge muss ich noch ergänzen.

Der Beispiel-Code: http://pastebin.com/1bWXx1Zm

Die bisherige (unfertige!) EBNF:
(Meine EBNF-Syntax weicht minimal von der offiziellen ab, aber ich denke man kann es trotzdem lesen)


Die EBNF ist sicher auch in ihrer bisherigen Form alles andere als minimal oder perfekt. Aber ich arbeite daran

Den Compiler inkl. Scanner und Parser schreibe ich komplett selbst in Delphi. Der Scanner ist soweit fertig. Mit dem Parser fange ich an, sobald die EBNF reif genug ist. Der Compiler wird Assemblercode (NASM) erzeugen und dann NASM die Umwandlung in Machinencode überlassen.

Meine Sprache wird (wie schon anhand der EBNF zu erahnen) ein ähnliches Unit-System unterstützen wie Pascal und Delphi es tun.

Mehr fällt mir jetzt auf Anhieb nicht ein. Wenn ihr irgendwelche Fragen habt, dann stellt sie ruhig und ich versuche eine Antwort darauf zu geben 

[AGGROStar1991]

wie siehts mit inlineassembler aus?
isses ne strukturierte oder ne prozeduale sprache?

[Cjreek]

wie siehts mit inlineassembler aus?
isses ne strukturierte oder ne prozeduale sprache?

Schonmal den Beispielcode angeschaut?

http://pastebin.com/1bWXx1Zm

Es ist eine prozedurale Sprache

[AGGROStar1991]

ah k^^
wie siehts mit AT&T syntax für den Inline ASM aus?
sieht aber schon seehr schick aus respekt

[Cjreek]

wie siehts mit AT&T syntax für den Inline ASM aus?

Nunja der Compiler wird an dem inline ASM Code nicht viel ändern. er wird nur (lokale) Variablen und Parameter ersetzen.

Z.B.

Code: [Auswählen]

mov si, Str
in

Code: [Auswählen]

mov si, [ebp+0x04]
oder so.

Sagen wir es so. Zur Zeit ist die Unterstützung von AT&T Syntax nicht geplant aber ich denke es wäre evtl nicht so schwer AT&T nachträglich dann zu unterstützen. Mal schauen 

sieht aber schon seehr schick aus respekt

Danke 

[erik.vikinger]

Hallo,

Der Beispiel-Code: http://pastebin.com/1bWXx1Zm

Sieht recht interessant aus, erinnert mich ein bisschen an VHDL, wahrscheinlich weil VHDL auch viele Syntax-Anleihen von Pascal hat.

Was ich schon immer vermisst hab ist eine saubere Unterstützung für mehrere Rückgabewerte, planst Du sowas?
Bei dem Inline-Assembler würde ich mir die gcc-Syntax mit (Assembler-Code : Eingabe : Ausgabe : Änderungen) wünschen. Das finde ich persönlich recht gut.

Wie gut kann/soll den Dein Compiler optimieren?
Das ist keine leichte Aufgabe, ich würde mich da nicht ran wagen.
Ich schreibe zur Zeit einen Assembler + Linker für meine CPU-Architektur, das ist für meinen Geschmack schwer genug.


Grüße
Erik

[Cjreek]

Was ich schon immer vermisst hab ist eine saubere Unterstützung für mehrere Rückgabewerte, planst Du sowas?

Geplant war es bisher nicht, aber es wäre mal eine Überlegung wert. 

Bei dem Inline-Assembler würde ich mir die gcc-Syntax mit (Assembler-Code : Eingabe : Ausgabe : Änderungen) wünschen. Das finde ich persönlich recht gut.

Ich kenne die gcc Syntax leider nicht. Kannst du mal ein Beispiel posten?

Wie gut kann/soll den Dein Compiler optimieren?

Ich denke es wird nicht besonders viel Optimierung geben. Zum einen, weil ich befürchte, dass ich dafür nicht das erforderliche Wissen/Können besitze und zum anderen weil die Sprache eigentlich nie dafür gedacht war besonders optimierten Code zu erzeugen, sondern in erster Linie einfach nur funktionierenden Code. Die ein oder anderen geringfügigen Optimierungen wird es schon geben, aber in der Richtung ist vorerst nicht so viel zu erwarten.

[kevin]

Ich kenne die gcc Syntax leider nicht. Kannst du mal ein Beispiel posten?

http://lowlevel.brainsware.org/wiki/index.php/Inline-Assembler_mit_GCC

[erik.vikinger]

Hallo,

Ich kenne die gcc Syntax leider nicht. Kannst du mal ein Beispiel posten?

Gerne: http://lowlevel.brainsware.org/wiki/index.php/Inline-Assembler_mit_GCC#Ein-_und_Ausgabeparameter

Ich denke es wird nicht besonders viel Optimierung geben.

Das ist sehr bedauerlich, das wird den erzeugten Code nicht nur langsam sondern auch groß machen. Ein paar Optimierungen, um z.B. die Register einigermaßen effizient zu nutzen, sind IMHO schon im Pflichtteil enthalten.

Zum einen, weil ich befürchte, dass ich dafür nicht das erforderliche Wissen/Können besitze

Um z.B. das Speichern und anschließende Laden des selben Wertes zu vermeiden sollte es IMHO schon reichen wenn man es schafft einen Compiler zu bauen.

und zum anderen weil die Sprache eigentlich nie dafür gedacht war besonders optimierten Code zu erzeugen

Ich wusste gar nicht das man eine Programmiersprache dafür extra designen müsste.

sondern in erster Linie einfach nur funktionierenden Code.

Ist das nicht das Ziel jeder Programmiersprache?


Grüße
Erik

[Cjreek]

Ja wie gesagt, so ein paar kleinere Optimierungen werden schon drin sein^^
Aber erwartet keinen hochoptimierten Code von meinem Compiler^^

Das funktionierender Code Ziel jedes Compilers ist, ist klar 
Damit wollte ich nur sagen, dass ich nicht vorhatte so viel Energie in die Optimierung zu stecken 

[bluecode]

Es könnte sinnvoll sein nur ein Frontend für deine Sprache zu schreiben und LLVM den Rest übernehmen zu lassen. LLVM soll besser optimieren können als der gcc. Außerdem soll er gut designt und dokumentiert sein.

[Cool-Andy]

Mal ne andere Frage: Hat der Name "haze" was zu bedeuten, oder wie bist du auf den Namen gekommen?

[Cjreek]

Es könnte sinnvoll sein nur ein Frontend für deine Sprache zu schreiben und LLVM den Rest übernehmen zu lassen. LLVM soll besser optimieren können als der gcc. Außerdem soll er gut designt und dokumentiert sein.

Mh müsste ich mir mal anschauen. Mal gucken. Wobei ich es denke ich mal zumindest testweise auch gerne mal selbst probieren würde.

Mal ne andere Frage: Hat der Name "haze" was zu bedeuten, oder wie bist du auf den Namen gekommen?

Eine direkte Bedeutung hat der Name nicht (bis auf die deutsche Übersetzung). Soll maximal soetwas wie eine Andeutung auf den Umfang der Sprache sein. 

[Cool-Andy]

http://translate.google.de/?js=y&prev=_t&hl=de&ie=UTF-8&layout=1&eotf=1&text=&file=&sl=de&tl=en#en|de|haze
LOL. 

[Cjreek]

Jo 

[erik.vikinger]

Hallo,

.... dass ich nicht vorhatte so viel Energie in die Optimierung zu stecken

Wenigstens in die Nähe von -O1 solltest Du schon kommen, es leidet wie gesagt nicht nur die Performance sondern es werden auch die Programme sehr groß. Um die wenigen Register von x86 effizient zu nutzen brauchst Du eine Art Datenfluss-Analyse und wenn die eh da ist kannst Du schon einiges Optimieren. Das ist natürlich nicht mal so nebenbei zu erledigen, für sowas könnten eventuell mehrere Mann-Jahre einzuplanen sein.

Schau Dir mal http://llvm.org/docs/LangRef.html an, wenn Du das als Deine Ausgabe (anstatt Assembler) schaffst kannst Du Dich ins gemachte LLVM-Nest setzen. Auf der Seite sind auch ne Reihe guter Konzepte beschrieben. Ob er wirklich besser optimiert als der gcc kann ich nicht beurteilen aber er hat ne Menge Tricks auf Lager und ne Menge Potential, langfristig ist er eine ernsthafte Konkurrenz zum gcc. Er hat auch eine deutlich schlankere und modernere Code-Basis.

Einen Assembler-Output für x86 stelle ich mir recht schwierig vor, der x86-Befehlssatz ist einfach ziemlich Scheiße (nicht nur weil er >30 Jahre gewachsen ist sondern wegen der blöden Operanden-Architektur) und sehr umfangreich (so gut 200 bis 300 Befehle solltest Du schon drauf haben um einen modernen x86-Prozessor einigermaßen auszureizen).


Für meine CPU möchte ich auch auf den LLVM setzen und ein Back-End coden das Assembler-Text für meine CPU ausgibt, das soll gar nicht so sehr schwierig sein (angeblich deutlich unter 6 Mann-Monate), es soll auch gute generische Libs geben um guten ASM-Code für moderne RISC-Architekturen zu erzeugen.


Grüße
Erik

[chris12]

respekt o.o
ich hab momentan nur nen compiler (scanner + parser) von pascal nach c# übersetzt und den modifieziert. und der erzeigt auch ziemlich brauchbaren nasm code ^^
wen's interessiert hier ein code, der ,hoffentlich irgendwann, "AF11" ausgiebt http://pastebin.com/YmPxkkxU . leider sind die funktionen write(); und read(); noch fest implementiert, aber das soll sich auch noch ändern. die sprache ist, wie man denke ich mal, sieht von C & Co bzw pascal beeinflusst, da der Compiler, der in pascal verfasst wurde, aus einem tut stammt und das tut gute gründe für einige elemente geliefert hat.
btw wie machst du das mit localen variablen? ich setze einfach nur den namen der subrotiene davor, also

Code: [Auswählen]

...
procedure main();
var a;
{
... wird

Code: [Auswählen]

...MAIN_A: DW 0
PROC_MAIN:
...aber das ist nicht die lösung ... denke ich

[kevin]

Lokale Variablen müssen auf den Stack, sonst klappt das mit der Rekursion nicht (letztendlich wären alle Variablen static, um es in C auszudrücken). In der Assemblerausgabe tauchen die also gar nicht mehr so direkt auf, sondern nur noch als [ebp - 4] oder sowas (oder auch relativ zu esp, wenn du keinen Framepointer benutzt).

[chris12]

aha, also genauso wie mit der parameter übergabe, wenn ich das recht verstehe

[erik.vikinger]

Hallo,

aha, also genauso wie mit der parameter übergabe, wenn ich das recht verstehe

Nein, Du musst einen Stack-Frame einrichten.
Das heißt das Dein Compiler selbstständig bei jeder Funktionen passenden Entry-Code (welcher Register sichert und den Stack-Frame aufbaut) und Exit-Code (welcher den Stack-Frame wegräumt und die Register wiederherstellt) dazu bauen muss.


Grüße
Erik