Selecting Addressing Mode in XA

[srowe]

And it's fun to complain about XA and it's fun to find something better.

xa is an Open Source project, if you can improve it to behave as you think it should then send Cameron a patch. He's always been responsive when I have.

[chysn]

And it's fun to complain about XA and it's fun to find something better.

xa is an Open Source project, if you can improve it to behave as you think it should then send Cameron a patch. He's always been responsive when I have.

That could be fun. I wouldn't submit pull requests to address philosophical questions like "should an assembler optimize 6502 by default?" My view is that the answer is no, but whatever. More important is that an optimization should not actually change the behavior of the code.

If an assembler sees STA $00FA and changes it to STA $FA, that doesn't change the behavior of the code. It's a somewhat-safe optimization.

However, a 6502 assembler should never optimize from absolute,X to zeropage,X, because the range of memory that could be read or written is different. The probability of breaking a program with that optimization is high.

So, where is XA? I found a mirror by the original author (https://github.com/fachat/xa65), but that doesn't look like the official repository.

[srowe]

So, where is XA? I found a mirror by the original author (https://github.com/fachat/xa65), but that doesn't look like the official repository.

I don't believe there's a code repo on GitHub I've mailed patches via the email address on the bottom of https://www.floodgap.com/retrotech/xa/

[chysn]

I think the change I'd make is in xat.c, line 325. I did this:

Code: Select all

323 /* indicates absolute->zp optimizable addressing modes (abs->zp) */
 324 /* indexed by addressing mode */
 325 static int opt[] ={ -1,-1,-1,-1,-1,-1,-1,-1,1,-1 /* <-- originally 2 */,3,-1,4,5,-1,-1,
 326            /*new*/ -1,8,9,-1,-1,-1,-1,-1 }; /* abs -> zp */

This disables the absolute,X to zeropage,X optimization. After the change, it works as expected. I'll use it for a week or so, then maybe I'll mention it to the developer. But even if he doesn't integrate it, I have a fork of XA that works the way I want it to.

Thanks for the advice!

[groepaz]

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.

the misunderstanding is that leading zeros in a constant are somehow related to the adressing mode.

[chysn]

the misunderstanding is that leading zeros in a constant are somehow related to the adressing mode.

Seeing as how all the 6502 assemblers I've used--from the old ones like HESMon and VICMON, through newer cross-assemblers like XA and Acme and 6502Overdrive--acknowledge the number of hex digits as an explicit lexical hint for the addressing mode, you seem to be all alone there. But it's not a question I'm interested in anymore. My focus has narrowed to how indexed addressing modes are optimized as a result of this hinting.

If you'd care to defend the optimization of indexed addressing modes, that's a counterargument I'd love to understand. It would help me decide whether to submit my pull request to the XA maintainer.

[Mike]

If an assembler sees STA $00FA and changes it to STA $FA, that doesn't change the behavior of the code. It's a somewhat-safe optimization.

They do have different cycle counts though, and that can make a difference for cycle-exact code.

the misunderstanding is that leading zeros in a constant are somehow related to the adressing mode.

That's however exactly how monitors like VICMON and HESMON differentiate between absolute and zeropage addressing in their direct assembler.

Anyhow, the expression parser in a symbolic assembler need not be restricted to carry on only the numeric value of an expression during evaluation, it could quite as well hold information about the size/type of the operand alongside, with clear rules how to defer the type of intermediary results. Like:

• $xx is a byte,
• $xxxx is a word,
• decimal values < 256 are bytes, decimal values >= 256 are words,
• a binary operation with at least one word results in a word,
• the result of a binary operation with two bytes that doesn't fit into a byte (i.e. is >= 256) is widened to a word,
• "<" and ">" operators on words result in bytes.
• optional: provide (byte) and (word) as C-like casts. (byte) may throw a warning on values >= 256.

Furthermore, when an instruction only accepts a zeropage address in a given syntax (like STX zp,Y - STX abs,Y doesn't exist!) and the expression parser "delivers" a word, it should not fault unexpectedly, but first check whether the value is < 256, and then assemble the instruction regardless. Same applies to results supplied as immediate values, say like in LDA #xx.

Well?

[groepaz]

That's however exactly how monitors like VICMON and HESMON differentiate between absolute and zeropage addressing in their direct assembler.

sure. monitors are totally different tools however. and monitors that support labels/symbols usually have similar "problems" too

Well?

you already demonstrated it... the rules quickly become complex (and i am willing to bet you need more than what you wrote to actually cover all corner cases).

i have discussed this with marco (the acme guy) quite a bit - and we always come to the conclusion that if you really need a specific addressing mode, you must explicitly write it as such. i dont see the problem in simply doing so either

[chysn]

If an assembler sees STA $00FA and changes it to STA $FA, that doesn't change the behavior of the code. It's a somewhat-safe optimization.

They do have different cycle counts though, and that can make a difference for cycle-exact code.

I considered that, as well as cases in which a programmer writes self-altering code, which is why I qualified it as "somewhat-safe." Most of the time, that optimization makes sense. But with absolute,X to zeropage,X, most of the time that optimization is problematic because of the huge difference in addressable space, and given the special roles of pages zero and one.

[Mike]

i am willing to bet you need more than what you wrote to actually cover all corner cases

Given the actually small set of type rules I gave above, maybe excluding the (byte) and (word) casts, do you think you could come up with a counter example for typical code?

(Intermediary) values >= 256 will always be typed as words. Especially if a 4-digit hex constant is used in a expression, the result will never be re-interpreted as byte (and thus be 'optimized' for zero page addressing by accident), much to chysn's and mine appreciation. Typical constructs that calculate table values for screen lines, like BASE+22*X (with X=0..22) will work as expected, as 22*X is widened to a word as necessary. Negative (intermediary) values are typed as words, but as long the result is < 256 they still work as operand of immediate address mode instructions.

If someone explicitly wants zeropage addressing on an operand value, that by some wild expression-fu has been typed as word, but fits in a byte regardless - with the inclusion of the casts it can always be written as "<opcode> (byte)...".

[chysn]

i have discussed this with marco (the acme guy) quite a bit - and we always come to the conclusion that if you really need a specific addressing mode, you must explicitly write it as such.

Of course you must explicitly write an addressing mode. I always do. But Acme's documentation mentions leading 0s as the first way to explicitly specify an oversized addressing mode.

My beef with XA is that I was explicitly writing an addressing mode, and it was reversing my decision. Which caused my program to crash.

[groepaz]

Given the actually small set of type rules I gave above, maybe excluding the (byte) and (word) casts, do you think you could come up with a counter example for typical code?

not offhand, no. but i know i stumble about it every once a while i dont want to remember those rules in the first place, its a waste of time to me. when i want a specific address mode, then i just force it. that just works, always, in all assemblers, and i dont have to remember specific rules of some assembler. as said, waste of time for me. (and "typical" is a bad idea here - i want stuff to work _always_)

My beef with XA is that I was explicitly writing an addressing mode

no, you are assuming leading zeros are related to addressing modes. if anything, thats an assembler specific convention, no more no less.

[chysn]

when i want a specific address mode, then i just force it. that just works, always, in all assemblers

Let me back up a second here and ask you what syntax you use to force an addressing mode?

[Mike]

i dont want to remember those rules in the first place, its a waste of time to me.

Really? IMO, the first six bullet points of my list don't look counter-intuitive to me. And you surely have similar rules memorized when you handle operator priorities. Or do you like to build labyrinths of parentheses?

when i want a specific address mode, then i just force it.

There's no convention across different assemblers how to force address modes, either. Some assemblers append ".B" or ".W" suffixes to the mnemonics and thus promote non-standard mnemonics.

With my proposal, the (word) cast pretty much works the same way as the "!" prefix operator in xa. Only my type rules are more likely to produce the word type (and keep it) in the first place.

That's pretty much for it. I would though have to actually write an own symbolic assembler with my bullet point list implemented to actively defend my point of view. However, as long as the inline assembler of BBC BASIC does the job for me (with all its idiosyncrasies), I'll keep it. In the end, we still get all our code assembled, no?

[chysn]

In the end, we still get all our code assembled, no?

Although I'm starting to wonder how....