HomeForumsWhat's newResources 
 
 
68k - 65c816 performance
patroclus02 - May 26, 2006
  patroclus02 May 26, 2006
Iām tring to write a comparative between MC68000 and 65c816 performance.

I always asumed that motorolaās was far more powerful than SNES CPU. But I begin to doubt. :huh

According to MC68000 documentation, and 65c816 docs:

For a 16 bits add with carry instruction:

Register to register, takes 4 cycles on 68k. 65c816 does not support it.

Memory- Register: takes 8 cycles on 68k using (An) addressing mode, 12 using short absolute and 16 using absolute long.

It takes only 5 in 65c816 for absolute short, and 6 cycles for 65c816, stroing result in accumulator. Even suposing 68k runs at twice the MHz, it still will be faster (twice 6 is 12, so at 7.5MHz, as Genesis runs, SNES should be able to do the operation in 12 cycles, compared with 16 in Genesis).

If we then want to refresh the memory location with the result, we should add more cycles:

6 for SNES, when absolute long addressing mode.

16 for Genesis, for the same mode. Even taking account of the higher MHz count, it will be still behind.

These results confuse me a bit. Because they show that, at least, in this case (and also in some others, such as move/load or store instructions), 68k is not faster than 65c816.

68k only comes over 65c816 when operating with 32 bit values. But with a speed gain of 1.2 ā 1.6, not more than 2 if we only consider clock frecuency.

What do you think about these results??

:smash

 antime May 26, 2006
That's about what I expected. You'll get similar results comparing the 6502 and Z80 processors.

 ExCyber May 26, 2006
68K is probably better at more complex algorithms even at 16-bit and smaller sizes. I think you'll find that 65xx is faster for the most common basic operations, but for anything that goes beyond very simple add/subtract integer math and basic bitwise operations, the 68K will pull ahead because of its richer instruction set and greater number of registers, which reduces the number of memory accesses (pretty much the only operation that the 65xx family is more efficient at). I think this is borne out if you compare the more technically complex SNES games to their nearest equivalents on Genesis and look at how many of the SNES games use on-cart processors, whereas pretty much the only Genesis game that uses an on-cart processor is Virtua Racing. Also, I'm not sure where you get 16 additional cycles to update a memory location on 68K. Can you explain your reasoning?

 patroclus02 May 26, 2006
Yes,

after adding, and storing data in a register, it takes 16 cycles to store in memory (do a move.w Dn, #$xxxxxx)

As it is an absolute long addressing access, it needs 3 reads, in order to fetch instruction (absolute short, would require 2 reads), and another write in order to store the data in memory.

That is 4 memory accesses, that take each 4 cycles according to 68k tech doc. Total, 4*4 = 16 cycles.

A SNES can do the same in 6 cycles.

In 32 bit operation, 68k rules.

Just a little example.

The same memory store that I discuss just now, will take 20 cycles for a 32 bit transfer (3 to fetch instruction, 2 for write 32 data bits).

SNES will require at least 6+6 = 12 cycles.

As Genesis runs 2.11 times faster, the equivalency would be:

Genesis : 20

SNES : 25.32

and if you want to use absolute long addressing, you can only use register A, so you will have to do some register transfers too.

the key point is that most games calculation are done in 16 bits, so the difference in a real SNES / Genesis is very similar, depending on the complexity, as ExCyber said.

But still, 68k is more confortable CPU for me. 65c816 is a bit obscure, and as registers can be configured to be 8/16 bits, it makes difficult to understand certain codes.

68k has more powerful instrution set. More registers! I personally preffer it, from the point of view of a programmer, not performance.

I like the 65c816 too. Has its own advantages.

But I preffer 6502. Easier.

 ExCyber May 26, 2006

  
	
	

		
		

			As it is an absolute long addressing access, it needs 3 reads, in order to fetch instruction (absolute short, would require 2 reads), and another write in order to store the data in memory.



That is 4 memory accesses, that take each 4 cycles according to 68k tech doc. Total, 4*4 = 16 cycles.

I guess my problem is that I don't understand what this hypothetical sequence is supposed to actually accomplish on each processor, not so much that the math itself is wrong...

 patroclus02 May 27, 2006
Example of this sequence:

(Add with carry from memory to a register, then update memory location)

SNES 65c816

(supposing one operand is already in acumulator)

ADC #$xxxxxx

STA #$xxxxxx

GENESIS 68k

(Supposing one operand is already in Dn register)

ADD.w #$xxxxxx, Dn

MOVE.W Dn, #$xxxxxx

As far as I know, 68k can't add two values stored in memory, one of them must be in a register.

As far as I know, 65c816 can only add to accumulator.

Is it clearer now?

Maybe what you were asking me is about the detail step-by-step exacution of the instructions??

 Mask of Destiny May 29, 2006
Your comparison isn't terribly fair because you're programming the 68K as if it was a 65c816. It's rare to use absolute long addressing on the 68K, using register indirect (An) or PC relative addressing. Furthermore since the 68K has 8 data registers it's uncommon to store a value back to memory after doing just a single operation on it. Also assuming that the source and destination address is the same and that you have no desire to update Dn you could just do:

add.w Dn, #$xxxxxx

Which I believe only takes a total of 16 cycles instead of 32 with the sequence you selected.

For very simple operations on relatively large non-sequential set of memory locations the 65c816 might win out, but for any reasonably complex algorithm the 68K will kick 65c816 butt (witness the lack of games like Zero Tolerance or that Brazillian Duke3D game on the SNES without an extra processor in the cart).

You really need to compare the implementation of an actual algorithm on the two processors to get a feel for the pros and cons of each. A simple operation like the example you gave has too many unknowns.

 Druid II May 30, 2006

  
	
	

		
		

			Originally posted by Mask of Destiny@Mon, 2006-05-29 @ 10:33 PM



posted by Mask of Destiny


Holy shit I'm seeing a ghost.

 Mask of Destiny May 30, 2006

  
	
	

		
		

			Originally posted by Druid II@Tue, 2006-05-30 @ 12:14 PM



Holy shit I'm seeing a ghost.




[post=146478]Quoted post[/post]


Hmm???

I don't think I've died yet....

 Druid II May 30, 2006
Yeah but I haven't seen you post since AGES. I remember you were deving a bunch of interesting stuff back then, when you were a regular at the Sonic Cult too.