Path: utzoo!dciem!nrcaer!scs!spl1!lll-winken!lll-tis!ames!amdahl!nsc!voder!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: BlockMove efficiency
Message-ID: <11698@Apple.Apple.COM>
Date: 6 Jun 88 22:58:18 GMT
Article-I.D.: Apple.11698
References: <7212@watdragon.waterloo.edu> <8796@dartvax.Dartmouth.EDU>
Reply-To: lsr@Apple.COM.UUCP (Larry Rosenstein)
Distribution: comp
Organization: Advanced Technology Group, Apple Computer
Lines: 27

In article <8796@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes:
>
>BlockMove isn't bad for general purpose use, and I probably couldn't
>do better.  For specific cases, however, there is certainly room for
>speed improvement.  BlockMove uses "move.b" for all moves, and strings

The last statement doesn't appear to be true in looking at the Mac Plus &
Mac II.  It uses MOVE.B's only if the exactly one of the source and
destination addresses is odd.  The code uses MOVE.W and MOVE.L where
possible and on the 68000 uses MOVEM.L if the number of bytes is greater
than 160.

You are right, however, that in some special cases you can do better than
BlockMove, since BlockMove is written for the general case.  The code
distinguishes a few different cases which takes a few cycles.  Also remember
that if you call BlockMove via a trap it takes a few microseconds; you can
get the address of BlockMove at the start of the program and JSR directly to
the code to eliminate this overhead.





-- 
		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 27-AJ  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr