l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: _L4_msg_get_string_item


From: Marcus Brinkmann
Subject: Re: _L4_msg_get_string_item
Date: Thu, 07 Apr 2005 13:16:04 +0200
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 7 Apr 2005 09:05:24 +0200,
Daniel Godás <address@hidden> wrote:
> 
> [1  <multipart/alternative (7bit)>]
> [1.1  <text/plain; ISO-8859-1 (quoted-printable)>]
> Hi,
> 
> i was reading some code when i came over this function. This is my version:

> __builtin_memcpy (string_item, &msg[pos], sizeof (_L4_word_t) * count);

> I just dont understand the one on the cvs but i think it wouldnt work.
> What do you think about it?

The one in CVS is identical to yours, except that it uses
__builtin_memcpy only for small sizes known at compile time.

The reason is explained in _L4_msg_get:

  /* We can't cast ANY_TYPED to anything useful and dereference it, as
     that would break strict aliasing rules.  This is why we use
     __builtin_memcpy, but only for known, small, fixed sizes, so that it is
     optimized away.  We know that sizeof (_L4_word_t) == sizeof (void *).  */

Ie, we want to inline all the code, and not make a function call.  The
function call would have a bigger overhead than any internal
optimization memcpy could do on arbitrary lengths, because we know we
copy at most 64 words.

But looking at that code again made me spot another bug, in
_L4_msg_append_word.  Thanks for that ;)

Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]