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

[Lawrence Crowl]

On 8/7/09, Gabriel Dos Reis <gdr at integrable-solutions.net> wrote:
> On Aug 4, 2009, 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
>
> 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.

Actually, I think the primary problem here is that the C++ definition
came first, and the path of least resistance in the ABI was to
simply represent it as a struct.  C99 came along and folks expected
compatiblity with Fortran, which was not struct-like.

> I'm not sure that C99 would have made the same decisions if they
> had as powerful abstraction mechanisms as C++.

Actually, C99 didn't need the abstraction mechanisms to ensure a high
degree of compatibility.  All they needed was to define the spelling
of "float _Complex" as "complex<float>".  Having an ability to name
types with template-like syntax does not imply supporting templates.

> 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.

Many of the more modern ABIs have very little performance difference
between a native type and a struct of the native type.  Sadly,
IA32 is too old for such a benefit.

> 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.

-- 
Lawrence Crowl