Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!oberon!sm.unisys.com!ism780c!ico!nbires!maa
From: maa@nbires.nbi.com (Mark Armbrust)
Newsgroups: comp.arch
Subject: Re: Endian wars
Summary: Nitpicking (nits are in season, aren't they?)
Message-ID: <213@nbires.nbi.com>
Date: 30 Jan 89 16:43:02 GMT
References: <6133@columbia.edu> <5124@aldebaran.UUCP> <7@microsoft.UUCP>
Reply-To: maa@nbires.UUCP (Mark Armbrust)
Distribution: na
Organization: NBI Inc, Boulder CO
Lines: 37

In article <7@microsoft.UUCP> jangr@microsoft.UUCP (Jan Gray) writes:
>In article <5124@aldebaran.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
>
>This went around comp.arch a while ago.
>	has_NUL = (((i-0x01010101)&~i)&0x80808080) != 0,
>e.g. "test if there were any borrows as a result of the bytewise subtracts"
>
>Using this trick on the '386, strlen on long strings can be made about 30%
>faster than using the dedicated string instruction "rep scasb"!

@:	lodsd				5 clocks to execute
	mov	ebx, eax		2
	sub	eax, 01010101h		3
	not	ebx			2
	and	eax, ebx		3
	and	eax, 80808080h		3
	loopz	<			12 (30 clocks/19 bytes)

Seems to me that the following would be a bit faster: 

@:	lodsd				5 clocks to execute
	mov	ebx, eax		2
	shr	ebx, 16			3
	and	ax, bx			3
	and	al, ah			3
	loopnz	@			12 (28 clocks/13 bytes)

In any case, I prefer strings stored with leading count instead of trailing
zero's--I've been thinking of writing an alternate library for C to be able
to handle them.  Some of the programming I've done could have benifitted from
this type of strings.  (So what if they're longer--memory is cheaper than
execution speed.)

Mark

(I should know better by now to post things when I have a nasty cold--there's
prob'ly something wrong with the above and I'll be burried in mail :-( )