Xref: utzoo comp.lang.c:12383 comp.arch:6275
Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!husc6!bloom-beacon!gatech!amdcad!news
From: news@amdcad.AMD.COM (Network News)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Explanation, please!
Message-ID: <22859@amdcad.AMD.COM>
Date: 7 Sep 88 01:10:03 GMT
Article-I.D.: amdcad.22859
References: <638@paris.ics.uci.edu> <dpmuY#2EBC4R=eric@snark.UUCP> <566@pcrat.UUCP> <9087@pur-ee.UUCP> <5654@june.cs.washington.edu>
Reply-To: tim@delirun.amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc., Sunnyvale CA
Lines: 34
Summary:
Expires:
Sender:
Followup-To:

In article <5654@june.cs.washington.edu> pardo@uw-june.UUCP (David Keppel) writes:
| hankd@pur-ee.UUCP (Hank Dietz) writes:
| >	if ((p - q) & 3) *byte copy* else *struct copy*
| 
| I believe that the VAX "movc" command takes arbitrary pointers and
| does the following:
| 
| * If both are word-aligned, do a word copy (I mean a 4-byte word).
| * If both are non-aligned and could be aligned with 1, 2, or 3 bytes
|   of byte-copy at either end, then do a byte copy at either end and do
|   a word copy down the middle.
| * If niether aligned then ??
| 
| Unfortunately, my VAX hardware reference is out of town for a couple
| of weeks, so I can't ask him about neither aligned.  Anybody know?

I assume that "both are non-aligned" in the above list means that the
source and the destination have the same alignment, but are not aligned
with respect to a 4-byte boundary, and that "neither aligned" means that
the source and the destination are misaligned.

We use an interesting trick in the Am29000 memcpy routine for
source/destination misalignment.  In this case, we set up the alignment
difference in the funnel-count register, read in two source words, and
"extract" a destination word using the funnel-shifter's ability to
extract any 32-bit word from a 64-bit double-word in a single cycle. 
The inner loop then consists of shifting the low source word to the high
source word, reading a new low source word, extracting a destination and
storing it (well, there is also the overhead of counting down the
correct number of "word" moves, but you get the idea.)

	-- Tim Olson
	Advanced Micro Devices
	(tim@delirun.amd.com)