Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!mirror!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: comp.lang.c
Subject: Re: A study in code optimization in C
Keywords: memcopy
Message-ID: <17267@frog.UUCP>
Date: 30 Jul 90 22:26:00 GMT
References: <133@smds.UUCP> <1990Jul26.144134.16053@ux1.cso.uiuc.edu>
Organization: Misanthropes-R-Us
Lines: 21

In article <1990Jul26.144134.16053@ux1.cso.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
> In article <133@smds.UUCP> rh@smds.UUCP (Richard Harter) writes:
> >The macro shown below is an optimized memory to memory copy macro.
> >It is probably faster than memcopy on your machine
> Oh My!.
> Sure looks like his code loses. As I would expect, of course:  The
> library can do the whole 20 kilobytes in one instruction, assuming
> aligned operands. Unaligned, it takes a few more.

Well, it turns out that even without being able to do memory-to-memory moves
with a single SPIN_CYCLE instruction, a poor little garden variety 68020 can
do better than the supplied macro.  I checked our movebytes() subroutine,
and it did about three times better than the macro.  It, of course, uses
all of the valuable optimization tricks mentioned in Richard's article
(reason enough to stash it away), and also takes care of minor little problems
like odd-address alignment (which is a problem on the 68000 though not on
the '20).  movebytes() is, as it happens, written in C, using a compiler
(GreenHills) which translates it into really good assembly code.
-- 
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu