ASAR 1.8X breaks instructions that worked on 1.7X

[five95]

I have managed to narrow down this issue to a tiny asm file. The following code would work on 1.7X for a file "test.asm" compiled using ./asar test.asm out.sfc

RAMADDRESS = $7E0012

org $808000
lda [RAMADDRESS]
pei (RAMADDRESS)

This would compile to:

$A7 $12 $D4 $12

However, in ASAR 1.81, it generates the following errors:

test.asm:4: error: (E5117): Unknown command. [lda [RAMADDRESS]]
test.asm:5: error: (E5117): Unknown command. [pei (RAMADDRESS)]

The only thing I could find in the changelog remotely resembling this was:

Repeatable instructions (like LSR #4 don't accept labels in their argument anymore. (randomdude999)

The issue seems to affect commands with 1-byte values being passed a label. But I don't quite understand the logic behind breaking that functionality if this is intentional, and it seems like a major regression. It is very reasonable to want to reuse the same address like this in code, for example to load a 2-byte value from a pointer and then increment the pointer.

lda [RAMADDRESS]
inc.b RAMADDRESS
inc.b RAMADDRESS

The above example is very clean code, and does what you'd expect in 1.71 ($A7 $12 $E6 $12 $E6 12). It feels right, but in 1.8X the first instruction causes an error. However I see no way to deal with the error without resulting in uglier code.

If this is indeed an intentional change, then what is the preferred way to write the above code?

[Alcaro]

Sounds like something involving the RAM optimizer.

I don't know if the change is intentional, but if it is, the recommended solution is lda.b [RAMADDRESS].

[five95]

Thank you very much for the quick reply! You are right, specifying the lengths does fix it, so that solves my issue.

RAMADDRESS = $7E0012

org $808000
lda.b [RAMADDRESS]
pei.b (RAMADDRESS)

I double-checked and these two commands don't have any alternate-length versions with [] and () respectively (you're probably aware).

[trillllian]

i think the actual recommended solution is optimize dp always and optimize address mirrors. basically what is happening is that label references get expanded to long instructions which previously got truncated to 1 byte, possibly incorrectly. now we have a mechanism for allowing shortening references to $7e00xx to $xx while still throwing errors for, e.g., $7f0000 or anything else which isn't mapped to dp. i'm not quite sure why those optimize settings aren't the default, probably still something related to backwards compatibility, but i don't see any reason to not enable them for new code.

[p4plus2]

Maybe these should be default enabled in 2.0...