Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!pyramid!decwrl!spar!freeman
From: freeman@spar.UUCP
Newsgroups: comp.arch
Subject: Re: String Processing Instruction
Message-ID: <909@spar.SPAR.SLB.COM>
Date: Thu, 26-Mar-87 12:29:51 EST
Article-I.D.: spar.909
Posted: Thu Mar 26 12:29:51 1987
Date-Received: Sat, 28-Mar-87 05:27:31 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP>
Reply-To: freeman@spar.UUCP (Jay Freeman)
Distribution: na
Organization: Schlumberger Palo Alto Research - CASLAB
Lines: 28

<*munch*>

In article <978@ames.UUCP> lamaster@pioneer.UUCP (Hugh LaMaster) writes:

> My question is this:  How likely is it that a compiler itself will be able to
> detect the case when it can use an instruction like this and generate code 
> automatically to use it.  One of the positive points to the RISC debate is
> that it brought out the point that useful instructions which are hard for a
> compiler to generate are not always a win.  

Note that this particular instruction may well win even if no compiler EVER
generates it:  BCase's posting stated that hand-modifying the object code
for two string-processing routines in the standard C library to use the
instruction, and arranging that the compiler word-align strings where
possible, effected consequent frequent improvements in run time of 15-20
percent.  That sounds like a substantial win for C programming, and surely a
fair amount of the code that does get written for this processor will be in
C.  That may be reason enough for the instruction's existence.

Although the point from the RISC debate, that LaMaster summarizes above, is
carefully qualified, it is perhaps nonetheless too narrow a view:  Surely
there are many other cases in which a well-planned library of calls to
functions coded with particular care, will allow efficient use of highly
specialized instructions.  Proper analysis of whether or not to include a
given instruction in an instruction set should include the effect of such
cases.

						-- Jay Freeman