Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.c
Subject: Re: String copy idiom.
Message-ID: <4084@umcp-cs.UUCP>
Date: Sat, 16-Mar-85 00:02:37 EST
Article-I.D.: umcp-cs.4084
Posted: Sat Mar 16 00:02:37 1985
Date-Received: Sun, 17-Mar-85 02:37:32 EST
References: <7044@watdaisy.UUCP> <3448@alice.UUCP> <209@gitpyr.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 40

I didn't really want to make a fuss over it, but robert@gitpyr is
correct; the reason "*s++ = *t++" is "harder" on Pyramids and other
such machines is that they have no auto-increment addressing modes.  If
you write

    while (*s = *t) s++, t++;

then both s and t point *to* the final '\0'; if you write

    while (*s++ = *t++) /* null */;

then both s and t point *past* the final '\0'.  The obvious way to
generate the sequence "*s++" on a machine without autoincrement, when
the value of the assignment might also be required, is

    copy s to temp
    incr s
    indirect using temp

This is, of course, not always the best way.  The increment can often
be deferred, saving the temporary register (or top of stack) and the copy.

In the particular code samples for strcpy() used earlier, a truly
optimizing compiler would "realize" that both codings have the same
semantics, and generate the most optimal instruction sequence for
both.  (They are the same since the values of s and t are not used
except for indirections---at which time they have the same
values---and, in theory, are inaccessible outside the function itself.
In actuality they are usually in some registers or stack frame and thus
accessible, but such possibilities are normally ignored during
optimization [which of course is the reason for introducing the
"volatile" keyword].)

I am surprised that the VMS C compiler doesn't realize that all it
needs to do is generate a loop of inline "locc" and "movc3"
instructions :-).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland