This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Update newlib to support efficient string operation functions for Thumb.


Hi Corinna,

I agree. I just need to leave the wrapper blank. The libc/string/ will be automatically pulled in as the default definition.

Thanks for your command. I will update this patch and do some testing locally before I send it out.

Thanks and Best Regards,
Hale Wang

> -----Original Message-----
> From: newlib-owner@sourceware.org [mailto:newlib-
> owner@sourceware.org] On Behalf Of Corinna Vinschen
> Sent: 2014å8æ14æ 16:28
> To: newlib@sourceware.org
> Subject: Re: Update newlib to support efficient string operation functions for
> Thumb.
> 
> Hi Hale,
> 
> On Aug 14 12:14, Hale Wang wrote:
> > Hi,
> >
> > The source files in newlib/libc/machine/arm/ are not so efficient
> > enough to sopport Thumb.
> >
> > For Cortex-M0, if we don't define '__OPTIMIZE_SIZE__' or
> > 'PREFER_SIZE_OVER_SPEED' which means size is not preferred,
> > inefficient code will be used. This may result in pool benchmark
> performance.
> >
> > In this case, we can include newlib/libc/string/strcmp.c to improve
> > the performance. And if size is preferred, the original code will be used.
> >
> > I have done some tests on Dhrystone benchmark, and the performance of
> > Cortex-M0 can be improved to 13% with this solution.
> >
> > The strlen.c can be improved in the similar way.
> >
> > Bootstrap and no make check regression on X86-64.
> 
> This patch is a bit complicated.  You're explicitely including ../../string/*.c, but
> that's not necessary.  What you should do is this:  Use #if to define the
> scenario in which the assembler code should not be used:
> 
>   # if [thumb1 && no-size-opimization]
> 
>     [code here]
> 
>   #endif
> 
> The result is that the strlen/strcmp functions won't be defined in the
> assembler-optimized files, and that will automatically pull in the default C
> definitions of strlen/strcmp from libc/string.  No reason to include them
> explicitely.
> 
> Along the same lines, the strcmp-stub.c file should not be necessary.
> Just don't define the strcmp() function in the assembler file in the scenario
> you don't want it, and newlib will fall back to the C function defined in
> libc/string/strcmp.c.
> 
> 
> Corinna
> 
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]