Quote:
Originally Posted by Karlos
The only things that will benefit from memory copy optimisation are;
1) Applications which copy large amounts of data from one place to another, which will benefit from any throughput improvements. This will soon become IO bound however.
2) Applications which frequently copy small amounts of data from one place to another which can benefit from reduce function call setup time.
Most applications don't fit either category ...
|
That's the reason why I don't use these CopyMem/Quick() exec functions. I prefer to call my internal 020+ subroutine CopyMemBlock instead, because in that way I avoid to change the A6 register and backup/restore D1, and my routine won't need to preserve anything on the stack either. After returning from CopyMemBlock I can sometimes further benefit from re-using the A0 and A1 registers directly, because they are pointing to the next address below the source and destination blocks, which is often just as required. With a call to an exec function, I could not make any assumptions about the contents of all scratch registers.
My 020+ routine is not optimized for 040/060 or unaligned blocks, but usually the block size that I have to copy is between 30 bytes and 5 kB only, not large enough or frequently called enough to benefit from additional checks of the circumstances and branching into (CPU) optimized subroutines. Anyway, I won't notice any speed improvements from a faster copying of memblocks for my icon.library, not even with benchmarks.