MichaelM wrote:
Consultants can always determine the processor that the must use in projects.
I presume that you mean
can't there?
Since the Z80 has been mentioned, I'll point out that the Z80 takes something like three clock cycles to perform a memory access (if memory serves, referred to as an "M-cycle"), unless there are wait-states involved, and four cycles for an opcode fetch (an M0-cycle) because it also does something to support old-style DRAMs. Something about providing an 8-bit "refresh" address cycle after fetching the opcode. More fun and games include the limited indirection facilities (already mentioned), specifically only THREE indirect registers available. Assuming that an indirect memory access doesn't involve "prefix" instructions (a further 4-cycle delay), we're looking at 4+3=7 clock cycles for an 8-bit indirect register load. Compare with the 6502's zero-page indirect addressing, and you have 1+1+2+1=5 clock cycles for an 8-bit indirect load... And up to 128 indirect "registers". And the disparity only gets worse as you go into practical code. I know that the NES's (1.7 MHz 6502) win over the SEGA Master System (3.5 MHz Z80) was a triumph of licensing agreements more than anything else, and the SMS video hardware was a bit more capable than the NES, but the NES CPU ran rings around the SMS.
Sometimes, when comparing CPUs, the thing to look at is how long it takes to perform
actual useful work rather than a memory access, or other operation. This will require working out instruction sequences for performing various operations, figuring out how many clock cycles it takes to execute the sequences, and then either assuming equivalent clock speeds or converting to some common unit of measure (such as picoseconds).