🚀 go-pugleaf

> [....] Since
> most C programs (especially utilities and other systems programs) do a lot of
> string processing, this one instruction is really worth the small
> implementation cost.  It often improves run times by 15% to 20% (just goes to
> show that the impact of processing C language strings has been long- ignored).

just curious which unix utilities use str(cpy|cmp|len) in their inner loops?
certainly, 'vn' comes to mind as devoting much cpu time to these functions.

is the 15-20% claimed due at all to either

	(a) significantly slow byte addressing to begin with (ala cray)?
	(b) in-line compilation of the string(3) stuff into the application?

if (a), then improving memory byte access speed in the architecture is a
more general solution with more payoff overall than the compare gate hack.
what is the risc chip cost for byte vs. word addressibility, anyway?

if (b), then maybe function call speed is the culprit rather than dearth of
the specialized instruction.

at any rate,
for cray unix, buffer copy ops in the kernel were vastly improved when
re-written for words instead of bytes, even more so when vectorized
(the only place in the kernel with vectorization, i think).

of course, table lookup using only 2^16 locations would be a joke
software solution for super-intensive null-char-in-16-bit-smallword
compare code.  drastic, but saves a test the amd chip appears worried about.
personally, i'm a fan of branch folding ...

ames!jaw