Re: Minimum floating-point requirements

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Jan 30, 2014 at 02:38:16PM +0000, Joseph S. Myers wrote:
> On Wed, 29 Jan 2014, Carlos O'Donell wrote:
> 
> > However, I think new ports do have the right to approach the community
> > to discuss why they may want to *not* use an IEEE format. The new port
> > would have to clearly explain their position and user requirements,
> > since a non-IEEE format is difficult to maintain in a unified framework
> > that relies on IEEE semantics.
> > 
> > Do we have a wiki page describing the policies for new ports?
> 
> No, we don't.  There are lots of unwritten expectations in glibc code 
> regarding the platform ABI - for example, that int is 32 bits, and 
> intmax_t is 64 bits.  I think we'd be unlikely to accept a port whose ABI 
> had non-32-bit int, but might well accept one where intmax_t is __int128 
> which is a proper integer type on that platform.  (Some ABI expectations 
> are hardcoded in GCC as well - for example, GCC only supports two's 
> complement integer types, although ISO C allows other representations.  
> POSIX requires 8-bit bytes, and by virtue of the types required in 
> <stdint.h> requires at least some types to be two's complement.)
> 
> (Code shared with gnulib generally aims to be portable to a wider range of 
> systems than glibc as a whole.)
> 
> An implication of my proposals is that if someone were, say, to propose a 
> VAX port of glibc (i.e. a new such port, for use with the Linux kernel, 
> since glibc used to support VAX) it would be expected to use software IEEE 
> floating point rather than hardware VAX floating point, because of the 
> disproportionate cost of VAX floating point support compared to any 
> benefit gained from it.  (I would also strongly discourage any new ports 
> from using IBM long double, although such discouragement of new ports from 
> using an existing feature isn't part of my proposal.)

I would agree on these points, but go a bit further on IBM long
double. My view (which you can take or leave) on long double is that
it's there to allow software to get access to higher precision
supported by the hardware, not for software emulation of
higher-precision types, and especially not poor-quality ones like IBM
long double that break basic floating point semantics. So I would at
least encourage new ports to simply define long double as double
unless there's support (or planned future support) for IEEE quad or an
existing IEEE extended precision type (like ld80) at the hardware
level.

Rich