wielang hat bei euch die entwicklung einer einfachen programmiersprache gedauert?



  • mngbd schrieb:

    Der Lexer ist doch eher langweilig. Mein Vorschlag ist, ihn so simpel wie möglich zu machen, solange er nur richtig funktioniert.

    also ich denke ich hab da ein paar begriffe durcheinander gewürfelt. versuchs mal ohne die buzzwords... also soweit bin ich jetzt:

    1.   eingabe string in token wandeln         -> 90% fertig
    2.   token auf richtige reihenfolge prüfen   -> 30% fertig
    2/3. parse-tree erstellen                    -> 90% fertig
    4.   parse-tree optimieren                   -> 10% fertig
    5.   interpretieren                          -> 10% fertig
    6.   code generator                          -> 0%  fertig
    

    mngbd schrieb:

    In welcher Sprache schreibst du das alles eigentlich?

    hab mal in c angefangen (ja ich weiß dass es für sowas eher ungeeignet ist).



  • BTW: Warum nutzt ihr für solcherlei Arbeit nicht lex und yacc? Gerade den Tokenizer mit all seinen C-Übelkeiten zu schreiben ist in lex ja ein reines Kinderspiel. 😕

    MfG SideWinder



  • SideWinder schrieb:

    BTW: Warum nutzt ihr für solcherlei Arbeit nicht lex und yacc? Gerade den Tokenizer mit all seinen C-Übelkeiten zu schreiben ist in lex ja ein reines Kinderspiel. 😕

    MfG SideWinder

    ja beim 2. mach ichs evtl. mit den tools, wollts aber mal von hand gemacht haben. es geht ja auch darum was zu lernen und nicht es arbeitsmäßig möglichst schnell fertigzustellen.



  • __-- schrieb:

    hab mal in c angefangen (ja ich weiß dass es für sowas eher ungeeignet ist).

    Ich hab Scheme genommen, und mich über 2 Dinge gefreut: den Garbage Collector (ein altes Streitthema), und besonders über die Homoikonität von Lisp, die dafür sorgt, dass mein Syntax-Baum zugleich ein ausführbares Lisp-Programm ist.

    Ich empfehle, wenn es möglich ist, auf Optimierungen zu verzichten, um so schnell als möglich was am Laufen zu haben. Dann kommt der Spass nicht zu kurz.

    Vielleicht solltest du, da es ja nur um Übungen geht, einen Teil oder alles in einer abstrakteren Sprache als C machen. Ich persönlich zähle C nicht wirklich zu den Hochsprachen.

    SideWinder schrieb:

    BTW: Warum nutzt ihr für solcherlei Arbeit nicht lex und yacc? Gerade den Tokenizer mit all seinen C-Übelkeiten zu schreiben ist in lex ja ein reines Kinderspiel. 😕

    Der Lexer war mir bis jetzt einfach nicht wichtig genug. Die Schnittstelle zum Parser hab ich definiert, und dann einfach schnell mal den Lexer zusammengehackt. Wenn alles gut läuft und ich genug Freizeit locker machen kann, werde ich auf Dauer um einen ordentlichen Lexer nicht herum kommen.

    Einen Parser-Generator will ich nicht verwenden, ich mach das alles nur zur Übung.

    Nachtrag:
    Eigentlich hab ich mich über mehr als 2 Dinge gefreut, z.B. auch über die tail call optimization und die lambda's, ohne die ich keinen CPS schreiben kann.

    Korrektur:
    Das lambda an sich ist nicht wichtig, was wichtig ist, sind Closures.



  • Ich habe vor einiger Zeit einmal einen "Assembler-Interpreter"( 🙄 ) gebaut. Er liest aus einer Datei die nötigen Anweisungen, natürlich ohne .data Abschnitte zu beachten.
    Sowohl "Register" als auch einige Befehle wie add, mul etc. sind vorhanden. PUSH und POP sind ebenfalls vorhanden und manipulieren einen std::stack.
    Ich wollte immer eine Art "inline asm" hinzufügen (per Editbox direkt auswerten 🙂 ), habe es jedoch nie gemacht. Ein Spaß war's trotzdem...



  • Vicious Falcon schrieb:

    Ich habe vor einiger Zeit einmal einen "Assembler-Interpreter"( 🙄 ) gebaut.

    Hihi, sag einfach "virtueller Prozessor" oder "Bytecode-Interpreter" dazu, dann klingt es professioneller. Versuch dich mal an einer anderen Sprache, sowas ähnliches wie einen Lexer hast du ja schon.
    🙂



  • mngbd schrieb:

    Ich empfehle, wenn es möglich ist, auf Optimierungen zu verzichten, um so schnell als möglich was am Laufen zu haben. Dann kommt der Spass nicht zu kurz.

    ich wollts mit den optimierungen nicht übertreiben, wichtig wären mir für den anfang sowas wie constant folding und inline funktionen, denk das wird schwer genug 😞



  • __-- schrieb:

    ich wollts mit den optimierungen nicht übertreiben, wichtig wären mir für den anfang sowas wie constant folding und inline funktionen, denk das wird schwer genug 😞

    Constant Folding musste ich nachschlagen, bin kein Informatiker. Vielleicht werd ich irgendwann mal einer. Ich denke, wenn du alles richtig machst, sollten diese Optimierungen prinzipiell recht einfach machbar sein. Damit meine ich nicht, dass es einfach ist, Kandidaten für das Inlining zu erkennen, aber die Umsetzung der beiden am Baum sollte nicht allzu schwierig sein.

    Ob es sich lohnen würde, daraus ein Projekt im Projekte-Forum zu machen? Sicherlich würden dann einige bedenkliche Leute mitreden, aber vielleicht zahlt es sich aus. Wäre eine nette Sache, wenn man das entspannt angeht, und trotzdem genug guten Code zusammenträgt, um was ordentliches zu bauen. Spaghetticode dürfte dann aber nicht dabei sein.
    🙂



  • Bei einem reinen Interpreter würd ich mir solche Optimierungen sparen, was bringt das denn?



  • mngbd schrieb:

    Ob es sich lohnen würde, daraus ein Projekt im Projekte-Forum zu machen? Sicherlich würden dann einige bedenkliche Leute mitreden, aber vielleicht zahlt es sich aus. Wäre eine nette Sache, wenn man das entspannt angeht, und trotzdem genug guten Code zusammenträgt, um was ordentliches zu bauen. Spaghetticode dürfte dann aber nicht dabei sein.
    🙂

    ja, ist ne überlegung wert. denk aber dafür ists noch ein bischen zu früh (müsst erstmal aufräumen und paar spaghettis rausziehen 🤡 (bischen funktionalität bräucht sie auch noch...)).

    Bashar schrieb:

    Bei einem reinen Interpreter würd ich mir solche Optimierungen sparen, was bringt das denn?

    naja also ohne interpreter kann ich ja die optimierungen nicht durchführen, oder? btw. ich find die schon wichtig, sonst lässt sie sich ja gar so schlecht nutzen und eigentlich wollt ich sie dann schon mal gelegentlich produktiv einsetzen 😋



  • Ich hab ehrlich gesagt keine Ahnung, was du mir mitteilen willst.



  • Bashar schrieb:

    Ich hab ehrlich gesagt keine Ahnung, was du mir mitteilen willst.

    int mul(int x,int y){
      return x*y;
    }
    

    muß ich doch interpretieren, wie soll ich sonst rausfinden was "mul(2,4)" rausgibt? wenns fertig ist würd ichs schon mal gern verwenden, das wär dann der teil "spaß" (sonst geht der ja iwie ab) 😃

    @edit: evtl. fehlt auch der teil, dass ich es im anschluß an den interpreter auch mal ganz gern nativ compilieren würde. 😕



  • Ja Spaß hin oder her, aber ich sehe nicht, wieso da jetzt Optimierungen zwingend notwendig sind, um das produktiv einsetzen zu können? Zumal die, wie ich schon sagte, nicht so viel bringen wie bei einem Compiler. Oder anders gesagt: Die beste Optimierung für einen Interpreter ist, daraus einen Compiler zu machen 😉



  • ich würd dem c-compiler ganz gern gutes ausgangsmaterial übergeben, evtl. brauchts ihn ja dann iwann nicht mehr 🤡



  • Vicious Falcon schrieb:

    Ich habe vor einiger Zeit einmal einen "Assembler-Interpreter"( 🙄 ) gebaut. Er liest aus einer Datei die nötigen Anweisungen, natürlich ohne .data Abschnitte zu beachten.
    Sowohl "Register" als auch einige Befehle wie add, mul etc. sind vorhanden. PUSH und POP sind ebenfalls vorhanden...

    Das ist sehr geil; ich erinnere mich, wie ich vor vielen Jahren in den Ferien an einem sehr, sehr langweiligen Tag einen "Assembler-Interpreter" unter DOS mit PowerBasic geschrieben habe. Gewisse Befehle wie Interrupts wurden dabei direkt wieder in Maschinencode umgesetzt. Zeitaufwand für einen dummen, aber hartnäckigen Jungen: 6-8 Stunden.

    Was war das für eine Freude, als spät am Abend die ersten Grafiken gezeichnet werden konnten, nachdem folgende Zeilen "interpretiert" wurden:

    mov al, 13h
    xor ah, ah
    int 10h
    

    Und was hat es mir am Ende gebracht? Sehr viel, denn wie sinnlos die Entwicklung einer eigenen Programmiersprache auch sein mag, sie vermittelt einem das ganze Repertoir an Techniken und Abstraktion, die man als Entwickler auch sonst immer wieder brauchen wird.





  • _-- schrieb:

    ich würd dem c-compiler ganz gern gutes ausgangsmaterial übergeben, evtl. brauchts ihn ja dann iwann nicht mehr 🤡

    Verwendest du C als Zielsprache?



  • mngbd schrieb:

    _-- schrieb:

    ich würd dem c-compiler ganz gern gutes ausgangsmaterial übergeben, evtl. brauchts ihn ja dann iwann nicht mehr 🤡

    Verwendest du C als Zielsprache?

    ja, hatte ich ursprünglich geplant. denk die performance wird dann besser als bei einem der asm erzeugt (da indirekt die ganzen optimierungen des compilers angewendet werden)?



  • __-- schrieb:

    ja, hatte ich ursprünglich geplant. denk die performance wird dann besser als bei einem der asm erzeugt (da indirekt die ganzen optimierungen des compilers angewendet werden)?

    Ja klar, das machen einige, die C als Zielsprache verwenden. Wenn du dich für einen speziellen C-Compiler entscheidest, kannst du den Code so generieren, wie er ihn gerne hat. Wobei ein Könner in der betreffenden Maschinensprache das wahrscheinlich händisch besser machen würde.

    Der andere Vorteil von C als Zielsprache ist die Portabilität, und natürlich die Tatsache, dass man die Maschinensprache nicht beherrschen muss. Für mich wäre das wichtiger als die Performance. volkard hat recht, wenn er sagt, dass man Performance viel eher duch Verzichten als durch Aufpropfen von Features erreicht. Und durch Verzichten erhält man imho auch am ehesten ein einfaches und klares Design.

    Ich kann deine Vorgehensweise nicht beurteilen, aber ich fürchte, dass du Gefahr läufst, dich in Details zu verlieren, bevor die Fundamente fest stehen.
    🙂


Anmelden zum Antworten