11

A lot have been said in the internet about the 6502 at 1MHz being roughly equivalent in performance to the Z80 at 4 MHz. Is said that the Z80 have a typical 4 clock ticks per instruction while the 6502 have typical 1 clock ticks per instruction and a rudimentary pipeline. Is said that the Z80 ALU internaly is 4 bits when the 6502 ALU is 8 bits. It is said that the z80 access memory every 4 clock ticks while the 6502 access memory every 2 clock ticks. My question: Is that true that the 6502 at 1 MHz is equivalent in performance to the Z80 at4 MHz? Is there any pratical evidence of this claim? Please consider only the Microprocessor performance, not the system build around it.

  • 1
    There is not a single 6502 instruction that operates in 1 tick. I think you mean to compare a 2Mhz 6502 and a 4Mhz Z80. – Tommy Feb 13 '18 at 21:42
  • 1
    Check the Ultimate Benchmark pages for real life data. – Raffzahn Feb 13 '18 at 21:43
  • "Practical evidence" and "don't consider the system built around the CPU" seems a bit contradicting... – tofro Feb 14 '18 at 10:36
  • This question has got excellent answer comparing directly 6502 and Z80. The former question is broader and no its answer contains such thorough comparison of 6502 vs Z80. – lvd Feb 14 '18 at 14:09
  • 1
    @tofro Perhaps asker wants to compare systems where the only difference is the ISA, such as a CreatiVision (6502 + TMS9918) vs. a ColecoVision (Z80 + TMS9918), or where the video/audio architecture is otherwise very similar, such as NES vs. Game Boy. – Damian Yerrick Nov 3 '18 at 15:05
13

Both processors are cacheless. So the process is fetch instruction, decode instruction, execute instruction, forget what you saw. That provides a first line of comparison.

The Z80's fastest memory fetch — the first half of an operation fetch — takes two cycles. That's always paired with another two cycles for refresh though, so the shortest instructions are four cycles long. Reads and writes that occur because the opcode tells them to generally take three cycles, though they're not always issued instantaneously.

E.g. compare PUSH or POP: the former writes two bytes to the stack, the latter reads two bytes from the stack. But because the Z80 stack predecrements, PUSH takes 11 cycles (two to read the instruction, two for refresh, one further because it hasn't yet worked out what the new stack pointer should be, then three to write the first byte and produce the next stack pointer, and three to write the second) whereas POP takes only 10 (four to get to the action, then three to read from the already known stack pointer and calculate the next followed by three to read from the next and calculate the final).

The 6502's memory cycles always last half a cycle. It does only one per cycle, leaving the bus unattended for the other half. But it always fetches at least two bytes per operation: it reads an operand regardless of whether the instruction needs one. If the instruction didn't need one, that read was wasted — it doesn't repurpose the operand it didn't need as the next operation and somehow save an access cycle.

Therefore the shortest instruction is two cycles long. Exactly half the shortest instruction of a Z80.

The 6502 also isn't always actually ready for the next memory access cycle after receiving the prior. In that case it'll do a read or write that it believes to be redundant. So it has less granularity in buying itself pauses in bus access. An example is anything read-modify-write. The 6502 will read, then perform a redundant read or write cycle of the original value while calculating what the result should be, then write.

Which ends up being 'faster' then depends on the specifics of the instruction stream but if they were fetching the same number of follow-up bytes then you'd expect the Z80 to be worse than twice as slow because its follow up accesses take three times as long as the 6502's.

In practice skilled Z80 programmers expend a lot of effort trying avoiding memory accesses by using its much deeper register set; the 6502 almost practically has a three-or-more cycle minimum because a lot of the time is spent shuffling things back and forth between the zero page.

So the 6502 tends to end up being a bit less efficient than a Z80 that is clocked twice as fast.

  • 1
    Doesn't NMOS 6502 actually make two writes (first unchanged value, then correct one) in read-modify-write commands? Later in CMOS 65c02 that was fixed to two reads, then write. – lvd Feb 14 '18 at 14:07
  • 1
    ...it fetches the low half of the operand, adds X to it while fetching the upper half, and then outputs an address formed from the result of the add and the newly-fetched byte while it adds 1 to the newly-fetched byte. If needed, it will then form an address using the previous low byte and the newly-computed high byte. Quite a clever design, actually. – supercat Feb 14 '18 at 16:08
  • 2
    Code written to exploit 6502's strengths, especially its (zp),y addressing mode, is generally faster than decently-written code on a Z80 running at twice the clock rate. One perhaps-extreme but practical example was my BTP2 music player, which uses 184 cycles out of every 304 to perform four-voice wave-table synthesis. In those 184 cycles, it uses the (zp),y addressing mode 20 times, using a different address every time. Doing the same on the Z80 would have taken about 468 cycles versus 184. On a more typical note... – supercat Feb 14 '18 at 16:16
  • 1
    ...even though the Z80 includes a memory-move LDIR instruction, that would take 84 cycles for each 4 bytes; a 4x unrolled loop on the 6502 could do the job in 41. – supercat Feb 14 '18 at 16:18
  • 1
    @supercat: the proper 6502 equivalent, limited to a 256-bute run would be STA abs, x; DEX*2. Which I make at least 20 cycles. Not 5. About four times as slow. You're writing two bytes and updating the pointer. But this discussion can recur indefinitely. There's an endless supply of things one processor can do much more easily than the other. Neither ends up at a complete advantage. – Tommy Feb 14 '18 at 18:35
4

These UCSD Pascal benchmarks of an Eratosthenes Sieve Prime Number Program show that the 6502 is roughly 2x as efficient per clock cycle as the Z-80, 8086, and 8088.

For posterity, here's a partial list of the results:

System          Time (sec)  MCycles  Notes
------          ----------  -------  -----

Sage II         57          456      (68000 at 8 MHz)

NEC APC         144         705.6    8086 at 4.9 Mhz  extended memory

JONOS           162         648      (pretty good for a 4 MHz Z-80A)
NorthStar       183         732      (Z-80 at 4 MHz)
OSI C8P-DF      197         394      (6502 at 2 MHz)
H-89            200         800      (4 MHz Z-80A)
IBM PC          203         938.31   (4.77 MHz 8088)

Apple ][        390         390      (1 MHz 6502)
H-89            455         910      (2 MHz Z-80)
  • 3
    I don't believe in any high level languages based benchmarks. Especially when comparing old compilers/pcode executors/etc. Because then also compiler and (if any) intermediate code executor comes into the equation, changing the end result in an inpredictable way. – lvd Feb 14 '18 at 14:11
  • 1
    @lvd That's true, but if the high level language provides exactly the function you need (like GetNextPrime()), then it's easily optimized on both platforms and then performance is dependent on the hardware again as much as in a low level language. (Not that it applies here...) – snips-n-snails Feb 14 '18 at 16:24
  • 4
    @lvd - note that UCSD Pascal is bytecode-interpreted, so you can really say that the comparison here is to the performance of the handcrafted bytecode interpreter, not the compiler, as the compiled code is identical for all tested CPUs. – Jules Feb 14 '18 at 18:46
  • 1
    Also, the byte code interpreters were more effectively translations of an earlier interpreter, rather than a clean room rewrite to spec. The various P-System interpreters are quite similar in architecture. In the above chart, outside of any system specific stuff (i.e. graphics), those are all running essentially identical interpreters, especially for each processor (all the Z80 are the same, all the 6502 are the same). The implementations were not particularly sophisticated by any stretch of the imagination. – Will Hartung Feb 16 '18 at 0:56
2

Many operations on the 6502 take fewer cycles than corresponding operations on the Z80; the ratio tends to be somewhere between 2:1 and 4:1. The 6502 particularly excels at accessing data structures which 256 bytes or less; operations which cross page boundaries will often be slightly less efficient than those which don't, but code which will work across page boundaries will generally only incur a penalty if operations actually span page boundaries, while Z80 code that works across page boundaries will incur a major penalty in all cases.

Given a byte "index" stored at an arbitrary memory address, if one wants to access the index'th byte of "table", the 6502 code would be:

ldx index
lda table,x

Nine bytes if the indexing operation crosses a page boundary; eight if it doesn't. Subtract 1 if "index" is stored in the first 256 bytes of RAM. On the Z80, if the table is page-aligned, and if the address of "index" happens to be in HL--rather favorable assumptions--one may be able to get by with something like:

ld  d,tableH
ld  e,(HL)
ld  a,(DE)

in 21 cycles. If neither condition applies, but there's no need to keep the value in A and the table is guaranteed not to cross a page boundary, code would be something like:

ld  a,(index)
add a,tableL
mov e,a
ld  d,tableH
ld  a,(DE)

the total would be 41 cycles. If the Z80 code had to accommodate page crossings, it may as well use a 16-bit index, and then the code would be:

ld  hl,(index)  -- Use a 16-bit index
ld  de,table
add hl,de
ld  a,(hl)

which would be 16+10+11+7=44 cycles.

The 6502 is not terribly efficient at working with objects larger than 256 bytes, but many applications use primarily smaller objects.

  • 1
    @Tommy: There aren't very many operations where the Z80 doesn't take at least twice as many clock cycles as the 6502, but since Z80 machines are usually run at clock speeds which are more than double the 6502, the overall performance of a typical Z80-based computer may be slightly better than that of a typical 6502-based computer. I would expect a C compiler for the Z80 would have a bit of an edge over one for the 6502, but that's because C doesn't have ways of expressing the constructs that help 6502 programs be efficient. For example... – supercat Feb 15 '18 at 15:28
  • 1
    ...the most efficient way to store an array of thirty 16-bit values on the 6502 is to use thirty consecutive bytes to store the lower half of each value and another thirty consecutive bytes to store the upper half. I don't have as much experience with the Z80 as the 6502, but I think I have a pretty good sense how to do things efficiently on it. The fact that every memory fetch takes 3-4 times as long on the Z80 as on the 6502 means that a Z80 program would have to avoid a lot of memory fetches not to need twice as many cycles. – supercat Feb 15 '18 at 15:39
  • 2
    No-one writes code like this on Z80, your example is just not particularly illuminating. You don't have enough registers on 6502, so you often have to read index from memory; index will almost always be in a register on Z80, which will save about one third of the total time in your examples. I can produce similarly irrelevant examples of inefficiency of 6502 compared to Z80. E.g. standard table-less multiplication by a constant (8bits*8bits->16 bits) could be done much more compactly on Z80. So what? – introspec Feb 15 '18 at 15:53
  • 1
    @supercat I still disagree with the conclusion, but I think we've covered that. I just think your answer should actually state something like "there are few examples where the Z80 is faster" if that's your argument. I'll add on the register question as per Introspec: for the same completely flat framebuffer, with dynamic modification used on the 6502 to try to do as well as possible, my little quick attempt produces 34.5 cycles average for a Z80 Bresenham versus 30.5 for the 6502, an atypical disparity because it's a real-world example of something that fits into the Z80's registers. – Tommy Feb 15 '18 at 16:26
  • 1
    @introspec: The inner loop I gave would generate a 16-bit result, since the carry from the adc would flow into the next rol instruction (it would simply need one final rol at the end to grab the last bit). The only slight ickiness is that would actually compute p*(q+1) because the adc would be executed with carry set, but that could be adjusted for easily enough. – supercat Feb 15 '18 at 17:29

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.