Selecting Addressing Mode in XA

[chysn]

I ran into a problem with the XA assembler, which is that it assembles

ADC $00FF,X

as 75,FF instead of what I want, which is 7D,FF,00

I mean... I'm using $00FF instead of $FF for a damn reason, right? It's important, especially given that it's indexed.

I don't see anything helpful in the XA documentation. Maybe it's time to switch to something else, which may or may not have problems of its own. I'm using a MacBook Pro... anybody have favorite assemblers?

Edit: I just swapped out XA for acme in my build script, and acme gets the addressing mode right. I'll run with acme for a bit.

[srowe]

The man page explains this is an optimisation and to assemble an absolute address you prefix the value with "!"

[wimoos]

A not so elegant, but quick solution is to use .DB or .BYTE directives.

[Mike]

See also here: http://sleepingelephant.com/ipw-web/bul ... =semantics, and to quote from there:

IMO, when a programmer writes "CMP $00xx,X" - or any other similar instruction with the high byte of the operand explicitly set to zero - in cold blood, without any involved symbols, that instruction should be assembled with *absolute* address mode, and not zero page. It ought not matter, whether "zero page optimization" is enabled or not. With numeric addresses in hex, ZP mode should only be enabled for two-digit hex operands.

As you know, on the NMOS 6502, ZP indexed operands wrap after $00FF, whereas ABS indexed operands do not. They have different semantics! So, when the programmer wrote "<mnemonic> $00xx,X" or "<mnemonic> $00xx,Y", he most probably meant it this way, and this leads to very difficult to find "bugs" (which actually are caused by a design fault in the assembler for this case here), when other parts of the code actually rely on the non-wraparound behaviour of ABS,X/ABS,Y, but don't find their data there if they then use "<mnemonic> $01xx" to retrieve it (quite apart from those unsuspecting ZP addresses being 'shot' by the unintended wraparound).

Just my 2 cents.

(emphasis added)

[chysn]

The man page explains this is an optimisation and to assemble an absolute address you prefix the value with "!"

Thank you! I missed that one and just grew annoyed in the middle of the night.

I agree with Mike's point above. If VICMON knows what $00FF means, then so should everybody. Ambiguity shouldn't be allowed to fester on the altar of optimization, and that's the hill I'm gonna die on!

[groepaz]

you can not really really on this however - since as soon as you write a non trivial program you will use symbols/labels instead of literal numbers, and at this point the assembler can no more track what it should be in a useful or even predictable way. and thats exactly why in many assemblers you'll have to use an explicit prefix to force zp or abs addressing.

[srowe]

As xa supports complex expressions such as

Code: Select all

value = $7654

lda #(value/1500)-2

the parser can't just assume your $00FF means you want an absolute address.

[chysn]

you can not really really on this however - since as soon as you write a non trivial program you will use symbols/labels instead of literal numbers, and at this point the assembler can no more track what it should be in a useful or even predictable way. and thats exactly why in many assemblers you'll have to use an explicit prefix to force zp or abs addressing.

The use of labels doesn't materially change the issue. Consider

Code: Select all

ZERO = $FF
ABSO = $00FF
ADC ZERO,X
ADC ABSO,X

Acme handles these labels as I would expect, resulting in 75 FF, 7D FF 00

Even if you go beyond naïve interpolation and use expressions,

Code: Select all

OFFSET = $20
ADC ZERO - OFFSET,X
ADC ABSO - OFFSET,X

Acme sticks with the addressing modes that I'd hope for, given the labels. It does move to absolute addressing mode with

Code: Select all

ADC ZERO + OFFSET,X

but that's pretty much forced.

[groepaz]

The use of labels doesn't materially change the issue

once you move away from trivial cases, you will notice various edge cases where this is not true. and thats precisely why every assembler worth noting has a way to force a specific addressing mode.

[chysn]

The use of labels doesn't materially change the issue

once you move away from trivial cases, you will notice various edge cases where this is not true. and thats precisely why every assembler worth noting has a way to force a specific addressing mode.

I don't know why you keep talking about non-trivial cases. I'm addressing the handling of the trivial cases here, not the complex ones. When a compiler sees

ADC $00FF,X

it doesn't get much more trivial than that. There's not much room for ambiguity in that syntax. I understand that if you're using a complex expression as an operand, you might need to force a certain addressing mode. That's not where my annoyance at XA lies. The trivial syntax, when used, should be sufficient to differentiate between $FF and $00FF. It's way clearer than, say, an exclamation point.

To put it another way, 0s are important. They mean something. 0s historically signify the concept of placeholding. I didn't put them there for fun.

[chysn]

I didn't put them there for fun.

I mean, of course I put them there for fun. VIC-20 programming is not my job, it's nothing but fun. And it's fun to complain about XA and it's fun to find something better.

[groepaz]

The parser handles all expressions equally, and after evaluating the value of an expression the information on how it was written does no more exist. What you say would require a special case handling for non trivial cases - which is a terrible idea.

[chysn]

The parser handles all expressions equally, and after evaluating the value of an expression the information on how it was written does no more exist. What you say would require a special case handling for non trivial cases - which is a terrible idea.

XA does it wrong and Acme does it right, so one of us is wrong. But I'm using Acme now, so I'm happy to concede this argument to you.

[groepaz]

also with acme (which is also my assembler of choice) there are cases when it comes out "wrong". you just cant rely on it, ever - unless you explicitly write what you want it to do. (current version even emits a warning when using absolute for zeropage - for this very reason)

[chysn]

you just cant rely on it, ever - unless you explicitly write what you want it to do.

I always explicitly write what addressing mode I want to use. Always. I never, ever, ever leave that to chance or whim. There's no excuse for my code to be misunderstood by an assembler. VICMON is never confused by my instructions, and neither should my cross-assembler be.