Hallo Besucher, der Thread wurde 3,1k mal aufgerufen und enthält 29 Antworten

letzter Beitrag von mc71 am

anfänger: lda ($0300,$0301),x oder wie?!

    Zitat von Hexworx

    Was soll das denn sein/werden?

    Zerbrich dir da nicht den Kopf. e2020 hat in seiner Abbildungsvorschrift von Algorithmus -> 65xx-Code immer noch einen anderen Prozessor als Zwischenschritt drin. :D Den zu eliminieren ist wohl nicht so einfach.


    Ging mir selber damals™ so, als ich meine ersten Programme auf dem ARM-Prozessor geschrieben hab ... die erste Zeit sah der Code eher so aus wie frisch vom 6502 übersetzt. :whistling: ... bis ich irgendwann mal dahinter gekommen bin, daß man noch ganz anders auf der neuen CPU programmieren kann. Das hatte dann echt etwas von "Handbremse lösen". 8o


    Witzigerweise programmier' ich heute umgekehrt so auf der 65er-Familie, als würde ein ARM-Prozessor im Hintergrund Modell stehen. Das muß also nicht unbedingt nachteilig sein. :)

    Zitat von Hexworx

    Was soll das denn sein/werden?

    mit der doppelläufigen Flinte von hinten durch die Brust ins Auge... er stapelt ja auch 16-Bit-Pointer in direkt aufeinanderfolgenden Adressen des 8-Bit-Speichers, setzt wahllos Immediate-Hashsigns '#' und Kommentar-Semikolons... :appel:wurm::nixwiss::nixwiss::nixwiss:


    EDIT: Sowas "16-Bit-Wert in direkt aufeinanderfolgenden 8-Bit-Adressen" gibts selbst in der irren Welt der IBM-PCs nur ein einziges Mal, nämlich beim Datenregister der AT-Festplatte.

    ich mache jedesmal die gleichen anfangsfehler und ich weiss jetzt auch warum...


    der code funktioniert einwandfrei, nur mit falschen daten - wegen falscher zeiger - und das passiert mir jedesmal deshalb hier



    aber okay, läuft jetzt alles einwandfrei...



    edit:
    @ mike
    ja, genau, gut erkannt! das kommt noch zusätzlich dazu...


    @ mc71
    anfänger dürfen *alles*' fragen, oder?
    anfänger dürfen fehler machen, oder?
    auch in den kommentaren?
    es ging mir um die kombination von 2 16bit werten, nur wusste ich nicht genau wonach ich fragen sollte - deshalb (auch) das falsche beispiel - ist das ok mit dir? - wie fragt man nach etwas was man nicht kennt?


    ach und:
    @ hexworx
    gute frage! wäre sonst nicht so schnell drauf gekommen...

    Wie auch Mike schon geschrieben hat, ist das eher die falsche Herangehensweise, sich gewisse "ideale" Adressierungsarten herbei zu sehnen. Klar, das ist die Vorgabe, die man lösen möchte und muss das auf das Programmierparadigma der entsprechenden CPU umlegen. Meine Beispiele zum 65816 zeigen, dass man sich auch mit anderen Möglichkeiten hier an die Rahmenbedingungen der CPU anpassen muss. Das Programmiermodell ist etwas, was nicht so ohne weiteres auf einen überspringt ... da braucht es etliches an Übung (mit Standardfällen und -Problemen), damit man dann diese "Standardphrasen" (sie bei einer Fremdsprache) intus hat. In der ersten Phase wird man relativ geradlinig ein Problem lösen. In der nächsten Stufe kann man das vorgegebene Problem dann schon so umformen, dass es der CPU besser angepasst ist und dessen Eigenschaften besser, vielleicht sogar optimal ausnutzen kann.


    Selfmodifying Code würde ich vermeiden, wenn es die Geschwindigkeit nicht wirklich erfordert. Mike hat das vorbildlich gezeigt, wie das geht. Beim 6502 muss man sich von Vorstellung verabschieden, dass irgendeine 16-Bit-Aktion auf "einen Schlag" erledigen lassen. Es ist alles irgendwie "abteilig" zu machen ... ;)

    ja, danke, schon verstanden, aber wie gesagt:


    "ich kam darauf, weil ich in turbo macro pro ohne probleme schreiben & compilieren kann:
    * sta $0400 + 1000, y"
    ^^^
    wenn man diese stelle (in der die 1000 steht) wie eine variable behandeln könnte hätte man 1 adressierungsart mehr, oder nicht? deshalb fragte ich ob selfmodifing code dort (wo die 1000 steht) eingreifen könnte...


    aber egal, das war auch nur so eine idee...

    Zitat von e2020

    "ich kam darauf, weil ich in turbo macro pro ohne probleme schreiben & compilieren kann:
    * sta $0400 + 1000, y"
    ^^^
    wenn man diese stelle (in der die 1000 steht) wie eine variable behandeln könnte hätte man 1 adressierungsart mehr, oder nicht? deshalb fragte ich ob selfmodifing code dort (wo die 1000 steht) eingreifen könnte...

    Der Witz ist halt, dass es eine solche "Stelle, wo die 1000 steht" gar nicht gibt: Wenn im Sourcecode "$0400 + 1000" steht, rechnet bereits der Assembler das zusammen und im Maschinencode steht dann nur noch das Resultat der Addition.

    MacBacon hat es ja schon erläutert, warum das mit 1000 usw. nicht geht.


    Self-modifying Code, um gewissermaßen neue "Möglichkeiten" oder auch Adressierungsspielarten zu erhalten, ist nicht unüblich. Findet man z.B. in CHRGET des BASIC-Interpreters, u.a. um eine Adressierung LDA (ZP) zu erhalten (also ohne das Y-Register auf 0 setzen zu müssen). Dabei liegt die Routine direkt in der Zeropage. Ebenso bei gewissen Forth-Implementierungen, die den Inner-Interpreter "NEXT" in der ZP ablegen, um so etwas wie JMP (++(ZP)) zu machen ...

    Ein kurzer Blick ins Datenblatt erleichtert die Auswahl der Adressierungsart. Sollte man bei jedem neuen Prozessor-Befehlsssatz machen, denn manche ändern die Flags bei einfachen Daten-Kopier-Befehlen, andere zerstören den Akku bei einem Sprungbefehl (die Architektur ist verständlicherweise längst ausgestorben) und noch wieder andere haben theoretisch 768 verschiedene Arithmetik-Befehle, von denen jedes Programm aber nur maximal 16 verwenden kann...)