Viele Sprünge usw - wie handhabt ihr das?

ZeHa · 30. Oktober 2017

Servus,

hin und wieder gibt es ja den Fall, dass man eine Variable auf zig verschiedene Werte pruefen muss, und darauf basierend dann verzweigen muss; z.B. wenn der Nutzer eine Taste drueckt und man diese auswertet. Also sowas hier (nur exemplarisch):

Code

lda key
cmp #'A'
beq .hat_a_gedrueckt
cmp #'B'
beq .hat_b_gedrueckt
cmp #'C'
beq .hat_c_gedrueckt
...

Nun kennt ihr bestimmt alle das Problem, dass die Sprungadressen irgendwann schnell zu weit weg liegen und er nicht mehr direkt hinspringen kann. Also wird es dann schnell sowas:

Code

lda key
cmp #'A'
beq .hat_a_gedrueckt
cmp #'B'
beq .hat_b_gedrueckt
cmp #'C'
beq .hat_c_gedrueckt
...
.hat_a_gedrueckt
jmp hat_a_gedrueckt
.hat_b_gedrueckt
jmp hat_b_gedrueckt
.hat_c_gedrueckt
jmp hat_c_gedrueckt
...

Alles anzeigen

Sprich, man springt eigentlich zweimal, und man schreibt auch noch viel "unnoetigen" Code. Wie sehr wuerde ich mir manchmal wuenschen, es gaebe auch ein BEQ mit einer absoluten Adresse...

Gibt es hierfuer eine elegantere Loesung? Klar, wenn die Werte linear sind (z.B. von 0-20), dann koennte man die Sprungadressen alle in eine Tabelle schreiben und per Index zugreifen. Aber auch das ist nur in manchen Situationen "schoener" als das obige Konstrukt. Und bei Dingen wie Tastencodes, die eben nicht linear sind, waere das schon gar nicht moeglich. Ist das da oben wirklich der einzige sinnvolle Weg?

Endurion · 30. Oktober 2017

Du kannst natürlich neben der Sprungtabelle noch eine zweite Tabelle für die Vergleichswerte halten; dann kannst du eine generische Funktion für das Anspringen verwenden.
Generisch kostet halt auch immer etwas Performance und Speicher. Es ist ein ewiges Abwägen

Squidward · 30. Oktober 2017

Am Ende ist das Branchen zum JMP nicht das Eleganteste, aber doch das Funktionalste...

Lysosom · 30. Oktober 2017

Könnte es so auch gehen?

Code

:start
lda key
cmp A
bne (+3)
jmp (Wohin bei A)
cmp B
bne (+3)
jmp (wohin bei B)
usw...

Alles anzeigen

Soulstealer · 30. Oktober 2017

Wenn die Sprünge so einigermaßen "hintereinander" liegen und man nicht im ROM/Modul ist, benutze ich gerne Selfmod.
Das hat den Vorteil, dass man bei der Rasterzeit immer gleich bleiben kann. Unbenutzte Bereiche fülle ich mit dem .Nothing auf.
Worst-Case wären natürlich 2x256 Werte für die Tables. Hier habe ich die aber z.B. mit dem LSR schon verkleinert.

Brainfuck-Quellcode

lda key
lsr ; only real keys from a-xxx are necesseray,
lsr ; so we can keep the table smaller
lsr
lsr
lsr
tax
lda .hi_key_press,x
sta .dynamic_cmp_ld+1 ; patch the jump with table value
lda .lo_key_press,x
sta .dynamic_cmp_ld+2 ; patch the jump with table value
.dynamic_jmp_key_press
jmp $0000 ; this table is patched relative to the key pressed
.hi_key_press
!byte <(.nothing), <(.key_press_a), <(.key_press_b), <(.key_press_c), <(.nothing) ...
.lo_key_press
!byte >(.nothing), >(.key_press_a), >(.key_press_b), >(.key_press_c), >(.nothing) ...
.nothing
rts
.key_press_a
...

Alles anzeigen

kbr · 30. Oktober 2017

Ich mach mir für sowas gern eine kombinierte Tabelle mit Vergleichswert und Sprungziel, und mach dann einen indirekten JMP:

Code

key='B'
ldx #0
loop:
lda tab,x
cmp #key
beq go
inx
inx
inx
bmi loop
rts
go: lda tab+1,x
sta $fa
lda tab+2,x
sta $fb
jmp ($fa)
tab:
.byte 'A': .word key_A
.byte 'B': .word key_B
.byte 'C': .word key_C
key_A:
key_B:
key_C:
lda #<text
ldy #>text
jsr $ab1e
rts
text: .byte "HELLO WORLD"
.byte 13,0

Alles anzeigen

Mac Bacon · 30. Oktober 2017

Die Einzelabfragen würde ich nur bei zwei oder drei verschiedenen Tasten nehmen, sonst immer Tabellen:

Code

menu jsr get_key
ldx #keys_end - keys_start - 1 ; max offset
loop cmp keys_start, x
beq found
dex
bpl loop
jsr beep ; invalid key
jmp menu
found lda action_lo, x
sta ptr
lda action_hi, x
sta ptr + 1
jmp (ptr)
keys_start !pet "mkdb"
keys_end
action_lo !by <maim, <kill, <destroy, <burn
action_hi !by >maim, >kill, >destroy, >burn

Alles anzeigen

Diese "saubere" Variante liefe auch aus dem ROM, in der Praxis nehme ich statt dem indirekten Jump eine Selbstmodifikation.

Hucky · 30. Oktober 2017

Hab ich früher auch immer so gemacht.
BEQ auf JMP
Hab über 10 Jahre nix mehr gecodet

Squidward · 30. Oktober 2017

@Macbacon: Letzten Absatz des Ausgangspost gelesen?

Soulstealer · 30. Oktober 2017

@Squidward
Ja, er hat ja mit seiner "mkdb" Tabelle schon eine sehr universelle Lösung aufgezeigt.

kbr · 30. Oktober 2017

Man kann den indirekten JMP auch noch etwas anders lösen:

Code

go: lda tab+2,x
pha
lda tab+1,x
pha
rts
tab:
.byte 'A': .word key_A-1
.byte 'B': .word key_B-1
.byte 'C': .word key_C-1

Alles anzeigen

Muß dann aber darauf achten, die Sprungtabelle mit jeweils -1 abzulegen!

Mike · 30. Oktober 2017

Zitat von Lysosom

Könnte es so auch gehen?

In einem konkreten Fall mit ca. 2 Dutzend wild gewürfelten Tastenabfragen war ich mir auch nicht zu schade, die "THEN"-Fälle praktisch zu in-linen. Solange die Fall-Routinen klein genug sind und immer sauber aus dem "switch" herausspringen geht das so:

Code

.switch
CMP #A:BNE switch_00
<Hier code für A>
RTS
.switch_00
CMP #B:BNE switch_01
<Hier code für B>
RTS
.switch_01
[...]

Der switch wird mit JSR aus der Hauptschleife angesprungen. Das kostet also 5 Bytes pro Fall (CMP/BNE/RTS) - selbst bei einer Tabelle mit Sprungzielen und Suchroutine braucht's für jeden Fall 4 Bytes (Suchbyte/Adresse/RTS) ... hängt also vom Einzelfall ab, was kompakter ist.

markusC64 · 30. Oktober 2017

Ich nehme ACME, da kann ich per Makro schreiben:

+beq ganz_weit

und der Assembler ersetzt das Makro dann durch ein

bne +
jmp ganz_weit
+

Ja, zugegebenerweise nichts neues, aber dennoch lesbarer.

detlef · 30. Oktober 2017

Zitat von Soulstealer

Wenn die Sprünge so einigermaßen "hintereinander" liegen und man nicht im ROM/Modul ist, benutze ich gerne Selfmod.

Selbstmodifizierender Code? Das tut man nicht - das ist ganz ganz B Ö S E.
Außer man will den Code bewusst verschleiern (z.B. bei Kopierschutzfunktionen).

Mike · 30. Oktober 2017

Zitat von detlef

Selbstmodifizierender Code? Das tut man nicht - das ist ganz ganz B Ö S E.
Außer man will den Code bewusst verschleiern (z.B. bei Kopierschutzfunktionen).

Meine schnellste Linienziehroutine (>30000 Punkte/Sekunde) wäre ohne selbstmodifizierenden Code sechsmal so groß (ca. 5 KB statt 800 Byte).

Hoogo · 30. Oktober 2017

Mal aus anderer Richtung betrachtet:

Kommt es nur hier und da mal im Programm mit ein paar Werten vor, oder wird es ein großes Projekt mit vielen Dutzend Menüpunkten und Untermenüs, wo sich auch schnell mal ein bisschen mehr Code lohnt?
Dann kann es sich wegen der Übersichtlichkeit und auch wegen des Platzes lohnen, das alles von einem Unterprogramm erledigen zu lassen und alle Parameter direkt hinter dem Aufruf abzulegen. Mit ein bisschen Stack-Manipulation kann man dann auch wieder hinter dieses Daten zurückspringen.

Aus einem alten Quelltext (keine Ahnung mehr, warum ich die Parameter ausgerechnet so angelegt habe):

Code

+flaemenu
jsr window
.stext "dbkel`b bloecke_k kreise_e ellipsen_f fuellen_`@"
jsr eingabe
.t "bkef":.b 0
.w zbloc,zfkre,zfeli,zfill
beq w2
jmp flaemenu
!window pla
sta $fa
pla
sta $fb
jsr window_zeichnen
lda $fa
bne dec2
dec $fb
-dec2 dec $fa
lda $fb
pha
lda $fa
pha
rts

Alles anzeigen

ZeHa · 31. Oktober 2017

Vielen Dank, sind auf jeden Fall ein paar interessante Ansaetze dabei, die man je nach Situation nutzen kann.

@detlef, selbstmodifizierenden Code verwende ich eigentlich staendig. In der Regel fuer Schleifenzaehler oder fuer Adressen die hochgezaehlt werden. Ist in vielen Faellen einfach die simpelste Variante, und boese finde ich das auch nicht. Es wird ja auch nicht wirklich "der Code" komplett veraendert, sondern lediglich ein Parameter eines Befehls, das ist jetzt nicht unbedingt Hexerei.

kbr · 31. Oktober 2017

Zitat von ZeHa

@detlef, selbstmodifizierenden Code verwende ich eigentlich staendig. In der Regel fuer Schleifenzaehler oder fuer Adressen die hochgezaehlt werden. Ist in vielen Faellen einfach die simpelste Variante, und boese finde ich das auch nicht. Es wird ja auch nicht wirklich "der Code" komplett veraendert, sondern lediglich ein Parameter eines Befehls, das ist jetzt nicht unbedingt Hexerei.

bin ich auch kein Freund von, vorallem weil das moderne Systeme schon gar nicht mehr zulassen, und auch bei einigen Architekturen, wie z. B. AVR geht sowas nicht, daher sollte man sich das jetzt auch gar nicht mehr angewöhnen, finde ich.

Aber wie immer, jeder wir er meint

ZeHa · 31. Oktober 2017

Das hat ja nix mit "Angewöhnen" zu tun. Auf einem System wie dem C64 ist das nunmal eine der simpelsten Methoden, etwas zu erreichen, was man ansonsten nur weitaus umständlicher zustande bekommt. Das hat nix mit anderen Systemen oder Prozessoren zu tun. Deinen Satz "aber jeder wie er meint" müsste eher lauten "auf jedem System das entsprechende Vorgehen/Werkzeug".

kbr · 31. Oktober 2017

Anderes Beispiel: Du hast solchen Code geschrieben, und irgendwann später möchtest du den selben Code für ein anderes Projekt in einem EPROM verwenden. Jetzt musst du alles entsprechend anpassen.

Vielleicht ist jetzt verständlich, worauf ich hinaus möchte.