Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!amdcad!bcase
From: bcase@amdcad.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Processing Instruction
Message-ID: <15304@amdcad.UUCP>
Date: Thu, 26-Mar-87 14:12:40 EST
Article-I.D.: amdcad.15304
Posted: Thu Mar 26 14:12:40 1987
Date-Received: Sat, 28-Mar-87 04:54:58 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP>
Reply-To: bcase@amdcad.UUCP (Brian Case)
Distribution: na
Organization: Advanced Micro Devices, Sunnyvale, California
Lines: 45
Keywords: instruction set architectures, Am29000
Xref: utgpu comp.arch:667 comp.lang.c:1339

In article <978@ames.UUCP> lamaster@pioneer.UUCP (Hugh LaMaster) writes:
>I appreciate seeing submissions like this.  Designing a computer instruction
>set is a little like backpacking: There is an art to figuring out exactly
>what you really need to take with you. 
Thanks for the positive feedback.  An interesting point of view!

>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.  The old STAR-100 had a number of
>instructions, including string processing instructions, which were left out of
>the Cyber 205 because it turned out that the compilers never generated them.
>They were neat instructions though.  So, my question is, is this instruction
>easily usable by a C, Fortran, Pascal, or ADA compiler and if so, under what
>conditions?

This is an excellent question, one that I intended to address in the original
posting.  However, I forgot to include it when the damn article got kinda
long.

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