Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins Willkommen Gast! RSS

Robotrontechnik-Forum » Technische Diskussionen » relativer Unterprogrammaufruf (KC85) » Themenansicht

Autor Thread - Seiten: -1-
000
19.12.2020, 08:15 Uhr
Bert



Hi!

Ich habe hier ein Stück Maschinencode disassembliert.
Dabei wird ein relativer Unterprogrammaufruf gemacht (CAOS-Funktion, 0F00Fh):

Quellcode:

UPREL:    equ 0xf00f
IRMON:    equ 0xf018
IRMOFF:   equ 0xf01b
.
.
.
call IRMON    ; cd 18 f0
ld hl,00000h  ; 21 00 00
call UPREL    ; cd 0f f0
defw 00024h   ; 24 00
call IRMOFF   ; cd 1b f0
ret           ; c9



Wenn ich das richtig verstanden habe, wird von CAOS mit der Routine auf 0F00Fh der Befehl RCALL (relativer CALL) emuliert, der beim Z80 fehlt (im Gegensatz zum relativen Sprung).

Mir ist anhand der Beschreibung im Handbuch nicht klar, an welcher Stelle ich nun das Unterprogramm finde. Kann mir da jemand auf die Sprünge helfen?
Am Besten mit einem kleinen Codebeispiel.

Viele Grüße,
Bert

Dieser Beitrag wurde am 19.12.2020 um 08:16 Uhr von Bert editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
19.12.2020, 10:58 Uhr
susowa



Ungefähr so (Auszug aus der CAOS-Version von PICGEN):


Quellcode:

;
    ORG    0

;Aufruf aus anderen Programmen
;z.B. BASIC:
;
    CALL    IRMON
    PUSH    AF
    CALL    UREL
    DW    START-2-$
    CALL    IRMOF
    POP    AF
    RET
;-------
    DW    7F7FH
    DB    'PICGEN',1
START:    LD    A,(7FFFH)



Das Programm wird auf Adresse 0 assembliert und MUSS mit Offset geladen werden, sonst stürzt CAOS ab, weil Systemzellen überschrieben werden.

CALL UREL ruft jetzt u.a. START relativ auf, weil zur Assemblierzeit der Adressabstand zur Aufrufadresse bekannt ist aber die absolute Adresse nicht, welche erst durch den Offset beim Laden des Programmes in den RAM festgelegt wird.

MfG
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
22.12.2020, 21:06 Uhr
Bert



Hauptsächlich war ich verwirrt, weil der ganze restliche Code nicht verschieblich ist, sondern nur diese eine Programmstelle.

Danke für die Erklärung,
Bert
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
08.01.2021, 00:12 Uhr
Crawler

Avatar von Crawler

Hallo Bert,

der von dir vorgestellte Code ist aus meiner Sicht komplett verschiebbar. Die dort enthaltenen absoluten Calls rufen externen Code auf, dessen Einsprung-Adressen durch das Betriebssystem fest definiert sind. Der relative Call ruft eine programminterne Unterroutine auf, die (zusammen mit dem kompletten Programm) verschiebbar ist.

Gruß,
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
08.01.2021, 01:36 Uhr
susowa




Zitat:
Crawler schrieb
der von dir vorgestellte Code ist aus meiner Sicht komplett verschiebbar.


Das war laut 000 nur "ein Stück Maschinencode".


Zitat:

Der relative Call ruft eine programminterne Unterroutine auf, die (zusammen mit dem kompletten Programm) verschiebbar ist.


Er wollte genau dazu ein Beispiel - was sagt jetzt 003 dazu ???

Der entscheidende Vorteil des CAOS-PV auf 0F00FH liegt m.M. nach darin, dass er die relative Abstandsbeschränkung von JR ... mit 127 Byte aufhebt und auch für verschiebliche MC-Programme eine Strukturierung statt Spaghetti-Code mit JR's oder Codereduzierung mit Unterprogrammen ermöglicht.
Wie Bert schon schrieb, kann das der Befehlsatz der CPU nicht aber mit dem CAOS-PV geht das dann doch elegant :-) .

MFG susowa
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
08.01.2021, 23:02 Uhr
Crawler

Avatar von Crawler

Hallo susowa, mein Beitrag bezog sich lediglich auf 002. Ich hatte in keiner Weise versucht, deine Antwort zu korrigieren oder zu ergänzen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
09.01.2021, 10:58 Uhr
susowa



Hallo Crawler, ich kann mit Deiner Antwort im Kontext der Frage nichts anfangen ?



Zitat:
Crawler schrieb
der von dir vorgestellte Code ist aus meiner Sicht komplett verschiebbar ...



Er hat den Code doch gar nicht vollständig vorgestellt, sondern nur einen Auszug - ich kann auch in 002 nichts derartiges erkennen ?


Zitat:
Crawler schrieb
Ich hatte in keiner Weise versucht...



Das kannst Du aber gern, vielleicht habe ich ja die Tomaten auf den Augen :-) !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
10.01.2021, 02:22 Uhr
Crawler

Avatar von Crawler

Mit

Zitat:
der von dir vorgestellte Code ist aus meiner Sicht komplett verschiebbar ...


hatte ich genau und nur den Code gemeint, der ursprünglich von Bert in 000 gepostet wurde. Nicht mehr und nicht weniger. Über etwas anderes kann ich hier ja auch keine Aussage machen. Wenn sich Bert in 002 ausschließlich auf den nicht einsehbaren Code bezogen hat, dann habe ich das einfach falsch verstanden.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
10.01.2021, 12:57 Uhr
Bert



Na, nun lasst gut sein :-)
Es gibt Spannenderes. Der Aufwand für verschieblichen Code ist m.E. relativ hoch, vor allem wenn noch Variablen im RAM gebraucht werden.

Viele Grüße,
Bert
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
009
10.01.2021, 21:46 Uhr
susowa




Zitat:
Bert schrieb
Na, nun lasst gut sein :-)



Ich hoffe, dass Crawler mir jetzt nicht böse ist aber es waren immer gesetzt !!


Zitat:

Es gibt Spannenderes.



Dem muss ich aber jetzt widersprechen. Ich finde verschieblicher Code kann sehr spannend sein, z.B. bei der fast unausweichlichen Fehlersuche beim Austesten.
Ich habe da auch eine ganze Weile gebraucht, um das damals bei den ersten Versuchen überhaupt zu verstehen - das war auch spannend
"Relative" RAM-Variablen lassen sich u.U. über die Return-Adresse auf dem Stack nach Aufruf von UREL im Programm verwalten. Habe ich bis jetzt noch nicht benötigt.
Einfacher ist es den IRM von BA00H bis BFFFH zu verwenden oder den Kassettenpuffer, wenn es denn sonst nichts Anderes stört.

MfG susowa
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
010
12.01.2021, 01:10 Uhr
Crawler

Avatar von Crawler


Zitat:
... aber es waren immer gesetzt !!



Dein Glück!
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
Seiten: -1-     [ Technische Diskussionen ]  



Robotrontechnik-Forum

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek