32-bit double and long double

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.

Here is the relevant excerpt from the documentation:

> 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

Re: 32-bit double and long double

[Rich Felker]

On Mon, Nov 26, 2018 at 06:25:04PM +0300, Eugene Sharygin wrote:
> 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.

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.

Rich


> Here is the relevant excerpt from the documentation:
> 
> > 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

Re: 32-bit double and long double

[Eugene Sharygin]

Hi Rich,

On 26 November 2018 20:03:39 GMT+03:00, Rich Felker <dalias@libc.org> wrote:
>On Mon, Nov 26, 2018 at 06:25:04PM +0300, Eugene Sharygin wrote:
>> 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.
>
>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

>> Here is the relevant excerpt from the documentation:
>> 
>> > 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).

Re: 32-bit double and long double

[Eugene Sharygin]

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

Hi Rich,

On 26 November 2018 20:03:39 GMT+03:00, Rich Felker <dalias@libc.org> wrote:
>On Mon, Nov 26, 2018 at 06:25:04PM +0300, Eugene Sharygin wrote:
>> 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.
>
>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

>> Here is the relevant excerpt from the documentation:
>> 
>> > 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).

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

Re: 32-bit double and long double

[Jon Chesterfield]

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

>
> 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

>

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

Re: 32-bit double and long double

[Szabolcs Nagy]

* Jon Chesterfield <jonathanchesterfield@gmail.com> [2018-11-26 17:36:58 +0000]:
> > 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)

Re: 32-bit double and long double

[Rich Felker]

On Mon, Nov 26, 2018 at 05:36:58PM +0000, Jon Chesterfield wrote:
> >
> > 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.

> 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.

> 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

Re: 32-bit double and long double

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2018-11-26 21:32:11 -0500]:
> On Mon, Nov 26, 2018 at 05:36:58PM +0000, Jon Chesterfield wrote:
> > 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.