[uClibc] improved memcpy/memset on arm in uClibc-0.9.19

[Manuel Novoa III]

Hello,

On Tue, Sep 16, 2003 at 05:40:34PM +0200, Markus Pietrek wrote:
> the C implementation of memcpy() and memset() is very slow on ARM. Using 

Heh... they are slow on all archs.  But they weren't intended to be fast.
They were intended to be small, portable, and correct.  The intention
was that at some point we would provide arch-specific fast versions.
But until now, performance tuning has been lower on the todo list than
filling in needed gaps in functionality.

> My code works only on the assumption that the memory is 32bit aligned and no 
> Wchar are used, the block size is large enough (>>0x38 bytes) to complement 
> the overhead and of course it is an ARM.
> 
> So my questions are
> o with these restrictions, does it make sense to put the code in this general
>   library?

I'm all for providing fast versions of the mem*/str* functions.  But
any such optimized functions will have to be standards-compliant, and
there is no requirement regarding memory alignment of the buffers these
functions operate on.  Actually, optimizing the wmem*/wcs* functions
would be simpler because you do have some alignment information.

> o what the best method for replacing C functions with custom assembler 
> functions.  Obviously, hacking libc/string/wstring.c is not good

Yes... hacking asm versions of the string functions into wstring.c is
definitely not an option.

Probably easist to simply have seperate subdirs for each arch that
supplies optimimized versions of given functions.  Then, after all
the generics were built, the optimized versions could be built and
stored in the libary thereby overriding the generic versions.

But I'll talk to Erik about.

Manuel