By far my most common mistake writing assembly is neglecting a # in front of a literal (lda ff) or named constant (lda MAGIC_NUMBER),
so I end up with a memory reference instead of the intended immediate value.

Any tricks for getting the assembler or linker to help me detect these problems? For example when I write a literal value I almost never mean to refer to a memory location (I would always give it a symbolic name). Or if I could generate a list of all referenced memory locations (vs a named symbol map) I might see that MAGIC_NUMBER and ff shouldn't appear there.

Thanks!

A list of labels is a good idea, if your assembler can produce it. (I suppose you're using ca65 and have typo'd in the topic title?)

But for myself I don't have any tricks - I'd proofread what I'd written, and I might notice the wrong opcode, because after some experience you will recognise the most common opcodes. And then, when debugging, it might become clear that all is not well. In some ways this is more a question about debugging tactics than about tactics in getting the source correct.

Interested to hear other suggestions, of course.

In addition to the 6502, I also program the 6800 and 6809, both of which have the same problem.

There is no easy solution to this problem except that the more code you write, the less often you will tend to make this error.

Stepping through your code in a debugger when it does not do what you intended makes this kind of error stand out.

Some relocatable assemblers will put an indication in the object code field such as an "r" next to relocatable addresses and you can scan for those.

<rant>
This problem is a direct result of instruction set designers who strive to make their architecture "appear more orthogonal" while ignoring the unintended consequences.
</rant>

If Motorola had used LDIA and LDIB instead of LDAA # and LDAB # in the original 6800 design, the problem solves itself. MOS might have chosen to use LDI instead of LDA for the immediate form.

Zilog made the same mistake with the Z80.

Instead of


they used


though you will get few Z80 fans to admit this is a problem...it is not as bad because () is more visible than a single #

Though they probably did the whole rewrite the assembler syntax to avoid the copyright lawyers at Intel.

yes, typo sorry, corrected in the initial post. and yes to debugging, that's ultimately how I usually catch them along with lots of source re-reading.

having different opcodes would be nice for sure. i suppose you could use macros to write code that uses different mnemonics for different addressing modes and adds the required '#' or not? not sure i'd get used to it, and might make it hard for others to read later.

i guess it's really a linting problem? are there any 6502 lint tools?

I notice ca65 allows you to distinguish label vs numeric constants (SOMETHING = 2 vs SOMEWHERE := 200) though it doesn't seem to treat them differently while assembling.
maybe i'll try making a little python linter script that looks for bare literals or numeric constant without # (e.g. lda 3 or lda SOMETHING).

could you catch other common mistakes like that, e.g.? mismatch ph{x|y|a] / pl[x|y|a] within same scope? unlabeled (unreachable) code after bra? obviously none of these are hard and fast but it might save a few debugging cycles...

One of the assemblers used by Acorn back in the day had a more regular syntax, with longer opcodes to distinguish addressing modes. I think it was MASM: you'll see LDAIM, ANDIM, and similar. Also LDAIY, and so on. In fact, I see there's a Bush & Holmes assembler for the C64 which did similarly.
https://archive.org/details/Commodore_6 ... rogramming

This is an assembler problem, not a hardware problem. The CPU doesn't care what lays down the object code, just that it's correct.

If the assembler you're using has a macro capability, you can make up whatever mnemonics you find useful.

Details vary depending on which assembler you're using, but as a simple example:

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

yup, tho if I adopt that = vs := convention then it could be leveraged for linting, i.e. it's usually wrong when I use a constant symbol as an address (without a #), and it's sometimes wrong if I use a label as a immediate value (tho not as often, and at least I had to explicitly add a # there).

so i might try a tiny lint script that looked at least for the first case, with some ;NOLINT comment to opt out when I really mean it

i've seen a few other threads about 6502 lint but they mostly seem concerned with code formatting which I don't care nearly as much about as pointing out places where I might have a bug

proof of concept illustrating the idea, where both of these references are missing a leading #

however If LCD_WIDTH was defined with :=, indicating a label, it knows not to warn since label as address is fine.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

not sure I agree with that sentiment. the more help I can get finding dumb mistakes through lint, static type checking and the like, the more time I can spend thinking about the actual difficult problems. bugs like this seem more like avoidable friction: "do what I mean, not what I say", so what not have a crutch to help avoid them?

Hello,

I find it helpful to set highlighting in my editor so that immediate arguments look different from others, like this:

It doesn't fix anything automatically, but the visual distinction makes it easy to spot differences, and I've become accustomed to noticing whether the value is in green (like a comment and, therefore, literal) or aggressive magenta (indicating a hot memory reference stuff). It might be a silly mnemonic, but it works for me.

(I use Linux Gentoo, edit nearly everything in Vim, have a half-transparent picture in the background, and use tabs for indenting, shown as blue "|----" marks.)

_________________
http://micro-corner.gilhad.cz/, http://8bit.gilhad.cz/6809/Expanduino/Expanduino_I.html, http://comp24.gilhad.cz/Comp24-specification.html, and many others