memcpy

Richard A. O'Keefe ok at goanna.cs.rmit.oz.au
Mon Sep 24 21:32:53 AEST 1990


In article <STEPHEN.90Sep22181237 at estragon.uchicago.edu>, stephen at estragon.uchicago.edu (Stephen P Spackman) writes:
> As to why this code works at all, it turns out that on most machines
> the appropriate stupid implementation IS the fastest; in fact on most
> of the CISC micros there's an instruction that does exactly that, and
> does it very fast indeed (being an instruction, not a loop).

But "some of the world _IS_ a VAX".  The VAX instructions for this
(MOVC3, MOVC5) do it the memmove() way.  On the NS32x32, there's a MOVS
instruction, but you have to set up the registers for it, and it has a
"backwards" option, so the entire overhead for a naive memmove() compared
with a naive memcpy() would be one comparison and one conditional
branch.  By the time you add the code to check for an opportunity to
move 16-bit (MOVSW) or 32-bit (MOVSD) chunks instead of 8-bit (MOVSB)
ones, the overhead of memmove() has disappeared in the noise.

> Furthermore, since it doesn't contain any transfers of control if it
> arrives as an instruction, many compilers will inline it.

Transfers of control needn't stop a compiler inlining it _anyway_.

> So what the situation amounts to is an assumption on the part of the
> programmer that having been given the freedom to implement memcpy()
> however you like in this case, that any "sane" implementor would do it
> the "easy" way

You are making quite unwarranted assumptions about what is "easy".
"however you like" means HOWEVER the implementor likes.
To quote the Goon Show:
	Man from the Geographical Society:
		"There are idiots in the world, you know."
	Neddie Seagoon:
		"Have you met them?"
	Man from the Geographical Society:
		"Met them?  I listen to you every week!"

There are a lot of tiny little dark spots in ANSI C where anyone
designing a language would have spelled out what was to be done.
These little dark spots are almost always there because there are
existing not-quite-hopelessly-broken implementations that did things
different ways.  Think of the dark spots as the warning "rattle" of
these implementations poised to bite you.

-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.



More information about the Comp.std.c mailing list