[Zenst]

45 and the whole point i was making is:

1) learning something new you might as well have something easier to learn 2) just becasue historicaly you had to use abreviations is not a handicap you have to impose upon yourself thesedays - especialy if your learning it from scratch and for educational aspects. 3) Sure you can use short TLA's instead of a longer version but for ease of reading and learning then something alot cleareer for the human without that over-comprimise you had with memory of computers is a artificial limitation. 4) realy not hard to run a substitution script to conver long to short and vice a versa - sed anyone!

We have all done assembly by hand and hand converted it, the compiler was a luxury for some back then and there small memory machines and even then you were not limited by the official shortcode versions of TLA's.

Thing is with hand converting is that you write something not maintainable on many levels, but as you said, you bent towards those lmitations as you had not alot of choice.

So if you want on say a Z80 write RETURN or the offical mnenoic of RET or go real hard code and just write C9 (using this example as my personal memory space seemed to of kept that one alive) then it was your choice. When you went to code it was C9h so converting RETURN or RET was something you did.

Least only op code that was standard across CPU's was NOP or "NO OPERATION" aka do nothing or 00h or 0 or 00000000, that was kinda portable and used by many for funky double-entry code padding etc. Though that was due to memory limitations and scary stuff to maintain, yet fun and rewarding to code. Apple early OS used that approach alot due to memory limitatons.

Heck of memory was such a limitation back then - explain COBOL becasue I can't, sadly still remember that as well :|.

[ColinWright]

Well, there's no point in getting out of shape about it, and I've got lots of other more important things to do than trying to convince you of this, but it seems to me that learning 6502 is already pretty useless as compared with learning something like ARM7 or StrongARM. Even there the assemblers still use TLAs for the operations. I honestly feel that it just seems right to maintain the contextual relevance and, in some sense, the culture of assembler.

If you want readability then by all means use Python or Go or Ruby or something like that. I don't know anyone who writes in assembly who doesn't use the TLAs (or similarly concise designations) for the operations, no matter what processor they're using. In feels to me like there is something natural about it.

But even beside that, I personally find that abbreviations make it easier to think in whatever subject I'm working on. When I write in assembler I think "MOV" - I don't think "move". Jargon in any field is there to make communication faster and more effective, and linguistics says that common expressions gets shorter over time.

So I think you're trying to improve the wrong thing, and while to some it may seem obvious that spelling out operations more verbosely and making them more obvious will help people learn, I'm not convinced. Sometimes concise, precise and semi-opaque terms can actually help learners.

[ralph]

I thought the original post was wrong to choose 6502. "So, it was designed to be written by humans. More modern assembly languages are meant to written by compilers, so let’s leave it to them. Plus, 6502 is fun. Nobody ever called x86 fun." I assume he's never written ARM. It was designed to be written by hand, is delightful to write, much more orthogonal than 6502, and still relevant today.

[tmzt]

STA didn't mean store address anyway, what would your long neumonics for store X or store Y be?

Having learned 6510 asm when I was younger, mov always seemed backwards and magical to me.

[to3m]

I'm not convinced. There's so little to your average assembly language that making the mnemonics longer won't help. With 6502, it would be totally pointless. You're going to be spending, what, 1 week learning this stuff, and then the next N years using it. You'll get used to it quickly enough. It makes more sense to optimise for experts, than it does for people who don't yet know what they're doing.

(And anyway, where do you stop? If you can't remember that STA means store accumulator and LDA means load accumulator, how will you remember what (&70),Y means, or what flags they use, or how many cycles they take? You'll end up with something like SUBTRACT FROM ACCUMULATOR MEMORY IN ADDRESS STORED IN &70 WITH Y REGISTER AND INVERTED CARRY FLAG WITH RESULT AFFECTING N AND Z AND C CLEARED IF BORROW AND V SET IF OVERFLOW TAKING 6 CYCLES PLUS PAGE BOUNDARY CROSSING PENALTY ;) - and even that probably isn't clear enough, because how will the poor reader know what the page boundary crossing penalty is if they don't know already?)

If you have something like x86's PUNPCKHBW, or POWER's rlinmw, and try to describe what they do clearly, you'll end up in even more of a mess. A one-volume instruction reference manual, sorted by opcode, with diagrams and pseudocode, would be far more useful.

[to3m]

As if to do almost the exact opposite of backing up my point, the PPC opcode I was thinking of is in fact `rlwimi' - Rotate Left Word Immediate then Mask Insert. I was thinking more like, Rotate Left and Insert Mask Word. Oh well.

So maybe longer opcodes would help, but I'd have got it wrong in either event - and I'd still need to have double checked the docs, to remind myself, again, just what the hell it does exactly.

[Someone]

IIRC, on 6502, 0x00 is BRK, not NOP. http://www.masswerk.at/6502/6502_instruction_set.html agrees with that.

[Zenst]

I forgot for every rule there is always an exception - cheers.

[Someone]

Many exceptions: http://en.wikipedia.org/wiki/NOP :-)