December 28, 2008
Does anyone know of true 128 bit cpus not just register size?


On Sun, 28 Dec 2008 17:38:12 +1300, Walter Bright <newshound1@digitalmars.com> wrote:

> You know, the unimplemented 128 bit integer types.
>
> Does anyone have a use for these?

December 28, 2008

bearophile wrote:
> ...
> 
> A possible use is for runtime test for overflows: you can perform operations among 64 bit integers with 128 bit precision, and then you can look at the result if it fits still in 64 bits. If not, you can raise an overflow exception (probably there other ways to test for overflow, but this seems simple to implement). You can use 64 bits to implement the safe operations among 32-16-8 bit numbers on the 64 bit CPUs).
> 
> Bye,
> bearophile

It's always annoyed me that the CPU goes to all the trouble of doing multiplies in 64-bit, keeping track of overflows, etc., and yet there's no way in any language I've ever seen (aside from assembler) to get that information.

Personally, rather than working around the problem with 128-bit types, I'd prefer to see something (roughly) like this implemented:

  bool overflow;
  ubyte high;

  ubyte a = 128;

  // overflow == false
  pragma(OverflowFlag, overflow) ubyte c = a + a;
  // overflow == true

  // high == 0
  pragma(ResultHigh, high) ubyte d = a * 2;
  // high == 1, d == 0

As for 128-bit types themselves, I'm sure *someone* would find a use for them, and they'd be their favourite feature.  Personally, I prefer arbitrary-precision once you start getting that big, but there you go.

  -- Daniel
December 28, 2008
John Reimer:
> That's why I was asking about SSE... I believe that they have 128-bit registers that can be viewed as integers and unsigned integers.  But I'm not very familiar with how this works.

You can perform a bitwise operation on 128 bits, but not arithmetic.
(Very long bitwise operations are useful for example for approximate string matching machines.)

Bye,
bearophile
December 28, 2008
Walter Bright wrote:
> You know, the unimplemented 128 bit integer types.
> 
> Does anyone have a use for these?

I would have liked them when implementing a fallback (non-asm) bigint implementation for 64-bit CPUs. Actually the only operations required are:
ulong * ulong -> ulong[2]
ulong[2] / ulong = ulong (only the case where it doesn't overflow, is required)
ulong + ulong = ulong[2]
ulong - ulong = ulong[2]

Otherwise, it's hard to imagine many cases where 64 bits are inadequate but 128 bits are enough. Actually there are very few cases where 32 bits are inadequate but 64 bits are enough.
December 28, 2008
Hello bearophile,

> John Reimer:
> 
>> That's why I was asking about SSE... I believe that they have 128-bit
>> registers that can be viewed as integers and unsigned integers.  But
>> I'm not very familiar with how this works.
>> 
> You can perform a bitwise operation on 128 bits, but not arithmetic.
> (Very long bitwise operations are useful for example for approximate
> string matching machines.)
> 
> Bye,
> bearophile


Ok, I see. thanks.

-JJR


December 28, 2008
Walter Bright wrote:
> John Reimer wrote:
>> Hello Walter,
>>
>>> You know, the unimplemented 128 bit integer types.
>>>
>>> Does anyone have a use for these?
>>>
>>
>>
>> Was that "cent" and "ucent"?
> 
> yes.
> 
>> Would any of these map well to SSE Instructions on Intel CPU's?
> 
> Not a chance :-(

Then it looks like we better leave large fixed-size integers to a library.

Andrei
December 28, 2008
Andrei Alexandrescu:
> Then it looks like we better leave large fixed-size integers to a library.

LDC may support 128-bit intrinsic operations, but they may be used from a lib too, I presume.

Bye,
bearophile
December 28, 2008
Daniel Keep wrote:
> 
> 
> bearophile wrote:
>> ...
>>
>> A possible use is for runtime test for overflows: you can perform operations among 64 bit integers with 128 bit precision, and then you can look at the result if it fits still in 64 bits. If not, you can raise an overflow exception (probably there other ways to test for overflow, but this seems simple to implement). You can use 64 bits to implement the safe operations among 32-16-8 bit numbers on the 64 bit CPUs).
>>
>> Bye,
>> bearophile
> 
> It's always annoyed me that the CPU goes to all the trouble of doing multiplies in 64-bit, keeping track of overflows, etc., and yet there's no way in any language I've ever seen (aside from assembler) to get that information.
> 
> Personally, rather than working around the problem with 128-bit types, I'd prefer to see something (roughly) like this implemented:
> 
>   bool overflow;
>   ubyte high;
> 
>   ubyte a = 128;
> 
>   // overflow == false
>   pragma(OverflowFlag, overflow) ubyte c = a + a;
>   // overflow == true
> 
>   // high == 0
>   pragma(ResultHigh, high) ubyte d = a * 2;
>   // high == 1, d == 0
> 
> As for 128-bit types themselves, I'm sure *someone* would find a use for them, and they'd be their favourite feature.  Personally, I prefer arbitrary-precision once you start getting that big, but there you go.

If 128-bit built-in integer can't be made more efficient by moving them in the core, then the question is really "do you need 128-bit literals?" because that's all the built-in feature would bring over a library.

Andrei
December 28, 2008
Don wrote:
> Walter Bright wrote:
>> You know, the unimplemented 128 bit integer types.
>>
>> Does anyone have a use for these?
> 
> I would have liked them when implementing a fallback (non-asm) bigint implementation for 64-bit CPUs. Actually the only operations required are:
> ulong * ulong -> ulong[2]
> ulong[2] / ulong = ulong (only the case where it doesn't overflow, is required)
> ulong + ulong = ulong[2]
> ulong - ulong = ulong[2]
> 
> Otherwise, it's hard to imagine many cases where 64 bits are inadequate but 128 bits are enough. Actually there are very few cases where 32 bits are inadequate but 64 bits are enough.

For the latter, file sizes come to mind:o).

Andrei
December 28, 2008
Don wrote:

> Walter Bright wrote:
>> You know, the unimplemented 128 bit integer types.
>> 
>> Does anyone have a use for these?
> 
> I would have liked them when implementing a fallback (non-asm) bigint
> implementation for 64-bit CPUs. Actually the only operations required are:
> ulong * ulong -> ulong[2]
> ulong[2] / ulong = ulong (only the case where it doesn't overflow, is
> required)
> ulong + ulong = ulong[2]
> ulong - ulong = ulong[2]
> 
> Otherwise, it's hard to imagine many cases where 64 bits are inadequate but 128 bits are enough. Actually there are very few cases where 32 bits are inadequate but 64 bits are enough.

32 bit -> 64 bit: 8x8 bit boards in computer chess.  zorbist hash codes
64 bit -> 128 bit: bit boards in 9x9 computer go.  Depending on the implementation, 11x11 bit boards (121 bits) can be very handy.