Also beim Z80/U880 gibt es nur den Befehl CALL nn, wobei nn eine 16Bit-Binärzahl ist. Ansonsten gibt es noch die bedingten CALL-Befehle, also Flag abhängig (Z, C usw). Was meinst Du mit 'Stack und Register ohne RAM-Zellen'? Stack liegt im RAM. Ansonsten mußt Du den JP-Befehl in seinen verschiedenen 'Unterarten' nutzen. -- viele Grüße Holger
ich weis das es den Befehl nicht im Befehlssatz gibt daher habe ich auch nach einer Ersatzlösung gesucht.
Ein bißchen Schlaf hat mir die Erlösung gebracht Es ist sooo simpel wenn man aus geschlafen ist.
Quellcode:
; die Zieladresse wird vom Aufrufenden Programm in HL übergeben. CALL M1 .... Und weiter im Programm
; Irgendwo im Code. M1: PUSH HL RET
Der RET macht einen vermeintlichen "Rücksprung" nach HL und landet im Programm an der Stelle die in HL steht. Wird das Programm über RET verlassen kehrt es an die Position hinter "CALL M1" zurück.
Danke. -- 42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest" Aktuelle Projektdokumentationen
; die Zieladresse wird vom Aufrufenden Programm in HL übergeben. CALL M1 .... Und weiter im Programm
; Irgendwo im Code. M1: PUSH HL RET
Und warum nicht gleich PUSH HL anstatt Call M1? Aus dem Stück ist nicht zu ersehen, warum du ein Unterprogramm aufrufst um HL zu PUSHen. Wenn dort gestanden hätte z.B. Call NZ xxxx dann könnte man das noch verstehen, aber so? -- Beste Grüße Andreas ______________________________________ DL9UNF ex Y22MF es Y35ZF JO42VP - DOK: Y43 - LDK: CE
*** wer glaubt, hört auf zu denken ***Dieser Beitrag wurde am 21.02.2017 um 09:52 Uhr von Wusel_1 editiert.
Das ist eher ziemlich dirty, von Erlösung weit entfernt. Der Stack ist nach dem "PUSH HL" korrumpiert. Du mußt ihn also korrigieren oder bekommst Probleme, wenn du Subroutinen schachtelst. Was ist eigentlich der Sinn des Ganzen?
das der Stack auch auf RAM läuft ist schon richtig es ging um extra Speicherzellen im RAM. Der Stack ist in dem Fall nicht von Bedeutung.
@KK "Der Stack ist nach dem "PUSH HL" korrumpiert." Nein er wird durch das folgende RET Korrigiert. Der RET ist wie ein "JP (SP)" oder mit dem PUSH HL zusammen zu JMP HL. Den CALL M1 brauche ich um eine Rücksprung Adresse auf dem SP zu haben. damit wird alles zusammen zu CALL HL.
Quellcode:
; die Zieladresse wird vom Aufrufenden Programm in HL übergeben. .... das Hauptprogramm LD HL, @SUBR1 ; Hier können verschiedene Adressen stehen. CALL M1 ; "CALL HL" was es nicht gibt nachbau .... Und weiter im Programm
; Irgendwo im Code. M1: PUSH HL ; Nachbildung des Befehls "JP HL" den es auch nicht gibt RET
SUBR1: NOP ; Irgendwas RET
SUBR2: NOP ; Irgendwas RET
SUBR3: NOP ; Irgendwas RET ... usw.
-- 42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest" Aktuelle ProjektdokumentationenDieser Beitrag wurde am 21.02.2017 um 11:30 Uhr von PIC18F2550 editiert.
hallo Pic, wenn nicht eine Subroutine aber unmittelbar bei ".... Und weiter im Programm" liegt, oder du durch vorhergehende Sprung-Befehle dorthin springst, kommst du ansonsten dort nie hin. oder? Und falls es noch weiter vorn in deinem Hauptprogramm ein noch nicht gepopptes Push gibt, dann ist der Stack eventuell doch korumpiert.
..."weiter vorn" ist unbedeutend für die Funktion "CALL HL" genauso wie ein echtes CALL nn.
Der Call Befehl erzeugt die Rücksprung Adresse automatisch auf dem Stack. Die M1: Routine ist nur für den Sprung nach HL.
Damit komme ich hin und zurück. -- 42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest" Aktuelle ProjektdokumentationenDieser Beitrag wurde am 21.02.2017 um 12:10 Uhr von PIC18F2550 editiert.
@KK: >Der Stack ist nach dem "PUSH HL" korrumpiert
Entschuldige Karsten, das ist "Lötzinn".
Wie kaputt und korrupt ist denn der Stack wenn ich wie bei C üblich Funktionsparameter über den Stack übergebe? Logischerweise muß man aufpassen was man da macht, aber "korrupt" ist was völlig anderes, das passiert z.B. wenn man seine Variablen da nicht mehr runter holt und dann "ins Feld" springt...
Vielleicht sehe ich den Wald vor lauter Bäume nicht, aber:
Wenn ich mit "CALL M1" in das Unterprogramm verzweige, wird die momentane Adresse automatisch auf den Stack gesichert. Im Unterprogramm M1 werden dann noch 2 Byte von HL draufgepackt. Beim anschließenden RET werden diese 2 Byte dann als Rücksprungadresse wieder vom Stack geholt, was der Sinn der Aktion ist. Allerdings befindet sich die 2 Byte der originalen Rücksprungadresse des "CALL M1" immer noch auf dem Stack. Die lösen sich ja nicht einfach auf, oder?
Also SP+4-4 = SP -- 42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest" Aktuelle ProjektdokumentationenDieser Beitrag wurde am 22.02.2017 um 10:16 Uhr von PIC18F2550 editiert.
ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
