Hallo Besucher, der Thread wurde 3,7k mal aufgerufen und enthält 8 Antworten

letzter Beitrag von ayvazhzf am

Gibt es einen Programmablaufplan von dem BASIC-Interpreter?

    Hallo ihr Experten!
    Kennt eigentlich irgend jemand einen Programmablaufplan vom Basic-Interpreter?
    Mir geht es jetzt nicht um jeden einzelnen Befehl (daher ist es egal ob es vom C64 oder von einem anderen Homecomputer stammt), sondern vielmehr darum, wie der Interpreter überhaupt arbeitet.
    Also wie er erkennt daß eine Zeile ein direkter Befehl ist oder eben zu einem Programm gehört; wie er Befehle speichert (doch nicht im Volltext, oder?), wie er Befehle erkennt (z.b. Schleife laufen um den Befehl Buchstabe für Buchstabe zu lesen und zu vergleichen; also: wie vergleicht er...) u.s.w. . Aber ein Parser ist ja nicht alles.


    Nicht daß mich die direkte Befehlsverarbeitung nicht interessiert, aber das würde wohl selbst bei unserem - ich nenne es mal: "recht sparsamen" - Dialekt den Rahmen sprengen. Ein Beispiel an zwei/drei Befehlen wäre natürlich interessant. Aber eben der Parser ist - so denke ich mal - doch eben auch sehr wichtig.


    Mich interessiert halt wie so ein Interpreter - und auch ein Compiler - überhaupt, und doch im genauen, arbeitet. Das Prinzip an sich ist mir klar - bei der Ursuppe braucht es nicht anzufangen. Aber wenn man z.b. so einen Interpreter in anderen Hochsprachen nachbauen würde wollen, wäre ein PAP (Programmablaufplan) doch recht hilfreich.


    Ein Verweis auf den ROM-Quelltext bringt mir leider gar nichts; Assembler ist für mich ein Böhmisches Dorf.
    Gibt es Literatur die sich mit diesem Thema beschäftigt?

    Erstmal ganz allgemein:


    Mich wundert schon, daß sich damals jemand tatsächlich die Mühe gemacht hat, den Code im BASIC-Interpreter in einen PAP zurückzuübersetzen.


    Programmablaufpläne sind hoffnungslos veraltet, beim Entwurf sie sind nicht in irgendeiner Weise geeignet Struktur in das Programm hineinzubringen, da der Ablauf beliebig in Spaghetti-Form entarten kann. Gleiches gilt für eine eventuelle Programmanalyse. Wenn überhaupt, dann sind Struktogramme das Mittel der Wahl.


    Beide Darstellungen haben ihre Grenzen beim Unterprogrammaufruf, sind also nur für einzelne Routinen geeignet. Als nächste Stufe gehört also immer noch ein Aufrufbaum dazu.


    Zitat von ajunra

    Also wie er erkennt daß eine Zeile ein direkter Befehl ist oder eben zu einem Programm gehört.

    Das hängt davon ab, ob am Anfang des Eingabepuffers eine Zeilennummer steht (-> Programm) oder nicht (-> Anweisung).


    Zitat

    wie er Befehle speichert (doch nicht im Volltext, oder?)

    Ein Interpreter könnte durchaus Befehle im Klartext speichern - da kannst Du vorweg keine Annahme zu machen. CBM BASIC V2 verkürzt aber bei der Ablage im Programmspeicher alle erkannten Befehle und Funktionen tatsächlich zu einem 1 Byte großen "Token".


    Zitat

    wie er Befehle erkennt (z.b. Schleife laufen um den Befehl Buchstabe für Buchstabe zu lesen und zu vergleichen; also: wie vergleicht er...)

    Bei der Übernahme aus der Eingabezeile wird von links nach rechts eine darin verschachtelte Schleife benutzt, die ab einer bestimmten Stelle jeweils immer mit allen Schlüsselwörtern vergleicht. Wird eines erkannt, so wird es durch das Token ersetzt, der Rest der Zeile direkt hinter das Token gezogen und ab da weiter geparst.


    Umgekehrt wird beim LISTen jedes Token wieder zum Originaltext expandiert.


    ...


    Und wie ogd bereits schrub: ohne Assemblerkenntnisse wirst Du ansonsten aus dem BASIC-ROM nicht schlau. Und wieder allgemein: im Rahmen eines Informatik-Studiums darf man sich durchaus auch mit so Sachen wie Compilerbau, endliche Automaten, etc ... herumschlagen. ;)

    Uhhh - mal schnell reingeschaut: Kapitel 4 ab Seite 403... Danke ogd!
    Na ja, ggf. bringen die kommentierten ROM-Listings am Anfang des Buches etwas Verständnis bezüglich Assembler.
    Mike: PAP sind total veraltet? Mann oh Mann; da sieht man mal wieder wie alt man ist.


    Jetzt las ich, daß auch Struktogramme kaum mehr benutzt werden - stattdessen nimmt man wohl Aktivitätsdiagramme in der UML (unified modelling language).
    Na ja, öfter mal was neues...


    Danke nochmal @ogd ! Das Buch liegt ja auch in der Wolke! Super!

    Ich finde, PAPs sind vor allem dann praktisch, wenn man einem Anfaenger das Programmieren beibringen moechte, so als Verstaendnishilfe. Ansonsten kenne ich keinen einzigen Programmierer, der sowas zeichnen wuerde.

    Programmablaufpläne sind eigentlich schon überholt, seit das "strukturierte Programmieren" aufkam. Für Struktogramme gilt das Gleiche, denn wozu ein Struktogramm erstellen, wenn der (Pseudo-)Code ebenso lesbar ist? (also lesbar für Leute, die eh programmieren können. Für Anfänger siehe was ZeHa schrub)


    Als Beispiel empfehle ich die Seiten 125 und 126 des deutschen 1571-Handbuchs, wo die Benutzung der Burstbefehle kurz und verständlich in Pseudocode erläutert wird. Ein PAP an dieser Stelle wäre eine Katastrophe und ein Struktogramm einfach nur vergeudete Zeit.


    EDIT: UML ist Kasperkram, ich bin zu alt für den Scheiß. :D

    Zitat von ajunra

    Mich interessiert halt wie so ein Interpreter - und auch ein Compiler - überhaupt, und doch im genauen, arbeitet.


    Zitat von Mike

    im Rahmen eines Informatik-Studiums darf man sich durchaus auch mit so Sachen wie Compilerbau, endliche Automaten, etc ... herumschlagen. ;)


    Einen Tipp hätte ich noch. Falls man eine praktische Einführung in Compilerbau (ohne theoretischen Ballast) sucht, ist Let's Build a Compiler von Jack Crenshaw immer noch ungeschlagen.