On Sun, Mar 22, 2020 at 1:30 AM Joel Sherrill <j...@rtems.org> wrote:
> > > On Sat, Mar 21, 2020 at 3:03 AM Aditya Upadhyay <aadit0...@gmail.com> > wrote: > >> >> >> On Sat, 21 Mar 2020, 10:29 Eshan Dhawan, <eshandhawa...@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 <j...@rtems.org> wrote: >>> >>>> >>>> >>>> On Fri, Mar 20, 2020 at 3:33 PM Eshan Dhawan <eshandhawa...@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 <j...@rtems.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 20, 2020 at 2:43 PM Eshan Dhawan <eshandhawa...@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@rtems.org >>>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>>> >>>>>> _______________________________________________ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel