| |
Mace
Registered: May 2002
Posts: 1799 |
Detect origin of JSR in subroutine?
Is it possible to detect where a JSR came from when you're in a subroutine?
I mean...
BLAH: jsr SUB // make border white
FOO: jsr SUB // make border black
rts
SUB: {some code}// (detect where this came from)
cmp BLAH // or something of this sort
beq SKIP
lda #$00
sta $d020
rts
lda #$01
sta $d020
rts
|
|
... 6 posts hidden. Click here to view all posts....
|
| |
Mace
Registered: May 2002
Posts: 1799 |
@ Copyfault: Of course, my example was only that, an example.
The program I'm working on has more complex subroutines, but some are very similar, apart from a few lines.
I was thinking of putting something inside the routine to switch between the particular bits, depending on the origin of the JSR.
Or rather... it was a thought experiment. :-) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
then put the different lines into another subroutine, and keep what's the same in one ?
|
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
@Mace: if the differing lines are occuring as a connected sequence in the subrout, you could place a jump-command there and tweak the jump-adress before calling the subrout.
This way only the differing parts of the subrout must be placed somewhere in memory.
However, Oswald's suggestion to have as many subrouts as needed will ofcourse be optimal when it comes to timing - unfortunatly not for mem usage :(
Looking forward to the result of your experiments! |
| |
Mace
Registered: May 2002
Posts: 1799 |
Ah, yeah, self modifying code is a cool idea too.
However, you will not see the result, as I'm working on a program to check lottery tickets at someone's request, not some demo, game or useful tool.
And it's in Dutch... |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Detecting the JSR's origin for some decision-making in the subroutine sounds like a complicated and hard-to-maintain idea.
It's better to have the caller pass all necessary arguments, and then to use macros for calling the subroutine so you can minimize boilerplate code.
If the three registers and the flags aren't enough, consider using the stack for extra arguments, or pass them by putting them behind the JSR and letting the subroutine return to after the extra arguments. This needs checking the call's origin, but only to find the extra arguments, and to manipulate the return address.
Another approach would be to write the extra arguments to some static memory area before calling the routine, but this does not work well with multi-threading (like calling the same routine in the main loop and from an IRQ handler while the main thread is inside the call). This can be solved by passing a pointer to some caller-allocated structure containing all arguments.
If the sub-routine needs to maintain an internal state: What Copyfault said. :) |
| |
Ervin
Registered: May 2008
Posts: 14 |
Quoting Krill
...have the caller pass all necessary arguments...
...using the stack for extra arguments...
...passing a pointer to some caller-allocated structure...
...the sub-routine needs to maintain an internal state...
Er, umm, what about considering the usage of a not-so-high-level language, such as C, which has native support for all these? ;) ;) ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"I'm working on a program to check lottery tickets "
how about basic, if it must run on a c64? |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting Mace...
And it's in Dutch...
Ik denk niet dat "Nederlandstalig" een echt probleem is ;))
But as this is for some lottery thing, it will ofcourse not show up here on CSDB.
Would be nice if let us know how you solved your problem when you're finished.
Good luck!
PS: and what Oswald asked: why not do this with BASIC? |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quoting Oswald"I'm working on a program to check lottery tickets "
how about basic, if it must run on a c64?
Because it has to test 10 files with 50 possible ticket combinations each, against a draw of 7 numbers.
On top of that: I already have the program that does it, it only needs some minor changes because the rules of the lottery changed.
Please let's not go into detail about the how and why of this program. Consider it a fact from where we head off... ;-)
As for the solution of the problem: I kept the various routines as there's no lack of memory but I do want to finish this project and thus don't want to spend much more time on it. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
I used this technique once for a bank switching jump table:
function1: jsr bankswitch
function2: jsr bankswitch
function3: jsr bankswitch
...
bankswitch:
sta save_a
stx save_x
lda #newbank
sta bank_ctl
pla
tax
lda jmptab,x
sta vector
lda jmptab + 1,x
sta vector + 1
save_a = * + 1
lda #$5e
save_x = * + 1
ldx #$5e
vector = * + 1
jmp vector
Can't remember which platform this was though...
|
| Previous - 1 | 2 - Next |
