GradualGames wrote:One thing I'm considering is simply prefixing or suffixing ALL zp symbols throughout my entire game with z_ and detecting this with the string macro technique in
this thread, to determine whether to use z: or a:.
I don't really understand how typing z_ every time you use a variable is going to be more convenient than typing z: every time you use it? (Especially if you're going to encumber it with complicated macros...)
GradualGames wrote:That just feels like overkill though to be honest. I think I can live with imperfect assembly given how little performance or code size improvement I seem to be getting with workarounds in place anyhow.
Well, I'd tend to think of the uses without z: or a: prefix as an "assembler's choice" option, i.e. I don't really
care, and might want to move variables around later anyway. That's generally my default position, because
most ZP use isn't mission critical.
In general, though, I end up looking directly at the generated code often enough when debugging, so I'm usually checking up on the assembler
enough to know where it's succeeding or failing at stuff like this. That's enough to inform me of various do's and don't for keeping the output like I expect it to be.
...and when I'm looking at some really performance critical code, I look at the output closely. Focused attention where it's needed.
I never knew about this nested scopes problem because I've only ever used .scope or .proc but never wanted to put a .proc inside a .scope. TBH I think the benefits of .proc are somewhat marginal anyway, and .scope I mostly used when I was dealing with .include of lots of files into one big assemble, but normally these days I encapsulate things by assembling indvidual files instead.