New issue: __int64 and friends

[Jim Dehnert]

> From loewis at informatik.hu-berlin.de  Thu Mar  9 17:21:15 2000
> 
> > 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.

That's the intent.

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

These are all specified to be typedefs, with a header file defining
them and the related types/limits.  I think it should be usable
directly in a C++ program, and that we don't need to be concerned with
(re)defining any of its content.  (I haven't looked carefully to verify
that these speculations are valid, however.)

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

This was decided long ago by the base ABI group.  I don't think
attempting to change the decision is likely to be successful, without
getting into whether it would be a good idea...

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

I only have IEEE-754 (1985), which doesn't specify.  If there's a
standardized format somewhere (preferably IEEE, but CORBA's a fine
backup), that's probably what we should use.  Does someone have a solid
reference?

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272