This is the mail archive of the cygwin-patches mailing list for the Cygwin 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: [patch cygwin]: Replace inline-assembler in string.h by C implementation


On Thu, Oct 25, 2012 at 10:48:39AM +0200, Corinna Vinschen wrote:
>On Oct 24 18:02, Kai Tietz wrote:
>>2012/10/24 Christopher Faylor wrote:
>>>On Wed, Oct 24, 2012 at 11:07:47AM -0400, Ryan Johnson wrote:
>>>>On 24/10/2012 5:16 AM, Kai Tietz wrote:
>>>>>Hello,
>>>>>
>>>>>this patch replaces the inline-assember used in string.h by C
>>>>>implementation.  There are three reasons why I want to suggest this.
>>>>>First, the C-code might be optimized further by fixed (constant)
>>>>>arguments.  Secondly, it is architecture independent and so we just
>>>>>need to maintain on code-path.  And as third point, by inspecting
>>>>>generated assembly code produced by compiler out of C code vs.
>>>>>inline-assembler it shows that compiler produces better code.  It
>>>>>handles jump-threading better, and also improves average executed
>>>>>instructions.
>>>>Devil's advocate: better-looking code isn't always faster code.
>>>>
>>>>However, I'm surprised that code was inline asm in the first place --
>>>>no special instructions or unusual control flow -- and would not be at
>>>>all surprised if the compiler does a better job.
>>>>
>>>>Also, the portability issue is relevant now that cygwin is starting the
>>>>move toward 64-bit support.
>>>
>>>Yes, that's exactly why Kai is proposing this.
>>>
>>>I haven't looked at the code but I almost always have one response to a
>>>"I want to rewrite a standard function" patches:
>>>
>>>Have you looked at other implementations?  The current one was based on
>>>a linux implementation.  A C version of these functions has likely been
>>>written before, possibly even in newlib.  Were those considered?
>>
>>Sure, I have looked up standard-implementation of
>>stricmp/strnicmp/strchr as code-base.  We could of course simply use
>>C-runtime-funktions here, but well, those wouldn't be inlined.  The
>>latter seems to me the only cause why string.h implements them at all.
>>They are defined there as 'static inline', which makes them pure
>>inlines.
>
>Right, that's what I forgot entirely in my reply.  From my POV they are
>good to go.  Chris?

Ok.  I wonder if newlib should be investigating make some of these inline
but that's not something that we have to worry about I guess.

cgf


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