This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Adding fenv.h for ARM and SPARC
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