Local variables - performance vs comfort

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Local variables - performance vs comfort

Post by lidnariq »

Maybe use a macro to trace overlay usage and issue a warning on collision?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Local variables - performance vs comfort

Post by lidnariq »

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.
User avatar
Zutano
Posts: 38
Joined: Tue Apr 04, 2017 1:22 pm
Location: Ohio, USA
Contact:

Re: Local variables - performance vs comfort

Post by Zutano »

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
Garth
Posts: 246
Joined: Wed Nov 30, 2016 4:45 pm
Location: Southern California
Contact:

Re: Local variables - performance vs comfort

Post by Garth »

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
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.
http://WilsonMinesCo.com/ lots of 6502 resources
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Local variables - performance vs comfort

Post by Oziphantom »

yaros 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.
65816 and a SNES has you covered ;)

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
So when you run a debug build you test to make sure weird stuff doesn't happen, and then in say a Development and Release build you don't test to get your speed and RAM back. You might need to have custom flags per "file" or section, to keep the RAM overhead under controls. Or say have the Debug build have 8K RAM expansion ( like a 'dev kit' ) that you can allocate all the extra debug variables into etc.

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.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Local variables - performance vs comfort

Post by thefox »

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
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Local variables - performance vs comfort

Post by Banshaku »

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 :lol:
User avatar
slembcke
Posts: 172
Joined: Fri Nov 24, 2017 2:40 pm
Location: Minnesota

Re: Local variables - performance vs comfort

Post by slembcke »

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.
Post Reply