On Sat, Mar 21, 2020, 3:16 PM Aditya Upadhyay <aadit0...@gmail.com> wrote:
> 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? > > > > I have cloned this NetBSD Sources. As I can see those > architecture-specific implemented methods here. Please correct me if I > am looking into different than what you are looking for. > > ./lib/libm/arch/powerpc/fenv.c > ./lib/libm/arch/sh/fenv.c > ./lib/libm/arch/mips64/fenv.c > ./lib/libm/arch/amd64/fenv.c > ./lib/libm/arch/arm/fenv.c > ./lib/libm/arch/i387/fenv.c > ./lib/libm/arch/hppa/fenv.c > ./lib/libm/arch/m88k/fenv.c > ./lib/libm/arch/alpha/fenv.c > ./lib/libm/arch/sparc64/fenv.c > ./lib/libm/arch/aarch64/fenv.c > ./regress/lib/libm/fenv/fenv.c > That's what I see browsing the repo. The single file NetBSD looks easy to integrate. Would be similar to the x86_64 or i386 there now on file layout. Does the freebsd support more hardware variants? > > > --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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 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