Zilog's Z80 opcode choice

[Cosmium]

This is probably more of a general Z80 question rather than applying to the Spectrum specifically, but do you think when Zilog designed and implemented the Z80's instructions and assigned them to either 1 or more byte opcodes that they always made the right choice? I'm not really talking about hypothetically adding new instructions, more about how they assigned the opcodes to be short or long form.

We know about the CB, ED (and the DD, FD index) prefixes, which add extra bytes and so take longer to execute but were some of the instructions selected to use these multi-byte opcodes the best choice?

I realise that Zilog wanted to maintain compatibility with its predecessor, and were constrained with what they could do with the die size, and from what I can see think they generally did a pretty good job.

But there are a few instructions that I wish were faster, one byte opcodes, without the ED prefix, such as SBC HL,rr, and LD (nn),BC/DE, LD BC/DE,(nn) etc.

Of course, to make room for this, there'd have to be existing instructions dropped from the 1 byte opcode, prefix-less space.

A candidate I might drop is the conditional CALL cc,nn instruction. Although fairly useful in a single use case scenario, I often find following a conditional check there are a series of CALLs to be made based on that one condition, and that means unless we preserve the flags between conditional CALLs (ie. more instructions) then a JR cc, d that can skip over a bunch of standard non-conditional CALLs does the trick, and so eliminates the need for 8 types of conditional CALL instructions.

Other rarely used 1 byte opcode candidates that might be up for demotion in my world would be the 8 RST instructions, although I understand they're useful in low memory systems and execute quickly, with the downside that you often end up with a JP at the RST destination address anyway, since you can't do much with the 8 bytes between destinations!

And then there are the nop-like LD A,A, LD B,B, LD C,C etc. I guess these were a result of the generalised instruction decoding logic, and die space constraints prevented anything else being used in their place.

[AndyC]

Well, the decision was mostly made for them. A design goal of the Z80 was to be able to run all 8080 code at a binary level, so you couldn't really just swap out less used instructions even if you wanted to.

Whether that was really necessary is a different question
I suspect the actual instruction set would've been significantly different if it wasn't tied to that goal, however.

[_dw]

0x40 LD B,B
0x49 LD C,C
0x52 LD D,D
0x5B LD E,E
0x64 LD H,H
0x69 LD L,L
0x79 LD A,A

OR A = AND A

Edit: sorry i can't read... .)

PS: In my opinion, having an ideal design of the instruction set as operating code and an ideal design from the hardware point of view are two different things. All the debate about RISK vs CISC, the effect of RAM speed on CPU development, there are too many parameters that affect it.

[1024MAK]

This is probably more of a general Z80 question rather than applying to the Spectrum specifically, but do you think when Zilog designed and implemented the Z80's instructions and assigned them to either 1 or more byte opcodes that they always made the right choice? I'm not really talking about hypothetically adding new instructions, more about how they assigned the opcodes to be short or long form.

Given the design goals that Zilog were working to, I think Zilog got it right. The Z80 is still made, sold and used, as is the later eZ80.

From a programmers perspective, the Z80 was a big step forward compared to the Intel 8080 (and Z80 systems were also cheaper and easier to design (*1) and manufacture compared to competing microprocessors).

The Z80 gives programmers a bit more choice than the 8080 and some of its rivals. You don't have to use the slow instructions. You can either design your code to be fairly compact but slightly slower or go for longer programs designed for speed.

On forums for 1980s computers that used the 6502, you may come across topics where they discuss what extra instructions they would have liked for the 6502, and how to add more than 256. Generally speaking, you don't get much of these type of discussions for the Z80 indicating that most programmers are happy with the instruction set.

Note *1, the Z80 was designed for embedded systems, plus at the time, RAM was very expensive and rather slow, hence easy interfacing to memory mapped video systems was not a primary consideration.

Mark

[ParadigmShifter]

6502 had proper multiple bit shift instructions I think though which would have been nice on Z80. EDIT: Maybe that was a later variant I don't think it had those on the 6502 either.

I think some of the addressing modes it had would be useful as well but I've never done any 6502 really... 3 is not the number of registers I am looking for lol.

EDIT: I remember our computer studies TEACHER at school being amazed when we told him about the Z80 LDIR instruction though lol I probably knew more about computers than he did

[ParadigmShifter]

DEC SP/INC SP are silly instructions too. It would be loads better if it decremented/incremented by 2, changing by 1 has no use I can think of, since you always push a word to the stack. If it incremented by 2 it would just be like discarding the value on the top of the stack (I usually use POP AF for that or another unused register pair but sometimes you want to keep A or the flags around).

[Lethargeek]

On forums for 1980s computers that used the 6502, you may come across topics where they discuss what extra instructions they would have liked for the 6502, and how to add more than 256. Generally speaking, you don't get much of these type of discussions for the Z80 indicating that most programmers are happy with the instruction set.

it may just as well indicate that most programmers weren't happy the prefixed instructions were slow and felt more would be just as useless
as for the 6502, well, there was quite some unused opcode space before even considering using prefixes

[Dr beep]

0x40 LD B,B
0x49 LD C,C
0x52 LD D,D
0x5B LD E,E
0x64 LD H,H
0x69 LD L,L
0x79 LD A,A

It is not just the Z80 but also the hardware. On a ZX81 I can use these opcodes to hide data on the screen and the hardware will just display a space.

An example... A snake game with inverted screen and white snake. I can use these opcodes to display a white snake but the data tells me where the tail moves to.

[Dr beep]

DEC SP/INC SP are silly instructions too. It would be loads better if it decremented/incremented by 2, changing by 1 has no use I can think of, since you always push a word to the stack. If it incremented by 2 it would just be like discarding the value on the top of the stack (I usually use POP AF for that or another unused register pair but sometimes you want to keep A or the flags around).

I needed these to mak my SP-2-MC10 emulator run since a TRS80 MC10 can do a single byte PUSH/POP.

[ketmar]

i really want "ex sp, sp'" instruction. having two stack pointers and 4ts (ok, even 8ts) way to switch between them is something any Forth programmer always deaming of! ;-) (unless we can use any register as stack pointer, of course.)

[AndyC]

DEC SP/INC SP are silly instructions too. It would be loads better if it decremented/incremented by 2, changing by 1 has no use I can think of, since you always push a word to the stack. If it incremented by 2 it would just be like discarding the value on the top of the stack (I usually use POP AF for that or another unused register pair but sometimes you want to keep A or the flags around).

I think they probably just fell out of the way the 16-bit increment instructions were encoded, rather than being an active choice per se. Changing it to increase by 2 each time would probably also have complicated the design somewhat.

[RST#08]

See here, particularly pages 6 and 9:
https://archive.computerhistory.org/res ... .05.01.pdf

Some folks might also be bemused by Shima's comments on p.10, too, regarding IXL/IXH etc.

(In) the new instruction set, the prefix instruction is able to redirect the selection of each register to index register X or Y. And this was our pride for not only (the) 16-bit index register, but also the lower or higher of (the) index register(s). But we didn’t publish that one.

[catmeows]

Well, I really wish Z80 had more addressing modes. Once you try 6809, you see how much time you waste with pointer arithmetic on Z80.
Otherwise, LDI, LDD would be nice without prefix.
And yes, CALL cc are used less than one would expect.
My ideal 8 bit CPU would be mix of 6809 and ZB0, possibly with few things borrowed from 65816.

[1024MAK]

To be fair, the 6809 came along a lot later, and because it was late to the party, and hence not established (so not as cheap) only made it into a small number of computer models.

Yes, it was a good and powerful microprocessor.

Mark

[Inky]

DEC SP/INC SP are silly instructions too. It would be loads better if it decremented/incremented by 2, changing by 1 has no use I can think of, since you always push a word to the stack. If it incremented by 2 it would just be like discarding the value on the top of the stack (I usually use POP AF for that or another unused register pair but sometimes you want to keep A or the flags around).

The Spectrum ROM authors found them useful as single inc/decs - there's one of each in the standard ROM

[sn3j]

It would be cool to have such instructions as NEG HL, CPL HL, SUB HL DE, SUB HL BC etc and without the shift opcode.
They managed to place HALT at the opcode for LD (HL),(HL) so why couldn't they replace LD A,A or LD B,B with something more sensible?
Likewise switch DI and EI with something that's used more often. Compatibility of course might have been an issue.

[PROSM]

Having LD A,A and so on is an 8080 design choice, and the Z80 designers had to keep it that way for compatibility's sake, since they were official instructions. The new Z80 instructions and prefixes replaced the undocumented opcodes of the 8080, which were all alternative encodings of documented instructions anyway.

[AndyC]

Honestly I don't think it's the prefixes I'd be bothered about. If I wanted to tweak the Z80 design, removing the need to re-read instructions like LDIR would've been where I'd go next. And maybe redesign instructions like OTIR to be better suited to a 16-bit IO range (use DE as the destination rather than BC).

Beyond that.putting a full 8 (or even 16) but ALU in there to speed up instructions and things could be massively improved. A barrel shifter would've been nice, but I could live without it.

[catmeows]

Having LD A,A and so on is an 8080 design choice, and the Z80 designers had to keep it that way for compatibility's sake, since they were official instructions.

When Motorola planned successor for 6800, they asked cutomers if they need binary compatibility or if source code compatibilty would be good enough. The answer was that source code compatibility is sufficient. Also authors of 6502 aimed just for pin compatibility with 6800 and came with completely new ISA (and were sued by Motorola so they had to change cpu pin layout). People around Z80 were the most conservative, choosing binary compatibility with 8080.

Honestly I don't think it's the prefixes I'd be bothered about. If I wanted to tweak the Z80 design, removing the need to re-read instructions like LDIR would've been where I'd go next.

As you probably know, that would complicate interrupt handling a lot. On other side LDx, LDxR without prefix would save one opcode fetch (3 ticks), making the instructions much faster and it seems like simple change.
And yes, 8 bit ALU would be nice, though I'm not sure if RLD, RRD instructions would be possible.

[1024MAK]

CP/M became a big thing and certainly helped make the Z80 successful. I don't know if during the design of the Z80 CP/M was considered. But it may have been.

As far as I can recall, the 6502 did not have a direct equivalent to CP/M back then.
There was FLEX for the 6800, and then later on a version for the 6809. But it was not as popular as CP/M.

Mark

[Cosmium]

Well, I really wish Z80 had more addressing modes. Once you try 6809, you see how much time you waste with pointer arithmetic on Z80.
Otherwise, LDI, LDD would be nice without prefix.
And yes, CALL cc are used less than one would expect.
My ideal 8 bit CPU would be mix of 6809 and ZB0, possibly with few things borrowed from 65816.

To be fair, the 6809 came along a lot later, and because it was late to the party, and hence not established (so not as cheap) only made it into a small number of computer models.

Yes, it was a good and powerful microprocessor.

Mark

Yeah, the 6809 was a really nice 8 bit CPU.

On the whole though, reading through the responses, most seem pretty happy with the way they (Zilog) did it on the Z80. Not bad for something designed about 50 years ago!