Looking at the development and architecture of the Z80, it appears to be a scaled-down, cost-reduced (in terms of total system cost), clone of the Intel 8080. It only used a 4-bit ALU. I assume this would have reduced its performance considerably.

However, the Z80 out performed the Intel version and nearly displaced it completely in the CP/M market. How did Zilog design their ALU to both out-perform and save cost?

Clarification: Put slightly different, the Z80 performs 8080-alike operations in the same number of cycles whilst having an ALU that operates on half as many bits per cyle. How?


Possibly a simple logic trick. The slow path in addition is carry propagation (not the individual half-adders). You can thus often double the clock rate by pipelining the carry. If you pipeline the carry, then you can reuse the bit adders at the beginning of the chain, and put them at the end. Depending on the ratio between pipeline registers, reuse muxes, and ALU logic gates, this trick can allow a savings in total gate count (die area, cost), as well as increasing the max clock rate (for a given technology level). Or you can just take one or the other potential advantage.

(A similar trick used on entire instruction sets is one path to the philosophy of parallel pipelined RISC architectures.)

(Also possibly related is that common practice in minicomputer logic design in that era was often done with 4-bit 2901's or 4-bit slice 74xx181 ALU's, with separate carry lookahead logic.)

  • This interview with Faggin has him talking about what sounds like pipelining in the z80, related to data propagation on the internal bus - archive.computerhistory.org/resources/text/Oral_History/… – Brian H Feb 16 '20 at 22:50
  • 4
    Fun fact: Pentium 4 used the same (or a similar) design: double-speed 16-bit ALUs (to implement an ALU that handled 8/16/32-bit operand-size), yes really even though the main clock speed was already super high (for the time / transistor size). Pipelining allowed the execution of two dependent ALU instructions in the same clock cycle on P4 Northwood. (This changed in Prescott, probably to enable 64-bit Nocona). Was there a P4 model with double-pumped 64-bit operations? has some diagrams and links. (@BrianH: in case you're interested, too.) – Peter Cordes Feb 17 '20 at 5:23

... a scaled-down, cost-reduced, clone of the Intel 8080.

The Z80 had a massively extended instruction set, featured more addressing modes and had more registers than the 8080.

It also had a built-in DRAM refreshing logic.

... and it was more expensive than the 8080!

This is the opposite of "cost-reduced".

It only used a 4-bit ALU. I assume this would have reduced its performance considerably.

Obviously the 8080 was not designed in an "optimal" way; as far as I have read the tables correctly, the 8080 needs the same number of cycles as the Z80 for most instructions.

Therefore, a program written for the 8080 will run with the same speed on the Z80.

However, a program written for the Z80 (if no 8080 compatibility is required) would use the additional instructions and addressing modes of the Z80.

Replacing 4 or 5 8080 instructions by a single Z80 instruction will of course speed up the program.

  • But much of the software that ran on Z80 machines also ran on 8080. I suspect many people writing for CP/M chose to not abandon the 8080 machines still in use. – WGroleau Feb 17 '20 at 17:01
  • 2
    @WGroleau You forget that most Z80 computers did not run CP/M as main operating system: There was a lot of software for the Spectrum, the Amstrad CPC or MSX machines. This software would not run on any other machine anyway. And the main reason why the Z80 was popular seems not to be the speed but the price: The CPU itself was more expensive than the 8080 but the circuit needed around it was much cheaper than the circuit required for an 8080. – Martin Rosenau Feb 17 '20 at 20:13
  • CP/M machines were mostly used by "business" users. Spectrums and similar came late in the game and were much cheaper (no disk drive) and sold to home users. Yep, the Z80 had a higher level of integration and all CP/M software either used only 8080 opcodes or (rarely) had some sort of fat binary installer to optionally use Z80 functionality. – Rich Feb 18 '20 at 1:16
  • @MartinRosenau, I didn’t forget it because I never knew it. But it doesn’t matter —OP specifically mentioned CP/M. – WGroleau Feb 18 '20 at 6:16
  • @WGroleau I understood the OP's question the way that the words "in the CP/M market" are related to the sentence "it nearly displaced the 8080" but not to the sentence "it outperformed the 8080". – Martin Rosenau Feb 18 '20 at 6:30

Why did the Z80 with 4-bit ALU out-perform the fully 8-bit Intel 8080?

Did it? I guess this depends on what 'performance' meant here.

  • If it's about instructions per clock, then No. They are, for all practical purposes, identical.

  • If it's about reaching higher clock speed, then Yes.

  • If it's about an increased instruction set, then as well Yes.

  • If it's about sales, then at best a Maybe.

  • If it's about usage in cheap home computers, then most definitely Yes.

So, I guess it would help to know what should be considered 'out-performing'.

Looking at the development and architecture of the Z80, it appears to be a scaled-down, cost-reduced, clone of the Intel 8080.

True. That and a greatly improved interrupt handling - like the majority of microprocessors at the time it was designed for embedded application; having the fastest interrupt handling at the time, combined with full code (and large hardware) compatibility and optional higher clock speed was a killer USP.

It only used a 4-bit ALU. I assume this would have reduced its performance considerably.

That's the fun part, as it doesn't. Using a half-sized ALU, while staying within the 8080 timing is another optimization. This was possible as Frederico Faggin figured out a way to stay within 8080 timing (which he had to do) but saving on half the ALU.

Changing ('improving') instruction timing was neither a goal, nor would it have been of any help, as it would not have resulted in any speed improvement. At least not without requiring faster memory as well. A no-go when intending to build a cheaper chip.

However, the Z80 out performed the Intel version and

Again, this needs a definition of what out-performing should mean.

nearly displaced it completely in the CP/M market.

True. But while the CP/M market is quite visible, it was always only a tiny fraction of the CPU market. The true market in which Intel and Zilog were competing was about embedded systems, were Intel had a very strong hold.

Also, the dominance of the Z80 here was due less to higher performance, but rather to lower cost. The chip itself was lower priced than Intel's 8080/85 and it needed fewer support chips. Both were very important factors in the extremely cost-sensitive market of small/home computers. For embedded, both factors play a lesser role. Here, not only are the margins way higher, but also long term-supply reliability defines products - a card Intel played quite well until 486 times.

How did Zilog design their ALU to both out-perform and save cost?

The ALU did not out-perform: instructions executed equally fast. This saved money due to lower production cost. It's also important to keep in mind that halving the ALU was just a tiny part of savings.

Bottom line: It was all that was needed to stay on par with the 8080.

Clarification: Put slightly differently, the Z80 performs 8080-alike operations in the same number of cycles whilst having an ALU that operates on half as many bits per cycle. How?

Essentially by using a 4 bit wide (on entry) deep pipeline, aka a set of two 4-bit latches. Ken Shirriff did a good writeup of the internal structure of the ALU and how it's integrated. There is also a great answer on Electronics.SE.

  • 1
    "fastest interrupt handling"? I think you meant faster interrupt handling, because the 65C02 (when using WAI) could enter an ISR in just 1 clock cycle! That's 1uS for a 1MHz 65C02 and so would be even less than that for a faster part. Good luck getting even relatively modern processors to respond that quickly. – Glen Yates Feb 17 '20 at 16:56
  • 1
    One answer says it costs less; another says the opposite. A citation for either would be nice. – WGroleau Feb 17 '20 at 17:03
  • @GlenYates Well, using WAI isn't interrupt processing, but stopping the CPU. The Z80 does the same with HALT (just several years before the C02 was done). This is a very special situation, were a system waits for a single signal, unable to do anything else. Interrupt processing is about doing this while working on a main/foreground task. Here over all interrupt response time/overhead is the relevant metric. By allowing seperate vectors for each interrupt source, as well as the mentioned register swap, which avoided any costly stack operation, the Z80 did get a good headstart. – Raffzahn Feb 17 '20 at 20:50
  • The 4-bit ALU stays within a cycle of the 8080 timings for 8080 instructions, but often imposes a penalty of two or more cycles for the new instructions on the Z80. Did Frederico Faggin coordinate his efforts with whoever was designing the instruction set? – supercat Feb 17 '20 at 23:39

I'm not familiar with the 8080's internal design, but the Z80 had, in addition to a general-purpose four-bit ALU, a separate 16-bit limited-function ALU (operations limited to adding or subtracting one) which sat on a 16-bit bus with all of the registers. In addition, a few of the 16-bit registers like PC and SP were isolated from the rest of the registers by a set of pass gates, which meant that the 16-bit ALU could be used to increment PC or decrement SP at the same time as other operations involving other registers were processed by the four-bit ALU.


Forgive me if this is a repeat, but I didn’t see it mentioned.

If 8080 compatibility isn’t needed, the ability to swap an entire register set instead of using a stack makes context switching faster, especially for an interrupt service routine.


If Frederico Faggin had anything to do with the examples in the Z80 manual then I'd say he was responsible for more optimisations than just the ALU. The example code for performing a multiplication (not available in an instruction) used a bit shifting algorithm (i.e. binary logic approach) rather than repetitive addition (simplistic approach) reducing the number of additions by several orders of magnitude. It is quite brilliant, although sadly today, it seems too damn obvious. I hate it when you look back at how you were decades ago and can only reflect on how dumb you were rather than appreciate how much smarter you are now. Yeah, that smarts, pardon the pun.

Anyhow, here's the algorithm (with a couple of minor errors in the comments) ... http://cpctech.cpc-live.com/docs/mult.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.