Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!pyramid!prls!mips!sjc
From: sjc@mips.UUCP
Newsgroups: comp.arch
Subject: Re: String Processing Instructions
Message-ID: <984@mips.UUCP>
Date: Fri, 27-Mar-87 16:40:37 EST
Article-I.D.: mips.984
Posted: Fri Mar 27 16:40:37 1987
Date-Received: Sat, 28-Mar-87 16:20:46 EST
Lines: 22

Even if a language had null-terminated strings built in, I don't think
a compiler would necessarily have trouble finding opportunities to emit
the AMD string-processing instruction. In C, it's even easier, because
you just hand-code the str* subroutines. But most languages don't have
null-terminated strings. Pascal provides fixed-length strings, which
imply heavy use of memcpy and memcmp (or bcopy and bcmp, or equivalent
in-line code) rather than the str* family. Similarly, F77 provides
fixed-length (or parameterized-length) strings with blank-padding,
which implies heavy use of memset as well as memcpy and memcmp.  PL/I
is similar. I happen to have a profile of a PL/I compiler written in
PL/I showing 3.9% of its cycles spent in memcpy, 2.7% in memset, 1.4%
in memcmp, and virtually none in the str* family.

Ironically, these languages probably need help with string manipulation
more than C does, because they encourage or hide inefficient practices.
Pascal programmers, for example, often copy or blank-pad strings solely
to circumvent type-compatibility problems, and PL/I programs frequently
require the compiler to make temporary copies of strings unnecessarily,
just because it can't determine statically what the user is going to do
with them.
-- 
...decwrl!mips!sjc						Steve Correll