David Woodhouse wrote:
> On Fri, 2008-10-03 at 16:43 +0200,
goldsimon@... wrote:
>
>> In 1.3.0, we converted all calls to 'memcpy' to either 'MEMCPY' or
>> 'SMEMCPY' (s for short). The goal is optimization: SMEMCPY is defined to
>> memcpy (which the compiler may inline e.g. if size is known at compile
>> time and small); whil MEMCPY can be overridden to provide a better copy
>> mechanism (on my platform, for example, copying non-aligned data can be
>> solved much better when loading full words and shifting in registers).
>>
>> Therfore, using 'memcpy' directly should be avoided: when you know your
>> compiler can't optimize it, you can redefine SMEMCPY to inlining yourself.
>>
>
> I'm inclined to suggest that the correct answer in that case is to _fix_
> the compiler, not work around it. But OK...
This isn't a question of broken compilers: It's a code size vs. speed
question (an optimized memcpy is much bigger than a simple for-loop that
does a byte copy). If the compiler decides not to inline, it would call
'memcpy'. And since on most platforms, memcpy is a generic
implementation of a C-library which is NOT optimized for the actual
hardware, an assembly-routine can be much faster.
SMEMCPY was chosen to explicitly state this is a short memcpy and we
(lwIP developers) don't want to call the fast routine for it since the
compiler might optimize it.
Simon
_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel
