RE: Adding fenv.h for ARM and SPARC

RE: Adding fenv.h for ARM and SPARC

[Wilco Dijkstra]

Aditya wrote:
> I do not have any idea about introducing softfloat in newlib and how
> this should be implemented in newlib. NetBSD uses softfloat and
> implemented fenv support for spu arch in different way as compare to
> implementation of fenv methods in newlib for spu arch.
>
> Would anyone please suggest me where and how to add fenv support for newlib.

When you use software floating point there is no need for fenv. The rounding
mode is fixed and there are no exceptions. You could do an empty (no-effect)
implementation but it wouldn't work with software that changes rounding mode
or tests/sets exception flags.

Wilco

RE: Adding fenv.h for ARM and SPARC

[Jon Beniston]

>When you use software floating point there is no need for fenv. The
rounding mode is
> fixed and there are no exceptions. 

That's not true for the softfloat lib though (assuming we're talking about
(http://www.jhauser.us/arithmetic/SoftFloat.html) - which I believe supports
both.

Cheers,
Jon

Re: Adding fenv.h for ARM and SPARC

[Wilco Dijkstra]

Jon Beniston wrote:
>>When you use software floating point there is no need for fenv. The
> rounding mode is
>> fixed and there are no exceptions. 
>
> That's not true for the softfloat lib though (assuming we're talking about
> (http://www.jhauser.us/arithmetic/SoftFloat.html) - which I believe supports
> both.

I was guessing that wasn't what the OP meant. The spu target was mentioned,
which has an fenv implementation in newlib - but that is for hardware floating point.

But yes it would be good if the OP clarifies what they are proposing.

Wilco



    

Re: Adding fenv.h for ARM and SPARC

[Joel Sherrill]

On 8/14/2017 7:46 AM, Wilco Dijkstra wrote:
> Jon Beniston wrote:
>>> When you use software floating point there is no need for fenv. The
>> rounding mode is
>>> fixed and there are no exceptions.
>>
>> That's not true for the softfloat lib though (assuming we're talking about
>> (http://www.jhauser.us/arithmetic/SoftFloat.html) - which I believe supports
>> both.
> 
> I was guessing that wasn't what the OP meant. The spu target was mentioned,
> which has an fenv implementation in newlib - but that is for hardware floating point.
> 
> But yes it would be good if the OP clarifies what they are proposing.

Aditya is an RTEMS Google Summer of Code student so let me try to explain
the goal.

newlib has very limited support for fenv.h. I forgot most of the
target architectures do have a mix of hard and soft float multilibs
but soft float isn't the main goal.

We want him to bring over the fenv.h support for as many architectures
as possible from NetBSD and FreeBSD.  They appear to have a structure
of <fenv.h> including <machine/fenv.h>. It would be great if newlib
followed this pattern so we could just drop in their support. That
leads to a few questions on how to achieve this:

+ Where would a file installed for the ARM as machine/fenv.h
need to be in the newlib/libm/machine source tree? I think
it would be newlib/libm/machine/ARCH/machine/fenv.h.

+ A common fenv.h would be nice. Could we use the *BSD fenv.h
over in libc/include and then have it include machine/fenv.h.
I think this would require reconciling the SPU and perhaps
winsup versions.

+ If the *BSD implementation has source files, they
would drop in libm/machine/ARCH/.

That does leave the question of what happens to all of
fenv.h when soft-float is enabled. But the first order
of business was to move newlib libm from really not
having any fenv.h support for the main architectures
to using the *BSD support.

That should provide the background on what he is trying
to do. If the SPU weren't in the tree, this would be
easier. :)

--joel
RTEMS


> Wilco
> 

Re: Adding fenv.h for ARM and SPARC

[Szabolcs Nagy]

On 14/08/17 15:04, Joel Sherrill wrote:
> That does leave the question of what happens to all of
> fenv.h when soft-float is enabled. But the first order
> of business was to move newlib libm from really not
> having any fenv.h support for the main architectures
> to using the *BSD support.

the standard specifies how fenv.h behaves if there
is no support for exceptions or rounding modes,
so soft-float should not be an issue.
(e.g. FE_* macros are not defined if there is no
support for them)

in principle soft-float can support exceptions and
rounding modes, but in multi-thread environment it
has to be thread local state which in practice means
there needs to be hw control/status registers that
are handled at a context switch (otherwise some
tls abi has to be introduced between the compiler
that provides the soft fp emulation and the libc
which manages tls, i think this was not done
historically since c99 implicitly also required that
fenv is as-safe so fp arithmetics works in signal
handlers which requires blocking signals in every
fp operation that may access the fenv or it needs
to be saved/restored around signal handlers by some
mechanism, this was changed in c11, fp arithmetics
is no longer as-safe so plain tls fenv would work
or if newlib does not provide threads for a target
then global fenv would work)

Adding fenv.h for ARM and SPARC

[Aditya Upadhyay]

Hello All,

I do not have any idea about introducing softfloat in newlib and how
this should be implemented in newlib. NetBSD uses softfloat and
implemented fenv support for spu arch in different way as compare to
implementation of fenv methods in newlib for spu arch.

Would anyone please suggest me where and how to add fenv support for newlib.


Thanks & Regards,
Aditya

Re: Adding fenv.h for ARM and SPARC

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

On Aug 13 22:45, Aditya Upadhyay wrote:
> Hello All,
> 
> I do not have any idea about introducing softfloat in newlib and how
> this should be implemented in newlib. NetBSD uses softfloat and
> implemented fenv support for spu arch in different way as compare to
> implementation of fenv methods in newlib for spu arch.
> 
> Would anyone please suggest me where and how to add fenv support for newlib.
> 
> 
> Thanks & Regards,
> Aditya

If somebody wants to help here, it's appreciated.  I'm much too fuzzy on
FP stuff to answer this question.


Corinna
/crawling back into her cave/

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]