My own experience comparing the performance of the 6502 to the 68008 is that the 68008 can do the same work with about 1/2 the cycles. But it really depends on the workload. The large number of registers available with the 68K and the number of reg to reg operations including division and multiplication can really speed your app up (and yes I've compared it to 6502 zero page performance). 68K also has some advantages with multiprocessing. Lastly compilers for the 68K produce more efficient code vs. those for the 6502, i.e. if you use compilers.

While you can get 6502's at 14MHz, you can still get 68K's at 20MHz (http://www.freescale.com/webapp/sps/sit ... rch=1&sr=4).

IMHO, for simplicity nothing matches the 6502 (or the 6800/6809). The 6502 will be more "fun". There's the "cool" factor as well. Wonder what Hz Bender's 6502 runs at.

Yes, but...

1. The discrete form of the W65C02S readily operates at 20 MHz, as does the W65C816S. ASIC forms of the 65C02 have run at speeds up to 200 MHz, far beyond what the fastest versions of the 68K family could do.
2. Standard tests, such as the Sieve, suggest that the 68K does no better in integer addition and subtraction at any given clock speed than the 65C816.
3. The 68K's interrupt latency is terrible, making even a 1 MHz NMOS 6502 look downright lively in comparison.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

This is kind of a bad comparison, IMHO.

It's like comparing a submarine with a Ferrari, and saying the Ferrari is better because it's faster.
However, if you're trying to cross an ocean, the effective speed of the Ferrari is zero.

Or comparing a DSP against a CPU, and saying the DSP is "better" because it can issue more multiply-accumulates per clock cycle.

The 6502 is good for some things:

1. Minimizing the number of gates used
2. Low interrupt latency
3. Better code density for 8-bit tasks

If these are important to you, then the 6502 is clearly "better".

The 68000 is good for other things:

1. Reasonably good compiler target
2. Better code density and performance for 32-bit tasks
3. Applications which require a large amount of memory (24-bit address space)

They're very different processors, and trying to directly compare them is silly IMHO.

Toshi

You're right.

That said, I merrily came across the integer performance when I was trying to decide which way to go. While the 6502 is still readily available, the 68008 never made it to CMOS AFAIK and is as rare as hen's teeth.

But yes, for 'proper' applications, the 68k series would be better. For smaller projects, the 6502 is the clear winner IMO. It's also faster than a z80, but that's a different story

-Yvo

68008 @ http://octopart.com/mc68008p8-motorola-2269386. eBay has them too. HMOS.

Dammit

I keep hearing good things about the 68K family for compilers and multitasking, but that doesn't mean it's faster at small jobs that are typically written in assembly and don't need a multitasking OS. I was looking at their datasheet at http://datasheet.octopart.com/MC68008P8 ... 112602.pdf and I have a little trouble with their statement, "The performance of the MC68008 is greater than any 8-bit microprocessor," after looking through the instruction timings and seeing that STOP is the only instruction that takes less than 8 clock periods, and most take dozens, up to 72, and exceptions take up to 94, and an interrupt takes 72. Its rated clock speed is less than that of off-the-shelf 65c02's too. I was interested to see how many clocks it would take to do an up-down clock pulse when bit-banging, as I have done on the 6502 & 6522, putting the clock line on bit 0 of a port:


which takes 12 clocks total on the 6502 (10 in the rare situation of having I/O in ZP); but that data sheet does not seem to have enough info to figure it out unless you already know the instruction set (which I don't). I had a big box of 68K documentation (data sheets, ap notes, etc.) that I kept for 25 years before deciding I would never use it so I put it in the recycling last year.

_________________
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?

I guess it comes down to what are you going to do.

The 68K starts to really shine when doing any work on an array (e.g. graphics memory, math, etc...). A single instruction can process 32-bits of data.

Although the z80 Mhz to Mhz is slower than the 6502, it was preferred over the 6502 for most 8-bit coin-op video games because of the 2nd set of registers used for interrupts.

6502 was/is a clear winner for ease of use and cost (at least in the '70s).

Without a clear understanding of the workload it's hard to prefer one over another.

Garth,

I'm reading up about the 68k right now, looking at its exception handling model to help me make a few decisions regarding my 65m32 specification. Looking through the instruction set, I don't see any instructions that increment or decrement memory locations directly, but there are the BSET and BCLR instructions, that can set and clear an individual bit in memory.

Looking at the timings, it seems that the fastest way would be to load the address into an An register and the bit number into a Dn register. Then, the BSET/BCLR pair would consume 24 cycles total, if I'm reading things correctly. You can leave the registers alone, and specify the exact bit of the exact address that you want to twiddle inside the instructions, but that would total 40 or 48 cycles, depending on whether you're using short-absolute or long-absolute addressing.

Mike

[Edit: It looks like ADDQ #1,(An) and SUBQ #1,(An) would also work, removing the need for a Dn register, but the best-case timing still seems to be 24 cycles total. The cool thing about ADDQ and SUBQ is that the immediate value can be 1 to 8, so you can twiddle any of the low four bits.]

[Edit #2: If the I/O port address can fit in 17-bits, my 65m32 should be able to inc/dec in six cycles total; otherwise, it would be eight.]

The Z80's 2nd set of registers for interrupts is nice until you need to nest interrupts. Then it loses its value.

The 32-bit stuff is why we were talking about the 65Org32, and why Mike is working on his 65m32. When you need the big values, a 32-bit processor becomes waaaaaaay more than four times as fast as an 8-bit processor of the same type. The 6502 wasn't just faster than the Z80 on a MHz-to-MHz level field though; it was faster even when the Z80 had a clock rate four times as high, and more and wider registers too. But repeating an earlier post:

There were a couple of paragraphs in an article by Jack Crenshaw in the 9/98 issue of Embedded Systems Programming where he talks about different BASICs he used on computers in the 1970's and 1980's, and said the 6800 and 6502 always seemed to run them faster than any other processor. He says that to him, the 6502 was a "near knock-off" of the 6800, and says he liked the 6800 architecture far more than that of the 80 family, even though his work made him much more familiar with the latter. Quoting two paragraphs:

"To me, the 8080 and Z80 always seemed to be superior chips
to the 6800 and 6502. The 8080 had seven registers to the
6800's two (plus two index registers). The Z80 added
another seven, plus two more index registers. Nevertheless,
I can't deny that, benchmark after benchmark, BASIC
interpreters based on the 68s consistently outperformed
those for the 80s.

"The biggest problem with the 68s was that they had no
16-bit arithmetic. Though the 8080 and Z80 were basically
8-bit processors, at least they had 16-bit registers (three
for the 8080, eight for the Z80), and you could actually
perform arithmetic in them, shift them, test them, and so
on. You couldn't do any of these things with the 6800 or
6502, which is one reason I still don't understand, to this
day, how the 68s could outperform the 80s in benchmarks."

After learning the 6502's instruction set and bus usage, I remember being impressed by the relative inefficiency of the 80 family, including the number of clock cycles it took to execute a single instruction, and how many extra instructions were needed because it did not have things like the 6502's automatic decimal arithmetic with the D flag, and the compare-to-0 implied in all logical, bit, arithmetic, and load instructions.

I don't know why he says, "You couldn't do any of these things in the 6800 or 6502" though. Sure you could.

The 80's even at that time though were generally run at 4MHz or a little higher IIRC, and they were still losing to the 1MHz 6502's and 6800's.

_________________
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?

I'm somewhat partial to the 68k series as I wrote a lot of stuff for the Amiga and Sega Genesis. That said, those had full 16-bit busses.

After digging around the 68008 data sheet, the bus-performance is absolutely ABYSMAL compared to the 6502. So while my initial 'hooray!' moment subsided and reality hit, the 6502 is still the clear winner for what I'm trying to do.

To take this back to the original post: An immediate BYTE write to memory on the 68008 takes 28 cycles, whereas an immediate WORD write (the one I cited) takes, wait for it, a whopping 32 cycles! That's TWICE as slow as a 6502 running at the same clock-speed.

So that's pretty unacceptable for me. Basically anything that goes out over the bus is going to make the thing crawl. Sure, multiplies and divisions and register-to-register moves are the same as a stock 68k, but a lot of that's offset by the cost of reading / writing to memory. Oh, and interrupts take a minimum of 44 cycles + whatever registers you have to move to/from the stack which of course, touch memory.

-Yvo

Sounds like a lot more than twice.

_________________
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?

Heh, yeah.. I just realized that was twice as slow as a 68k with a 16-bit bus and more than THREE times slower than a 6502 writing a 16-bit immediate value.

-Yvo

I've been away for a while, is there a 65Org32/65m32?

I wonder how much that has to do with the BASIC implementation. I've written benchmarks where a 2MHz z80 outperforms a 1MHz 6502 (but not by much 107 sec vs 114 sec). In both cases the benchmarks are written in assembly and every possible trick is being used to increase performance (e.g. unrolled block copy, using stack pointer for processing arrays, etc...). I do not expect the average BASIC to do the same. But I do expect an assembly programmer to max out performance.

I read a blog post where the blogger said that a 1MHz 6502 was faster than a 4.77 MHz 8088. I wanted to believe him until I read his method. He used the specs and measured the time it would take to fetch, decode, and execute a shift instruction. And if that is all the program was going to do (a *single* shift), then he was right. However if you did a series of shifts the 4.77 MHz 8088 was 2.6x faster than the 1MHz 6502 (when using words not bytes, bytes vs. bytes 8088 was 2x faster).

The point is that one should actually run real code to compare.

BTW, are you looking at the 68008 or 68000 timings? The time to write a byte or word is the same for the 68000.