memcpy vs. memmove (was: Re: Explanation, please!)

[Larry Jones]

In article <7039 at bloom-beacon.MIT.EDU>, scs at athena.mit.edu (Steve Summit) writes:
> I'll probably be disgusted by the answer, but can someone explain
> why two functions are needed instead of one?  Why not just add
> the guarantee to memcpy?  In my experience, it's not hard to
> implement the correct, bidirectional copy behavior.  Did someone
> actually manage to convince the committee that there is an
> architecture and/or implementer out there that is so badly broken
> that the overlap test would significantly slow down programs
> which did not need the guarantee?  Or is it a code size issue for
> potential in-line implementations?  (I am aware that a correct
> overlap test is not trivial for badly broken architectures such
> as the segmented 80x86, but the correct test on those machines is
> not really hard or slow, either.)

All of the above.  Many machines have only a single block move instruction
which means that the "backwards" move has to be very inefficient and you
need to do a true overlap test (rather than a simple direction test).
That could add up to a lot of code to inline, but it would really hurt
to not inline if the overlap case never happens.  The easiest way for
the compiler to know for sure whether the overlap case ever happens is
to have different functions for the different cases.

Also, the committee received a number of letters noting that there are
some fairly common operations where memcpy is the inner loop and so
ANY slowdown would be unacceptable (e.g. block moves on bitmap displays).

----
Larry Jones                         UUCP: uunet!sdrc!scjones
SDRC                                      scjones at sdrc.uucp
2000 Eastman Dr.                    BIX:  ltl
Milford, OH  45150                  AT&T: (513) 576-2070
"Save the Quayles" - Mark Russell