Re: Supporting decimal float on additional platforms
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 jos...@codesourcery.com
Re: Supporting decimal float on additional platforms
"Joseph S. Myers" 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
Janis Johnson 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 _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
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 jos...@codesourcery.com
Re: Supporting decimal float on additional platforms
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 _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
