Coldfire MCF5475 performance question

I think you should first forget about the memcpy calls, and ask why a thousand empty loops should take 1.5 ms. Look at the assembly code generated there, and try to figure out what is happening.

The empty loop's instructions are:

MOVEQ #63,D0 CMP.L (FFCE,A6),D0 BLT.B 0C007C (this is the exit jump) MOVEQ #01,D1 ADD.L D1(FFCE,A6) BRA.B 0C006C (this is the first instruction above - ie. jump back to beginning of loop).

This takes 1.5ms for 1000 iterations of these 6 instructions.

I can't see how that could give 1000 iterations, unless the local variable is initialised with -937 instead of 0. It's also very poor code - are you compiling it with all optimisation off? I find it is normally much easier to see what is happening at the assembly level with basic optimisation enabled.

Are you running this from external memory with all caching and the like disabled?

Have you checked your clock, to see if you are running at 266 MHz ?

Have you enabled the cache?

Optimisation is off at present as recommended by P&E for debugging. Also wasn't sure if it would optimise out the loop entirely as it had no instructions within it.

The actual code which generated this empty loop was:

for (temp_loop = 0; temp_loop < 1000; temp_loop++) { }

Running from SDRAM.

As for cache - didn't realise I had to turn it on! Looked at some startup code and found assignment to CACR (cache control register) invalidating the data, branch and instruction caches and not turning them on. I've since set the 3 bits in this register to turn each of the caches on, and the empty loop now takes 106us, a factor of 14 improvement.

Thanks for the advice on that!

This is something I thought of, but wasn't sure where to check this - it's a standard evaluation board with little/no configuration available, and this eval board only had 1 model, so no chance of mistake over purchase.

I'll now go back and look at the other suggestions and see whether there's any more tweaking I can do - but for now, it appears that at least for an empty loop, performance has increased.

Thanks again

I wasn't aware I needed to! Having looked into it, the sample code I was using only set the invalidate flag on the data, branch and instruction caches. I've now also enabled these caches and the time for the empty loop has gone from 1.5ms for 1000 iterations, down to 106us for 1000, a factor of 14!

Thanks for the advice!

Too much optimisation can make debugging hard - it becomes hard to follow what's happening as the compile re-arranges everything. But too little optimisation can also make it difficult, since the compiler puts data on the stack and uses unnecessarily long, slow code sequences. It depends on your compiler and debugger, but I find (with gcc and gdb) that -O gives a reasonable compromise.

You have to watch out for a few things, however - an empty loop like this can be removed entirely. The correct way to deal with this is to declare "temp_loop" to be volatile (a slightly different alternative would be to add an assembly "nop" inside the loop).

The easiest way to check your clock rate is if you have a decent scope, look at the clock output pin (driving the clock to the sdram, for example). You'll have to check what the bus division ratio is for your chip - it's likely to be divide by 3.

The clock rate for most micros (with configurable clocks) is very conservative to start with - the 150 MHz MCF5234 I'm using at the moment comes out of reset at 37.5 MHz (using a 25 MHz reference).

This can't be the code. Please check your output again or for try to post all the relevant stuff. BTW: An asm(" nop;nop;"); before and after the code make it easier to find it.

But still too much. It should be around 22us@266MHz.

I doubt the 410MIPs Freescale advertises (1.5 instructions per cycle!) and more I doubt that you can achieve such (if ever) with memcpy().

Why is that hard to believe? After all, the figure of 410 is for peak Dhrystone mips, which is not at all the same thing as claiming the processor can execute 410M random instructions per second. Since Dhrystones are based on a particular ISA (was it a VAX?), a processor with a more powerful or more efficient instruction set is going to get better scores per MHz. Also, the Coldfire v4 does its branch prediction in the instruction prefetch-decode pipeline, so correctly predicted branches take 0 cycles, and can do limited super-scaling (register moves, amongst other simple instructions, are done in parallel). So for a small loop where everything is in the caches and branch target buffers, you'll get more than one real instruction per clock cycle.

Of course, for a memcpy, you're going to be constrained by the memory bandwidth more than anything else.

Well, in the debugger I was stepping through from the start of the 'for' loop in C, and then stepped into the assembly. Those 6 instructions were repeated, jumping back to the first one each time.