Beiträge von Mike im Thema „Basic Code in eine PRG-File schreiben“

    kiri008,

    ja und dann gilt immer noch das, was ich in meinem Beitrag Bitte melde dich an, um diesen Link zu sehen. geschrieben habe: vorbehaltlich dessen, daß zufällig noch wer anders mit einer für dich maßgefertigten Lösung in C# daherkommt, wird dir nichts anderes übrig bleiben als eine bereits bestehende Lösung (von Endurion z.B.) nach C# umzusetzen oder dich selbst mit der Originalroutine im ROM vertraut zu machen und dann selbst davon eine C#-Version zu implementieren.

    Viele Grüße,

    Michael

    Dass man den Begriff "Fehler" nicht in einem Satz zusammen mit "Comm[o]dore" verwenden darf, ohne dass das gleich fundamentalistische Grundsatzdiskussionen auslöst, war mir nicht klar.

    Nochmal: das einzige, was ich gemacht habe war, genauer nachzufragen was Du mit "Fehlern" meinst.

    Wir haben offensichtlich unterschiedliche Vorstellungen, ob das beobachtete Verhalten ein Fehler ist oder nicht. Ein eindeutiger Fehler liegt meiner Ansicht nach vor, wenn die Spezifikation nicht eingehalten wird.

    Jetzt kann und darf man durchaus die Frage stellen ob die Spezifikation das hergibt, bzw. ob überhaupt was existiert, was sich Spezifikation nennen darf. Die Frage kann ich dir jetzt nicht beantworten, die Beschränkung auf maximal zwei signifikante Zeichen in Variablennamen ist aber ein starker Hinweis für mich, daß der Tokenizer genau so implementiert wurde wie vorgesehen.

    Davon ab gibt es richtige, *dicke* Fehler im BASIC-Interpreter zuhauf. Der mögliche Stacktrash bei gemischten String- und Zahlausdrücken, der mögliche Stringstapelüberlauf bei IF, die kaputte Multiplikation und RND()-Funktion seien nur mal so als Beispiel genannt. Das heißt, ich bin der letzte, der es nötig hat "zur Verteidigung" eine Grundsatzdiskussion vom Zaun zu brechen.

    goloMAK,

    dieser "Knoten" läßt sich allerdings auflösen, wenn man auf die (einfache) Editierbarkeit im C64 verzichtet und den Hauptaugenmerk auf die Ausführbarkeit legt.

    Dann hätten wir einen Präprozessor für BASIC-Quelltext und von dem könnte man durchaus auch mehr verlangen, eben z.B., daß längere Variablennamen erlaubt sind. Diese längeren Namen könnte der Präprozessor dann auf 1- oder 2-buchstabige Variablennamen abbilden. Leerzeichen im Quelltext wären außerhalb von Anführungszeichen egal, da man sie problemlos beim Tokenisieren wegstrippen kann (bei der Ausführung werden sie übersprungen) und damit bleibt der Speicherverbrauch auch unten.

    Das oben beschriebene geht übrigens mit Einschränkungen auch schon "ab Werk" - schreibst Du statt "...:FORT=STOP:..." die FOR-Anweisung wie folgt: "...:FORT=S{SHIFT-Z}TO{SHIFT-Z}P:..." erhältst Du nach dem LISTen tatsächlich wieder "...:FORT=STOP:...", was aber tatsächlich als "S TO P" tokenisiert ist! Die geshifteten Zeichen werden als ungültige Abkürzung erkannt und dann vom Tokenizer eliminiert. Heißt, im tokenisierten Programmtext tauchen die geshifteten Zeichen nicht auf.

    Welchen geshifteten Buchstaben man da hernimmt ist erstmal egal, Hauptsache er bildet mit dem vorherigen Teil nicht zufällig doch ein Schlüsselwort. "Z" kommt aber in keinem V2 Schlüsselwort vor und ist darum für diesen Zweck ideal geeignet.

    Diese Technik macht dann auch Variablennamen wie "IF", "TO", "ON" oder "OR" zugänglich, indem man das {SHIFT-Z} zwischen dem ersten und zweiten Buchstaben hinschreibt.

    Viele Grüße,

    Michael

    P.S. ich nehme mal an der OP sucht einfach nach bereits vorhandenem Quelltext für einen Tokenizer in C#. Nicht mehr und nicht weniger. Daß das Original im ROM nicht so ganz die einfache Nummer zum rausrippen und portieren ist, hat Endurion ja schon geschrieben.

    Bevor Mike den Inhalt meines Beitrags verdreht hat.

    Verdreht habe ich deine Aussage in Bitte melde dich an, um diesen Link zu sehen. mal überhaupt nicht, sondern lediglich genauer nachgefragt.

    Dann mit so rhetorischen Figuren wie:

    Selbstverständlich ist Commodore-Basic 100% fehlerfrei!

    anzukommen bringt uns hier auch nicht weiter.

    Hast Du derweil eine Antwort auf meine Fragen am Ende von Bitte melde dich an, um diesen Link zu sehen. parat?

    Sorry, dass ich das in Zweifel gezogen hatte.

    Kein Grund sich zu entschuldigen.

    Selbstverständlich ist Commodore-Basic 100% fehlerfrei!

    Habe ich das hier behauptet? Ich habe dir lediglich eine Frage gestellt und bin dir sogar soweit entgegengekommen, daß ich die wahrscheinlich von dir gemeinte Eigenheit der "Spezifikation" vorweg benannt habe.

    Das Ding im ROM ist nun mal ein "greedy" Parser, es werden keine Delimiter zur Begrenzung der Schlüsselworte links und rechts gefordert, von Variablennamen sind nur die ersten zwei Zeichen signifikant, was vom Gebrauch längerer Namen eher abrät wodurch auch die Wahrscheinlichkeit heruntergebracht wird, daß sich da irgendwo ein Schlüsselwort drin versteckt.

    Du kannst die Routine ja gerne verbessern. Kriegst Du sie dann immer noch in die 8K des BASIC-ROMs rein? Bist Du sicher, daß die Erzwingung von Delimitern (im häufigsten Fall nutzlose, Speicher kostende Leerzeichen) der heißeste Wunsch von BASIC-Programmierern auf dem C64 ist?

    Besonderheiten und Fehler

    Besonderheiten, klar. Die Routine im ROM ist die Referenz. Aber auf welche Fehler sprichst Du an? Ich kann mir höchstens Fälle vorstellen, wo der Tokenizer ein auf den ersten Blick unerwartetes, letztendes aber doch stimmiges Ergebnis liefert, z.B. hier: "...:FORT=STOP:...", wo eben nicht "S TO P" sondern das Schlüsselwort "STOP" tokenisiert wird.

    kiri008,

    in einem anderen Thread hast Du ja auch nachgefragt, wie man eine *.prg-Datei mit einem Zeichensatz erstellt.

    Genauso wie so eine Zeichensatzdatei hat auch ein *.prg mit einem BASIC-Programm drin die ersten zwei Bytes mit der Ladeadresse. Damit enden aber schon alle Gemeinsamkeiten. Während der Zeichensatz aus 256 Zeichen a 8 Bytes aufgebaut ist, hast Du bei einem BASIC-Programm eine komplizierte Datenstruktur mit einer verketteten Liste aus (Programm-)Zeilen, die dann auch noch tokenisiert sind. Die Routine dazu ist im BASIC-Interpreter drin, es haben aber schon einige Leutz das für's Cross-Entwickeln erfolgreich portiert, z.B. in das bereits erwähnte petcat.

    Welche Programmiersprache Du außerhalb des zu emulierenden Rechners für die Unterstützung deiner Cross-Entwicklung hernimmt, ist mal so herzlich egal. Jeder hat da so seine bevorzugten Werkzeuge.

    Wenn Du unbedingt einen Tokenizer in C# selbst schreiben willst, nur zu: schreib ein paar BASIC-Programme im Emu, speichere sie ab, und analysiere deren Inhalt mit einem Hex-Editor. Detailkenntnisse von 65xx-Code sind allerdings schon hilfreich, wenn Du zum Gegenchecken den Tokenizer im ROM als Referenz und zum analysieren hernimmst.

    Viele Grüße,

    Michael