clib memory optimization bug

Terry W

The C function library clib.spin is a very useful tool. However, the memcpy and memset routines have a small problem. The long and word operations still use the byte count. Suggest adjusting as follows:

memcpy
··· longmove(dest, src, n>>2)······ '<<<< divide by 4 for byte to longs
··· wordmove(dest, src, n>>1)····· '<<<< divide by·2 for byte to words
memset
··· longfill(dest, val, n >>2)
··· wordfill(dest, val, n >>1)
The overhead of the Spin code to test for long/word boundaries probably exceeds the time saved in the long/word operations. Just do the bytemove/bytefill for overall fastest execution time.

Dave Hein

Terry,

Thanks for your comments.· I came across this a few weeks ago, and I intended to update the clib version in OBEX to fix this.· I was also planning on including file I/O routines in clib at the same time, but this has become a bigger task than I first estimated.· I'll go ahead and update clib with the fix and a few other functions that I've added, and then update it again when I've finished the file I/O.

I'll have to do some timing tests to see if there's any benefit to using longmove or wordmove.· You're probably correct that ovehead for the Spin code is offsetting the benefits of using the more efficient moves.· Maybe I can add a simple test up front such as "if n < 100" where it will automatically use bytemove, and then above 100 it would test for word or long alignment.· I'll run some tests to see what works best.

Dave
·

Dave Hein

I updated CLib in the OBEX to version 1.0.1.· This fixes the bug in memcpy and memset, and it also improves efficiency when the byte count is around 200 or below.· I ran some timing tests and found that even·just a few·Spin instructions·use·up a lot of cycles.· The calling overhead alone takes over 2,000 cycles, so it is better to use bytemove,·wordmove or longmove directly for small byte counts.

If you are currently using CLib·please upgrade to version·1.0.1 to·fix the·memcpy/memset bug.

Dave