Update newlib to support efficient string operation functions for Thumb.

Corinna Vinschen vinschen@redhat.com
Thu Aug 14 08:28:00 GMT 2014

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]


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 Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20140814/a2f0282e/attachment.sig>

More information about the Newlib mailing list