Re: Minimum floating-point requirements

["Joseph S. Myers" <joseph at codesourcery dot com>]

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 imagine a wiki page would list both things that are universal among 
existing ports (such as use of ELF) and things where there are variations 
but some versions are discouraged (alignment for integer types other than 
natural alignment, for example - note that m68k has its own version of 
wcpcpy because of its weaker alignment requirements).

-- 
Joseph S. Myers
joseph@codesourcery.com