Sources to port fenv.h to ARM and AARCH64

Eshan Dhawan eshandhawan51 at gmail.com
Sat Mar 21 20:15:55 UTC 2020


On Sun, Mar 22, 2020 at 1:30 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Sat, Mar 21, 2020 at 3:03 AM Aditya Upadhyay <aadit0402 at gmail.com>
> wrote:
>
>>
>>
>> On Sat, 21 Mar 2020, 10:29 Eshan Dhawan, <eshandhawan51 at gmail.com> wrote:
>>
>>> I went through the FreeBSD and NetBSD sources for implementation
>>> In FreeBSD there is an architecture-specific implementation with
>>> different header file for each architecture it supports .
>>> Whereas in NetBSD there is a single fenv.h defined but each architecture
>>> has its own C file to implement the functions.
>>> Also FreeBSD has soft-float for ARM
>>> So, I think FreeBSD would be a better option.
>>>
>>
>> Look into this discussion on mail thread:
>> https://sourceware.org/legacy-ml/newlib/2017/msg00818.html
>>
>> and this patch series on newlib mailing list.
>>
>> https://sourceware.org/legacy-ml/newlib/2019/msg00418.html .
>>
>> It will help to understand the fenv-stub code.
>>
>
> I am having trouble finding the implementation of any fenv method in the
> NetBSD code. I only am finding the weak alias mappings. Where is an example
> of the body of one of the methods in any architecture?
>

This is the implementation File of fenv.c in arm
https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/arm/fenv.c
It contains some sort of implementation for arm

This is the implementation File of fenv.c in aarch
https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/aarch64/fenv.c
It contains some sort of implementation for aarch

--eshan

>
> --joel
>
>>
>>
>>
>>> On Sat, Mar 21, 2020 at 2:37 AM Joel Sherrill <joel at rtems.org> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Mar 20, 2020 at 3:33 PM Eshan Dhawan <eshandhawan51 at gmail.com>
>>>> wrote:
>>>>
>>>>> thanks, dr Joel
>>>>>
>>>>> I had gone through the musl-libc library but it doesn't have much
>>>>> architecture specific support for ARM as well as AARCH64
>>>>> It has support for s390x, m68k, powerpc64
>>>>>
>>>>
>>>> This type of evaluation is important.  The architecture may be
>>>> supported in only one implementation or one may be more complete than
>>>> another.
>>>>
>>>> Ignoring the license requirements of course.
>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 21, 2020 at 1:32 AM Joel Sherrill <joel at rtems.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 20, 2020 at 2:43 PM Eshan Dhawan <eshandhawan51 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> What would be the preferred source to port fenv.h to ARM and AARCH64
>>>>>>> its implementation is present in both FreeBSD as well AS NetBSD
>>>>>>> -> ARM
>>>>>>> ---FreeBSD Source
>>>>>>> # https://github.com/freebsd/freebsd/tree/master/lib/msun/arm
>>>>>>> ---NetBSD Source
>>>>>>> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm
>>>>>>>
>>>>>>> ->AARCH64
>>>>>>> ---FreeBSD Source
>>>>>>> # https://github.com/freebsd/freebsd/tree/master/lib/msun/aarch64
>>>>>>> ---NetBSD Source
>>>>>>> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64
>>>>>>>
>>>>>>
>>>>>> Don't forget MUSL-C Library which has a lot of architectures and
>>>>>> is appropriately licensed.
>>>>>>
>>>>>> https://git.musl-libc.org/cgit/musl/tree/src/fenv
>>>>>>
>>>>>> I think our the order is going to be FreeBSD, NetBSD, then other
>>>>>> places.
>>>>>>
>>>>>> The code drops into newlib's libm in a particular way which may
>>>>>> require
>>>>>> some refactoring. fenv.h is shared across all ports and
>>>>>> machine/fenv.h is
>>>>>> where port code goes. There must be an architecture specific file for
>>>>>> each
>>>>>> method. But the entire implementation could go in one file and the
>>>>>> others
>>>>>> be stubs. The i386 does this.
>>>>>>
>>>>>> --joel
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64>
>>>>>>>
>>>>>>> Thanks
>>>>>>> -Eshan
>>>>>>> _______________________________________________
>>>>>>> devel mailing list
>>>>>>> devel at rtems.org
>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>
>>>>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200322/88413c91/attachment-0001.html>


More information about the devel mailing list