Gibt es einen Programmablaufplan von dem BASIC-Interpreter?

  • 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?
    Ein Rechner ohne Windows ist wie Erdbeerkuchen ohne Senf.
  • Im vorzüglichem Buch C64 für Insider gibt es sehr viele Flussdiagramme. Aber auf Dauer wirst du ohne Assemblerkenntnisse wohl nicht weiterkommen.
    Bilder
    • Clipboard01.png

      232,82 kB, 755×750, 54 mal angesehen
    • Clipboard02.png

      254,84 kB, 867×749, 17 mal angesehen
    • Clipboard03.png

      258,84 kB, 883×692, 16 mal angesehen
  • 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.

    ajunra schrieb:

    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).

    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".

    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!
    Ein Rechner ohne Windows ist wie Erdbeerkuchen ohne Senf.
  • 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
    Yes, I'm the guy responsible for the ACME cross assembler
  • ajunra schrieb:

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


    Mike schrieb:

    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.