[cxx-abi-dev] decimal floating point support for C++

[Gabriel Dos Reis]

On Tue, Aug 4, 2009 at 12:09 PM, Janis Johnson<janis187 at us.ibm.com> wrote:
> I'm investigating support for decimal floating-point arithmetic in G++
> and sent similar mail to the GCC mailing list last month, where Jason
> Merrill suggested that this might be a more appropriate discussion
> venue.
>
> GCC currently supports decimal floating point functionality in C for
> several targets based on ISO/IEC TR 24732.  The C support adds 3 new
> scalar types: _Decimal32, _Decimal64, and _Decimal128.  With minor
> changes to GCC, including support for mangling those types, and
> changes to tests to define typedefs to the underlying type modes, G++
> already passes almost all of GCC's decimal float tests for C.
>
> The C++ standards committee defined quite different support for C++ in
> ISO/IEC DTR 24733, "Extension for the programming language C++ to
> support decimal floating-point arithmetic".  It defines the support in
> terms of classes decimal32, decimal64, and decimal128 in namespace
> decimal, defined in <decimal>, and allows decimal floating-point
> literals as a conforming extension.
>
> If the libstdc++ implmentation of the decimal classes can depend on
> compiler support for the decimal float type modes then the support is
> straightforward, with classes that contain a data member of the
> appropriate mode.  The only tricky part I've run into is passing
> arguments and return values in a way that is compatible with C, since
> one is a scalar and the other is a class.  This affects not just
> intercallability between user code written in C and C++, but also
> access to the decimal float math functions defined for both C and C++.
>
> Given that libstdc++ is used with compilers other than G++, is it
> reasonable to depend on non-standard C++ compiler support?  An
> alternative is for the libstdc++ support to use decNumber and/or
> libbid libraries, but that would be less efficient and more time-
> consuming to implement.
>
> Both TRs are available online:
> C:   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1312.pdf
> C++: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2849.pdf

Hi Janis,

The fundamental problem is not limited to <decimal>.  Similar
issues exist for <complex>.  One could argue that the C99 committee
did not care about compabitility, or that the C++ committee did not
care about compability.  I think that would be beside the point.
I'm not sure that C99 would have made the same decisions if they
had as powerful abstraction mechanisms as C++.

Anyway, C++0x has the notion of "literal types".  For example complex<double>
is a literal type.  Concretely, what it means is that the compiler can
manipulate
values of such type at compile time (there is nothing that prevents the decimal
types from being such types.)  an ABI that aims at efficient support of C++
could (and should) treat literal types very efficiently as opposed to saying
"oh, this is a struct, let's not make it faster than in C".  For
example, the ABI
could define the parameter passing mechanism as equivalent to that
of the underlying representation -- even on IA32.  In this case, it
would mean no
difference between the C and C++ versions, even if in C++ it is a
class -- the key
point being that it is not just a random struct: it is a literal type.

-- Gaby