128-bit long long?

128-bit long long?

[Scott Robert Ladd]

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?

I'm just wonder...

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: 128-bit long long?

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

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?
>
> I'm just wonder...

That will break too many "portable" software ;-(.

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: 128-bit long long?

[Paolo Carlini]

Andreas Jaeger wrote:

>That will break too many "portable" software ;-(.
>  
>
Thanks. In this respect C99 seems much better than current C++.
However:

    http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1568.htm

:)

Paolo.

Re: 128-bit long long?

[Erik Trulsson]

On Sun, Mar 21, 2004 at 04:35:47PM +0100, Andreas Jaeger wrote:
> 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?
> >
> > I'm just wonder...
> 
> That will break too many "portable" software ;-(.

And probably some software that actually is (or rather was) portable.
In C90 it was (implicitly) guaranteed that 'long' was the largest
integer type.  This is not guaranteed in C99, but there is almost
certainly code out there that relies on 'long' being the largest
integer type.
Having 'long long' and 'long' being the same size keeps the compiler
compatible with C90.
(I don't know if that is the reason the sizes where chosen as they
were, but it is certainly *a* good reason for doing it.)

Then there are of course loads of buggy software that make invalid
assumptions and break when faced with a 128-bit 'long long', but I
suspect that many of them will break when faced with a 64-bit 'long' as
well, so I don't know if they are much to worry about.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

Re: 128-bit long long?

[Zack Weinberg]

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

Re: 128-bit long long?

[Joseph S. Myers]

On Sun, 21 Mar 2004, Zack Weinberg wrote:

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

Except it can't be an extended integer type within the meaning of C99
either, because the same ABIs also fix intmax_t to be 64 bits.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: 128-bit long long?

[Scott Robert Ladd]

Zack Weinberg wrote:
> 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).

I always wondered why C99 didn't define both int128_t and uint128_t in 
<stdint.h>.

..Scott

Re: 128-bit long long?

[Paolo Carlini]

Scott Robert Ladd wrote:

> I always wondered why C99 didn't define both int128_t and uint128_t in 
> <stdint.h>.

However, according to 7.18.1.1, p3, intN_t and uintN_t are *all* optional.

I wonder if any 64 bit architecture actually provides 128bit integer types,
typedef-ed in stdint.h. Sparc64?!? s390x?!?

Paolo.

Re: 128-bit long long?

[Richard B. Kreckel]

On Sun, 21 Mar 2004, Paolo Carlini wrote:

> Scott Robert Ladd wrote:
>
> > I always wondered why C99 didn't define both int128_t and uint128_t in
> > <stdint.h>.
>
> However, according to 7.18.1.1, p3, intN_t and uintN_t are *all* optional.

Hmmm, I've always believed that the next sentence ("However, if an
implementation provides integer types with widths of 8, 16, 32 or 64 bits,
it shall define the corresponding typedef names") is to be construed as a
*requirement* of these types on machines where they make sense.  In
particular this applies to x86 and x86_64, the two architectures this
thread was originally all about.

Regards
    -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>

Re: 128-bit long long?

[Paolo Carlini]

Richard B. Kreckel wrote:

>Hmmm, I've always believed that the next sentence ("However, if an
>implementation provides integer types with widths of 8, 16, 32 or 64 bits,
>it shall define the corresponding typedef names") is to be construed as a
>*requirement* of these types on machines where they make sense.
>
I agree.

Paolo.

Re: 128-bit long long?

[Jim Wilson]

Scott Robert Ladd wrote:
> 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?

Part of the reason here is historical accident.  Early 64-bit targets 
had to be supported via cross compilation from 32-bit hosts.  Gcc 
internally represents tree and rtl values as 2 HOST_WIDE_INT values. 
This was before most compilers had long long support, so HOST_WIDE_INT 
had to be long.  Thus a 32-bit host could support at most a 64-bit 
integer type.  So all early 64-bit ports had to limit long long to 
64-bits.  This restriction was removed relatively recently, between 3.3 
and 3.4.  So it wasn't until 3.4 that we can have a 128-bit long long 
type and still support cross compilation from a 32-bit host.  However, 
by now, 64-bit long long assumptions have been written into so much 
software that changing it would be too painful.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com