Position sensitive macros? (aka mvabs lost .skip) #81
Description
This error is infuriating me because I can't even guess what is going on. It makes no sense. I have no idea where to look for the solution. Why is this assembler trolling me?!
deep breaths ... ok ... the particular romhack I'm starting on requires replacing everything that would normally happen between the sega logo and the start of the level gamemode, so I've been causing pretty substantial size changes that move certain bits of code around. My changes are fine, the problem lies in a macro. I'm going to past the listing file as reference here rather than source... you'll see why.
ROM size is $100000 bytes (1024 KiB). About $32A bytes are padding. Waaaay down in SSPlayer_Traction there's this section:
68659/ 342B8 : 6A1E bpl.s return_34048
68660/ 342BA : (MACRO) addi_.b #4,d0
68660/ 342BA : 0600 0004 !addi.b #4,d0
68661/ 342BE : 0C00 0088 cmpi.b #-$78,d0
68662/ 342C2 : 6514 blo.s return_34048
68663/ 342C4 : (MACRO) mvabs.w inertia(a0),d0
68663/ 342C4 : 3028 0014 move.w inertia(a0),d0
68663/ 342C8 : 6A02 bpl.s .skip
68663/ 342CA : 4440 neg.w d0
68663/ 342CC : .skip:
68664/ 342CC : 0C40 0100 cmpi.w #$100,d0
68665/ 342D0 : 6406 bhs.s return_34048
68666/ 342D2 : 117C 0008 0024 move.b #8,routine(a0)
Perfectly acceptable, my rom is compiling, it's happy day. Note that I haven't touch this code. I haven't touched the mvabs macro.
Now let me just go add a nop up where I'm working in up around line 12k ... a single nop. And recompile...
ROM size is $100000 bytes (1024 KiB). About $3AE bytes are padding. Eh? So many errors...
68660/ 342BC : 6A1A bpl.s return_34048
68661/ 342BE : (MACRO) addi_.b #4,d0
68661/ 342BE : 0600 0004 !addi.b #4,d0
68662/ 342C2 : 0C00 0088 cmpi.b #-$78,d0
68663/ 342C6 : 6510 blo.s return_34048
68664/ 342C8 : (MACRO) mvabs.w inertia(a0),d0
68664/ 342C8 : 3028 0014 move.w inertia(a0),d0
> > > s2.asm(68664) mvabs(2):17: error #1010: symbol undefined
> > > .skip
> > > bpl.s .skip
> > > ~~~~~
68664/ 342CC : bpl.s .skip
68664/ 342CC : 4440 neg.w d0
68664/ 342CE : .skip:
68665/ 342CE : 0C40 0100 cmpi.w #$100,d0
68666/ 342D2 : 6404 bhs.s return_34048
68667/ 342D4 : 117C 0008 0024 move.b #8,routine(a0)
What do you call that label to $342CE, you stupid assembler? Looks a lot like a .skip to me. In fact, it looks like all the opcodes generated are identical (address shift aside) with the exception of the macro. Some of the many, many errors...
> > > s2.asm(68664) mvabs(2):17: error #1010: symbol undefined
> > > .skip
> > > bpl.s .skip
> > > ~~~~~
> > > s2.asm(71760) mvabs(2):17: error #1010: symbol undefined
> > > .skip
> > > bpl.s .skip
> > > ~~~~~
> > > s2.asm(71764) mvabs(2):17: error #1010: symbol undefined
> > > .skip
> > > bpl.s .skip
> > > ~~~~~
> > > s2.asm(85699) begin_animpat(2):30: error #1010: symbol undefined
> > > APM_EHZ_Blocks
> > > APM_EHZ_Len := APM_EHZ_End - APM_EHZ_Blocks
> > > ~~~~~~~~~~~~~~
> > > s2.asm(85699) begin_animpat(3):22: error #1010: symbol undefined
> > > APM_EHZ_Len
> > > dc.w $1800 - APM_EHZ_Len
> > > ~~~~~~~~~~~
> > > s2.asm(85699) begin_animpat(4):26: error #1010: symbol undefined
> > > APM_EHZ_Len
> > > dc.w bytesToWcnt(APM_EHZ_Len)
> > > ~~~~~~~~~~~
> > > s2.asm(88166) plrlistheader(2):36: error #1010: symbol undefined
> > > __LABEL__Plc
> > > dc.w (((PlrList_Std1_End - __LABEL__Plc) / 6) - 1)
> > > ~~~~~~~~~~~~
> > > s2.asm(88176) plrlistheader(2):36: error #1010: symbol undefined
> > > __LABEL__Plc
> > > dc.w (((PlrList_Std2_End - __LABEL__Plc) / 6) - 1)
> > > ~~~~~~~~~~~~
> > > s2.asm(88195) plrlistheader(2):40: error #1010: symbol undefined
> > > __LABEL__Plc
> > > dc.w (((PlrList_GameOver_End - __LABEL__Plc) / 6) - 1)
> > > ~~~~~~~~~~~~
> > > s2.asm(88202) plrlistheader(2):36: error #1010: symbol undefined
> > > __LABEL__Plc
> > > dc.w (((PlrList_Ehz1_End - __LABEL__Plc) / 6) - 1)
> > > ~~~~~~~~~~~~
> > > s2.asm(88214) plrlistheader(2):36: error #1010: symbol undefined
> > > __LABEL__Plc
> > > dc.w (((PlrList_Ehz2_End - __LABEL__Plc) / 6) - 1)
> > > ~~~~~~~~~~~~
I know forward macro resolution is related to the two-pass stuff the assembler does... I know some code doesn't like crossing certain address boundaries... but why does moving this code from $342C8 to $342CC make it suddenly forget there's a symbol?!
But guess what happens if I add some more nops...
68665/ 342CA : 6514 blo.s return_34048
68666/ 342CC : (MACRO) mvabs.w inertia(a0),d0
68666/ 342CC : 3028 0014 move.w inertia(a0),d0
68666/ 342D0 : 6A02 bpl.s .skip
68666/ 342D2 : 4440 neg.w d0
68666/ 342D4 : .skip:
68667/ 342D4 : 0C40 0100 cmpi.w #$100,d0
Yup, when the .skip lands 12 bytes later it's fine. Clearly there's some boundry alignment going on somewhere, adding another nop isn't moving the label but the one after makes it jump to $342D8 ... I'm getting off track though ...
Can anyone enlighten me on what in this monstrous s2.asm is sensitive to addresses beyond the usual word alignment and, even better, give me some guidance on what's actually happening under the hood and how I fix it.
PS: I think you might be able to tell that having to constantly mess with padding to avoid it blowing up is driving me more insane than I usually am. Actually, the fact s2.asm is apparently able to crash my preferred VS Code syntax extension was already frustrating enough heh. (I use the Amiga Assembly (m68k) by preference since it has the 68k PRM properly embedded, but something about it and maybe git is breaking everything)