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.
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.
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.
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)
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.