DRW wrote:
So, does this mean that the creator of the next NES assembler would be free to redeclare the "load into accumulator" command from LDA to LoadAcc and his design decision would be just as valid since there's no standard?
Or does this command has to be called LDA when creating a 6502 assembler?
If it has to be called like this, why are there no rules on how to declare local labels?
What does "has to" mean?
Once the code is assembled the string "LDA" or "LoadAcc" doesn't exist, only the opcode it assembles to, so it certainly doesn't technically have to be called LDA.
And if you do happen to make it LoadAcc instead of LDA, will the 6502 police at WDC come and arrest you? No, of course not. It doesn't legally have to LDA.
So yes, if you want you can make it LoadAcc in your assembler. People probably won't like it because they're used to LDA. They're used to LDA because the original documentation for the chip called it LDA and it's what all the other assemblers use and have used since time immemorial. It's a convention, like everything with assembly language, and some conventions stick better than others. Tepples and lidnariq gave several examples of times when assembler makers bucked trends for their assemblers and made unconventional syntax decisions, for one reason or another.
Without hunting around the official 6502 documentation, WDC probably doesn't specify the format for temporary labels and stuff like that, because they don't really correspond to anything on the chip, so it's not really their business. Developers of new assemblers thus choose the format based on what's easiest to parse, what looks nicest to them, and what they're used to from whatever assemblers they've used/coded before.
There's a bunch of reasons why this stuff happens less often with, say, C compilers. For one thing, C is an ISO standard. Almost everything is specified (or left intentionally unspecified), so you often don't have much of an excuse to make stuff up on your own, and, I dunno, maybe someone might actually yell at you or even sue you if you call your compiler a C compiler if it doesn't actually compile C? For another thing, there's a massive amount of C code out there written for massive numbers of compilers for massive numbers of platforms, and the nature of (and reason for) the C standard is such that you, to some extent or another, expect standards-compliant C code to compile on all of it and will get mad at you the compiler writer if they need to change all their =s to :=s, whereas by convention and due to the lack of standards assembly programmers generally don't expect their code to assemble without modifications with other assemblers. And finally, in fact, many so-called C compilers
do have subtle incompatibilities/deviations from the standards, because of bugs or technical limitations (as in cc65) or just because they're not feature complete for time/effort reasons (or in the case of something like CompCert, probably because of unresolved research issues).