Yes, and when the 6502 is also running at 4MHz, divide those 6502 instruction execution times by four. So again, we see that the 4MHz 6502 is faster than the 4MHz 8085. I *REALLY* don't see the problem here, or why you keep insisting that the 8085 is a faster processor. Which brings us back to our original argument: the 6502 makes more efficient use of the bus. Clock for clock, the 6502 can move more data than the 8085. I'm sorry, that's just the way it goes.

BTW:

JSR takes 6 cycles on the 6502, which at 1MHz, takes 6us. A RET also takes 6 cycles, and thus another 6us, for a total subroutine overhead time of 12us. But at 4MHz, we divide this result by 4, giving us only 3us. The 8085, on the other hand, has a total of 7.1us (4.5 for the CALL + 2.6 for the RET). OUCH! The 6502 is more than twice as good at making subroutine calls as the 8085. Perhaps this is why 6502s are the processors of choice for implementations of Forth, which is heavily dependent on subroutine calls.

So much for your assertion that the 8085 has faster subroutine response time than the 6502.

I'll leave the remainder of the instruction timings as an exercise to the reader. You'll find that the 6502's performance is pretty consistent across the board.

Now, I will concede that passing parameters to subroutines in registers is considerably faster than using memory (this is why, for example, the 68000 was able to get the seive done in 0.49 seconds instead of 0.8 or more). But the last I checked, the 8085 wasn't exactly register rich, which means there's going to be a HIGH probability that the parameters you pass in registers will be PUSHed/POPed later, or stored in temporary holding buffers *anyway*. The 6502 avoids all this completely with judicious use of zero-page memory. Thus, while in the local case there might be more data shuffling going on in memory, GLOBALLY there is less. I won't say that the 6502 is faster because of this though, but I will be bold enough to say it'll break even with the 8085. The benchmarks posted above even seem to support this.

Moreover, *EVERY* high-level language I'm aware of for the 8085 uses the stack to pass parameters. The 6502 can treat its zero-page like a stack using the dp,X and (dp,X) addressing modes quite effectively (Forth makes great advantage of this). The 65816 does one better by introducing an explicit stack-relative addressing mode, which the 8085 doesn't have.

The simple fact of the matter is this: if you're going to compare processors, compare them at speed. It is absolutely, mind-numbingly dumb to even consider a 64MHz 8085 when a 16MHz 6502 is available and will do the same job in half the time. Likewise, anyone with basic elementary school mathematics can see that the 6502, clocked at one quarter the speed of the 8085, is running at half the speed of the 8085. A 6502 running at 2MHz, therefore, is competitive with the 8085 across the board, and at 4MHz, demolishes it. You'll note the benchmarks posted above also support this observation.

You must be including CLC before ADC# and SEC before SBC#, because these two instructions on the 6502 take 2 clocks each, not 4.

Although looking at how many clocks per instruction does give an idea of how the processor will perform, the real proof is to have the various processors in the contest do an actual job that's relevant to whoever is interested in the results.

I can't speak about the 8085, but have more experience than I wish on Microchip's PIC16Cxx microcontrollers with their RISC core that's supposedly so blazing fast. So here's an example of what I mean: Take a single-byte table look-up, where the table might be anywhere in memory. The 6502, using LDA address,X, takes 4 to 5 clocks. The PIC, since it has to do things like see if a page is crossed and if so adjust the PCLATH (program counter latch high byte), takes 48 clocks (12 instruction cycles). Both are available to 20MHz, so the 6502 does this one roughly ten times as fast.

Disabling interrupts by setting the interrupt-disable flag on the 6502 takes 2 clocks. On the PIC, if an interrupt hits while it's clearing the GIE (global interrupt enable) bit, its status will be restored after the ISR runs to be what it was before the instruction, meaning you have to try again. So just to disable interrupts, you have to have a loop. If GIE gets cleared the first time through, the PIC will take 12 clocks to do what the 6502 does in 2; so at a given clock speed, the 6502 is at least 6 times as fast.

This might not be very significant if these were the PIC's only two disadvantages; but I can give you a whole pile of them. Taking Microchip's own optimized coding examples, I re-coded many of them in 6502 assembly for comparison and clarification while I was learning the PIC. I found that the 6502 generally takes half as many instructions and half as many clocks as the PIC to do a job. Of course there are a lot of things the 6502 can do that PIC can't do at all, so the contest ends there.

Now, if only there were such an array of 6502-based microcontrollers with the same availability, all the I/O options, easy, inexpensive programming of on-board EPROM, etc. etc....

Garth

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

As is sometimes the case, after I made the last post, I realized I didn't really make the point I wanted to. This time it was about benchmarks. I'll try again.

Suppose a company has a processor they're trying to sell. (Not too unusual.) To make it sound attractive, they'll tout its strengths instead of an overall objective evaluation of how well it will do in your particular application. (Again, normal.) If they have a single-cycle multiply instruction and they see the processor you're using does not, they'll make a big deal out of it, and maybe come up with a benchmark that heavily favors this instruction. They make their product appear to blow the doors off all other processors in its class. However, suppose your embedded control application really has little or no use for a fast multiply instruction; and as you take a harder look at this processor, you find out it has no actual indirect and/or indexed addressing modes (like the PIC), it does not allow any direct access to the stack (like the PIC), that bank-switching and paging will be a constant overhead headache (like the PIC), that interrupt response is considerably slower than what you have (like the PIC), that the limited instruction set means it takes more instructions to do a job (like the PIC), etc. etc.. If you point this out to the manufacturer, they'll get defensive and try to reassert their superiority, again based on the criteria that may be irrelevant to your application. If you don't give in, they'll think you're biased, that your mind is made up, and you won't be bothered with the "facts".

There was something in the electronics industry trade magazines a couple of years ago about lots of companies getting together to develop a benchmark that took many different things into account so it would not be partial to any one company's product. I never heard what became of it. I expect they probably couldn't agree, for the very reasons mentioned above, and they all took their toys and went home in a huff.

So if I obviously hate Microchip's PIC microcontrollers' processor core so much, why do I design PICs into products? Their register and bit names are extremely cryptic, their free simulator is nearly useless, and their data books even have a ton of spelling and punctuation errors that bug me to no end. But I design PICs into products because part of the benchmark is not just the performance of the processor itself. It's the fact that the PICs are inexpensive, offer a lot of choices in I/O and packages, have good on-chip support like watchdog timer, power-up reset timer, brown-out reset, multi-mode oscillator, etc., there are oodles of varieties in stock at so many distributors, they're easy to program on the workbench (even for production), and so on. It doesn't hurt either that Microchip has a free assembler and other good support. But oh how I wish they'd put a 65c02 core in the PIC microcontrollers!

Garth

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Sorry to resurrect an old thread, but the benchmark organization was actually created in 1997.
The first benchmark they did was called CoreMark, and now they have a bunch of benchmarks for various applications. See this URL:

http://www.eembc.org/

I've actually used their ConsumerBench while at Renesas.

Toshi