6502 can be faster than 68k :-)

[BigEd]

I suppose you're saying that load and store have a cost? It's true, but there's a cost to spilling and filling when you don't have enough registers for the task in hand. More registers means less time spilling and filling - which is a greater win when memory accesses take longer than ALU operations. On the other hand, more registers means a greater cost to interrupts - unless you have a shadow set for the purpose, as the Z80 and ARM do. And then we get into discussions about re-entrancy of interrupt handling code...

CPU architecture is all about tradeoffs and cost limitations, with different choices leading to different products. Don't forget that the 68k has more than 10x the number of transistors compared to the 6502, and that's without any cache.

Cheers
Ed

[Aaendi]

I've seen a lot of faulty comparisons between the 68000 and the 65816 where people have compared memory-memory math on the 65816 to register-register math on the 68000.

[Aaendi]

The 68000's speed was a self-fulfilling prophecy, due to how popular the chip was. It was fast because programmers thought it was fast, when other CPUs could've had similar performance if programmers made as much effort speed-coding them as they did with the 68000.

[yzoer]

Wow.. Been a while since I last posted here

Given I've moved to a different state and changed jobs, I haven't been able to do much on the hardware side. That said, I've had enough 'thought' time to run a bunch of scenarios in my head. Most of the discussion here, which I had to re-read in its entirety, made the valid point that the application pretty much determines which CPU is probably your best fit. Since my application could probably be boiled down to being a simple process controller, I feel the 68k8 is the best fit... for now

Still looking at the 65816 though.. I also bought the WDC tools but have yet to analyze the output. My best guess is that it has a virtual machine of sorts a la sweet16.

Yvo