Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181126181957.GR21289@port70.net>
Date: Mon, 26 Nov 2018 19:19:58 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: 32-bit double and long double

* Jon Chesterfield <jonathanchesterfield@...il.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)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.