www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 128 bit signed and unsigned integer types

reply Walter Bright <newshound1 digitalmars.com> writes:
You know, the unimplemented 128 bit integer types.

Does anyone have a use for these?
Dec 27 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Walter,


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


I'd like to see them. Some times it can be handy to have a "larger" integer 
than the default size, so as 64bit get implemented (it is right?) I think 
it will be handy.
Dec 27 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright Wrote:


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


Well the only uses I can think of, I'd prefer an unlimited-size big integer
struct anyway... Since they can't be operated on in registers (at least in
x86), their value seems limited.
Dec 27 2008
prev sibling next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Walter,


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



Was that "cent" and "ucent"?

Would any of these map well to SSE Instructions on Intel CPU's?

-JJR
Dec 27 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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 :-(
Dec 27 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 28 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Dec 28 2008
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 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


Something that I still don't think has been made very clear in this discussion
that I'm very curious about:  How efficient would these large fixed-size ints be
(on 32-bit hardware)?  Would they be almost as fast as 64-bit, almost as slow as
bigints, or somewhere roughly in the middle?  Obviously on 64-bit hardware they
can be made fast, but if that's the only place they can be made fast, then I
think
it's more important that DMD support 64-bit hardware first.
Dec 28 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 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


 
 Something that I still don't think has been made very clear in this discussion
 that I'm very curious about:  How efficient would these large fixed-size ints
be
 (on 32-bit hardware)?  Would they be almost as fast as 64-bit, almost as slow
as
 bigints, or somewhere roughly in the middle?  Obviously on 64-bit hardware they
 can be made fast, but if that's the only place they can be made fast, then I
think
 it's more important that DMD support 64-bit hardware first.


Assume we define a FixedInt(uint bits) structure. That would contain the 
value in-situ so there is no dynamic allocation, no indirection, and 
full-blown copying. For built-in sizes, FixedInt will alias itself away, 
for example:

template FixedInt(uint n) if (n == 8) { alias byte FixedInt; }
template FixedInt(uint n) if (n == 16) { alias short FixedInt; }
template FixedInt(uint n) if (n == 32) { alias int FixedInt; }
template FixedInt(uint n) if (n == 64) { alias long FixedInt; }

That's nice because it allows you to use FixedInt with a parameterized 
size throughout, yet still take advantage of builtin optimizations 
whenever applicable.

For the larger sizes and operations my guess would be that FixedInt will 
be close to what can be achieved via built-ins.


Andrei
Dec 28 2008
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:

 dsimcha wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article

 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


 Something that I still don't think has been made very clear in this
 discussion
 that I'm very curious about: How efficient would these large
 fixed-size ints be
 (on 32-bit hardware)? Would they be almost as fast as 64-bit, almost
 as slow as
 bigints, or somewhere roughly in the middle? Obviously on 64-bit
 hardware they
 can be made fast, but if that's the only place they can be made fast,
 then I think
 it's more important that DMD support 64-bit hardware first.


 Assume we define a FixedInt(uint bits) structure. That would contain the
 value in-situ so there is no dynamic allocation, no indirection, and
 full-blown copying. For built-in sizes, FixedInt will alias itself away,
 for example:

 template FixedInt(uint n) if (n == 8) { alias byte FixedInt; }
 template FixedInt(uint n) if (n == 16) { alias short FixedInt; }
 template FixedInt(uint n) if (n == 32) { alias int FixedInt; }
 template FixedInt(uint n) if (n == 64) { alias long FixedInt; }

 That's nice because it allows you to use FixedInt with a parameterized
 size throughout, yet still take advantage of builtin optimizations
 whenever applicable.

 For the larger sizes and operations my guess would be that FixedInt will
 be close to what can be achieved via built-ins.


 Andrei


is it possible to make int/long/short/etc internal to the compiler and 
use the above FixedInt in the language? there shouldn't be any 
performance differences between an old-style int and the above 
FixedInt!(32), for instance.
this way all the different types are reduced to one built-in type that 
looks like a template. similar to the way C++ uses the template syntax 
for casts like static_cast<type>(var) even though it's usually 
implemented inside the compiler.

also, this approch can be expanded to eliminate also size_t (which to me 
seems ugly).
libs could perhaps extend the same interface and add a BigInt as well.
Dec 28 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:

 Andrei Alexandrescu wrote:

 dsimcha wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article

 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


 Something that I still don't think has been made very clear in this
 discussion
 that I'm very curious about: How efficient would these large
 fixed-size ints be
 (on 32-bit hardware)? Would they be almost as fast as 64-bit, almost
 as slow as
 bigints, or somewhere roughly in the middle? Obviously on 64-bit
 hardware they
 can be made fast, but if that's the only place they can be made fast,
 then I think
 it's more important that DMD support 64-bit hardware first.


 Assume we define a FixedInt(uint bits) structure. That would contain the
 value in-situ so there is no dynamic allocation, no indirection, and
 full-blown copying. For built-in sizes, FixedInt will alias itself away,
 for example:

 template FixedInt(uint n) if (n == 8) { alias byte FixedInt; }
 template FixedInt(uint n) if (n == 16) { alias short FixedInt; }
 template FixedInt(uint n) if (n == 32) { alias int FixedInt; }
 template FixedInt(uint n) if (n == 64) { alias long FixedInt; }

 That's nice because it allows you to use FixedInt with a parameterized
 size throughout, yet still take advantage of builtin optimizations
 whenever applicable.

 For the larger sizes and operations my guess would be that FixedInt will
 be close to what can be achieved via built-ins.


 Andrei


 
 is it possible to make int/long/short/etc internal to the compiler and 
 use the above FixedInt in the language? there shouldn't be any 
 performance differences between an old-style int and the above 
 FixedInt!(32), for instance.
 this way all the different types are reduced to one built-in type that 
 looks like a template. similar to the way C++ uses the template syntax 
 for casts like static_cast<type>(var) even though it's usually 
 implemented inside the compiler.


Well it's possible but probably too verbose for many. I mean, if I had 
only FixedInt, I'd first define int, short et al as aliases :o).

Andrei
Dec 28 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:

 Yigal Chripun wrote:

 Andrei Alexandrescu wrote:

 dsimcha wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article

 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


 Something that I still don't think has been made very clear in this
 discussion
 that I'm very curious about: How efficient would these large
 fixed-size ints be
 (on 32-bit hardware)? Would they be almost as fast as 64-bit, almost
 as slow as
 bigints, or somewhere roughly in the middle? Obviously on 64-bit
 hardware they
 can be made fast, but if that's the only place they can be made fast,
 then I think
 it's more important that DMD support 64-bit hardware first.


 Assume we define a FixedInt(uint bits) structure. That would contain the
 value in-situ so there is no dynamic allocation, no indirection, and
 full-blown copying. For built-in sizes, FixedInt will alias itself away,
 for example:

 template FixedInt(uint n) if (n == 8) { alias byte FixedInt; }
 template FixedInt(uint n) if (n == 16) { alias short FixedInt; }
 template FixedInt(uint n) if (n == 32) { alias int FixedInt; }
 template FixedInt(uint n) if (n == 64) { alias long FixedInt; }

 That's nice because it allows you to use FixedInt with a parameterized
 size throughout, yet still take advantage of builtin optimizations
 whenever applicable.

 For the larger sizes and operations my guess would be that FixedInt will
 be close to what can be achieved via built-ins.


 Andrei


 is it possible to make int/long/short/etc internal to the compiler and
 use the above FixedInt in the language? there shouldn't be any
 performance differences between an old-style int and the above
 FixedInt!(32), for instance.
 this way all the different types are reduced to one built-in type that
 looks like a template. similar to the way C++ uses the template syntax
 for casts like static_cast<type>(var) even though it's usually
 implemented inside the compiler.


 Well it's possible but probably too verbose for many. I mean, if I had
 only FixedInt, I'd first define int, short et al as aliases :o).

 Andrei


Obviously such a solution needs a shorter name to be useful.
many languages use "Integer" as the name of the type.
I agree that C's "int" is probably the shortest, but using anything 
like: int!(4) to define a 4-byte int or an int!(32) if your prefer bits 
isn't that much longer.

having int!(WORD) or something like that to denote a size_t or even just 
alias it as "word" is also nice and much better than C style whatever_t 
typedefs.
also, isn't it better design to have just *one* generalized type and one 
keyword and allowing the user to alias it however he wants and/or 
provide aliases in a stdlib module rather than the other way around? if 
nothing else than from a minimalist POV and eliminating unneeded stuff 
from the language?

Also, I wonder what's the usage percentage for these keywords. how 
frequently do people actually use short/long instead of just int?
Dec 29 2008
next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Mon, Dec 29, 2008 at 5:22 PM, Yigal Chripun <yigal100 gmail.com> wrote:

 Also, I wonder what's the usage percentage for these keywords. how
 frequently do people actually use short/long instead of just int?


I'd guess there are three use cases for non-native-word-sized ints:

- Poor man's ranged int type (unsigned ints fall in that category too)
- Obsessive space-saving
- Interfacing with externally-defined software or hardware interfaces
Dec 29 2008
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Mon, Dec 29, 2008 at 6:28 PM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:

 On Mon, Dec 29, 2008 at 5:22 PM, Yigal Chripun <yigal100 gmail.com> wrote:

 Also, I wonder what's the usage percentage for these keywords. how
 frequently do people actually use short/long instead of just int?


 I'd guess there are three use cases for non-native-word-sized ints:

 - Poor man's ranged int type (unsigned ints fall in that category too)


Er, I should say that unsigned ints _can_ be used for that purpose.
There are certainly plenty of perfectly-justifiable uses for them.
Dec 29 2008
prev sibling next sibling parent reply Martin d'Anjou <martin.danjou neterion.com> writes:
 template FixedInt(uint n) if (n == 8) { alias byte FixedInt; }
 template FixedInt(uint n) if (n == 16) { alias short FixedInt; }
 template FixedInt(uint n) if (n == 32) { alias int FixedInt; }
 template FixedInt(uint n) if (n == 64) { alias long FixedInt; }


Where can I find FixedInt for generic values of n? I assume FixedInt will 
not resize itself ever. Perfect for emulating hardware/CPU registers of 
arbitrary size.

Martin
Dec 29 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Martin d'Anjou wrote:

 template FixedInt(uint n) if (n == 8) { alias byte FixedInt; }
 template FixedInt(uint n) if (n == 16) { alias short FixedInt; }
 template FixedInt(uint n) if (n == 32) { alias int FixedInt; }
 template FixedInt(uint n) if (n == 64) { alias long FixedInt; }


 
 Where can I find FixedInt for generic values of n? I assume FixedInt 
 will not resize itself ever. Perfect for emulating hardware/CPU 
 registers of arbitrary size.
 
 Martin


As of now it's in your mind.

<makes Jedi hand gesture>

You only need to write it down and contribute it to Phobos.


Andrei
Dec 29 2008
prev sibling parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:

 
 Assume we define a FixedInt(uint bits) structure. That would contain the
 value in-situ so there is no dynamic allocation, no indirection, and
 full-blown copying. For built-in sizes, FixedInt will alias itself away,
 for example:
 
 template FixedInt(uint n) if (n == 8) { alias byte FixedInt; }
 template FixedInt(uint n) if (n == 16) { alias short FixedInt; }
 template FixedInt(uint n) if (n == 32) { alias int FixedInt; }
 template FixedInt(uint n) if (n == 64) { alias long FixedInt; }
 
 That's nice because it allows you to use FixedInt with a parameterized
 size throughout, yet still take advantage of builtin optimizations
 whenever applicable.
 
 For the larger sizes and operations my guess would be that FixedInt will
 be close to what can be achieved via built-ins.
 
 
 Andrei


Cool, but don't name it FixedInt unless it implements fixed point
arithmetic.

This name immediately suggests to me that it implements fixed point
arithmetic using an integer of the given size, but then I'd be confused
since I don't know how many bits are allocated to the fractional part.

Maybe just Int.  Less typing.  Makes the point.  The template
instantiation is a huge giveaway as to what is happening.
Int!(64) == long
UInt!(64) == ulong
Int!(8) == byte
etc..
that would be "kicking rad".
Dec 29 2008
next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Mon, Dec 29, 2008 at 3:34 PM, Chad J
<gamerchad __spam.is.bad__gmail.com> wrote:

 Cool, but don't name it FixedInt unless it implements fixed point
 arithmetic.

 This name immediately suggests to me that it implements fixed point
 arithmetic using an integer of the given size, but then I'd be confused
 since I don't know how many bits are allocated to the fractional part.

 Maybe just Int.  Less typing.  Makes the point.  The template
 instantiation is a huge giveaway as to what is happening.
 Int!(64) == long
 UInt!(64) == ulong
 Int!(8) == byte
 etc..
 that would be "kicking rad".


I agree with you, but "FixedInt" couldn't possibly have anything to do
with fixed-point arithmetic, since fixed-point deals with
non-integers.  It's like having an imaginary real ;)

/me shames ireal.  bad, bad ireal!
Dec 29 2008
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Chad J wrote:

 Cool, but don't name it FixedInt unless it implements fixed point
 arithmetic.


Fine, but don't name it 'Integer' or 'Int' unless it can store any value 
in the set of integers; you know, the infinite one that doesn't have 
that stupid "1 + T.max = T.min" nonsense.

The name 'FixedInt' is ambiguous because it doesn't specify what 
attribute of the int is being fixed; *you* look at it and see 
'FixedPointInt' which is clearly impossible.  Someone else will look at 
it and see 'FixedWidthInt'.  Yet another person will see 'FixedValueInt' 
and question why they didn't just use const.

No matter what name you come up with, you're eventually going to find 
someone who hates it and can come up with a good reason for not using it.

:P

  -- Daniel

P.S. 'FixedWidthInt' sucks because it's too damn long.  ;)
Dec 29 2008
parent reply Don <nospam nospam.com> writes:
Daniel Keep wrote:

 
 
 Chad J wrote:

 Cool, but don't name it FixedInt unless it implements fixed point
 arithmetic.


 
 Fine, but don't name it 'Integer' or 'Int' unless it can store any value 
 in the set of integers; you know, the infinite one that doesn't have 
 that stupid "1 + T.max = T.min" nonsense.
 
 The name 'FixedInt' is ambiguous because it doesn't specify what 
 attribute of the int is being fixed; *you* look at it and see 
 'FixedPointInt' which is clearly impossible.  Someone else will look at 
 it and see 'FixedWidthInt'.  Yet another person will see 'FixedValueInt' 
 and question why they didn't just use const.
 
 No matter what name you come up with, you're eventually going to find 
 someone who hates it and can come up with a good reason for not using it.


I disagree. I'm with Chad. 'Fixed' has a very well established meaning 
in computer arithmetic, and it means 'Fixed point arithmetic' (it's as 
fundamental a term as 'floating'.
It's a shame that 'widthed' isn't a word. 'WidthedInt' seems to be the 
concept we want. 'SizedInt' ?
Dec 29 2008
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Don wrote:

 Daniel Keep wrote:

 Chad J wrote:

 Cool, but don't name it FixedInt unless it implements fixed point
 arithmetic.


 Fine, but don't name it 'Integer' or 'Int' unless it can store any 
 value in the set of integers; you know, the infinite one that doesn't 
 have that stupid "1 + T.max = T.min" nonsense.

 The name 'FixedInt' is ambiguous because it doesn't specify what 
 attribute of the int is being fixed; *you* look at it and see 
 'FixedPointInt' which is clearly impossible.  Someone else will look 
 at it and see 'FixedWidthInt'.  Yet another person will see 
 'FixedValueInt' and question why they didn't just use const.

 No matter what name you come up with, you're eventually going to find 
 someone who hates it and can come up with a good reason for not using it.


 
 I disagree. I'm with Chad. 'Fixed' has a very well established meaning 
 in computer arithmetic, and it means 'Fixed point arithmetic' (it's as 
 fundamental a term as 'floating'.
 It's a shame that 'widthed' isn't a word. 'WidthedInt' seems to be the 
 concept we want. 'SizedInt' ?


I think the bicycle shed would look hideous if it were named anything 
but "Int(uint bits)".
Dec 30 2008
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:

 Daniel Keep wrote:

 Chad J wrote:

 Cool, but don't name it FixedInt unless it implements fixed point
 arithmetic.


 Fine, but don't name it 'Integer' or 'Int' unless it can store any 
 value in the set of integers; you know, the infinite one that doesn't 
 have that stupid "1 + T.max = T.min" nonsense.

 The name 'FixedInt' is ambiguous because it doesn't specify what 
 attribute of the int is being fixed; *you* look at it and see 
 'FixedPointInt' which is clearly impossible.  Someone else will look 
 at it and see 'FixedWidthInt'.  Yet another person will see 
 'FixedValueInt' and question why they didn't just use const.

 No matter what name you come up with, you're eventually going to find 
 someone who hates it and can come up with a good reason for not using it.


 
 I disagree. I'm with Chad. 'Fixed' has a very well established meaning 
 in computer arithmetic, and it means 'Fixed point arithmetic' (it's as 
 fundamental a term as 'floating'.


I think Int following Fixed pretty much takes that meaning away, but 
that's only me.


 It's a shame that 'widthed' isn't a word. 'WidthedInt' seems to be the 
 concept we want. 'SizedInt' ?


I like them less than FixedInt, but I trust a better name will come forth.


Andrei
Dec 30 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Don wrote:

 
 I disagree. I'm with Chad. 'Fixed' has a very well established meaning 
 in computer arithmetic, and it means 'Fixed point arithmetic' (it's as 
 fundamental a term as 'floating'.
 It's a shame that 'widthed' isn't a word. 'WidthedInt' seems to be the 
 concept we want. 'SizedInt' ?


I like names that read like a phrase.  How about IntOfSize?  Second 
choice would be SizedInt.


Sean
Dec 30 2008
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

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


Well, we've got bigints in both Phobos and Tango now.  Given the clumsiness or
downright impossibility of manipulating 128-bit ints in hardware on x86-32,
would
they even be much faster than bigints?  I mean, you couldn't even fit 2 128-bit
ints plus a stack pointer in the general-purpose registers of an x86.
Dec 27 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello dsimcha,


 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 

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


 Well, we've got bigints in both Phobos and Tango now.  Given the
 clumsiness or downright impossibility of manipulating 128-bit ints in
 hardware on x86-32, would they even be much faster than bigints?  I
 mean, you couldn't even fit 2 128-bit ints plus a stack pointer in the
 general-purpose registers of an x86.
 



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.

-JJR
Dec 27 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Dec 28 2008
parent John Reimer <terminal.node gmail.com> writes:
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
Dec 28 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article

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


 
 Well, we've got bigints in both Phobos and Tango now.  Given the clumsiness or
 downright impossibility of manipulating 128-bit ints in hardware on x86-32,
would
 they even be much faster than bigints?  I mean, you couldn't even fit 2 128-bit
 ints plus a stack pointer in the general-purpose registers of an x86.


It can be done (not impractical at all), the issue is is it worth while?
Dec 27 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 It can be done (not impractical at all), the issue is is it worth while?


128 bit are two words in the 64-bit CPUs that are now getting very common. So
it's  like 64 bit operations on 32 bit CPUs.

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
Dec 28 2008
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Dec 28 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 28 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 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.


The literals would be an issue, otherwise you get into the std::string 
problem where:

s + "abc"

works, but:

"abc" + "def"

does not.

If it's not built-in, you also lose the constant folding and math 
identity stuff.
Dec 28 2008
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Sat, 27 Dec 2008 20:38:12 -0800, Walter Bright wrote:


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


Cryptographers would.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Dec 28 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

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


I have already answered something in another post.
But instead of asking us/yourself if we can use the feature X, why don't you
think about implementing the features Y and Z that are most useful to
programmers, like, for example, named arguments (and several other things
discussed in the past)? I can find many uses for named arguments and only one
or two for 128-big integral numbers...

I know the story of the car/horse by Ford, but often the users know what they
need :-) I may use several things currently absent in D2 while I have little
use of many of the things recently added/modified in D2. (for example I may
like the idea of vector operations, but so far I haven't used them yet in
actual programs, while I can think of several other things missing still that I
can find useful today, that are missing still in D2).

Bye,
bearophile
Dec 28 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 I have already answered something in another post. But instead of
 asking us/yourself if we can use the feature X, why don't you think
 about implementing the features Y and Z that are most useful to
 programmers, like, for example, named arguments (and several other
 things discussed in the past)? I can find many uses for named
 arguments and only one or two for 128-big integral numbers...
 
 I know the story of the car/horse by Ford, but often the users know
 what they need :-) I may use several things currently absent in D2
 while I have little use of many of the things recently added/modified
 in D2. (for example I may like the idea of vector operations, but so
 far I haven't used them yet in actual programs, while I can think of
 several other things missing still that I can find useful today, that
 are missing still in D2).


Yet in the past, many people asked for vector operations.
Dec 28 2008
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 bearophile wrote:

 I have already answered something in another post. But instead of
 asking us/yourself if we can use the feature X, why don't you think
 about implementing the features Y and Z that are most useful to
 programmers, like, for example, named arguments (and several other
 things discussed in the past)? I can find many uses for named
 arguments and only one or two for 128-big integral numbers...

 I know the story of the car/horse by Ford, but often the users know
 what they need :-) I may use several things currently absent in D2
 while I have little use of many of the things recently added/modified
 in D2. (for example I may like the idea of vector operations, but so
 far I haven't used them yet in actual programs, while I can think of
 several other things missing still that I can find useful today, that
 are missing still in D2).


 Yet in the past, many people asked for vector operations.


I absolutely *love* the vector ops, except that they're kind of buggy.  The only
reason I haven't filed bug reports is that the bugs are kind of hard to
reproduce.
 Now that it's been brought to my attention and I have some free time, maybe
I'll
try to reproduce and file some of them.
Dec 28 2008
parent bearophile <bearophileHUGS lycos.com> writes:
dsimcha Wrote:

 I absolutely *love* the vector ops,


I am a person that is usually happy when understands to be wrong, even for few
cases ^_^

Bye,
bearophile
Dec 28 2008
prev sibling next sibling parent "Tim M" <a b.com> writes:
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?
Dec 28 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:


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


If that means bitwise operations on them would optimize to SSE instructions,
then I would love to see them.
Dec 28 2008
parent Weed <resume755 mail.ru> writes:
Jason House пишет:

 Walter Bright Wrote:
 

 You know, the unimplemented 128 bit integer types.

 Does anyone have a use for these?


 
 If that means bitwise operations on them would optimize to SSE instructions,
then I would love to see them.


Why it is impossible to use for the description "128 bit int" structure
and an assembly insertion for operations over it?
Dec 28 2008
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
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.
Dec 28 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 28 2008
prev sibling next sibling parent Jason House <jason.james.house gmail.com> writes:
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.
Dec 28 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 Otherwise, it's hard to imagine many cases where 64 bits are inadequate 
 but 128 bits are enough.


Counting the federal deficit comes to mind.
Dec 28 2008
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
 Does anyone have a use for these?


I use sum area tables in my research and currently restrict the problem  
size to avoid overflow issues, so a longer integer type would be useful.
Dec 28 2008
prev sibling next sibling parent reply Miles <_______ _______.____> writes:
Walter Bright wrote:

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


In distributed systems, *a lot*.

1. In network programming, IPv6 addresses are becoming very common
(nobody should ever think about writing a network-enabled application
without native IPv6 support nowadays). IPv6 addresses are 128-bit. No
arithmetic is needed, just copy, comparison and bitwise, masking and
bitshift operations.

2. Also, UUIDs[1] and other similar universal identification schemes are
very common, we use them all the time in distributed systems. They are
128-bit numbers, only copy, comparison and bitwise operations are needed.

3. In cryptography, also very common in distributed systems, it is
common to have symmetric ciphers with key sizes of 128 and 256-bits. We
currently have to break the cypher blocks in peaces and move a lot of
the complexity up to the algorithm level in order to process such data
in 32 or 64-bit registers and variables. It would be great if
cryptographers could trust compilers to do this in the lower level
(properly using SSE registers and so).

In all these cases, bigints are completely inadequate. I currently have
to use (for the first two cases) a struct with operators implemented in
asm (with different versions for x86 and x64) for efficient manipulation
of these numbers. All this in C and C++.


[1] http://en.wikipedia.org/wiki/Universally_Unique_Identifier
Dec 28 2008
parent Moritz Warning <moritzwarning web.de> writes:
On Sun, 28 Dec 2008 17:17:03 -0200, Miles wrote:


 Walter Bright wrote:

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


 
 In distributed systems, *a lot*.
 
 1. In network programming, IPv6 addresses are becoming very common
 (nobody should ever think about writing a network-enabled application
 without native IPv6 support nowadays). IPv6 addresses are 128-bit. No
 arithmetic is needed, just copy, comparison and bitwise, masking and
 bitshift operations.
 
 2. Also, UUIDs[1] and other similar universal identification schemes are
 very common, we use them all the time in distributed systems. They are
 128-bit numbers, only copy, comparison and bitwise operations are
 needed.
 
 3. In cryptography, also very common in distributed systems, it is
 common to have symmetric ciphers with key sizes of 128 and 256-bits. We
 currently have to break the cypher blocks in peaces and move a lot of
 the complexity up to the algorithm level in order to process such data
 in 32 or 64-bit registers and variables. It would be great if
 cryptographers could trust compilers to do this in the lower level
 (properly using SSE registers and so).
 
 In all these cases, bigints are completely inadequate. I currently have
 to use (for the first two cases) a struct with operators implemented in
 asm (with different versions for x86 and x64) for efficient manipulation
 of these numbers. All this in C and C++.
 
 
 [1] http://en.wikipedia.org/wiki/Universally_Unique_Identifier


Good point.
Dec 29 2008
prev sibling next sibling parent "Saaa" <empty needmail.com> writes:
I could use them for a certain neural network implementation I'm working on 
if they are fast for boolean operations.

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gj6vrj$2lj4$1 digitalmars.com...

 You know, the unimplemented 128 bit integer types.

 Does anyone have a use for these?
Dec 28 2008
prev sibling parent Martin d'Anjou <martin.danjou neterion.com> writes:
 Does anyone have a use for these?


1) 128-bit IPV6 addresses

2) Gives me one more way to implement a Verilog-like fixed size integer
    type.

Martin
Dec 29 2008