What's screwed up about cpu speed comparison charts

I just need to say this, please leave the 65816 out of this, because I hate how every technical thread always has to turn into a stupid snes vs genesis war thread.

I've seen a few comparison charts comparing the 6809 to the 68000, and they always make the 68000 look vastly superior to the 6809, then they give a reason why there is such a big difference, and that "reason why" they give always have some very obvious problems to me.

First of all, why do they always compare 32-bit operations? In real programming, 16-bit and 8-bit operations are much more useful because their the more optimal than 32-bit. The only reason why the 6809 sucks at 32-bit operations is simply because it doesn't support any 32-bit registers. If they compare 16-bit operations and 8-bit operations the 6809 would be much faster on charts, and it will be a lot more accurate since 8-bit and 16-bit operations are used much more often than 32-bit.

Secondly, when benchmarking math operations such as add and subtract, they usually compare register to register addition on the 68000 to memory to memory addition on the 6809. Why do they do that, I just don't know? The thing about memory to memory math on the 6809 is that it is actually takes 3 opcodes to do: load accumulator, add accumulator, store accumulator. What if I only need to add something with the value already in the accumulator? What if I'm manipulating the same register twice in a row and so need to store back and then reload it? Then I don't need to use 3 instructions to perform adds to register values. So after all, that makes the 6809 appear slower than it really is.

Instead of using memory to memory adds to benchmark the 68000 the way they do for the 6809, they usually use register to register adds to benchmark the 68000 instead. Sure it can take up a little amount of cycles when your doing register to register, but you'll always are going to need to use external memory values sometime eventually. The memory to register adds are much slower than register to register adds so that makes 68000 appear faster on charts than it actually is.

 

There was a nice article on ars-technica about CPU benchmarks & the relevancy of comparing MIPS, FLOPS, etc... :

http://arstechnica.com/cpu/2q99/benchmarking-1.html

 

The link is not working.

 

hmmm... strange... worked an hour ago...

and this ?
http://arstechnica.com/old/content/1999/04/benchmarking.ars

 

:thumbsup:

 

68000 can do more will less instructions, but it is not as cycle efficient as 65816 is. On a lot of simpler 8 and 16bit bit stuff 68000 will lose, but when you are going to 32bit stuff and things that work on memory directly, 68000 will win. Both CPUs have good and bad points. I still prefer 68K over anything, extremely user friendly CPU, and very flexible.

 

wait? can the 68000 add memory to memory directly? I always thought it could only do memory to register, or register to register adding instructions, and only moving instructions let you do memory to memory?

 

It can do memory to memory with the ADDX instruction. Or more precisely indirect to indirect and with both registers auto decremented. But it's not really that useful of an instruction. Plus, it's ADD with X (extended flag) and you still have to load the registers with the address.

You can't do ADD.W abs.w, abs.w, which would be much more useful. Another pet peeve is indexing on the 68k. It's kind of a hassle compared to the 6809, 65x, '816 *and* it's not free (cycles) on the 68k like it is with those processors.

I know you don't want to make this a 65816 Vs thread, but 32bit addition/arithmetic is still faster on the 65816 cycle wise - though it takes more code.


Some code examples I worked on: http://rafb.net/p/AbFfxG99.html ( Sorry, no 6809 stuff) Top one is 68k, second one is 6280 (close enough to the 6809) and last one is 65816.
That link is only going to last for 24hours. This forum doesn't have a

Code:

 tag :dammit:

 [I]Edit[/I]: This link seems to be more permanent - [URL="http://pastebin.com/f76e312e0"]http://pastebin.com/f76e312e0[/URL]


 TmEE's right though. The 68k is pretty easy to code with and fairly laid back.  One of the biggest reasons it was popular though, was because it was available at much higher clock speeds in comparison to the competition. Even the initial releases of 1980 had some high clock speeds for the time. 

 The slow cycle times really drag it down though. 32bit register to register is nice, but there aren't that many registers for that sort of method. Only eight address registers VS 128 on the 65x and '816 (and 6809 iirc) is kinda cramped. That said, 68k is still fun to code on. I've had a blast with it.


 I've said this many times before but, there's a reason why motorola didn't release the 6809 at higher speeds than 2mhz. It would have blown away the 68k and being cheaper - that's not a smart marketing move. Motorola was putting all their focus, plans, and PR on the 68k. They needed a processor that was a forward thinking model. Something that had room in the architecture for "clean" advancement. Sure, you didn't really *need* 32bit arithmetic operations back when it was released and even years later, but Motorola knew there was going to come a point when it would be needed and the 68k line would already have native support for it. The PC having a 32bit address range is a beautiful thing (even if the original 68k lack those upper address pins). And Motorola could decrease the slow cycle times at a later point when appropriate. 

 If I were to choose between a 6809 and a 68k at the same Mhz rating, 11 times out of 11 I'd choose the 6809. It's an improved 65x.

 

I was afraid to talk about the 65816 is because I was afraid I would get the Sega-16.com esque responses. I hate that website so much.

 

We aren't Sega fanboys here. I find comparing the 68k and 65816 interesting as it is something to be curious about given that Genesis and SNES were using those CPUs and the long going myth has been that the Genesis CPU was far more powerful. I've been working with the 65816 lately and while I'm not sure how fast one at 2.68mhz is, it certainly seems like it should be a capable CPU. It does seem like with the Genesis you could probably be alittle less efficant in your code without being punished like you would be on the SNES.

FastROM speed sounds like it would help a bit since the cpu speed would mainly drop only during certain accesses like to RAM and certain registers I believe. It also seems FastROM is pretty easy to get working. I tried hacking Gradius 3 to enable FastROM and see if it helps the slowdown but I haven't had time to play into it to the point to get enough going on to cause slowdown I guess.

 

Or maybe you did, it's just that the part that slowsdown isn't the part that slowsdown anymore.:thumbsup:

 

Well, like I was saying, I haven't had time to really test it, but I believe if I did it correctly, which I believe I did, it should reduce the slowdown in that game simply by enabling FastROM. FastROM does apparently give a nice speed increase.

 

Anyway given that out of all the CPUs mentioned only the 68000,65816 and Z80 cores are still being made by various companies why are you banging on about a 8bit CPU that ran at a whooping 1 or 2Mhz that quietly died a death by the end of the 80s?

 

The 6809 lasted passed the 90's as core in one of motorola's MCU - IIRC. WDC 8bit 65c02 core is still being sold.

 

because I find comparing cpus and debunking myths to be interesting? Why do people play golf, if it doesn't do anything at all except take away boredom?

 

Well rather then complain about it why don't you write something that compares like for like on the 6809, 68000, Z80 and 65816 for example a sort on a list of values held in a memory table or the addition of a list of values held in a memory table using 8bit numbers (you could do 16 and 32 bit numbers too if you feel inclined), then work out how many T-States it would take for each to do. That way you can see which one would be fastest and maybe debunk a myth.

Each CPU does have a strength and weakness so you could write a version that uses this, and if you feel inclined write one for another CPU that uses all it's weaknesses...

 

Tomethius already did something like that in this thread, but maybe I'll do one myself anyway, just because I like doing stuff like this.

 

I wrote an algorithm for converting bytes into nibbles,

example:
$04,$0A,$08,$07, becomes $4A,$87

you get it?

for 4 different cpus. Sorry I was too lazy to do cycle counting for them. I'm a little sick today so I feel like sleeping a lot.

 

I assume that you will take two nybbles and turn them into a byte?

I am posting this, mainly as I can use one of the least used Z80 instructions ever, it destroys the source but I am sure that don't matter....

LD HL,source+1 ; 10
LD A,(HL) ; 7
DEC HL ; 6
RLD ; 18
LD A,(HL) ; 7
LD (result),A ; 13

 

Nobody posted here in awhile. I deleted my last post because I was mostly talking to myself and wasn't important.

Anyway I found out I made a few mistakes with the cycle counting, so I fixed them. I also made a looped version and an unrolled version for each of the cpus.

Unrolling the code boosted the cycle efficiency on all the cpus, but the 65816 got an exceptionally large speed boost with the unrolled code.