Discussion:
[musl] Cortex-M support / single float
Jon Chesterfield
2018-09-13 11:30:45 UTC
Permalink
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
Szabolcs Nagy
2018-09-13 12:51:30 UTC
Permalink
Post by Jon Chesterfield
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)
Rich Felker
2018-09-13 15:39:25 UTC
Permalink
Post by Jon Chesterfield
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

Loading...