This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 128-bit long long?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]