This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: Mips optimized versions of strlen, strncpy, strcmp
- From: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- To: "Aaron J. Grier" <aaron at frye dot com>
- Cc: newlib at sources dot redhat dot com
- Date: Thu, 15 Nov 2001 11:28:24 -0600
- Subject: Re: Mips optimized versions of strlen, strncpy, strcmp
- Organization: OAR Corporation
- References: <200111132044.fADKi6b03446@tiktok.cygnus.com> <20011114143155.L20777@aaron.internal>
- Reply-to: joel dot sherrill at OARcorp dot com
"Aaron J. Grier" wrote:
>
> On Tue, Nov 13, 2001 at 03:44:06PM -0500, Michael Meissner wrote:
>
> > In general, I feel that the str* (& to some extent the mem*) functions
> > in newlib could be better tuned for different machines (I suspect you
> > may wind up with 3-4 versions, depending on whether a machine has pre
> > or post incrementation, how deep the pipeline is to/from memory,
> > etc.).
>
> I was looking at these a few weeks ago as well... the loop unrolling
> done in some of the string operations is silly to do on m68k cpu32
> variants, since they have a loop mode. I imagine other architectures
> are similar.
I tend to agree with Michael, if there were probably a handful of standard C
implementations from which the architectures could choose, most would end
up with a better performing version. One implementation could favor code
space, another could unroll loops, another could do memory operations in
larger non-octet chunks, etc. The trick is to make sure the various
implementations can be shared and that an architecture pick the one
that suits it the best.
For example, I am pretty sure that the m68k and other CISC would do well with
an
implementation that arranged to move 32-bit quantities as much as possible.
The i386 would do OK with this but its string instructions are probably still
better.
> maybe some of these could be moved to libgloss for the architecture-
> specific implementations?
I think libgloss is for board specific code. This type of code
is normally in libc/machine.
> --
> Aaron J. Grier | Frye Electronics, Tigard, OR | aaron@frye.com
> "In a few thousand years people will be scratching their heads
> wondering how on earth the first computer was invented and
> bootstrapped without a prior computer to do it with."
> -- Chris Malcolm, on comp.arch
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985