JMP from Subroutine (no RTS)

Es gibt 62 Antworten in diesem Thema, welches 8.104 mal aufgerufen wurde. Der letzte Beitrag (20. Juni 2022 um 16:34) ist von Sorbas2020.

  • Krill: der BASIC-Interpreter checkt in Bitte melde dich an, um diesen Link zu sehen. explizit, ob der Stackpointer noch $3E (plus ein paar Extra-Bytes je nach Fall) oder größer ist, und zwar:

    • beim Anlegen einer FOR-Schleife (will 9 Bytes "Luft"),
    • bei der Ausführung von GOSUB (will 3 Bytes Luft) und
    • bei der Auswertung eines (Unter-)Ausdrucks (will 1 Byte Luft).

    Damit hält sich der BASIC-Interpreter effektiv aus dem Bereich $0100..$013D heraus. Der KERNAL nutzt diesen unteren Teil des Stackbereichs, um das Error-Log bei Tape-Betrieb abzulegen und BASIC selbst nutzt dann auch noch $0100 bis $010F bei der FP->ASCII-Umwandlung.

    Knapp unterhalb von $0200 werkelt BASIC auch noch bei der Eingabe einer BASIC-Zeile herum, neben der KERNAL-ISR-Geschichte dürfte das noch ein weiterer Grund sein, warum BASIC beim Warmstart den Stackpointer auf $FB bzw. $FA setzt (und warum da zwei verschiedene Werte verwendet werden geht mir auch nicht ein. Hat da jemand nicht aufgepaßt?)


    sparhawk: Klar kann man im allgemeinen einen konstanten Offset auch in der Basis-Adresse subsumieren. Nur ist in diesem Fall die Semantik des Stacks (Zugriff auf $0100..$01FF) eine andere als die des LDA-Befehls (Zugriff auf $0104..$0203) und damit ist die B-Flag-Abfrage im Original-KERNAL eben Murks.

  • Klar kann man im allgemeinen einen konstanten Offset auch in der Basis-Adresse subsumieren. Nur ist in diesem Fall die Semantik des Stacks (Zugriff auf $0100..$01FF) eine andere als die des LDA-Befehls (Zugriff auf $0104..$0203) und damit ist die B-Flag-Abfrage im Original-KERNAL eben Murks.

    Der Murks ist da, aber halt sehr theoretisch Ich glaub nicht, dass dieser in der Praxis irgendwie relevant ist.

    Mir wäre noch nie aufgefallen, dass ein Programm, Betriebssystem, Programmiersprache (aber ich kenne natürlich nicht alles) hier den "Überlauf" des Stacks als Fehlerhypothese tatsächlich berücksichtigt hätte. Beispielsweise wird diese Art des Zugriffs auf Elemente am Stack bei Forth-Implementierungen intensiv genutzt, wo der Hardware-Stack als Return-Stack genutzt wird. Ein Wrap-around von $00 auf $FF wird wohl schon aus Effizienzgründen nicht weiter in Betracht gezogen. Aber da geht man ja davon aus, dass ein Forth-Programmierer ohnehin immer genötigt wird zu wissen was man tut ...

    Wenn es schon mal soweit kommt, dass der Stackpointer "wrapped", dann ist ja ohnehin - wie man so schön sagt - die Kacke am Dampfen. Dass das B-Flag nicht ordentlich abgefragt wird, dürfte dann eher nebensächlich sein. ;)

  • Danke an alle, für die verschiedenen Hinweise und Blickwinkel.
    Fazit für mich :

    • ich war immer schon ein Liebhaber der 'strukturierten' Programmierung, und das wird am C64 auch so bleiben...
    • man muss in ASM schon recht gut wissen was man tut,..., dann sind unter kontrollierten Bedingungen auch so manche 'Unschönheiten' möglich
    • leider lassen sich ASM Code-Teile aus verschiedenen Quellen nicht immer so problemlos miteinander in neuen Projekten kombinieren wie etwa bei höheren Programmieresprachen