Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: bcopy
Message-ID: <9152@smoke.BRL.MIL>
Date: 12 Dec 88 18:00:06 GMT
References: <9095@smoke.BRL.MIL> <9167@ihlpb.ATT.COM> <1356@astroatc.UUCP> <669@auspex.UUCP> <8522@alice.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <8522@alice.UUCP> andrew@alice.UUCP (Andrew Hume) writes:
>memcpy and memmove should be the same entry point;

I fully agree with this for implementation on systems with small virtual
address spaces.  In cases where there is good hardware support for memcpy
but not for memmove, I would recommend making memcpy an in-line intrinsic
(there are acceptable ways to do this; the library must still include an
actual function having that name, and memmove's code can be shared for
that).  Really fancy implementations could also inline memmove even if
only memcpy semantics are directly supported by the hardware, but the
generated code would be more complex than for the expansion of memcpy.

>	in any case, in a lot of hardware, overlapping doesn't matter;
>what matters is left to right or right to left.

Which affects behavior on block-copy of overlapping regions.

>	does anyone know of any case where the above analysis fails?

If memcpy and memmove are implemented as functions, then the savings from
avoiding the special-case tests are, as you say, normally neglible.  But
in the case of in-line expansion, it can make a significant difference
(if there is a really good blitter in the hardware and the typical block
being transfered is of modest size).