From: loth AT gec DOT net (Burton Radons)
To: djgpp-workers AT delorie DOT com
Subject: Re: libc replacement (memcmp)
Date: Sat, 21 Mar 1998 22:59:45 GMT
Message-ID: <35164318.29078043@mail.gec.net>
References: <350f6b73 DOT 34099775 AT mail DOT gec DOT net> <3510D70A DOT 7DBC AT rug DOT ac DOT be>
In-Reply-To: <3510D70A.7DBC@rug.ac.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Thu, 19 Mar 1998 09:27:54 +0100, you wrote:

>For functions that are inlined by the compiler, I suggest to leave the
>libc functions in their most simple (and inefficient) form, since they
>won't be used at all. If it is decided to optimize them in despite, it
>may be better to rewrite them in (inline) assembler. That way you might
>get a 1000% speed increase on the slower varieties of x86 processors. 
>On this particular function:
>Since memcmp is often done on byte-aligned data, it may be better to
>pre-align the pointers before going 'lword'.
>Does this function work with s1 or s2 being NULL, or shouldn't it?
>This function contains bugs. (If it may be a hint: unsigned char)

Agreed completely.  On my 486, the inlined memcmp (Sorry Eli, for
contradicting you, you were right) is about 94 times faster than my
patch, and apparently doesn't have page problems.  I think an
optimized memcmp should be in libc, but certainly in better form.
Sorry, everyone.

- Burton Radons, loth AT gec DOT net
Vancouver Island, British Columbia, Canada