When RAM is at a premium, as it was in the old days, a greater code density of an instruction set can be a substantial advantage.

(Click saver: Code density refers loosely to how many microprocessor instructions it takes to perform a requested action, and how much space each instruction takes up.)

How did the popular 8-bit microprocessor lines (6502, ..., and 8080, ...) compare against one another in that regard? An attempt to look up "6502 vs 8080" or "6502 vs Z80" brings up discussions about clock frequencies, clock cycles per instruction, programming preferences, etc. but not about the code density.

  • An option would be to use some C (for example) cross-compilers and compare the results on a significant program with options turned on for space optimization. 6502.org/tools/lang indicates a port of gcc for 6502, here z88dk.org/forum for Z80. – Michel Billaud Aug 13 '17 at 10:34

An instruction set can be considered as a Huffman coding of an idealised instruction stream. So the question is really asking which CPUs have a good balance of short encodings for common tasks to longer encodings for rare tasks. However, it is not sufficient to just look at the encoding of individual instructions because a RISC instruction generally does less than a CISC instruction, and real-world code need to be considered.

Further, it is possible to increase code density by creating a more efficient virtual machine to execute bytecode, threaded code (not to be confused with modern-day threads), or a variety of other similar techniques. All of these tricks are effectively instruction sets in their own right.

But you're not really asking about the theory, but hard data. The paper that immediately came to mind was Code Density Concerns for New Architectures (Citation, Presentation, Paper). It is more biased towards modern architectures, but it does include the Z80 and 6502 in (some of) its results.

You can intuit the likely results for similar retro CPUs: the 8080 is a subset of the Z80 so will be less dense. Likewise the 8088 is a subset of modern x86 and also less dense and arguably not really an 8 bit CPU anyway, or we could just include the 68008 or 65816.

To crudely summarise the paper's results: Modern x86 tends to be the most-dense code; CISC, ARM Thumb, Z80 and the embedded-optimised CPUs are a close second; RISC and 6502 are a respectable third (many don't think of the 6502 as being RISCy!), and Itanium and Alpha come in a poor fourth. If you ignore the Itanium outlier, there's only about a factor of 1.5 difference between all the CPUs tested.

So if you're looking for a (popular) retro CPU with the absolute-highest code density, you want the Z80.

  • It would be interesting to see where Z80 and 6502 derivates like the 65816 or Z180 series went with regards to code density. Both included a number of new and useful instructions besides simply widening buses and adding on-chip peripherals. – tofro Aug 13 '17 at 9:31
  • 5
    Now thats a very interesting paper. Thanks a lot. Reading it, I'd be careful in interpreting too much, as the 'hand optimized assembly' sounds more as it is. Looking at the 6502 version it seams that the coder wasn't realy using teh 6502 ISA. I know it's not easy for everyone, but when switching architectures, the way of thinking also needs to be changed. /370 works different then 6502 sounds trivial but is fundamental.We might need more research here. Still. Cool find. – Raffzahn Aug 13 '17 at 10:35
  • 1
    @tofro the 6502 and the Z80 are very different beasts. The 6502 has short instructions for operating with the $00-$FF memory page, and only three registers, and the Z80 has more registers and 16-bit operations. The Sargon programmers thought the 6502 nicest for chess. – Thorbjørn Ravn Andersen Aug 13 '17 at 15:37
  • why does Itanium lost in the comparison? I believe it packs even more than MIPS (which waste at least 5 bits in most [if not all] R-type instructions) – phuclv Aug 14 '17 at 3:36
  • 2
    @LưuVĩnhPhúc, Itanium theoretically packs three instructions into 128 bits, so it's inherently lower-density than anything but the CISC instruction sets. Density is then reduced further because of limitations on which instructions you can pack together (eg. a bundle can't contain more than a single FPU instruction, and you can't pack two instructions that depend on each other into the same bundle). – Mark Aug 15 '17 at 0:27

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.