Beiträge von M. J. im Thema „Indirekte Adressierung“

    Ich programmiere schon seit 40 Jahren Microcontroller und es gab noch nie eine Notwendigkeit für selbstmodifizierenden Code.

    Mikrocontroller mit Code im Rom kann man nicht vergleichen mit Spieleprogrammierung für den C64 oder AppleII oder... Das sind zwei verschiedene Paar Schuhe.

    Da tun sich dann die Disassembler ziemlich schwer mit.

    Ja und? Man schreibt den Code doch nicht, damit ihn andere mit Disassemblieren angucken.

    wer weiss ob du nicht auch mal was auf eine Cartridge packen willst

    Heutzutage läßt man die Programme aber nicht direkt vom Cartridge laufen, sondern ein Entpacker entpackt das Programm ins Ram. Das Cartridge dient lediglich als Datenträger wie auch Diskette oder Tape. Für den extrem seltenen Fall, daß man wirklich Routinen braucht, die vom Rom aus laufen sollen, kann man das Programm daran anpassen. Aber bei diesen Sonderfällen weiß man auch schon vorher, was man tut. Die Wahrscheinlichkeit, daß ein Programm, welches fürs Ram konzipiert wurde, irgendwann mal in einem Rom laufen soll (Welches überhaupt? Kernal-Rom?) ist nahezu Null.

    Es gibt definitiv keine Notwendigkeit für selbstmodifizierenden Code.

    Mit solch fundamentalistischen Aussagen wäre ich sehr vorsichtig.
    Folgendes reale Beispiel:
    Auf dem AppleII soll die Soundausgabe per Menü gewechselt werden von Speaker (Adresse $c030) auf Kassettenausgang (Adresse $c020) wie z. B. im Spiel "Summer Games". Die genannten Adressen (auch bekannt als "Softswitches") werden in einer Schleife mittels BIT angesprochen, um dadurch die Membran zum Schwingen zu bringen bzw. den Ausgangspegel umzuschalten.
    Üblicherweise wird ein Wechsel nun so gehandhabt, daß im Programm bei allen BIT $c030-Befehlen die Low-Adresse von $30 auf $20 gepatcht werden. Würde man die extrem zeitkritischen Soundroutinen nun so schreiben wollen, daß man mittels indirekter Adressierung auf sie zugreift, benötigt man pro Zugriff 2 Zyklen mehr für den Befehl "STA (zp), y". ("LDA (zp),y" würde nicht gehen, da hierdurch der Akkumulator überschrieben wird.) Hinzukommt, daß das Y-Register verschwendet wird, das man aber als Zähler dringend benötigt. Folglich muß man den Zähler auslagern in eine Zeropage-Adresse und dort dekrementieren, was dann wieder 3 Taktzyklen mehr fordert. Damit dann mehrstimmige Musik hinzubekommen wird schwierig. Noch schlimmer wird es, wenn die Knacks-Aufrufe von $c030 in Malroutinen eingebaut werden, damit die Malschleife gleichzeitig als Frequenz-Verzögerungsschleife verwendet werden kann (z. B. Boulderdash), um dadurch wichtige Zeit zu sparen. Kein Programmierer hat den Fehler gemacht und ideologisch verkündet: "Das muß man jetzt aber unbedingt mittels indirekter Adressierung machen, weil Selbstmodifikation Teufelszeug ist."
    Merke: Selbstmodifikation ist nur dort wirklich schlecht, wo der Prozessor über einen eigenen Instruktionscache verfügt und nicht mitbekommt, daß sich der Code ändert bzw. die Anpassung an die Codeänderung mehr Zeit verschluckt als gewonnen wird. Der 6502 verfügt aber auch nach Jahrzehnten immer noch über keinen Cache. Daher war Selbstmodifikation in der Programmentwicklung auf dem 6502 schon immer fester Bestandteil, um Programme schnell und in einigen Fällen auch übersichtlicher zu gestalten, und so wird es auch weiterhin sein. Daran wird auch Deine Aussage nichts ändern.