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 :-(

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"?

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


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"?

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


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"?

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


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 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"?

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


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
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
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?
 

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.
 

(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 "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 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 next 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
prev sibling 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 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