Strange align bug

[Awuwunya]

This is the interesting bug that me and Markey faced constantly. I am 80% confident it is to do with the align directive (doesn't matter if its the weird hacky align macro in S&K disassembly or !align, both break it). I remember going through the S3K Battle Race code and trying to remove all aligns and eventually this stopped happening - however before it, it was a constant issue.

So, you'll write code, and suddenly you get nonsense errors, mostly just addressing mode not allowed, but also other seemingly stupid errors. Recreating this bug is difficult, it just kinda happens. I remember in specific Markey used a single align $1000 that was not needed somewhere, and other aligns present in S&K already. I trimmed those since we were using the S3C DMA method anyway, they were not needed.

It is hard to describe how to make the bug happen because it only really had to do with some code, and maybe very speicifc offsets? But to me, this did not seem to make sense. No matter what change I would enact on the alignment macros in S&K, this was never fixed. Even a straight !align did not do it. We had this "variable", that would insert few hundred bytes of dc.l's at the end of the header when enable, so using that when the bug happened, either enabling or disabling, would fix it temporarily. It would only ever happen so often, so sometimes a few months would go by without needing it, while other times it was more common.

The only real clue I got it was to do with align and seemingly specific-ish offsets, and adding more code either made it happen or fixed it. Further than that, I was not able to figure it out ever.

[flamewing]

This is something I have seen mentioned by a lot of people (though to be fair, you have given more details than most on how it might be reproduced). But without having an actual example I can use for debugging, I have no clue what might be causing it, and no way to debug it at present. Testcases welcome!

[Awuwunya]

It might be worth asking Markey if its ok to privately share Battle Race source back from when this used to be an issue. If so, I can muck about with it until I get it happening, and then share it

[flamewing]

Repost from the Retro forums:

I have been investigating the issue @MarkeyJester reported; and I have good news. @AURORA☆FIELDS managed to reproduce it, and I have determined that the issue was apparently fixed in 1.42 build 139, with improvements in build 142. The issue was in the way that AS was forward symbols in the first pass: before build 139, values of some forward symbols could try to be checked before their values were settled and end up being considered to be out of range because a -1 was returned by the evaluation function, which becomes out of range.

I still want to try out more cases before declaring the bug fixed, but I am optimistic.

[Clownacy]

I think I've found another way of tripping this bug. Here's a minimal reproducible example:

    CPU 68000
TitleCard_ZoneName = -$4F80

    !org $300000

    move.l  #titlecard_x_target,d0
    cmp.w   (TitleCard_ZoneName+titlecard_x_target).w,d0 ; has title card sequence finished?
titlecard_x_target     = $30    ; the X position the object will reach

The move.l is just there to illustrate an effect of the bug: if you look at the listing file, the move.l has a literal of 0x300000 for some reason. This causes the build to fail, saying that the cmp.w cannot use short addressing.

It happens if the !org is a phase too.

This is on Windows, using the 32-bit build of the latest snapshot.