Re: Cortex-M support / single float

Re: Cortex-M support / single float

[Jon Chesterfield]

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

> note that a large part of the float code in libc is in the
> math library which expects efficient double arithmetics,
> i plan to rewrite the most important single precision math
> functions using double arithmetics, this gives significant
> benefits on all systems except ones with single precision
> only hw.
>

I'm responsible for libm on an architecture with 32bit float in hardware
and 64bit float via integer ops. It's derived from musl because I like musl.

Currently operations written in terms of double are rather slow. Would
upstream accept functions optimised for a 32bit float+int system? I haven't
written them yet but it's on the todo list.

Cheers

Jon

>

[-- Attachment #2: Type: text/html, Size: 1252 bytes --]

Re: Cortex-M support / single float

[Szabolcs Nagy]

* Jon Chesterfield <jonathanchesterfield@gmail.com> [2018-09-13 12:30:45 +0100]:
> > note that a large part of the float code in libc is in the
> > math library which expects efficient double arithmetics,
> > i plan to rewrite the most important single precision math
> > functions using double arithmetics, this gives significant
> > benefits on all systems except ones with single precision
> > only hw.
> >
> 
> I'm responsible for libm on an architecture with 32bit float in hardware
> and 64bit float via integer ops. It's derived from musl because I like musl.
> 
> Currently operations written in terms of double are rather slow. Would
> upstream accept functions optimised for a 32bit float+int system? I haven't
> written them yet but it's on the todo list.
> 

the math code already has target specific code because of
different long double formats, but the policy in musl is to
minimize such variation because of maintainability.

currently we dont support hw float + soft double systems,
but i think such code is acceptable if it's for supporting a
specific target (i think what we would really like to avoid
is configurability: if users of a target can choose between
several different options and change behaviour with many
knobs, that would be hard to test/maintain)

Re: Cortex-M support / single float

[Rich Felker]

On Thu, Sep 13, 2018 at 12:30:45PM +0100, Jon Chesterfield wrote:
> > note that a large part of the float code in libc is in the
> > math library which expects efficient double arithmetics,
> > i plan to rewrite the most important single precision math
> > functions using double arithmetics, this gives significant
> > benefits on all systems except ones with single precision
> > only hw.
> 
> I'm responsible for libm on an architecture with 32bit float in hardware
> and 64bit float via integer ops. It's derived from musl because I like musl.
> 
> Currently operations written in terms of double are rather slow. Would
> upstream accept functions optimised for a 32bit float+int system? I haven't
> written them yet but it's on the todo list.

If implementations with float+int can be reasonably trusted to give
comparable precision (and of course exact results for the functions
specified to be exact), I don't see a reason not to accept them. How
are exception flags handed on such archs? Are the double operations
expected to set the flags in the single-precision fpu correctly? Or
does it just have to be treated as a no-fenv arch?

Rich