z80 vs 8080... Which to develop in and why? (from a historical POV)

[cj7hawk]

Hi All,

I'm guessing that maybe this thread came up 40 years ago and got done to death back then, probably in a newsletter before online services existed... But the more I sit around CP/M forums, the more I noticed there seems to be two distinct groups in terms of development - The 8080/8085 developers and the z80 developers, with the z80 developers either coming in much later than the 8080 developers and also with anyone coming in to play with the technology in modern times typically defaulting to z80 - I can't recall seeing too many 8080 projects of late, but there's a plethora of z80 projects emerging.

I don't know if my observation is correct, or is affected by bias, since I'm usually working with z80, which may affect what I notice, but it seems that while 8080(5) may be the "universal" language of CP/M due to being the lowest common denominator, that the era post-1980 seems dominated by z80 based cp/m machines, yet they continually used mostly 8080 based assembler in their code and design.

And of course, working with two languages doesn't work well with me coming from z80 - I can somewhat read 8080, but if I translate it to z80, I can read both the code and the programmers intent just fine.

So why didn't CP/M "migrate" to z80 in the early 80's? And why did so much code get written only in 8080 assembler? I'm guessing that a lot of modern people returning to z80 only ever started on z80 on non-CP/M machines like I did, but in writing up a new CP/M in z80, there are clearly elements that benefit CP/M such as the index registers and other additional instructions.

It's not like all 8080 machines were compatible - with a lot of early CP/M machines differing from each other once machine specific differences became relevant to the code...

I'm left curious also why z80 as an assembler language never really took off then in the early 80s when so machine CP/M machines switched hardware from Intel to Zilog. And whether environments built entirely around both CP/M and z80 in other areas - eg, Japan's PC8801 - did go z80 native in their code design.

I would love come historical insight to the 80s era as to what was thought about developing in z80 over 8080 and what kind of thinking drove the outcomes back then.

Regards
David

 

[Chuck(G)]

8085 systems were still around contemporaneously with CP/M 80. Anything that would run on an 8080 will run on a z80. The feeling was that z80-specifc code didn't really give a significant performance advantage. Also, many, if not most of the bread-and-butter commercial packages (e.g. Wordstar, Multiplan, SuperCalc, DBase II, Microsoft dev tools, etc.) were all 8080 compatible--even m80 in Z80 mode. And with Exxon running Zilog, it wasn't at all clear if Zilog would survive--Intel of course, was a given. Back in the day, I would only write Z80-specific code if the customer insisted on it, otherwise it was 8080. I knew where my bread was buttered--the fact that 8080 code is Z80-compatible is a selling point.

 

[geowar1]

Being 8080 compatible was only important for commercial software where selling to the widest audience was necessary. All the customer specific code I worked on was always Z80.
An experienced Z80 developer could write code that out performed 8080 code easily.

 

[durgadas311]

Note that there's a difference between "8080 vs. Z80 code" and "Intel vs. Zilog mnemonics". M80 and RMAC both allowed one to use Z80 instructions in an Intel mnemonics mode. As geowar1 noted, there are plenty of performance advantages that can be had from using Z80 instructions. The right programmer can make Z80 code much more compact and performant than 8080 code. It really comes down to the "customer". If you're writing code for a specific platform, like a BIOS and system utilities, it makes sense to optimize the code for that platform's CPU. DRI needed to be platform-agnostic, so they had to write in 8080. But they did provide things like ZSID specifically for the Z80. And there are platforms that require writing code for the CPU, like Z80 interrupt mode 2 or the Z180 20-bit address space.

 

[Bruce Tomlin]

It should be pointed out that Turbo Pascal for CP/M required a Z80, even though it only used the JR instructions.

 

[Chuck(G)]

On the other hand, JRT Pascal ran fine on an 8080.

 

[durgadas311]

So, "language" (as in "assembly language") can mean instructions or mnemonics. When I was first starting out, the company I worked for needed to make the decision on how to write code for Z80 CPUs. After thorough discussions and weighing pros and cons, the clear winner was Intel mnemonics with Z80 macros, DRI RMAC and LINK. Back then, all development had to be done on the target machines and so tools were somewhat limited compared to modern day (where one can compile/assemble/link in Linux). Being an OS vendor, we needed the features exclusive to DRI LINK for building components for CP/M 3 and MP/M, and M80 had a nasty habit of producing REL files that LINK could not handle (so that pushed RMAC, which doesn't do Zilog mnemonics). There are other reasons for preferring Intel mnemonics with Z80 macros, but these technical issues were probably enough on their own. It's easy to disparage that which one doesn't know, but rest assured there are still two camps today for a reason.

 

[DDS]

As flame wars go, this one never got off the ground. The reason is quite simple. Z80 vs 8080 vs 8085 is pitching one set of "Eighters" against another set of "Eighters."

Booooooring.

If you really want to crank things up, you have to pit the "Eighters" against the "Sixers."

;-)
.

 

[Chuck(G)]

I'll add that any programmer worth his salt doesn't care about mnemonics or operand syntax. You learn the toolset and CPU and move on. Intel-vs-Zilog assembly syntax/mnemonics anxiety is for amateurs.

 

[cj7hawk]

I'll add that any programmer worth his salt doesn't care about mnemonics or operand syntax. You learn the toolset and CPU and move on. Intel-vs-Zilog assembly syntax/mnemonics anxiety is for amateurs.

Hi Chuck, I think you've hit the nail on the head with where my question is heading, even with the earlier thoughts about Zilog's stability issues. The architecture clearly grew, and the 8080 and 8085 were out of use by then compared to the z80. By the mid 80s, the clear way forward was 16 bit and the 8086 - I made my final switch in 1986/1987 and never looked back for 35 years.

But to rephrase your statement, which makes a lot of sense, into a question - When the z80 started to replace the intel chips, why didn't the switch to the extended architecture ( I guess you could say it was the additional opcodes/mnemonics) begin to occur across the board?

z80 was being heavily implemented into many of the home PCs of the era and most them them were not CP/M compatible as the lower chip count favored having a ROM permanently wired into low memory and while the 68000 was still a way off, the z80 seemed as it if went into everything, even CP/M machines. The mnemonics definitely reflected the new architectures, and I thought it was interesting that "macros" were the solutions to that rather than programmers moving onto the new instruction set. And it seems like people who were brought up on machines that used z80 and often had inbuilt BASIC learned to program in z80... While CP/M programmers tended to ( and still tend to I think ) follow 8080.

I know I'm in the minority being a z80-only CP/M programmer and a recent one at that.... I can't get my head around 8080 and it still looks alient to me, regardless that I can pretty quickly work out what the instructions do and even though I did a lot in '86 and still do weekly work with MCS51, but with CP/M I just work exclusively with z80, and one thing I noticed early on was that there is very little z80 native CP/M code, either written back in the day in modern times, with the exception of hobbyists who, I assume like me, learned z80 first.

And while it makes sense that many would just stick with what they learned, the hardware architectures nearly fully transitioned to z80.

It's not really an argument I'm making about which is better - I'm just trying to better get my head around why zilog opcodes never overtook intel, and the best explanation I've heard so far was the Exxon one you mentioned earlier.

David

 

[cj7hawk]

As flame wars go, this one never got off the ground. The reason is quite simple. Z80 vs 8080 vs 8085 is pitching one set of "Eighters" against another set of "Eighters."

Booooooring.

If you really want to crank things up, you have to pit the "Eighters" against the "Sixers."

;-)
.

OK, I thought I figured this out, then I realized I didn't, then I thought it was an Octal joke, but then realized it wasn't that either...

So I'm going to ask the question - What is a Sixer? The closest I came was "6 bit cpu" but I can't think of any relevant 6 bit CPUs....

David

 

[durgadas311]

...
It's not really an argument I'm making about which is better - I'm just trying to better get my head around why zilog opcodes never overtook intel, and the best explanation I've heard so far was the Exxon one you mentioned earlier.

David

I think you're missing the point I'm trying to get across. The mnemonics used to write assembly language are independent of whether the programmer is utilizing Z80 instructions or the potential availability of Z80 CPUs. In some (many?) cases the choice is merely one of personal preference. As I tried to point out, there may be other - more technical - factors that drive the decision. Also, there is benefit to organizations/projects of maintaining uniformity and consistency - particularly when multiple developers are involved. Switching between different styles is a good way to introduce bugs and impede progress.

Regarding whether vendors back in the day used Z80 instructions, you perhaps just have not been introduced to them. I've worked a lot with Kaypro's, which are Z80-based and use Z80 instructions extensively. The parts of the OS that come from DRI, of course, are 8080-only instructions. Many of the third-party applications that came with the Kaypro were also written in 8080-only, for the same reason (larger customer base). I've run across many other systems where the platform-specific code uses Z80 instructions. Much of the source code has been lost, so there's no way to tell whether Intel or Zilog mnemonics were used.

 

[jlang]

In my mind the great divide was:
programming for CP/M you used 8080
not programing for CP/M you used zilog

Early in my career I applied for a job programming (assembler) They were looking for a Z80 guy.
I was a 6800 guy. The interviewer said you start in two weeks and handed me the Mostek z80 programmers guide
and the reference card.

The point is if you program in assembly it doesn't matter much what mnemonics you use it's about knowing how to program.
I can't count on two hands the number of different assemblers i have used. (>20)

joe

 

[BillGee]

So I'm going to ask the question - What is a Sixer?

6800, 6502, 6809

Around 1980, First Texas Savings aired a TV spot featuring three masked thugs and the theme, "we will help you beat the 80's." I would joke that those baddies were 8080, 8085 and Z80 as I was mostly a 6800 and 6809 guy at the time.

 

[BillGee]

Note that there's a difference between "8080 vs. Z80 code" and "Intel vs. Zilog mnemonics". M80 and RMAC both allowed one to use Z80 instructions in an Intel mnemonics mode. As geowar1 noted, there are plenty of performance advantages that can be had from using Z80 instructions. The right programmer can make Z80 code much more compact and performant than 8080 code.

The feeling was that z80-specifc code didn't really give a significant performance advantage.

With a few exceptions like the alternate register set, the "new" Z80 instructions were slow for what they did, mostly due to the cost of fetching an additional opcode byte. The cost to get an address into an index register sometimes negates the benefit of using them.

Many CompuPro machines were based on the 8085 and the classic Altair and IMSAI the 8080, so do not exclude them if you can avoid it.

It should be pointed out that Turbo Pascal for CP/M required a Z80, even though it only used the JR instructions.

It uses the alternate register set extensively for floating point operations. It also makes heavy use of "adc HL,DE" and some of the bit fiddling instructions.

More detailed discussion here: https://forum.vcfed.org/index.php?threads/turbo-pascal-can-it-be-set-up-to-compile-into-8080.77676/

 

[BillGee]

z80 was being heavily implemented into many of the home PCs of the era and most them them were not CP/M compatible as the lower chip count favored having a ROM permanently wired into low memory and while the 68000 was still a way off, the z80 seemed as it if went into everything, even CP/M machines. The mnemonics definitely reflected the new architectures, and I thought it was interesting that "macros" were the solutions to that rather than programmers moving onto the new instruction set. And it seems like people who were brought up on machines that used z80 and often had inbuilt BASIC learned to program in z80... While CP/M programmers tended to ( and still tend to I think ) follow 8080.

For CP/M work, if the decision was made to produce a program compatible with the 8080/8085, there is a distinct advantage in sticking with 8080 mnemonics - you cannot accidentally use a Z80-only instruction.

When Intel made the transition from the 8008 to the 8080, they decided to stop using mnemonics which encoded the registers used. For example, "lad" became "mov A,D"

Many said that code written the new way was easier to read. The assembler had to be more complicated though.

The Z80 instruction set took that a step further, eliminating different mnemonics for different addressing modes. There remained some glaring inconsistencies such as "sub D" versus "sbc A,D" "add A,D" and "adc A,d"

 

[Chuck(G)]

And almost all Z80 assemblers are not exhaustive in their mnemonics; that is, they don't include the variations possible when using prefixes in non-official combinations. It's hard to say if Zilog simply decided that "enough is enough" or specifically sought to include such things as accessing the left and right halves of the IX and IY registers.

The official position in projects that I've worked on with the Z80 is that unless you have control over the entire system (not using someone else's OS or drivers), that it was strictly "no me tangere" with the alternate register set. The idea is that the alternate set was used in interrupt processing as a fast context switch.

 

[durgadas311]

...
Many said that code written the new way was easier to read. The assembler had to be more complicated though.

The Z80 instruction set took that a step further, eliminating different mnemonics for different addressing modes. There remained some glaring inconsistencies such as "sub D" versus "sbc A,D" "add A,D" and "adc A,d"

I would argue that the Zilog mnemonics are not an improvement, because the underlying instruction architecture is NOT symmetrical even though the Zilog mnemonics imply that it is. I can't count how many bugs I've found in Zilog mnemonics assembly language code caused by misunderstanding of that lack of symmetry. The Intel mnemonics follow the common assembly language syntax where the opcode mnemonic matches 1:1 with machine opcodes. I would also argue that Zilog could not simply extend Intel mnemonics because Intel (a very litigious company) had copyrighted their mnemonics. Digital Research got away with providing Z80.LIB, which is a natural extension of Intel mnemonics for the Z80, but even DRI had to distance themselves from that.

 

[Chuck(G)]

I've long wondered why Zilog chose parentheses in its addressing modes rather than brackets. It kind of closes the door to more complex assembly-time expressions.

 

[BillGee]

The 6502 and 68000 also had this problem with their indirect modes. My guess is that teletype machines and early terminals do not support '[' and ']' characters.

The best way to handle this is for the assembler to expect an indirect addressing mode specification when it encounters a '(' instead of trying to evaluate an expression. If a complicated constant is desired, the assembler can be easily persuaded:

    ld  A,0+(W+X)*(Y+Z)     ; Load a constant