<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 21, 2020, 3:16 PM Aditya Upadhyay <<a href="mailto:aadit0402@gmail.com">aadit0402@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Mar 22, 2020 at 1:30 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a>> wrote:<br>
><br>
><br>
><br>
> On Sat, Mar 21, 2020 at 3:03 AM Aditya Upadhyay <<a href="mailto:aadit0402@gmail.com" target="_blank" rel="noreferrer">aadit0402@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Sat, 21 Mar 2020, 10:29 Eshan Dhawan, <<a href="mailto:eshandhawan51@gmail.com" target="_blank" rel="noreferrer">eshandhawan51@gmail.com</a>> wrote:<br>
>>><br>
>>> I went through the FreeBSD and NetBSD sources for implementation<br>
>>> In FreeBSD there is an architecture-specific implementation with different header file for each architecture it supports .<br>
>>> Whereas in NetBSD there is a single fenv.h defined but each architecture has its own C file to implement the functions.<br>
>>> Also FreeBSD has soft-float for ARM<br>
>>> So, I think FreeBSD would be a better option.<br>
>><br>
>><br>
>> Look into this discussion on mail thread:<br>
>> <a href="https://sourceware.org/legacy-ml/newlib/2017/msg00818.html" rel="noreferrer noreferrer" target="_blank">https://sourceware.org/legacy-ml/newlib/2017/msg00818.html</a><br>
>><br>
>> and this patch series on newlib mailing list.<br>
>><br>
>> <a href="https://sourceware.org/legacy-ml/newlib/2019/msg00418.html" rel="noreferrer noreferrer" target="_blank">https://sourceware.org/legacy-ml/newlib/2019/msg00418.html</a> .<br>
>><br>
>> It will help to understand the fenv-stub code.<br>
><br>
><br>
> 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?<br>
><br>
<br>
I have cloned this NetBSD Sources. As I can see those<br>
architecture-specific implemented methods here. Please correct me if I<br>
am looking into different than what you are looking for.<br>
<br>
./lib/libm/arch/powerpc/fenv.c<br>
./lib/libm/arch/sh/fenv.c<br>
./lib/libm/arch/mips64/fenv.c<br>
./lib/libm/arch/amd64/fenv.c<br>
./lib/libm/arch/arm/fenv.c<br>
./lib/libm/arch/i387/fenv.c<br>
./lib/libm/arch/hppa/fenv.c<br>
./lib/libm/arch/m88k/fenv.c<br>
./lib/libm/arch/alpha/fenv.c<br>
./lib/libm/arch/sparc64/fenv.c<br>
./lib/libm/arch/aarch64/fenv.c<br>
./regress/lib/libm/fenv/fenv.c<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That's what I see browsing the repo.</div><div dir="auto"><br></div><div dir="auto">The single file NetBSD looks easy to integrate. Would be similar to the x86_64 or i386 there now on file layout. </div><div dir="auto"><br></div><div dir="auto">Does the freebsd support more hardware variants?</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> --joel<br>
>><br>
>><br>
>><br>
>>><br>
>>> On Sat, Mar 21, 2020 at 2:37 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Fri, Mar 20, 2020 at 3:33 PM Eshan Dhawan <<a href="mailto:eshandhawan51@gmail.com" target="_blank" rel="noreferrer">eshandhawan51@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> thanks, dr Joel<br>
>>>>><br>
>>>>> I had gone through the musl-libc library but it doesn't have much architecture specific support for ARM as well as AARCH64<br>
>>>>> It has support for s390x, m68k, powerpc64<br>
>>>><br>
>>>><br>
>>>> This type of evaluation is important. The architecture may be supported in only one implementation or one may be more complete than another.<br>
>>>><br>
>>>> Ignoring the license requirements of course.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Sat, Mar 21, 2020 at 1:32 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Fri, Mar 20, 2020 at 2:43 PM Eshan Dhawan <<a href="mailto:eshandhawan51@gmail.com" target="_blank" rel="noreferrer">eshandhawan51@gmail.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> What would be the preferred source to port fenv.h to ARM and AARCH64<br>
>>>>>>> its implementation is present in both FreeBSD as well AS NetBSD<br>
>>>>>>> -> ARM<br>
>>>>>>> ---FreeBSD Source<br>
>>>>>>> # <a href="https://github.com/freebsd/freebsd/tree/master/lib/msun/arm" rel="noreferrer noreferrer" target="_blank">https://github.com/freebsd/freebsd/tree/master/lib/msun/arm</a><br>
>>>>>>> ---NetBSD Source<br>
>>>>>>> # <a href="https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm" rel="noreferrer noreferrer" target="_blank">https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm</a><br>
>>>>>>><br>
>>>>>>> ->AARCH64<br>
>>>>>>> ---FreeBSD Source<br>
>>>>>>> # <a href="https://github.com/freebsd/freebsd/tree/master/lib/msun/aarch64" rel="noreferrer noreferrer" target="_blank">https://github.com/freebsd/freebsd/tree/master/lib/msun/aarch64</a><br>
>>>>>>> ---NetBSD Source<br>
>>>>>>> # <a href="https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64" rel="noreferrer noreferrer" target="_blank">https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64</a><br>
>>>>>><br>
>>>>>><br>
>>>>>> Don't forget MUSL-C Library which has a lot of architectures and<br>
>>>>>> is appropriately licensed.<br>
>>>>>><br>
>>>>>> <a href="https://git.musl-libc.org/cgit/musl/tree/src/fenv" rel="noreferrer noreferrer" target="_blank">https://git.musl-libc.org/cgit/musl/tree/src/fenv</a><br>
>>>>>><br>
>>>>>> I think our the order is going to be FreeBSD, NetBSD, then other places.<br>
>>>>>><br>
>>>>>> The code drops into newlib's libm in a particular way which may require<br>
>>>>>> some refactoring. fenv.h is shared across all ports and machine/fenv.h is<br>
>>>>>> where port code goes. There must be an architecture specific file for each<br>
>>>>>> method. But the entire implementation could go in one file and the others<br>
>>>>>> be stubs. The i386 does this.<br>
>>>>>><br>
>>>>>> --joel<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Thanks<br>
>>>>>>> -Eshan<br>
>>>>>>> _______________________________________________<br>
>>>>>>> devel mailing list<br>
>>>>>>> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
>>>>>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>>><br>
>>> _______________________________________________<br>
>>> devel mailing list<br>
>>> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>