This extends beyond Famicom/NES programming but that's certainly the context I'm dealing with it in these days.
In the course of disassembling various titles, I've often found some variables in the memory map of titles may pull double, triple, or more duty depending on how isolated their usage is. This is most common with non-specific "work ram" variables that are used for instance as subroutine arguments, temporary "registers", that sort of thing. Where I've been uncertain over the years is whether these are best represented in code as a single constant (or label) that resolves to the address of the bit of memory and then further constants that all resolve to that single definition, or if instead it'd be better to define each and every use as the numerical value of the thing. An example:
Say we have this little hunk of memory in the zero page. One piece of code uses work_0, work_1, and work_2, as char, char, and void * subroutine arguments, but then another uses them as local "register" variables. If labeling specific to the contexts is desired, would folks be more inclined towards:
or
I've been torn on this for a while because on one hand, if you use the absolute address for every unique use of a working variable, then they don't necessarily need to "live together", they just happen to. On the other hand, if you do keep them grouped, then this ensures if you move something that is going to respect the analysis you've previously done on where all you can use, say, work_0, without those uses interfering with one another.
One nice thing about the latter is you can setup these kinds of remaps local to subroutines (i.e. in the same assembly unit) while keeping your memory map itself clean, one label per defined memory object. However, the downside then becomes looking at your memory file itself, it's not clear there in isolation how many reuses each field has.
What do folks think? How do you all handle this sort of thing?
Also any cool schemes anyone has come up with to effectively track concurrent use of the same memory addresses in different contexts? Basically engineering against overwriting of a general working variable from place to place? I've been thinking of maybe a prefix or suffix of "t" to mirror the RISC-V ABI register names, which are "s" prefixed if they're expected to be saved and restored across subroutine calls or "t" if they're expected to be undefined upon return from a subroutine call. Then the rule can be if you see "t_" or "_t" on a name, don't expect that variable to have any meaning if there's any flow redirection between the last access and the current line.
Curious to see other folks' practices regarding memory coherence!
In the course of disassembling various titles, I've often found some variables in the memory map of titles may pull double, triple, or more duty depending on how isolated their usage is. This is most common with non-specific "work ram" variables that are used for instance as subroutine arguments, temporary "registers", that sort of thing. Where I've been uncertain over the years is whether these are best represented in code as a single constant (or label) that resolves to the address of the bit of memory and then further constants that all resolve to that single definition, or if instead it'd be better to define each and every use as the numerical value of the thing. An example:
Code:
work_0= $00work_1= $01work_2= $02Code:
func_arg_0 = $00func_arg_1 = $01func_arg_2 = $02Code:
func_arg_0 = work_0func_arg_1 = work_1func_arg_2 = work_2One nice thing about the latter is you can setup these kinds of remaps local to subroutines (i.e. in the same assembly unit) while keeping your memory map itself clean, one label per defined memory object. However, the downside then becomes looking at your memory file itself, it's not clear there in isolation how many reuses each field has.
What do folks think? How do you all handle this sort of thing?
Also any cool schemes anyone has come up with to effectively track concurrent use of the same memory addresses in different contexts? Basically engineering against overwriting of a general working variable from place to place? I've been thinking of maybe a prefix or suffix of "t" to mirror the RISC-V ABI register names, which are "s" prefixed if they're expected to be saved and restored across subroutine calls or "t" if they're expected to be undefined upon return from a subroutine call. Then the rule can be if you see "t_" or "_t" on a name, don't expect that variable to have any meaning if there's any flow redirection between the last access and the current line.
Curious to see other folks' practices regarding memory coherence!
Statistics: Posted by segaloco — Mon Jul 08, 2024 9:21 am — Replies 1 — Views 105