Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!oliveb!intelca!clif
From: clif@intelca.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: Re: String Processing Instruction
Message-ID: <2131@intelca.UUCP>
Date: Fri, 27-Mar-87 19:56:48 EST
Article-I.D.: intelca.2131
Posted: Fri Mar 27 19:56:48 1987
Date-Received: Sat, 28-Mar-87 15:48:43 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15304@amdcad.UUCP>
Distribution: na
Organization: Intel, Santa Clara, Ca.
Lines: 48
Xref: utgpu comp.arch:680 comp.lang.c:1354

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


[ Discussion of best history of string instructions]


> The fact of the matter is:  A C compiler is going to have a real hard time
> generating this instruction.  A Pascal Compiler might have a slightly
> easier time since the conept of "string" is a little more integrated with
> the langauge.  In general, a compiler for a language without built-in types
> and functions for dealing with strings will have a hard time with our
> compare-bytes instruction.  We realized this when we added it to the
> architecture (and it was truly a last-minute addition).  However, it has
> such a significant impact on C programs in general that we were not deterred
> by the realization that this instruction will probably occur only a few
> times in the strcpy(), strcmp(), and strlen() library functions.  Out of
> all the megabytes of code in a UNIX system, this instruction will account
> for maybe 40bytes/5Megabytes or .008% of all code (obvioulsy a real rough
> guess).  But if it improves the running time of all the string-oriented
> system utilties (i.e. almost all utilties!!) by 15% to 20%, it seems
> worth it.  And the implementation cost was so small.  Also, there are
> some instructions that must be present just to administer the system,
> like return from interrupt, move-from-special-register, etc.  These
> are not generated by a compiler either.  Just to reiterate a point:  RISC
> is not reducing the instruction set but is improving performance.
> 
> Ok, so you don't believe the above?  How about "It improved dhrystone
> a hell of lot."
> 
>     bcase

I think that it makes sense to add instructions like this even if
they only get put into the standard libraries, presumably they will
prove to be modest win for most applications written in C.  I 
vaguely remember reading that  calls to string routines represented
about .5% of all C code.  

As for Brian's second statement about Dhrystone being helped by 
string instructions:  He is certainly right about that.

-- 
Clif Purkiser, Intel, Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!clif

These views are my own property.  However anyone who wants them can have 
them for a nominal fee.