🚀 go-pugleaf

> Gee, Guy, something must have gotten lost in the translation.  I never
> suggested that you needed a moveq there.  It works great no matter what
> value happens to be in d1.  Unless d1 always has a small value at that point
> in the code, you'll hit the end of the string before the dbra expires,
> saving an instruction.  					:-)

No, I stuck the "moveq" in there; the credit was for the general clich\`e
for "dbCC with a 32-bit count".  The "moveq" is cheaper than the "bne", both
on the 010 and on the 020; if it prevents the "dbeq" from running out enough
times, it'll be worth it.

Unfortunately, how often it will prevent the "dbeq" from running out depends
on the frequency distribution of incoming values in "d1" and of string
lengths (and on the correlation, if any, between those values); lacking any
such data, there's no way of saying which is better.  This situation also
occurs on the VAX; since the VAX's string instructions are oriented towards
counted strings rather than null-terminated strings, the assembler-language
version of "strcpy" must first do a "locc" to find the length of the string
to copy before it does the "movc3" to move the string.  As such, there are
cases where the simple-minded "strcpy" outperforms the assembler-language
version (I don't remember what the lengths in those cases were on the 780; I
did that a long time ago).

I doubt anybody'd have the statistics on values of "d1" upon entry to
"strcpy", but does anybody have a distribution of string lengths in
"strcpy"?  The trouble is that you'd have to build an instrumented version
of "strcpy" and rebuild some reasonably large subset of commands with this
(unless you had it in a shared library that you could replace the standard
library with *without* rebuilding the commands - this would probably require
that library references be bound to addresses at run time).
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)