libitery directory in gcc-3.1.1 source code package

[Liang Chen]

Is the file "bcopy.c" in the "libitery" directory the implement of the
GNU C library function "bcopy"? If so, how can it run so fast?(copy-by-byte
rather than copy-by-word) When I copy the code of "libitery/bcopy.c" to my
own code, I find that it is so slow even if I turn on "-O3" and define
"NDEBUG". Why?

[Gordon Burditt]

Re: libitery directory in gcc-3.1.1 source code package

> Is the file "bcopy.c" in the "libitery" directory the implement of the[color=blue]
>GNU C library function "bcopy"?[/color]

Most likely. I'm not sure I'm looking at the same version you are,
and that interface and functionality of "bcopy()" predates GNU, I
believe, but it looks like it.
[color=blue]
>If so, how can it run so fast?[/color]

Who claims that it does run fast, whether so or non-so? And with
what evidence?
[color=blue]
>(copy-by-byte
>rather than copy-by-word)
>When I copy the code of "libitery/bcopy.c" to my
>own code, I find that it is so slow even if I turn on "-O3" and define
>"NDEBUG". Why?[/color]

That implementation of bcopy() (which seems to be portable to all
platforms) still runs faster than a program that needs bcopy() but
doesn't have any implementation of it at all (and therefore won't
link).

Often you have a tradeoff: pick 1:

portable and mediocre performance
unportable, good performance on some platforms,
won't work or works incorrectly on others
unportable, good performance on some platforms,
terrible performance on others

Gordon L. Burditt

[Liang Chen]

Re: libitery directory in gcc-3.1.1 source code package

Thank you for your reply, and I should say sorry for my unclear expression of these questions, which should mainly attribute to my poor English :(

In "libitery", I find the file, "memcpy.c". In it, there is the following code fragment,

PTR
DEFUN(memcpy, (out, in, length), PTR out AND const PTR in AND size_t length)
{
bcopy(in, out, length);
return out;
}


It is clear that memcpy() calls bcopy(). So, I open "bcopy.c" in the same directory and find these codes,

void
bcopy (src, dest, len)
register char *src, *dest;
int len;
{
if (dest < src)
while (len--)
*dest++ = *src++;
else
{
char *lasts = src + (len-1);
char *lastd = dest + (len-1);
while (len--)
*(char *)lastd-- = *(char *)lasts--;
}
}


This version of bcopy() is implemented to behave more "correctly" when memory blocks are overlaped. We know that according to the C89 standard, function memcpy() does not need to have this kind of "correct" behavior(maybe bcopy() needs for some dependence issues), and if a programmer calls memcpy() with two overlaped memory blocks, its behavior is not defined. So, I feel that this implementation of memcpy() is too awful. The following implementation can be better,

void* memcpy1 (register void* des, register void* src, register size_t len)
{
void* pdes = des;

for(; len>0; --len)
*(char*)des++ = *(char*)src++;

return pdes;
}

And it can be more efficient when copy a word directly,

void* memcpy2 (register void* des, register void* src, register size_t len)
{
void* pdes = des;

switch(len%size of(int))
{
case 3: *(char*)des++ = *(char*)src++;
case 2: *(char*)des++ = *(char*)src++;
case 1: *(char*)des++ = *(char*)src++;
}
for(len/=sizeof(int); len>0; --len)
*(int*)des++ = *(int*)src++;

return pdes;
}

It can be much more efficient if I copy more words rather than one word from des to src in "for" loop. Anyhow, memcpy2() should run faster than memcpy() does when processing large memory blocks, I believe. But, when I test them(copy between two 10240 bytes memory blocks), I am surprised to find that memcpy() runs the fastest. This result make me completely confused. Do you know the reason? Would you kind to explain it to me? Thank you!


Liang Chen

"Gordon Burditt" <gordonb.x8zdi@ burditt.org> wrote in message news:cfk1d1$1s@ library1.airnew s.net...[color=blue][color=green]
> > Is the file "bcopy.c" in the "libitery" directory the implement of the
> >GNU C library function "bcopy"? [/color]
>
> Most likely. I'm not sure I'm looking at the same version you are,
> and that interface and functionality of "bcopy()" predates GNU, I
> believe, but it looks like it.
> [color=green]
> >If so, how can it run so fast?[/color]
>
> Who claims that it does run fast, whether so or non-so? And with
> what evidence?
> [color=green]
> >(copy-by-byte
> >rather than copy-by-word)
> >When I copy the code of "libitery/bcopy.c" to my
> >own code, I find that it is so slow even if I turn on "-O3" and define
> >"NDEBUG". Why?[/color]
>
> That implementation of bcopy() (which seems to be portable to all
> platforms) still runs faster than a program that needs bcopy() but
> doesn't have any implementation of it at all (and therefore won't
> link).
>
> Often you have a tradeoff: pick 1:
>
> portable and mediocre performance
> unportable, good performance on some platforms,
> won't work or works incorrectly on others
> unportable, good performance on some platforms,
> terrible performance on others
>
> Gordon L. Burditt[/color]

[Gordon Burditt]

Re: libitery directory in gcc-3.1.1 source code package

>This version of bcopy() is implemented to behave more "correctly" when =[color=blue]
>memory blocks are overlaped. We know that according to the C89 standard, =
>function memcpy() does not need to have this kind of "correct" =
>behavior(may be bcopy() needs for some dependence issues), and if a =
>programmer calls memcpy() with two overlaped memory blocks, its behavior =
>is not defined. So, I feel that this implementation of memcpy() is too =
>awful. The following implementation can be better,[/color]

I believe the "definition " of bcopy() (which is not ANSI C, but some
kind of old BSD de-facto non-standard) includes non-destructive
handling of overlapping areas. This is NOT true of memcpy() in
ANSI C but is true of memmove().
[color=blue]
>void* memcpy1 (register void* des, register void* src, register size_t =
>len)
>{
> void* pdes =3D des;
>
> for(; len>0; --len)
> *(char*)des++ =3D *(char*)src++;
>
> return pdes;
>}
>
>And it can be more efficient when copy a word directly,[/color]

Warning: source code below appears to have been MIMEd to death.
[color=blue]
>void* memcpy2 (register void* des, register void* src, register size_t =
>len)
>{
> void* pdes =3D des;
>
> switch(len%size of(int))
> {
> case 3: *(char*)des++ =3D *(char*)src++;
> case 2: *(char*)des++ =3D *(char*)src++;
> case 1: *(char*)des++ =3D *(char*)src++;
> }
> for(len/=3Dsizeof(int); len>0; --len)
> *(int*)des++ =3D *(int*)src++;[/color]

I can see no reason why the above line won't smegfault on a
majority of calls to memcpy2() on a machine which enforces alignment
restrictions. Nasty example:
char buf[10240];

... something to put some data in buf ...
memcpy2(buf+3, buf, strlen(buf)+1);

Another possibility is that the machine doesn't enforce alignment
restrictions but comes up with the wrong answer. That is, assuming
4 byte ints,
*(int *) 0xdeadbee3
fetches or stores the integer at the addresses 0xdeadbee0 thru 0xdeadbee3,
*NOT* 0xdeadbee3 thru 0xdeadbee6.
[color=blue]
> return pdes;
>}
>
>It can be much more efficient if I copy more words rather than one word =
>from des to src in "for" loop.[/color]

I don't consider "segmentati on fault - core dumped" to be more
efficient than anything which doesn't core dump. There are ways
to copy words at a time in the presence of alignment restrictions.
This isn't it.
[color=blue]
>Anyhow, memcpy2() should run faster than =
>memcpy() does when processing large memory blocks, I believe.[/color]

I believe that any such statement about how performance otto-be is
made *BECAUSE* it is wrong.
[color=blue]
>But, when =
>I test them(copy between two 10240 bytes memory blocks), I am surprised =
>to find that memcpy() runs the fastest. This result make me completely =
>confused. Do you know the reason? Would you kind to explain it to me? =
>Thank you![/color]

I don't see any measurement methodologies or test results here.
Any performance measurements where the difference between two
ways of doing something are less than 1% or less than 10 times
the granularity of the clock being used to measure the time are
likely crap. And multitasking screws things up even worse.
The best performance demonstrations are those where you can
easily measure the difference in time with a wrist watch, *IF*
throwing the test in a loop and repeating it a million times
doesn't screw up what you are trying to measure (e.g. maybe
you don't want the test run completely from cache).

Also, are you sure you are using the memcpy() from the libiberty
directory? (As opposed to one in libc?) On FreeBSD the two
are very different.

Gordon L. Burditt

[CBFalconer]

Re: libitery directory in gcc-3.1.1 source code package

Liang Chen wrote:[color=blue]
>
> Part 1.1 Type: Plain Text (text/plain)
> Encoding: quoted-printable[/color]

Please do not use html or mime attachments in newsgroups.

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Liang Chen]

Re: libitery directory in gcc-3.1.1 source code package

> I can see no reason why the above line won't smegfault on a[color=blue]
> majority of calls to memcpy2() on a machine which enforces alignment
> restrictions. Nasty example:
> char buf[10240];
>
> ... something to put some data in buf ...
> memcpy2(buf+3, buf, strlen(buf)+1);[/color]

Could I consider that memcpy2() is un-portable and hardware-sensitive?
[color=blue]
> Another possibility is that the machine doesn't enforce alignment
> restrictions but comes up with the wrong answer. That is, assuming
> 4 byte ints,
> *(int *) 0xdeadbee3
> fetches or stores the integer at the addresses 0xdeadbee0 thru 0xdeadbee3,
> *NOT* 0xdeadbee3 thru 0xdeadbee6.[/color]

I run and test my programmes on a PC. The CPU is Intel Pentium. The OS is
Linux 2.4.18-12L, not xBSD. I use GDB to debug memcpy2(), and I find that
the situation is not the same as you said above. *(int*)0xdeadbe e3 does
fetch and store the integer, for example, at the addresses 0xdeadbee3 thru
0xdeadbee6 rather than 0xdeadbee0 thru 0xdeadbee3.
[color=blue]
> I don't consider "segmentati on fault - core dumped" to be more
> efficient than anything which doesn't core dump. There are ways
> to copy words at a time in the presence of alignment restrictions.
> This isn't it.[/color]

I checked my programme thoroughly last night. Now, memcpy2() looks like
this,

void* memcpy2 (register void* dest, register void* src, register size_t len)
{
void* pdest = dest;

for(; len%sizeof(int) !=0; --len, dest=(char*)des t+1, src=(char*)src+ 1)
*(char*)dest = *(char*)src;
for(len/=sizeof(int); len>0; --len, dest=(int*)dest +1, src=(int*)src+1 )
*(int*)dest = *(int*)src;

return pdest;
}

It is a ANSI C program this time. But my machine doesn't enforce alignment
restrictions. I do not know how to copy words at a time in the presence of
alignment restrictions. Can you give me some examples or hints?
[color=blue]
> I don't see any measurement methodologies or test results here.
> Any performance measurements where the difference between two
> ways of doing something are less than 1% or less than 10 times
> the granularity of the clock being used to measure the time are
> likely crap. And multitasking screws things up even worse.
> The best performance demonstrations are those where you can
> easily measure the difference in time with a wrist watch, *IF*
> throwing the test in a loop and repeating it a million times
> doesn't screw up what you are trying to measure (e.g. maybe
> you don't want the test run completely from cache).[/color]

Now memcpy2() is as fast as memcpy() in library.
[color=blue]
> Also, are you sure you are using the memcpy() from the libiberty
> directory? (As opposed to one in libc?) On FreeBSD the two
> are very different.[/color]

When I say "memcpy()", I mean the memcpy() in libc.
They are different? You mean the memcpy() in libiberty is not the real code
to be compiled to add into libc? But, does the libc be made when I MAKE a
GCC package? If it does, where is it's source codes, whatever they are C
codes or ASM codes?

Chen L.

[Liang Chen]

Re: libitery directory in gcc-3.1.1 source code package

> I can see no reason why the above line won't smegfault on a[color=blue]
> majority of calls to memcpy2() on a machine which enforces alignment
> restrictions. Nasty example:
> char buf[10240];
>
> ... something to put some data in buf ...
> memcpy2(buf+3, buf, strlen(buf)+1);[/color]

Could I consider that memcpy2() is un-portable and hardware-sensitive?
[color=blue]
> Another possibility is that the machine doesn't enforce alignment
> restrictions but comes up with the wrong answer. That is, assuming
> 4 byte ints,
> *(int *) 0xdeadbee3
> fetches or stores the integer at the addresses 0xdeadbee0 thru 0xdeadbee3,
> *NOT* 0xdeadbee3 thru 0xdeadbee6.[/color]

I run and test my programmes on a PC. The CPU is Intel Pentium. The OS is
Linux 2.4.18-12L, not xBSD. I use GDB to debug memcpy2(), and I find that
the situation is not the same as you said above. *(int*)0xdeadbe e3 does
fetch and store the integer, for example, at the addresses 0xdeadbee3 thru
0xdeadbee6 rather than 0xdeadbee0 thru 0xdeadbee3.
[color=blue]
> I don't consider "segmentati on fault - core dumped" to be more
> efficient than anything which doesn't core dump. There are ways
> to copy words at a time in the presence of alignment restrictions.
> This isn't it.[/color]

I checked my programme thoroughly last night. Now, memcpy2() looks like
this,

void* memcpy2 (register void* dest, register void* src, register size_t len)
{
void* pdest = dest;

for(; len%sizeof(int) !=0; --len, dest=(char*)des t+1, src=(char*)src+ 1)
*(char*)dest = *(char*)src;
for(len/=sizeof(int); len>0; --len, dest=(int*)dest +1, src=(int*)src+1 )
*(int*)dest = *(int*)src;

return pdest;
}

It is a ANSI C program this time. But my machine doesn't enforce alignment
restrictions. I do not know how to copy words at a time in the presence of
alignment restrictions. Can you give me some examples or hints?
[color=blue]
> I don't see any measurement methodologies or test results here.
> Any performance measurements where the difference between two
> ways of doing something are less than 1% or less than 10 times
> the granularity of the clock being used to measure the time are
> likely crap. And multitasking screws things up even worse.
> The best performance demonstrations are those where you can
> easily measure the difference in time with a wrist watch, *IF*
> throwing the test in a loop and repeating it a million times
> doesn't screw up what you are trying to measure (e.g. maybe
> you don't want the test run completely from cache).[/color]

Now memcpy2() is as fast as memcpy() in library.
[color=blue]
> Also, are you sure you are using the memcpy() from the libiberty
> directory? (As opposed to one in libc?) On FreeBSD the two
> are very different.[/color]

When I say "memcpy()", I mean the memcpy() in libc.
They are different? You mean the memcpy() in libiberty is not the real code
to be compiled to add into libc? But, does the libc be made when I MAKE a
GCC package? If it does, where is it's source codes, whatever they are C
codes or ASM codes?

Chen L.

[Chris Torek]

Re: libitery directory in gcc-3.1.1 source code package

[someone noted possible alignment problems in some code variants]

In article <news:cfrqn3$5f o$1@mail.cn99.c om>
Liang Chen <chenliang@citi z.net> wrote:[color=blue]
>I run and test my programmes on a PC. The CPU is Intel Pentium. ...[/color]

Pentium-based systems never[%] enforce alignment constraints.
Try a MIPS, ARM, or SPARC-based system, for instance (if you
can get hold of one).
[color=blue]
>When I say "memcpy()", I mean the memcpy() in libc.
>They are different? You mean the memcpy() in libiberty is not the real code
>to be compiled to add into libc? But, does the libc be made when I MAKE a
>GCC package? If it does, where is it's source codes, whatever they are C
>codes or ASM codes?[/color]

None of these are really questions about using Standard C, but rather
about how to build GNU programs with nonstandard extensions.

As it happens, the answer (based on your earlier mention of underlying
OS -- which I snipped) is that they are indeed different, the source
code is not in libiberty at all, and the source code *is* available
somewhere (because of the nature of Linux) but it is difficult to
say precisely where (again because of the nature of Linux :-) ).
The Linux C library is built when you build the Linux C library --
which, unless you-the-reader rebuild Linux, is not something you-
the-reader would normally do, even when installing various GNU
software.

As it also happens, if you use the GNU C compiler on a Pentium
system and turn optimization up high, calls to memcpy() often never
even call anything at all -- they turn into inline assembly code
instead. The compiler is allowed to do this because the name
"memcpy" is reserved, so the compiler can be sure precisely what
any call to memcpy() is supposed to do. This in turn means that
if you attempt to replace memcpy(), but do it by supplying a
different memcpy() function, your new function may never get called
at all!

The behavior described in the last paragraph above -- in which an
attempt to replace a C library function with some other substitute
fails -- is allowed by the C standard. If you want your programs
to run on any system that supports Standard C, do not attempt to
override library functions: if it works at all, it may not work
correctly.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Chris Torek]

Re: libitery directory in gcc-3.1.1 source code package

In article <news:cfrte70mb 8@news4.newsguy .com> I wrote:[color=blue]
>Pentium-based systems never[%] enforce alignment constraints.[/color]

Gah, I forgot the footnote:

[%] What, never?
No, never!
What, never?
Well, hardly ever!

(The SSE instructions require alignment.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Ben Pfaff]

Re: libitery directory in gcc-3.1.1 source code package

Chris Torek <nospam@torek.n et> writes:
[color=blue]
> In article <news:cfrte70mb 8@news4.newsguy .com> I wrote:[color=green]
>>Pentium-based systems never[%] enforce alignment constraints.[/color]
>
> Gah, I forgot the footnote:
>
> [%] What, never?
> No, never!
> What, never?
> Well, hardly ever!
>
> (The SSE instructions require alignment.)[/color]

Also, if you set bit 18, called "AC" or "Alignment Check", in
EFLAGS, then most unaligned accesses in user mode will fault.
--
"I should killfile you where you stand, worthless human." --Kaz

[Dan Pop]

Re: libitery directory in gcc-3.1.1 source code package

In <87d61quydo.fsf @benpfaff.org> Ben Pfaff <blp@cs.stanfor d.edu> writes:
[color=blue]
>Chris Torek <nospam@torek.n et> writes:
>[color=green]
>> In article <news:cfrte70mb 8@news4.newsguy .com> I wrote:[color=darkred]
>>>Pentium-based systems never[%] enforce alignment constraints.[/color]
>>
>> Gah, I forgot the footnote:
>>
>> [%] What, never?
>> No, never!
>> What, never?
>> Well, hardly ever!
>>
>> (The SSE instructions require alignment.)[/color]
>
>Also, if you set bit 18, called "AC" or "Alignment Check", in
>EFLAGS, then most unaligned accesses in user mode will fault.[/color]

Unfortunately, no Pentium-based OS in wide use does it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Gordon Burditt]

Re: libitery directory in gcc-3.1.1 source code package

>> I can see no reason why the above line won't smegfault on a[color=blue][color=green]
>> majority of calls to memcpy2() on a machine which enforces alignment
>> restrictions. Nasty example:
>> char buf[10240];
>>
>> ... something to put some data in buf ...
>> memcpy2(buf+3, buf, strlen(buf)+1);[/color]
>
>Could I consider that memcpy2() is un-portable and hardware-sensitive?[/color]

Yes.
[color=blue][color=green]
>> Another possibility is that the machine doesn't enforce alignment
>> restrictions but comes up with the wrong answer. That is, assuming
>> 4 byte ints,
>> *(int *) 0xdeadbee3
>> fetches or stores the integer at the addresses 0xdeadbee0 thru 0xdeadbee3,
>> *NOT* 0xdeadbee3 thru 0xdeadbee6.[/color]
>
>I run and test my programmes on a PC. The CPU is Intel Pentium.[/color]

This is not a CPU that enforces alignment restrictions, in general.
There's a bit you can turn on to try enforcing restrictions, but I
don't think any major OS running on an i386 platform lets you use it.
[color=blue]
>The OS is
>Linux 2.4.18-12L, not xBSD. I use GDB to debug memcpy2(), and I find that
>the situation is not the same as you said above. *(int*)0xdeadbe e3 does
>fetch and store the integer, for example, at the addresses 0xdeadbee3 thru
>0xdeadbee6 rather than 0xdeadbee0 thru 0xdeadbee3.[/color]

It could behave that way on some CPU. I didn't say it would
on the one you happen to use.
[color=blue][color=green]
>> I don't consider "segmentati on fault - core dumped" to be more
>> efficient than anything which doesn't core dump. There are ways
>> to copy words at a time in the presence of alignment restrictions.
>> This isn't it.[/color]
>
>I checked my programme thoroughly last night. Now, memcpy2() looks like
>this,
>
>void* memcpy2 (register void* dest, register void* src, register size_t len)
>{
> void* pdest = dest;
>
> for(; len%sizeof(int) !=0; --len, dest=(char*)des t+1, src=(char*)src+ 1)
> *(char*)dest = *(char*)src;
> for(len/=sizeof(int); len>0; --len, dest=(int*)dest +1, src=(int*)src+1 )
> *(int*)dest = *(int*)src;
>
> return pdest;
>}[/color]

I don't see any significant change: casting a void * pointer to
int * and then dereferencing it can cause a segfault.
[color=blue]
>It is a ANSI C program this time.[/color]

One which invokes the wrath of undefined behavior under many
combinations of parameters which are perfectly acceptable to pass
to memcpy().
[color=blue]
>But my machine doesn't enforce alignment
>restrictions . I do not know how to copy words at a time in the presence of
>alignment restrictions. Can you give me some examples or hints?[/color]

Example: if you dereference an int pointer containing an address that
is not a multiple of 4, you get a smegmentation fault.

Question: how do you *PORTABLY* figure out whether a pointer
is aligned to a multiple of 4?

If dest and src are 3 apart, then this:[color=blue]
> *(int*)dest = *(int*)src;[/color]
is *GUARANTEED* to cause a smegmentation fault on such a machine, because
one of them MUST be odd. If you increment both of them by the
same amount first, you still have the same problem.
[color=blue][color=green]
>> I don't see any measurement methodologies or test results here.
>> Any performance measurements where the difference between two
>> ways of doing something are less than 1% or less than 10 times
>> the granularity of the clock being used to measure the time are
>> likely crap. And multitasking screws things up even worse.
>> The best performance demonstrations are those where you can
>> easily measure the difference in time with a wrist watch, *IF*
>> throwing the test in a loop and repeating it a million times
>> doesn't screw up what you are trying to measure (e.g. maybe
>> you don't want the test run completely from cache).[/color]
>
>Now memcpy2() is as fast as memcpy() in library.[/color]

If you don't tell me how you measured it, or at least establish
credentials in knowing how to do benchmarks, I'm not going to believe
any statement that X is faster than Y on platform Z. This could
just as well mean "X is faster than Y on platform Z by
0.0000000000000 001%", which is a meaningless difference.
[color=blue][color=green]
>> Also, are you sure you are using the memcpy() from the libiberty
>> directory? (As opposed to one in libc?) On FreeBSD the two
>> are very different.[/color]
>
>When I say "memcpy()", I mean the memcpy() in libc.
>They are different? You mean the memcpy() in libiberty is not the real code
>to be compiled to add into libc? But, does the libc be made when I MAKE a
>GCC package? If it does, where is it's source codes, whatever they are C
>codes or ASM codes?[/color]

When I make a GCC package, I do not make libc, as GCC does not include
a C library at all (on platforms such as FreeBSD, Ultrix, Tru64 aka OSF,
etc.). I believe that even on Linux the C library is not considered
to be part of gcc.

On FreeBSD, the memcpy() and bcopy() code under 'libiberty' is very
different from the code under /usr/src/lib/libc.

Gordon L. Burditt

[L. Chen]

Re: libitery directory in gcc-3.1.1 source code package

> Question: how do you *PORTABLY* figure out whether a pointer[color=blue]
> is aligned to a multiple of 4?[/color]

How about this one?

void* memcpy3 (register void* dest, register void* src, register size_t len)
{
void* pdest = dest;

if( ((unsigned int)dest)%4==(( unsigned int)src)%4 )
{
for(; dest%4!=0; --len, dest=(char*)des t+1, src=(char*)src+ 1)
*(char*)dest = *(char*)src;
for(; len>0; len-=sizeof(int), dest=(int*)dest +1, src=(int*)src+1 )
*(int*)dest = *(int*)src;
for(; len>0; --len, dest=(char*)des t+1, src=(char*)src+ 1)
*(char*)dest = *(char*)src;
}
else
{
for(; len>0; --len, dest=(char*)des t+1, src=(char*)src+ 1)
*(char*)dest = *(char*)src;
}

return pdest;
}
[color=blue]
> When I make a GCC package, I do not make libc, as GCC does not include
> a C library at all (on platforms such as FreeBSD, Ultrix, Tru64 aka OSF,
> etc.). I believe that even on Linux the C library is not considered
> to be part of gcc.
>
> On FreeBSD, the memcpy() and bcopy() code under 'libiberty' is very
> different from the code under /usr/src/lib/libc.[/color]

Oh, I see.(I always think when I build GCC, it will automatically re-compile
libc.)

[L. Chen]

Re: libitery directory in gcc-3.1.1 source code package

> Question: how do you *PORTABLY* figure out whether a pointer[color=blue]
> is aligned to a multiple of 4?[/color]

How about this one?

void* memcpy3 (register void* dest, register void* src, register size_t len)
{
void* pdest = dest;

if( ((unsigned int)dest)%4==(( unsigned int)src)%4 )
{
for(; dest%4!=0; --len, dest=(char*)des t+1, src=(char*)src+ 1)
*(char*)dest = *(char*)src;
for(; len>0; len-=sizeof(int), dest=(int*)dest +1, src=(int*)src+1 )
*(int*)dest = *(int*)src;
for(; len>0; --len, dest=(char*)des t+1, src=(char*)src+ 1)
*(char*)dest = *(char*)src;
}
else
{
for(; len>0; --len, dest=(char*)des t+1, src=(char*)src+ 1)
*(char*)dest = *(char*)src;
}

return pdest;
}
[color=blue]
> When I make a GCC package, I do not make libc, as GCC does not include
> a C library at all (on platforms such as FreeBSD, Ultrix, Tru64 aka OSF,
> etc.). I believe that even on Linux the C library is not considered
> to be part of gcc.
>
> On FreeBSD, the memcpy() and bcopy() code under 'libiberty' is very
> different from the code under /usr/src/lib/libc.[/color]

Oh, I see.(I always think when I build GCC, it will automatically re-compile
libc.)

---
Liang Chen

[CBFalconer]

Re: libitery directory in gcc-3.1.1 source code package

"L. Chen" wrote:[color=blue]
>[color=green]
> > Question: how do you *PORTABLY* figure out whether a pointer
> > is aligned to a multiple of 4?[/color]
>
> How about this one?
>
> void* memcpy3 (register void* dest, register void* src, register size_t len)
> {
> void* pdest = dest;
>
> if( ((unsigned int)dest)%4==(( unsigned int)src)%4 )[/color]

Nope. Casting a pointer to any form of integer is not guaranteed
to be reversible, and the results are implementation defined.

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!