Local variables - performance vs comfort
Moderator: Moderators
Re: Local variables - performance vs comfort
Maybe use a macro to trace overlay usage and issue a warning on collision?
Re: Local variables - performance vs comfort
Simplest stupidest option is give every function a non-overlapping static allocation. Don't worry about the logistics of overlays—after all, that's where you're getting tripped up.
Re: Local variables - performance vs comfort
You could simulate some near-arbitrary stack access.
Code: Select all
; Declare locals
.rsset 0
varFoo .rs 1
varBar .rs 1
; Init locals in reverse order
LDA #$00
PHA ; init varBar
PHA ; init varFoo
; Macro to access a given variable
.macro getVar i
TSX
.repeat i
INX
.endrepeat
LDA $0100, X
.endmacro
getVar varFoo
getVar varBar
http://zutanogames.com/ <-- my dev blog
Re: Local variables - performance vs comfort
You don't need to constantly be pulling stuff off the stack and putting it back on. Nor are you limited to just the byte(s) at the top of the stack. I address this in section 14 of my 6502 stacks treatise, "Local variables & environments." The following section, section 15, is on recursion. Note that these build on material laid in earlier sections.2. Slow and more comfortable - Use hardware stack, which is so-so for A register, but quite slow for anything else as it would require lda mem, pha, pla, sta mem for every variable
http://WilsonMinesCo.com/ lots of 6502 resources
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Local variables - performance vs comfort
65816 and a SNES has you coveredyaros wrote:It is not really important is it assembler of C, because cc65 does not encourage using local stack variables anyway. I don't say I really like x86, but arbitrary stack access in 6502 would be nice... Or at least fast stack.
I though CC65 used it own stack for such things, making it even slower though?
But when one uses C on a 65(X)XX one expects it to be slow and poor. There is no free lunch, you either accept C is poor for the job, or not use it. However being in C and having a DEBUG build you can make asserts to check that things don't get trashed..
make a debug local variable
Code: Select all
#if _DEBUG
byte testTmp1 = tmp1;
#endif
foo2();
#if _DEBUG
ASSERT(testTmp1 == tmp1, "Tmp1 trashed assign new temp");
#endif
I kind of do this in ASM only I use a testing application to do the testing for me, rather than in my running code.
Re: Local variables - performance vs comfort
I'll always go for the "fast and dangerous" option. Although it would be nice if there was some compiler support to make it easier.
So far what I've done is to manage everything manually and set up some Lua scripts (= no overhead) to check at runtime for violations (same variable used from more than one place). In other words, I allocate/free each local variable in procedures (Lua code keeps track which memory is used), and during allocation generate an error if an overlapping allocation of the same memory happens. Example: https://github.com/fo-fo/ngin/blob/mast ... yer.s#L242
So far what I've done is to manage everything manually and set up some Lua scripts (= no overhead) to check at runtime for violations (same variable used from more than one place). In other words, I allocate/free each local variable in procedures (Lua code keeps track which memory is used), and during allocation generate an error if an overlapping allocation of the same memory happens. Example: https://github.com/fo-fo/ngin/blob/mast ... yer.s#L242
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: Local variables - performance vs comfort
I think C can be quite fast if you know how to "tame" it. You have to avoid some structure, parameters to function, uses a lot of global and know when to use asm for some tight spots.
For non intensive code like intro, title etc, I even have C call back in NMI with no issue at all so it all depends on you (ab)use it
For non intensive code like intro, title etc, I even have C call back in NMI with no issue at all so it all depends on you (ab)use it
Re: Local variables - performance vs comfort
On my last project, I did pretty well with 3 zero page globals mostly used for loops/indexing (idx, ix, iy). I rarely called functions from a loop, so it wasn't much of a problem. Most of the remaining variables were static local, and stack local were really only used in cold code like init functions and such. Yet another reason why I recommend auditing the generated assembly often. It's definitely possible to get halfway decent assembly out of cc65 if you are careful.