Bruce Partridge wrote:
> This is the code I timed:
>  for (i=0; i<16; i++)
>     {
>        temp_array1[i] = array1[i];
>        temp_array2[i] = array2[i];
>     }
>
> All of the arrays are 32 bit float.

Argh!  This is exactly the kind of reason you need to know what you're doing
at the machine laguage level, whether using assembler or a compiler.
Apparently this is on an 18 family PIC.  You could unroll the whole loop
into 128 MOVFF instructions if program space is not a problem.  The next
fastest method would be to make good use of the autoincrement FSRs.  This
may be difficult for the C compiler to figure out.  This is very likely
prevented altogether by putting both copy operations in the same loop.
Again *THINK* about what has to go on.  If you did one array, then the
other, you could blast thru each array without having to reload FSRs.
Switching arrays every 4 bytes is silly.  I'd be real impressed if the
compiler could rewrite this as two separate array copies.

> I was quite surprised that it took so long.  The above C code
> generates about 70 instructions in assembler.

That should have been a big clue right there.  I keep saying this, but THINK
about all the evidence you have.

This is a perfect example of what is wrong with using a compiler on this
kind of small resource limited system.  All technical arguments aside, using
a compiler can obviously lead some people to feel the brain is no longer
needed.  Stick to writing GUI apps on a 3GHz Pentium if that's what you
believe.  Maybe Microsoft if hiring.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body