🚀 go-pugleaf

> The last 68000 compiler I used aligned strings on WORD boundaries.
> This would cost one byte per string, half the time. But there was a
> big speed payoff: I could do word operations in my strnlen, strncmp,
> strncpy, and whatever other string processing functions I happened to
> write.

Oh, really?

	char	string1[] = "foo";
	char	string2[] = "xfoo";

	return(strcmp(string1, string2 + 1));

If you can do this with straightforward word operations, and not take a
performance hit relative to byte-by-byte copies, you've got a really clever
"strcmp".  (Hint:  my 68010 manual does *NOT* mention any "swap bytes"
instruction, and the 68010 doesn't have a barrel shifter.)

Furthermore,

	char	string3[128+1];

	strcpy(string3, string1);

would, if it copied a word at a time, have to deal both with words of the
form

	00xx

(when it recognizes a word of that form, it should stop *before* copying it
and stuff a zero byte at the end of the target) and of the form

	xx00

(when it recognizes a word of that form, it should stop *after* copying it).

> All this code ported to a Sun-3 no (apparent) problem, but crashed on a
> Sun-2, because the SUN compiler allocated strings in a totally stingy
> 1-byte alignment.

It would also have crashed on the first example given above *regardless* of
whether the Sun compiler allocated strings on 1-byte or 2-byte boundaries.
If your routines couldn't handle arguments off byte boundaries, I'm sorry,
but they were *not* correct implementations of the string routines!
*!NOTHING*!  guarantees that the arguments to the string routines always
point to the *first* byte of a string.  Furthermore, nothing guarantees that
"strcat" and "strncat" will always do aligned copies, even if the arguments
always point to the first byte of a string; the reason for this should be
obvious.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)