Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!ihnp4!fortune!rpw3
From: rpw3@fortune.UUCP
Newsgroups: net.lang.c
Subject: Re: Orphaned Response - (nf)
Message-ID: <2458@fortune.UUCP>
Date: Tue, 7-Feb-84 04:04:19 EST
Article-I.D.: fortune.2458
Posted: Tue Feb  7 04:04:19 1984
Date-Received: Thu, 9-Feb-84 13:35:46 EST
Sender: notes@fortune.UUCP
Organization: Fortune Systems, Redwood City, CA
Lines: 28

#R:houxt:-35400:fortune:16200019:000:1050
fortune!rpw3    Feb  7 00:27:00 1984

Gee, we used to optimize loops like that with a 'DBcc', until the first time
somebody tried to do more than 65536 things and discovered what the compiler
person should have discovered before he ever hacked it in (it's o.k., he fixed
it before we shipped it), namely:

	[From the 68000 User's Manual, Third Edition, page 115]
	"...If the termination condition is not true, the low-order
	16 bits of the data counter are decremented by one..."

Copying more than 256K bytes (65k longs) is not that uncommon
these days.  (How much memory does your system have?)

If a "move word" was used to set up the counter (optimize! optimize!),
you also get VERY strange results if the counter value gets used
for anything inside the loop, regardless of the size of the count.
Even with "move long", guess what prints about halfway through this:

	for( i = -10, i < 10, i++) printf("%d\n", i);

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065