This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Sun, May 06, 2007 at 02:52:14AM +0200, insight insight wrote: > Hello, > i use glibc 2.4 on X86_64 and in debugging a C program, i have looked > at the code of memmove > and I was quite surprise by the code produced. no inline function or > macro and more disturbing > byte by byte copy and not 64 bits by 64 bits copy.... > > code of the loop of memmove on my computer : > > - 0x2b3481a26290 <memmove+144>: movzx eax,BYTE PTR [rbx] > - 0x2b3481a26293 <memmove+147>: add rbx,0x1 > - 0x2b3481a26297 <memmove+151>: mov BYTE PTR [rbp],al > - 0x2b3481a2629a <memmove+154>: add rbp,0x1 > - 0x2b3481a2629e <memmove+158>: sub rdx,0x1 > - 0x2b3481a262a2 <memmove+162>: jne 0x2b3481a26290 > > memset (or bzero) is much more optimized, because it seems to use > inline function or macro if number of bytes to set is less than a > certain number and else a function with 64 bits sets in memory in the > loop. > but these functions should used inline functions in every situations, > the function is else incredibly long to initialize the loop... > i thought that the "rep stosd" was used (in 64 bits, i dont know if > it is "rep stosq", long time i dont use assembler) > > Was I juste unlucky with this version of glibc on X86_64 ? That has (IMHO) nothing to do with the glibc, as the libc has nothing to do with code generation, your compiler does. Which compiler did you used, if gcc did you turned optimisations (-O2 usually) on ? -- ÂOÂ Pierre Habouzit ÂÂO madcoder@debian.org OOO http://www.madism.org
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |