I notice that a lot of the CPU-derailing crashes and freezes I write in 65816 assembly have to do with the m and x flags. Sometimes the assembler thinks these are set differently from how they actually turn out to be at runtime, so it generates the wrong size instructions and the CPU gets de-synched from the code, loading operand bytes and trying to interpret them as opcode/admode bytes. This usually causes showstopping problems, not little annoying bugs. If you suspect a crash/freeze might be because of getting these mx flags and register sizes out of sync, these macros will make ca65 print out what it thinks the register sizes currently are in a given program location. Then you can compare them to what the surrounding assembly source code wants the register sizes to be.


In general it is not possible for an assembler to figure out what the state of the m and x flags will be at runtime because of Rice's theorem - that is the limitation of the .SMART directive. If there are other reasons you dislike the .SMART directive, I'm curious to know why. Also, if anyone has macros like these for other assemblers, feel free to post them here.

with ca65 you can just directly tell the assembler what width the registers have right now using the .A8 .A16 .I8 .I16 directives.
include those inside your register width switching macros and you shouldn't have this issue anymore. much better than relying on the .SMART directive.


also remember to include the .A8 .A16 .I8 .I16 directives at the start of each subroutine, just to be safe.

Hi Proxy, I find that taking up another two lines at the beginning of every routine is a lot of linenoise so I don't always do it. Perhaps some souped-up .proc-like macros that fold those .Ann/.Inn directives into the procedure declaration would ease that. BigEd pointed out the 65816 only has 5 modes after all when it comes to these register sizes (and emulation/native):

viewtopic.php?f=2&t=7139&p=93299&hilit=has+5+modes#p92986