New issue: __int64 and friends

[Martin von Loewis]

> The IA-64 software conventions define a number of implementation
> types:  __int64, __int128 (and unsigned versions), __float80, and
> __float128.  For those that match builtin types, i.e. __int64 and
> __float80, this raises the question of whether they are intended
> to be treated as typedefs of builtin types, or as new types.
> 
> In C, the significance is limited.

In C99, there is also a type "long long", as well as a type "long
double". Whatever the C ABI says about these must be copied into the
C++ ABI. Otherwise,

  struct foo{
    long long x;
    int y;
  };

will have a different lay-out, depending on whether it is processed by
a C or a C++ compiler.

Furthermore, C99 defines <stdint.h>, with int64_t mandatory, and other
types optional. I guess a C99 implementation should be advised to
provide int128_t, and it would be a good idea if the base ABI
specified the exact definitions of the _least_ and _fast_ types
(e.g. uint_least32_t, int_fast16_t) as well as intmax_t for the same
reason: structure layout relying on those types should be identical
across implementations.

> My preference would be the typedef treatment, specifically:
> 
> 	__int64 == long long (because it can be the same for both
> 				32-bit and 64-bit ABIs)

That is reasonable.

> 	__float80 == long double

>From my (perhaps limited) viewpoint, __float128 would make a better
long double type. For one thing, the CORBA standard specifies that the
IDL type 'long double' is 128 bits on the wire. This is a pain to
implement on ia32.

> On a related note, the SW Conventions document says (in a footnote)
> that it is defining the __float128 so that everyone implementing it
> will have matching representations, but it doesn't specify the
> representation.

I think the current IEEE standard (IEC 60559:1989) specifies the
layout of the 128 bit floating point type. Without checking
(ie. taking the format from CORBA instead), this should be sign +
15bit-exponent + 112bit-mantissa, the exponent being with a bias of
16383.

Regards,
Martin