🚀 go-pugleaf

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