This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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] i386: Assembly Implementation cleanup


On Wed, Aug 12, 2015 at 6:58 AM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
> On 12-08-2015 09:44, H.J. Lu wrote:
>> On Wed, Aug 12, 2015 at 5:38 AM, Adhemerval Zanella
>> <adhemerval.zanella@linaro.org> wrote:
>>>
>>>
>>> On 11-08-2015 21:22, H.J. Lu wrote:
>>>> On Fri, Jul 3, 2015 at 8:41 AM, Adhemerval Zanella
>>>> <adhemerval.zanella@linaro.org> wrote:
>>>>> This patch removes i386 assembly implementation for epoll_wait, mmap,
>>>>> mmap64, semtimeop now that i386 have 6 argument syscall support from
>>>>> C code.
>>>>>
>>>>> The mmap implementation used is the wordsize-32 generic linux one.
>>>>>
>>>>> Tested in i386.
>>>>>
>>>>> ---
>>>>>
>>>>>         * sysdeps/unix/sysv/linux/i386/mmap.c: New file.
>>>>>         * sysdeps/unix/sysv/linux/i386/epoll_pwait.S: Remove file.
>>>>>         * sysdeps/unix/sysv/linux/i386/mmap.S: Likewise.
>>>>>         * sysdeps/unix/sysv/linux/i386/mmap64.S: Likewise.
>>>>>         * sysdeps/unix/sysv/linux/i386/semtimedop.S: Likewise.
>>>>>
>>>>
>>>> What is the motivation?  6 argument syscalls aren't really inlined.
>>>> They put arguments on stack and call __libc_do_syscall.  It is
>>>> slower than assembly code.
>>>>
>>>
>>> Same for ARM: code maintainability on functions that are not really
>>> performance-critical.  This avoids issues like the x86 pthread_cond_*
>>> assembly implementation (which are now aimed to be removed), that
>>> required specific fixes just for x86.
>>
>> Is there a way to truly inline syscall with 6 arguments, not by calling
>> __libc_do_syscall?
>>
>
> I checked around some other projects that implements i386 syscall and
> neither seems to have a workaround for this.  I also recall that Joseph
> has said GCC does not really support to not cobbler the required register,
> so that's why he has implemented through a helper function.  Anyway, as
> Tovarld has asked, I think these are not really heavy hitter (and kernel
> implementation is much more complex than the time to save/restore the
> register in stack).

Let me take a look on this.

-- 
H.J.


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