nesdev.org

I do not know if this could ever be solved, but I ABHOR the way WLA DX makes me force the labels to use .b, .w, or .l on all opcodes used, it's hard to convert a whole ASM file alone without either typing it in manually (I hate that) or using a converter (which does not exist).

There was a issue number on Github made by Nicklausw (I sincerely apologize if the name gets butchered!), but it is left for the most part abandoned while being closed, and I cannot do a duplicate posting,

If only there is a way... But for now it is just my two cents!!!

It's not really abandoned ... nicklausw noticed separate issues that happen to talk about the same thing ultimately, and decided to close his in favor of mine.

https://github.com/vhelin/wla-dx/issues ... -138097803

Believe me, we are all very keen on solving this. Speaking for myself, I have very low interest.

The thing I hated the most was that all the opcode names are three bytes; so it was such a shame to either have to use tab, lots of extra spaces, or not have operands line up.

I came up with using some otherwise binary operators as unary prefixes to indicate size to get around this.

< = 8-bit
> = 16-bit
^ = 24-bit
Understandably, it's not for everyone. I try to rely on implicit detection where possible, eg "lda #$1234" is clearly 16-bit. "lda $012345" is clearly 24-bit.

I once tried some special prefixes like ".a8, .x16, .d=$0100, .db=$20" that would then let lda #0 know that you were in 8-bit mode. But this turned out to work very poorly in practice. I'd very often forget to place them between function boundaries, and I abhored typing them after every rep/sep/plp/pld/plb/tad/rts/rtl instruction. The visual noise was too much. (You can try to auto-detect the changes after rep/sep, but that doesn't work so well in practice due to code jumps.)

byuu wrote:The thing I hated the most was that all the opcode names are three bytes; so it was such a shame to either have to use tab, lots of extra spaces, or not have operands line up.

I just chose not to have operands line up. They don't line up in other languages I use (C, PHP, Python).

I came up with using some otherwise binary operators as unary prefixes to indicate size to get around this.

< = 8-bit
> = 16-bit
^ = 24-bit

Code: Select all

lda #<24  //lda.b #$24
ldx (>addr,x) //ldx.w (addr,x)
sta ^addr //sta.l addr

Except in the standard 65816 syntax (source: WDC datasheet in Apple IIGS Hardware Reference), >value is already used for <(value >> 8), to retrieve the high byte of a 16-bit value.

(You can try to auto-detect the changes after rep/sep, but that doesn't work so well in practice due to code jumps.)

The .smart mode in ca65 does exactly that.

I wasn't aware .smart followed branches/jumps, only "linearly" (not sure what other word to use). The documentation seems to imply it doesn't ("Beware: Since the assembler cannot trace the execution flow this may lead to false results in some cases."). Other assemblers (I've discussed several in another thread) that have this similar feature don't follow branches/jumps either -- and can't, because effectively you'd have to implement an entire system emulator inside of an assembler to be able to do this accurately.

As for me, I've never had qualms using explicit pseudo-ops to inform the assembler what the relevant A/X/Y sizes were, alongside whatever "auto-detection" methodology (e.g. .smart) was available. It's just the nature of the beast that is 65816. But everyone has different views of it, and that's OK.

As for the main complaint about .b/.w/.l suffixes -- let's just pray the individuals complaining never look at the 68000...

I may have misunderstood what I read. I acknowledge that following rep/sep fails with jumps. Perhaps an assembler and a debugging emulator can work together to add zero-cycle runtime assertions alongside debugging symbols. Such an assertion would change the width of following instructions and break if, at runtime, the MX state does not match that in the debugging symbols. It's the only way I know of to handle the problem of sticky modes that affect instruction encoding. Or does the community around another architecture with such modes have a better practice of handling them?

byuu wrote:The thing I hated the most was that all the opcode names are three bytes; so it was such a shame to either have to use tab, lots of extra spaces, or not have operands line up.

but you can work on the symbol rather than the opcode and not have this problem at all. lda <symbol or lda symbol.b for example

> Except in the standard 65816 syntax (source: WDC datasheet in Apple IIGS Hardware Reference), >value is already used for <(value >> 8), to retrieve the high byte of a 16-bit value.

"Get this thing out of my sight!" [tosses rule book out window]

> The .smart mode in ca65 does exactly that.

And it works very poorly. I've done the same thing before as I said.

The more sophisticated you make it, the more surprising it is when it fails to work as you expect.

And you don't find out until your game crashes on you.

> but you can work on the symbol rather than the opcode and not have this problem at all. lda <symbol or lda symbol.b for example

The former of which is exactly what I do.

byuu wrote: > The .smart mode in ca65 does exactly that.

And it works very poorly. I've done the same thing before as I said.

The more sophisticated you make it, the more surprising it is when it fails to work as you expect.

And you don't find out until your game crashes on you.

I've had xkas make my program crash because it DOESN'T handle opcode size automatically.

Smart mode works well if you make sure your subroutines always make opcode sizes what they want. I find this a lot easier to manage than manually handling opcode size.