Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!think!ames!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Explanation, please!
Message-ID: <8379@smoke.ARPA>
Date: 26 Aug 88 21:18:14 GMT
References: <638@paris.ICS.UCI.EDU> <2873@ttrdc.UUCP> <9957@eddie.MIT.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 41

In article <9957@eddie.MIT.EDU> jbs@fenchurch.MIT.EDU (Jeff Siegal) writes:
>...  I prefer (and also use, in highly-speed-sensitive code): ...

It is worth noting that byte-at-a-time is not optimal on most architectures.
Duff's device is useful for arbitrarily-aligned data, but if you can
arrange for (most of) the source and destination buffers to be relatively
word-aligned, then along with processing the head and tail pieces via
something like Duff's device, the bulk of the data can be transferred in
bigger chunks, gaining considerable increase in speed.  One should really
use memcpy() in all cases where the source and destination do not overlap,
because all the work done to optimize block-move for a specific architecture
are supposed to be centralized there.

A couple of people have complained about the tone of my previous response
on this topic.  I meant it to be informative and minimal, i.e. requiring
some thought on the reader's part.  Since some have missed the point, let
me summarize the C style issue:

	Since the constructs are not forbidden by the C language
	rules, they are perforce permitted.  One should have an
	explicit rule to point at as being violated in order to
	think that the code is not valid.  "Intuition" is a lousy
	guide, particularly when it was formed by experience in
	other contexts (e.g. Pascal).

	Now, because of the demands made on one's understanding
	of the language, the cited code would be considered bad
	programming style IF what it did could be effectively
	accomplished in some other way.  As I pointed out in my
	previous posting on this, Duff's device does indeed have
	use in cases where other approaches fail, namely moving
	overlapping unaligned data.  Eventually we can all use
	memmove() for this, but not today.

Incidentally, Duff's device is used to manipulate text strings in the
"sam" text editor.  I recently changed it to use the device for both
directions, only in cases of overlap, using memcpy() for all other
cases.  (Originally the device was used for all transfers in one
direction and memcpy() for all in the other, which assumed more about
the behavior of memcpy() than is officially guaranteed.)  So this is
not just an academic issue..