All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zack Weinberg" <zack@codesourcery.com>
To: Richard Henderson <rth@redhat.com>
Cc: Andreas Jaeger <aj@suse.de>,
	libc-alpha@sources.redhat.com, linux-gcc@vger.kernel.org,
	gcc@gcc.gnu.org
Subject: Re: i386 inline-asm string functions - some questions
Date: Sat, 27 Dec 2003 02:24:59 -0800	[thread overview]
Message-ID: <87fzf6mubo.fsf@egil.codesourcery.com> (raw)
In-Reply-To: <20031227045815.GA14291@redhat.com> (Richard Henderson's message of "Fri, 26 Dec 2003 20:58:15 -0800")

Richard Henderson <rth@redhat.com> writes:

> On Thu, Dec 25, 2003 at 07:40:42PM -0800, Zack Weinberg wrote:
>> For a starter, try changing "m" and see how far you get.
>
> That would definitely be wrong when the operand is actually used.

I suspected that might be the case.

Denis' original example doesn't quote actual code but I think it's
talking about stuff like this (from libc cvs,
sysdeps/i386/i486/bits/string.h) -

__STRING_INLINE void *
__memcpy_g (void *__dest, __const void *__src, size_t __n)
{
  register unsigned long int __d0, __d1, __d2;
  register void *__tmp = __dest;
  __asm__ __volatile__
    ("cld\n\t"
     "shrl      $1,%%ecx\n\t"
     "jnc       1f\n\t"
     "movsb\n"
     "1:\n\t"
     "shrl      $1,%%ecx\n\t"
     "jnc       2f\n\t"
     "movsw\n"
     "2:\n\t"
     "rep; movsl"
     : "=&c" (__d0), "=&D" (__d1), "=&S" (__d2),
       "=m" ( *(struct { __extension__ char __x[__n]; } *)__dest)
     : "0" (__n), "1" (__tmp), "2" (__src),
       "m" ( *(struct { __extension__ char __x[__n]; } *)__src)
     : "cc");
  return __dest;
}

so, first off, I don't think this kind of optimization is libc's
business; we have the tools to do a better job over here in the
compiler.  And furthermore I think it's buggy - if the block to be
copied is large and not aligned, it will overwrite memory past the end
of the destination.  

But let's suppose /arguendo/ that there is a legitimate use for a
construct like this: the notation is frankly appalling.  Let me try to
make up some better notation, using C99 variably-modified arrays and
GNU forward parameter declarations (we have the blasted things, we
might as well get some use out of them...)  Note I am not attempting
to fix the bugs in the assembly.

__STRING_INLINE void *
__memcpy_g (size_t __n; char __dest[restrict static __n], 
            const char __src[restrict static __n], size_t __n)
{
  void *savedest = __dest;
  __asm__ __volatile__
    ("cld\n\t"
     "shrl      $1,%%ecx\n\t"
     "jnc       1f\n\t"
     "movsb\n"
     "1:\n\t"
     "shrl      $1,%%ecx\n\t"
     "jnc       2f\n\t"
     "movsw\n"
     "2:\n\t"
     "rep; movsl"
     : "+c" (__n), "+@S" (__src), "+@D" (__dest));
  return savedest;
}

@ is a character not otherwise used in constraints; it means 'the
value here is a pointer and the memory pointed to will be accessed'.
Exactly how much memory, and the nature of the access, are determined
by the type of the pointer.  Here, both pointers are restrict-
qualified and point to memory blocks of known size (that's what
"static __n" in the brackets means).  Furthermore, __src points to
constant memory, so that block is only read, whereas __dest is not
constant so the compiler shall assume it's written.  I had to change
the types from void to char so the size expressions would be
meaningful; if you were actually to use this to implement memcpy,
you'd wrap it in another inline function that casted the arguments.

I think that's all that should be needed.  Thoughts?

zw

  reply	other threads:[~2003-12-27 10:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-25  0:20 i386 inline-asm string functions - some questions Denis Zaitsev
2003-12-25  0:38 ` Richard Henderson
2003-12-25  1:15   ` Denis Zaitsev
2003-12-25  1:21     ` Zack Weinberg
2003-12-25  1:45       ` Denis Zaitsev
2003-12-26  3:40         ` Zack Weinberg
2003-12-27  4:58           ` Richard Henderson
2003-12-27 10:24             ` Zack Weinberg [this message]
2003-12-27 11:35               ` Denis Zaitsev
2003-12-27 18:38                 ` Zack Weinberg
2003-12-28 20:58                   ` Denis Zaitsev
2003-12-29  2:22                     ` Zack Weinberg
2003-12-29  2:44                       ` Denis Zaitsev
2003-12-29  2:46                         ` Zack Weinberg
2003-12-29  2:53                           ` Denis Zaitsev
2003-12-29  3:35                       ` Ulrich Drepper
2003-12-29  3:54                         ` Andrew Pinski
2003-12-29  6:57                           ` Jakub Jelinek
2003-12-29  3:56                         ` Zack Weinberg
2003-12-29  5:31                           ` Daniel Jacobowitz
2003-12-29  5:55                             ` Zack Weinberg
2003-12-29 18:37                             ` Denis Zaitsev
2003-12-29 19:09                               ` Zack Weinberg
2003-12-29 19:31                                 ` Denis Zaitsev
2003-12-29 19:37                                   ` Denis Zaitsev
2003-12-29 18:51                           ` Denis Zaitsev
2003-12-29 19:15                             ` Zack Weinberg
2003-12-27 10:52           ` Denis Zaitsev
     [not found]   ` <20031225060850.C7419@zzz.ward.six>
     [not found]     ` <20031225012711.GD13447@redhat.com>
2003-12-25  1:38       ` Denis Zaitsev
2003-12-25  1:53         ` Richard Henderson
2003-12-25  2:08           ` Denis Zaitsev
2003-12-25  0:39 ` Roland McGrath
2003-12-25  1:13   ` Denis Zaitsev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fzf6mubo.fsf@egil.codesourcery.com \
    --to=zack@codesourcery.com \
    --cc=aj@suse.de \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sources.redhat.com \
    --cc=linux-gcc@vger.kernel.org \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.