[musl] 32-bit double and long double

[Eugene Sharygin]

Hi,

We're using Musl on a platform where both float, double, and long double
are in IEEE-754 binary32 format, and I'm wondering if a patch that lifts
some of the assumptions made regarding widths of floating-point types
would be accepted.

Floating-point formats are assumed to be IEEE-754 binary32 format for
float and IEEE-754 binary64 for double.
Supported long double formats: IEEE-754 binary64 (ld64) and x86 80 bit
extended precision format (ld80) are fully supported and there is
partial support for IEEE-754 binary128 (ld128).

Eugene

[Rich Felker]

This post might be inappropriate. Click to display it.

[Eugene Sharygin]

Hi Rich,

Post by Eugene Sharygin

Post by Eugene Sharygin
Hi,
We're using Musl on a platform where both float, double, and long

double

Post by Eugene Sharygin
are in IEEE-754 binary32 format, and I'm wondering if a patch that

lifts

Post by Eugene Sharygin
some of the assumptions made regarding widths of floating-point types
would be accepted.

No, musl only supports (roughly) Annex-F conforming environments, with
IEEE single and double and a long double type with IEEE-compatible
semantics. Such patches won't be accepted upstream.
Is there a reason your target is defining double in an unuseful and
incompatible way rather than doing hard-single and soft-double? If you
have any control over the choice of ABI, I think the latter makes a
lot more sense.

I guess it does. The platform is very memory constrained though, so we'll
have to evaluate first.

Thank you for suggestion!

Eugene

Post by Eugene Sharygin

Post by Eugene Sharygin

Floating-point formats are assumed to be IEEE-754 binary32 format

for

Post by Eugene Sharygin

float and IEEE-754 binary64 for double.
Supported long double formats: IEEE-754 binary64 (ld64) and x86 80

bit

Post by Eugene Sharygin

extended precision format (ld80) are fully supported and there is
partial support for IEEE-754 binary128 (ld128).

[Eugene Sharygin]

Hi Rich,

Post by Eugene Sharygin

Post by Eugene Sharygin
Hi,
We're using Musl on a platform where both float, double, and long

double

Post by Eugene Sharygin
are in IEEE-754 binary32 format, and I'm wondering if a patch that

lifts

Post by Eugene Sharygin
some of the assumptions made regarding widths of floating-point types
would be accepted.

No, musl only supports (roughly) Annex-F conforming environments, with
IEEE single and double and a long double type with IEEE-compatible
semantics. Such patches won't be accepted upstream.
Is there a reason your target is defining double in an unuseful and
incompatible way rather than doing hard-single and soft-double? If you
have any control over the choice of ABI, I think the latter makes a
lot more sense.

I guess it does. The platform is very memory constrained though, so we'll
have to evaluate first.

Thank you for suggestion!

Eugene

Post by Eugene Sharygin

Post by Eugene Sharygin

Floating-point formats are assumed to be IEEE-754 binary32 format

for

Post by Eugene Sharygin

float and IEEE-754 binary64 for double.
Supported long double formats: IEEE-754 binary64 (ld64) and x86 80

bit

Post by Eugene Sharygin

extended precision format (ld80) are fully supported and there is
partial support for IEEE-754 binary128 (ld128).

[Jon Chesterfield]

Post by Rich Felker
Is there a reason your target is defining double in an unuseful and
incompatible way rather than doing hard-single and soft-double? If you
have any control over the choice of ABI, I think the latter makes a
lot more sense.

I can see a few arguments for float==double, but haven't actually done that
for our target yet.

A common error is to write 1.0 instead of 1.0f, where the former sometimes
pulls in the soft double support.

Integer arguments to libm functions promote to double but I would prefer
promote to 32 bit float.

Arguments to variadic functions promote to double. Again I would prefer 32
bit float.

Leaving long double as 64 bit, unlike in the question, means no loss of
functionality relative to double == long double.

Cheers

Jon

[Szabolcs Nagy]

Post by Jon Chesterfield

Post by Rich Felker
Is there a reason your target is defining double in an unuseful and
incompatible way rather than doing hard-single and soft-double? If you
have any control over the choice of ABI, I think the latter makes a
lot more sense.

I can see a few arguments for float==double, but haven't actually done that
for our target yet.
A common error is to write 1.0 instead of 1.0f, where the former sometimes
pulls in the soft double support.
Integer arguments to libm functions promote to double but I would prefer
promote to 32 bit float.
Arguments to variadic functions promote to double. Again I would prefer 32
bit float.
Leaving long double as 64 bit, unlike in the question, means no loss of
functionality relative to double == long double.

lot of existing c code assumes double is 64bit,
(and you don't get a compile error building them,
just wrong results)

if you expect users to write software from scratch
for your target then using 32bit double is fine
(e.g. baremetal embedded software)

if you expect existing libraries to work on your
target then double should be 64bit.
(e.g. you want linux userspace)

[Rich Felker]

Post by Jon Chesterfield

Post by Rich Felker
Is there a reason your target is defining double in an unuseful and
incompatible way rather than doing hard-single and soft-double? If you
have any control over the choice of ABI, I think the latter makes a
lot more sense.

I can see a few arguments for float==double, but haven't actually done that
for our target yet.
A common error is to write 1.0 instead of 1.0f, where the former sometimes
pulls in the soft double support.

I think gcc has a language-variant option to make floating point
constants float by default rather than double, but this is probably a
bad idea. Better would be just setting up your tooling to catch
inadvertent use of double where it's not wanted/needed.

Post by Jon Chesterfield
Integer arguments to libm functions promote to double but I would prefer
promote to 32 bit float.

This is only the case if you're calling the functions that take double
arguments. If you call the float ones, promotion is just to float.
It's your choice which you use.

Post by Jon Chesterfield
Arguments to variadic functions promote to double. Again I would prefer 32
bit float.

Indeed this is a hard limitation of the language. I suppose it comes
in mostly/only for passing floating point values to printf. The
promotion should at least be nothing more than a few 64-bit shift/or
ops.

Rich

[Szabolcs Nagy]

Post by Rich Felker

Post by Jon Chesterfield
Arguments to variadic functions promote to double. Again I would prefer 32
bit float.

Indeed this is a hard limitation of the language. I suppose it comes
in mostly/only for passing floating point values to printf. The
promotion should at least be nothing more than a few 64-bit shift/or
ops.

well floating-point is usually tricky..

conversion to double should signal an invalid exception for snan.

subnormal range values need different logic than normal range ones
and likely require a clz operation.

if you support flush-to-zero arithmetics then subnormal input
should raise an input-denormal exception and treat it as zero.

..but all this is implemented in libgcc soft-fp support.