Sources for fenv (ARM, PPC, x86, SPARC and RISC5)
Gedare Bloom
gedare at rtems.org
Wed Jul 17 18:12:33 UTC 2019
On Tue, Jul 16, 2019 at 6:57 AM Joel Sherrill <joel at rtems.org> wrote:
>
> Let's give preference to FreeBSD sources. Notes below.
>
> On Wed, Jul 3, 2019 at 1:08 PM Vaibhav Gupta <vaibhavgupta40 at gmail.com> wrote:
>>
>> Hello,
>> I have found sources for fenv.
>>
>> 1.1) - ARM FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.c
>> .
>> 1.2) - ARM NetBSD Source :
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/arm/fenv.c
>> -----------------------------------------------------------------------------
>
>
> For the ARM FreeBSD source, there are some ifdef's which appear to
> be for architectural variations. Please check the gcc source for arm
> (gcc-XXX/gcc/config/arm) to see if they are defined by gcc. If they
> all are, then there is nothing to consider on how they get tripped.
>
> For example, __ARM_PCS_AAPCS64 is one. That looks like a multilib
> define.
>
>>
>> 2.1) - SPARC NetBSD Source :
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/sparc/fenv.c
>> ----------------------------------------------------------------------------
>
>
> This looks good and may work for sparc64 as well as sparc. Check if
> sparc64-rtems5-gcc defines __arch64 as used byL
>
> https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h#L36
>
>>
>> 3.1) - PPC FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.c
>> .
>> 3.2) - PPC NetBSD Source:
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/powerpc/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/powerpc/fenv.c
>> ---------------------------------------------------------------------------
>
>
> Sam advice on PPC. Looks OK, check ifdefs
>
>>
>> 4.1) - x86 FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/x86/fenv.h
>> .
>> 4.2) - x86 NetBSD Source:
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/x86_64/fenv.c
>> --------------------------------------------------------------------------
>
>
> This is not i386 (e.g. 32-bit), it is for the 64-bit target. Good to merge it into
> newlib but we don't have a fully functional port to test this with.
>
>>
>> 5.1) - RISC5 FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.c
>> .
>> 5.2) - RISC5 NetBSD Source:
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/riscv/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/riscv/fenv.c
>> ========================================================
>
>
> Same advice.
>
>>
>> ========================================================
>>
>> It's impossible to depend on either NetBSD or FreeBSD.
>
>
> Yep. Give preference to FreeBSD but if it isn't in FreeBSD, use NetBSD.
>>
>> .
>> For some architectures, FreeBSD has code,
>> for some, NetBSD has.
>> .
>> For x86, Free BSD has explicit header
>> and NetBSD has .c file.
>
>
> These are all architecture specific files so do not go in a main include
> or source directory. They go in an architecture specific subdirectory.
>
> See https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libm/machine;h=9b2197b2660fd84c6b64ef265c1ec3b6e30c9074;hb=HEAD
>
> And notice that arm, aarch64, riscv, and i386 are all already there. Looks
> like you can focus on the ones not there (PPC and SPARC). Ignore x86_64
> for now. If there is a ticket for the port, just add a comment to that. I don't
> think we are setup to test that port right now.
>
Since arm/riscv/i386 are there, you might be able to write an fenv
test suite that can pass on one of those archs, and then use it with
confidence to do TDD of other architectures.
> Hope that all makes sense.
>
> --joel
>
>> .
>> .
>> .
>> Vaibhav Gupta
More information about the devel
mailing list