Supporting decimal float on additional platforms

Supporting decimal float on additional platforms

[Rainer Orth]

I've recently looked into what it takes to support decimal float on
additional platforms (like Solaris, IRIX, and Tru64 UNIX in my case).
I've found no documentation, and while I could figure out some things
myself, I'd like to get some advice before continuing down that road.

I found that --enable-decimal-float alone is not enough.  One at least
needs to add config/t-dfprules to config.gcc, too.  In addition, the
platform <target>_scalar_mode_supported_p function needs to be augmented
accordingly.  (I haven't tried this yet; it's just from code
inspection.)

Even if this works, I now think this won't be enough and probably not
even remotely useful (if only to pass parts of the testsuite) without
libc support for the new *printf/*scanf formats, which certainly won't
be added on legacy platforms like IRIX and Tru64 UNIX, and even on
Solaris probably won't show up until DFP is fully standardized.

Comments?

        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Supporting decimal float on additional platforms

[Janis Johnson]

On Wed, 2009-11-18 at 19:19 +0100, Rainer Orth wrote:
> I've recently looked into what it takes to support decimal float on
> additional platforms (like Solaris, IRIX, and Tru64 UNIX in my case).
> I've found no documentation, and while I could figure out some things
> myself, I'd like to get some advice before continuing down that road.
> 
> I found that --enable-decimal-float alone is not enough.  One at least
> needs to add config/t-dfprules to config.gcc, too.  In addition, the
> platform <target>_scalar_mode_supported_p function needs to be augmented
> accordingly.  (I haven't tried this yet; it's just from code
> inspection.)

The target ABI needs to define how to handle the decimal32/64/128 data
types.  The compiler backend needs to implement that ABI for argument
passing and function results, and needs to define which registers to
use for those types.

> Even if this works, I now think this won't be enough and probably not
> even remotely useful (if only to pass parts of the testsuite) without
> libc support for the new *printf/*scanf formats, which certainly won't
> be added on legacy platforms like IRIX and Tru64 UNIX, and even on
> Solaris probably won't show up until DFP is fully standardized.

Much of the support for decimal floating types is in libraries that
are outside the scope of the GCC project.  This includes not just I/O
but math functions and support for floating-point exceptions and
rounding modes.  That support is provided by the libdfp project hosted
in the EGLIBC repository.  libdfp currently supports only GNU/Linux
targets, but that could be changed.

Janis

Re: Supporting decimal float on additional platforms

[Rainer Orth]

Janis Johnson <janis187@us.ibm.com> writes:

> On Wed, 2009-11-18 at 19:19 +0100, Rainer Orth wrote:
>> I've recently looked into what it takes to support decimal float on
>> additional platforms (like Solaris, IRIX, and Tru64 UNIX in my case).
>> I've found no documentation, and while I could figure out some things
>> myself, I'd like to get some advice before continuing down that road.
>> 
>> I found that --enable-decimal-float alone is not enough.  One at least
>> needs to add config/t-dfprules to config.gcc, too.  In addition, the
>> platform <target>_scalar_mode_supported_p function needs to be augmented
>> accordingly.  (I haven't tried this yet; it's just from code
>> inspection.)
>
> The target ABI needs to define how to handle the decimal32/64/128 data
> types.  The compiler backend needs to implement that ABI for argument
> passing and function results, and needs to define which registers to
> use for those types.

Thanks.  I've found the pertinent information in version 0.99 of the
AMD64 psABI, but haven't found where updates to version 4 of the Intel
386 psABI are kept.

Besides, it were helpful if there existed an overview of what it takes
to support decimal float for a new target in GCC once the psABI
specification is in place.

>> Even if this works, I now think this won't be enough and probably not
>> even remotely useful (if only to pass parts of the testsuite) without
>> libc support for the new *printf/*scanf formats, which certainly won't
>> be added on legacy platforms like IRIX and Tru64 UNIX, and even on
>> Solaris probably won't show up until DFP is fully standardized.
>
> Much of the support for decimal floating types is in libraries that
> are outside the scope of the GCC project.  This includes not just I/O
> but math functions and support for floating-point exceptions and
> rounding modes.  That support is provided by the libdfp project hosted
> in the EGLIBC repository.  libdfp currently supports only GNU/Linux
> targets, but that could be changed.

Understood, that's why I asked in the first place.  While it were
possible to get new functions from an additional library, extensions to
existing functions need to be done in the target libc.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Supporting decimal float on additional platforms

[Joseph S. Myers]

On Wed, 18 Nov 2009, Rainer Orth wrote:

> be added on legacy platforms like IRIX and Tru64 UNIX, and even on
> Solaris probably won't show up until DFP is fully standardized.

I'd have expected the Solaris maintainers to care more about whether 
Solaris customers are asking for DFP support, than about whether it is an 
ISO/IEC Technical Report Type 2 (as at present - TR 24732:2009 published 
2009-01-05) or an International Standard.

As Janis says, the psABI needs to be aware of decimal floating point, so 
if there is any group or community for a particular target concerned with 
its ABI for interoperability between multiple implementations, you should 
work with them on establishing the ABI for decimal floating point for that 
target.

Much the same applies if anyone wishes to add fixed point (TR 18037) 
support for more targets.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Supporting decimal float on additional platforms

[Rainer Orth]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Wed, 18 Nov 2009, Rainer Orth wrote:
>
>> be added on legacy platforms like IRIX and Tru64 UNIX, and even on
>> Solaris probably won't show up until DFP is fully standardized.
>
> I'd have expected the Solaris maintainers to care more about whether 
> Solaris customers are asking for DFP support, than about whether it is an 
> ISO/IEC Technical Report Type 2 (as at present - TR 24732:2009 published 
> 2009-01-05) or an International Standard.

I wasn't aware of that.  Buying the TR from ISO is prohibitive, to I
stayed with the (last?) draft, N1312 for now.  I've asked the Sun
compiler guys about their plans for decimal float support, but no answer
so far:

	http://mail.opensolaris.org/pipermail/tools-compilers/2009-November/000907.html

> As Janis says, the psABI needs to be aware of decimal floating point, so 
> if there is any group or community for a particular target concerned with 
> its ABI for interoperability between multiple implementations, you should 
> work with them on establishing the ABI for decimal floating point for that 
> target.

While the i386 and amd64 psABIs already exist (although I haven't found
the i386 specification yet), for SPARC that would be SPARC
International, I think.  Since I expect neither SGI nor HP to implement
decimal float in libc on IRIX 6 or Tru64 UNIX, MIPS and Alpha are
irrelevant from my point of view.

> Much the same applies if anyone wishes to add fixed point (TR 18037) 
> support for more targets.

I'll have a look at the last draft (N1169) for now.  Right now, only
MIPS support is in GCC, so there seems to be less traction so far.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Supporting decimal float on additional platforms

[Joseph S. Myers]

On Fri, 20 Nov 2009, Rainer Orth wrote:

> > Much the same applies if anyone wishes to add fixed point (TR 18037) 
> > support for more targets.
> 
> I'll have a look at the last draft (N1169) for now.  Right now, only
> MIPS support is in GCC, so there seems to be less traction so far.

Each of these extensions is aimed at a specific class of programs, and 
users of such programs are much more likely to use some processors than 
others - various embedded processors have fixed point instructions of one 
form or another (not necessarily all mapping neatly to the TR 18037 
types), while some Power and S390 processors have hardware support for 
decimal floating point.

The TRs may eventually result in those classes of programs becoming more 
portable, in which case people might eventually want to include free 
software using these extensions in general-purpose operating system 
distributions - which may drive porting the feature as people wish to 
build those distributions for many different processors - but the limited 
application domains for these features seem likely to exacerbate the 
chicken-and-egg effect that applies to any new language feature (no demand 
for the feature in compilers without applications using it, no 
applications using it without compilers implementing it).  Implementing a 
feature without having any applications for it is of course one way of 
addressing that effect, as is implementing a feature you'd like to use 
yourself in programs you write in future; it seems a fine improvement to 
the compiler to contribute as long as you work with any ABI maintainers to 
avoid it causing future compatibility problems.

(Though I made decimal floating point work on e500 processors - to 
eliminate the test failures seen in such configurations given that it's 
enabled by default for Power GNU/Linux and already worked for other Power 
processors - it's quite possible that no-one has ever used that 
functionality other than for testcases.  There were no ABI compatibility 
issues there since e500 uses the same ABI as soft-float Power processors.)

Note that the fixed point implementation for MIPS substantially slows down 
the build of libgcc for MIPS targets because of a huge number of libgcc 
functions for fixed point that need to be built, so people may not care 
for their libgcc builds being slowed down for other targets without any 
applications for the new feature.

-- 
Joseph S. Myers
joseph@codesourcery.com