| |
mhindsbo
Account closed
Registered: Dec 2014
Posts: 50 |
fastest or smallest 'switch' statment
I use the following code a lot to switch between two values and was wondering what others do and if there is a faster, smaller or simply more elegant way someone has come up with.
lda #value1 ; default value: AR = value1
ldy switch ; get value of switch in YR
cpy #case1 ; compare switch
beq @cont
lda #value2 ; if switch != #case1 then AR = value2
@cont ... ; AR = value1/value2 depending on switch
|
|
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
a table, use y as index
ldy switch
lda table,y
table
byte value1, value2, etc |
| |
mhindsbo
Account closed
Registered: Dec 2014
Posts: 50 |
Absolutely ... That is probably the most elegant, especially for multiple values.
But what about the case where you have two switch values that are not sequential. E.g. two different screen address (hi byte), where switch value is not 0,1,2,3,... But e.g. $c0 and $d0.
Any elegant alternatives in that specific case? |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
if all you have is a 8bit index and want to return a 8bit value, a $100 bytes table is always the fastest solution, just place the values where needed, unless you don't have a free page ($100 bytes) in memory for this lookup.
But if you just need to select 2 values, a cmp is enough.. |
| |
Fungus
Registered: Sep 2002
Posts: 617 |
Just 2 values?
mod1
lda value
eor #$xx
sta mod1+1
where xx is the eor to get the other value you want to toggle between. |
| |
soci
Registered: Sep 2003
Posts: 473 |
Fungus: There was at least a '#' missing.
mod1 lda #value1
eor #value1 ^ value2
sta mod1 + 1
But this is not what he wants to do.
For $c0 and $d0 only a shorter table could do it fast.
ldy switch
lda table - $c0,y
table .fill $d0 - $c0, value1
.byte value2
|
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting iAN CooGa table, use y as index
ldy switch
lda table,y
table
byte value1, value2, etc
Sometimes this could be faster:
switch = * + 1
lda table
|
| |
mhindsbo
Account closed
Registered: Dec 2014
Posts: 50 |
Thanks for all the input. good stuff. I dont have $100 to spend on a table unfortunately.
I use it in a number of functions where the switch values are different (but all to switch between two states)... so it would lead to multiple tables.
The 'cmp' is probably the best in this use case, but it just felt so inelegant using it all the time ;-) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
can you cite a real world example where you need to use this ? maybe it can be done algorithmically better. |
| |
mhindsbo
Account closed
Registered: Dec 2014
Posts: 50 |
In my game I have a number of objects (enemies, bullets, ...) and each has a specific identifier (0-255). In many of the object routines I check for a specific object or a specific state and take one of two actions or set one of two parameters.
Hope this helps explain it. Its always a balance of speed and size for a game. Tables can be obvious as can unrolled code or specific code for specific objects ... but with level graphics, music, etc. I find myself often in a compromise between the two.
E.g. the table lookup is faster, but cant do too many $100 tables. Specific code for each object is faster, but similar ends up eating up memory quickly.
Hope that gives some context. I am decently happy with what I mentioned originally in terms of compromise to switch between to values depending on a parameter ... but just thought I would seek some inspiration as well.
Thanks to everyone who chimed in! |
| |
soci
Registered: Sep 2003
Posts: 473 |
Quoting mhindsboThe 'cmp' is probably the best in this use case, but it just felt so inelegant using it all the time ;-)
Well, then use the one below for a change ;)
lda switch ; get value of switch in AR.
eor #case1 ; compare switch.
beq @cont
lda #value2^value1 ; if switch != #case1 then AR = value2
@cont eor #value1 ; default value: AR = value1
; AR = value1/value2 depending on switch
It's not faster or shorter, but it's only using the accumulator and does not destroy the carry. |
... 14 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
