Explanation, please!

[Rod Creason]

Newsgroups: comp.lang.c,comp.arch
Subject: Re: Explanation, please!
Summary: 
Expires: 
References: <638 at paris.ics.uci.edu> <dpmuY#2EBC4R=eric at snark.UUCP> <189 at bales.UUCP> <9064 at pur-ee.UUCP>
Sender: 
Reply-To: rodc at unet.PacBell.COM (Rod Creason)
Followup-To: 
Distribution: 
Organization: Network Equipment Technologies, Redwood City, CA
Keywords: byte copy

In article <9064 at pur-ee.UUCP> hankd at pur-ee.UUCP (Hank Dietz) writes:

>2.	If the number of items/bytes is not known, then build a binary tree of
>	such structs and copy half, then half of what remains, etc.  This is
>	funny looking, but very fast also.  Suppose the number of ints (n) is
>	not known at compile time, but can't be more than 601.  You can write:
>
>	struct t512 { int t[512]; };
>	struct t256 { int t[256]; };
>	struct t128 { int t[128]; };
>	struct t64 { int t[64]; };
>	struct t32 { int t[32]; };
>	struct t16 { int t[16]; };
>	struct t8 { int t[8]; };
>	struct t4 { int t[4]; };
>	struct t2 { int t[2]; };
>	if (n & 512) {
>		*((struct t512 *) q) = *((struct t512 *) p); q+=512; p+=512;
>	}
> [ rest of the example ]

A key point is that this code is *not* portable unless you can *guarantee*
that q and p are ALWAYS aligned at a four-byte boundary.  Any 3b2 (WE32000),
for example, will core dump if this is not the case.  Although 68000 based 
computers only require even alignment, they would still fail in most cases
where this routine would be used.

The key to a fast memory-to-memory copy is getting to these boundaries.
(and in the case where q or p is an odd address and the other is at an 
even address, none of this will work)

>					hankd at ee.ecn.purdue.edu

Rod Creason
...!{ames,amdahl,oliveb,pacbell}!unet!rodc