This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 128-bit long long?
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Scott Robert Ladd <coyote at coyotegulch dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 21 Mar 2004 10:15:31 -0800
- Subject: Re: 128-bit long long?
- References: <405DB46B.80208@coyotegulch.com>
Scott Robert Ladd <coyote@coyotegulch.com> writes:
> On a 64-bit AMD64 architecture, GCC defines long long as 64 bits, the
> same as a long.
>
> Given that certain 64-bit instructions (multiply) produce 128-bit
> results, doesn't it seem logical the long long be defined as 128 bits?
No, for two reasons:
1) The choice of 64-bit 'long long' has been written into the ABI of
most LP64-model operating systems; we can't unilaterally change it.
2) This is actually the correct choice, as it removes the aberration
that makes 'long' not the widest basic integral type. There is
lots and lots of code in the wild written to the assumption that
sizeof(long) >= sizeof(size_t) - this is at least potentially
broken by ABIs where long long is wider than long.
(This was an extremely contentious topic during the development of
C99. As best as I can tell from an outside perspective, 'long long'
was only standardized due to pressure from Microsoft who can't for
some reason implement an LP64 model. Everyone else hated the idea
of making 'long' not necessarily the widest basic integral type.)
Best current practice appears to be to provide an "extended integral
type" __int128. This doesn't have the problems of 'long long' because
it's not a *basic* integral type (in particular, it cannot be used for
size_t).
zw