search

cvghivebrain / s1disasm

Sonic the Hedgehog (Mega Drive) Hivebrain 2022 disassembly
44 stars 8 forks source link

Fixed "*" usage in Z80 macros by copying number parameters into varia… #26

Closed DevsArchive closed 2 years ago

DevsArchive commented 2 years ago

…bles before storing instruction data

Awuwunya commented 2 years ago

This will cause issues, in particular because sometimes the symbols or expressions passed as arguments rely on forward references, and trying to put expressions that can't be determined yet in variables will stop assembly. Making expressions safe in macros should be as easy as wrapping the arguments (like \1) in parenthesis instead

cvghivebrain commented 2 years ago

I think forward references are okay if you use equ, though I'm not sure about local variables. To be safe I went through and replaced \1 with (\1) where necessary. "dc.b \1" should be fine without brackets.

DevsArchive commented 2 years ago

This will cause issues, in particular because sometimes the symbols or expressions passed as arguments rely on forward references, and trying to put expressions that can't be determined yet in variables will stop assembly. Making expressions safe in macros should be as easy as wrapping the arguments (like \1) in parenthesis instead

That is why I used EQU instead of =. Because EQU is used to hold a finalized value, ASM68K sets it to be processed after assembly. The problem wasn't "*" being safely processed, it was that "*" was being calculated AFTER the opcode was written, which causes stuff like "JP *" to assemble incorrectly. I have tested the changes before making the PR, and they've worked without issue for me, even with the usage of local variables within macros.

Awuwunya commented 2 years ago

yeah, after talking to Rala about this, I indeed had missed the point with the changes and how they work. Indeed, equ can use forward references in many cases, and in particular here it should still work. Set (or =) in contrast can't, which is what I mainly use in macros because of global scope, but that is why local symbols were generated instead. So yeah, my bad, I made a little mistake here =P