No loss of instructions. Full Z80 instruction set available.I guess the straight jacket you know is better than all the powerful instructions you don't.
It may seem weird, but it is not unusual. Before the 8080, and even in modern times. The PowerPC instruction set calls register-register transfers "moves", and uses "load" and "store" terminology as well. It may not be entirely consistent across all architectures, but it is common. Even 8080 is not entirely consistent: MVI "move immediate" is really a load from PC+1, LXI "load double-reg immediate" is the same idea but called a load. Zilog's use of LD for nearly everything is at least as weird. It's probably unlikely anyone could point to an existing architecture and get agreement that it is perfect.The whole 'MOV' for move is just weird; it is NOT a move, it's a copy. Or a LoaD. And stores are just reversed loads....
Consider the 8086, then, where MOV isn't even isomorphic; that is, there are several encodings (depending on the assembler being used) for a single MOV instruction. That is, the assembler can generate a "short form" move or one that uses the MOD R/M field to specify operations.At the risk of reopening the whole "Intel vs Zilog mnemonics" war, I'll just say that when I first saw Zilogs mnemonics I thought "cool". But then I saw things like that "ld" was a crude catch-all for all move, load, and store operations. Plus, the mnemonics imply a symmetry that does not exist (you can do "sbc a,b" but not "sbc h,b", etc ad nausium). You basically still need to know the underlying machine language in order to program effectively, so I just chose to stick with Intel mnemonics where that architecture was obvious.
Not true; the z80 macro library was incomplete; the IX & IY addressing modes especially. And none of the undocumented instructions.No loss of instructions. Full Z80 instruction set available.
Macro library. You can add any instructions you want. and I did. But I've gone back and purged all the undocumented instructions from my code because it needs to run on Z180 and beyond. Indexed addressing instructions were present in the DRI Z80.LIB.Not true; the z80 macro library was incomplete; the IX & IY addressing modes especially. And none of the undocumented instructions.
"And beyound" would include the Z280 which formalized all the undocumented ones. It's my current Z80 hardware of choice (perhaps ironically I use a Z280 macro library to generate Z80 code for when Z280 hardware isn't available) . Only some of the indexed instructions were present; but not all.Macro library. You can add any instructions you want. and I did. But I've gone back and purged all the undocumented instructions from my code because it needs to run on Z180 and beyond. Indexed addressing instructions were present in the DRI Z80.LIB.
Yeah, it made sense to me to read LD A,H as ' load A with the contents of H.' The word 'move' implies, at least to me, that the source is deleted or zeroed; the 'mv' shell command in Bourne and similar Unix shells, for instance. And reading MOV A,H as 'move to A from H' is just backwards (the more natural read is 'move A to H' but that's wrong). But, there are those who enjoy such things (RPN users, for instance), I guess.The ld thing is funny because that was one of the things I liked - the concept of ld dest, source just makes sense to me even if not all possibilities are present. I agree that it is a serious catch-all though!
Yeah, for the Z280 don't accept anything before rev G. IIRC the newest rev was J. The only known bug there was having to put a NOP after some OUT instructions. Still a great processor.But Z80 is way far from orthogonal. Even Z280, which fixes a lot of things, mainly the Z80 lack of stack pointer relative loads, is way far from orthogonal (and real Z280 silicon, depending on revision, has some really squirrelly bugs).
I got bitten by the SUB A,B versus SUB B inconsistency while programming the NEC TK-80. Assembling was done on my laptop using asm8080 assembler and it did not complain about SUB A,B but the result of that instruction was always zero.. Took me a while before I found out (being used to Z80 more than 8080)...
That sounds like the classic MOV vs. MVI mistake when using Intel mnemonics. The assembler probably wasn't telling you "MVI A,0" was better done by "XRA A", but rather that "MOV A,0" was not legal syntax. Many assemblers were not this sophisticated, though, and "MOV A,0" would have just been silently turned into "MOV A,B". Likewise, "MVI A,B" was silently turned into "MVI A,0" (similar to intentional, useful, things like "MVI A,JMP"). I know I got bit several times by converting code between using immediates and registers, and failing to change a "MOV" to "MVI" or vice versa.The memory is vague, most of them are these days, but I remember dumping an assembler that insisted that I didn't really want to MOV A,0. I really wanted to XOR A AND SAVE A WHOLE FREAKING BYTE!
This is why assemblers that let you use comments without a semicolon are a problem. They simply ignore everything else after they think they got what they wanted. But even then, at least they could bother to check for stuff before the next blank and complain about the extra stuff. As for me, I like being able to put blanks in my operands for readability, so it's semicolon always for comments.Try "sub a,xyzzy" for fun...
That's why I make an effort to support different instruction set variants when I can, it's belt and suspenders to make sure you don't do stuff that won't work. It's important in a disassembler too.implemented the enhanced instruction set