#65 forced 3 bytes INC where it should do a 2 byte zeropage one

[Geert Verschueren]

Hello Soci,

I bumped onto some issue in a 64tass from 2011. ;)
So I thought upgrading to the most recent version might solve something but it didn't.

The problem seems to happen when you reference a label that is behind the code and in zeropage.

the original code was

    .logical $f7
getbyte 
    lda $ffff
            inc getbyte+1
             bne +          
            inc getbyte+2

+       rts 

but due to some reasons I had to change the order to what you see below

    .logical $f7
getbyte 
        inc $fe;gb+1
        bne gb
        inc $ff;gb+2
gb      lda $ffff
        rts 

in this case using gb+1 creates long INCs which results that the lda gets moved to $ff and is partially out of ZP.

the only solution I could find was hardcoding the addresses.

is there a way to fix this with another INC method or is this a bug?

I also had some misery with with for example INC -+1 but that's because the logic of - changed.
INC (-)+1 seems to work but looks kind of ugly so I better use a label instead.

any advice on the first issue would be appreciated

thanks

[Soci/Singular]

The problem is 64tass assumes that an unknown label will be not on the zero page as that's how it is 99% the time. Because of this assumption in this case the long instruction length pushes it off so it really won't on the zero page :)

Assuming short size instead would cause unnecessary passes in many cases, so I won't change to that.

To make it behave give it a little hint with @b that the short variant is what you need. (INC @b gb+1)

Yes the -/+ label recognition in expressions got fixed and needs parentheses when it's ambiguous. It was rather confusing in old versions that the label looked like a regular minus sign while it was not.

[Geert Verschueren]

thanks for the hint, Soci!

that inc @b gb+1 method works fine.