digitalmars.D - 128 bit signed and unsigned integer types
- Walter Bright (2/2) Dec 27 2008 You know, the unimplemented 128 bit integer types.
- BCS (4/8) Dec 27 2008 I'd like to see them. Some times it can be handy to have a "larger" inte...
- Robert Fraser (2/5) Dec 27 2008 Well the only uses I can think of, I'd prefer an unlimited-size big inte...
- John Reimer (4/8) Dec 27 2008 Was that "cent" and "ucent"?
- Walter Bright (3/13) Dec 27 2008 Not a chance :-(
- Andrei Alexandrescu (3/19) Dec 28 2008 Then it looks like we better leave large fixed-size integers to a librar...
- bearophile (4/5) Dec 28 2008 LDC may support 128-bit intrinsic operations, but they may be used from ...
- dsimcha (7/26) Dec 28 2008 Something that I still don't think has been made very clear in this disc...
- Andrei Alexandrescu (15/39) Dec 28 2008 Assume we define a FixedInt(uint bits) structure. That would contain the...
- Yigal Chripun (12/58) Dec 28 2008 is it possible to make int/long/short/etc internal to the compiler and
- Andrei Alexandrescu (4/66) Dec 28 2008 Well it's possible but probably too verbose for many. I mean, if I had
- Yigal Chripun (16/82) Dec 29 2008 Obviously such a solution needs a shorter name to be useful.
- Jarrett Billingsley (5/7) Dec 29 2008 I'd guess there are three use cases for non-native-word-sized ints:
- Jarrett Billingsley (4/11) Dec 29 2008 Er, I should say that unsigned ints _can_ be used for that purpose.
- Martin d'Anjou (4/8) Dec 29 2008 Where can I find FixedInt for generic values of n? I assume FixedInt wil...
- Andrei Alexandrescu (5/15) Dec 29 2008 As of now it's in your mind.
- Chad J (13/33) Dec 29 2008 Cool, but don't name it FixedInt unless it implements fixed point
- Jarrett Billingsley (6/18) Dec 29 2008 I agree with you, but "FixedInt" couldn't possibly have anything to do
- Daniel Keep (14/16) Dec 29 2008 Fine, but don't name it 'Integer' or 'Int' unless it can store any value...
- Don (6/24) Dec 29 2008 I disagree. I'm with Chad. 'Fixed' has a very well established meaning
- Christopher Wright (3/28) Dec 30 2008 I think the bicycle shed would look hideous if it were named anything
- Andrei Alexandrescu (5/30) Dec 30 2008 I think Int following Fixed pretty much takes that meaning away, but
- Sean Kelly (4/10) Dec 30 2008 I like names that read like a phrase. How about IntOfSize? Second
- dsimcha (5/7) Dec 27 2008 Well, we've got bigints in both Phobos and Tango now. Given the clumsin...
- John Reimer (5/16) Dec 27 2008 That's why I was asking about SSE... I believe that they have 128-bit re...
- bearophile (5/8) Dec 28 2008 You can perform a bitwise operation on 128 bits, but not arithmetic.
- John Reimer (3/15) Dec 28 2008 Ok, I see. thanks.
- Walter Bright (2/10) Dec 27 2008 It can be done (not impractical at all), the issue is is it worth while?
- bearophile (5/6) Dec 28 2008 128 bit are two words in the 64-bit CPUs that are now getting very commo...
- Daniel Keep (20/26) Dec 28 2008 It's always annoyed me that the CPU goes to all the trouble of doing
- Andrei Alexandrescu (5/45) Dec 28 2008 If 128-bit built-in integer can't be made more efficient by moving them
- Walter Bright (9/12) Dec 28 2008 The literals would be an issue, otherwise you get into the std::string
- Derek Parnell (6/9) Dec 28 2008 Cryptographers would.
- bearophile (6/8) Dec 28 2008 I have already answered something in another post.
- Walter Bright (2/16) Dec 28 2008 Yet in the past, many people asked for vector operations.
- dsimcha (5/21) Dec 28 2008 I absolutely *love* the vector ops, except that they're kind of buggy. ...
- bearophile (4/5) Dec 28 2008 I am a person that is usually happy when understands to be wrong, even f...
- Tim M (3/5) Dec 28 2008 Does anyone know of true 128 bit cpus not just register size?
- Jason House (2/5) Dec 28 2008 If that means bitwise operations on them would optimize to SSE instructi...
- Weed (3/10) Dec 28 2008 Why it is impossible to use for the description "128 bit int" structure
- Don (11/14) Dec 28 2008 I would have liked them when implementing a fallback (non-asm) bigint
- Andrei Alexandrescu (3/19) Dec 28 2008 For the latter, file sizes come to mind:o).
- Jason House (3/19) Dec 28 2008 32 bit -> 64 bit: 8x8 bit boards in computer chess. zorbist hash codes
- Walter Bright (2/4) Dec 28 2008 Counting the federal deficit comes to mind.
- Robert Jacques (2/3) Dec 28 2008 I use sum area tables in my research and currently restrict the problem ...
- Miles (22/24) Dec 28 2008 In distributed systems, *a lot*.
- Moritz Warning (2/34) Dec 29 2008 Good point.
- Saaa (4/6) Dec 28 2008 I could use them for a certain neural network implementation I'm working...
- Martin d'Anjou (4/5) Dec 29 2008 1) 128-bit IPV6 addresses
You know, the unimplemented 128 bit integer types. Does anyone have a use for these?
Dec 27 2008
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
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
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
John Reimer wrote:Hello Walter,yes.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?Not a chance :-(
Dec 27 2008
Walter Bright wrote:John Reimer wrote:Then it looks like we better leave large fixed-size integers to a library. AndreiHello Walter,yes.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?Not a chance :-(
Dec 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
Dec 28 2008
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s articleWalter Bright wrote: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.John Reimer wrote:Then it looks like we better leave large fixed-size integers to a library. AndreiHello Walter,yes.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?Not a chance :-(
Dec 28 2008
dsimcha wrote:== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s articleAssume 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. AndreiWalter Bright wrote: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.John Reimer wrote:Then it looks like we better leave large fixed-size integers to a library. AndreiHello Walter,yes.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?Not a chance :-(
Dec 28 2008
Andrei Alexandrescu wrote:dsimcha wrote: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.== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s articleAssume 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. AndreiWalter Bright wrote: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.John Reimer wrote:Then it looks like we better leave large fixed-size integers to a library. AndreiHello Walter,yes.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?Not a chance :-(
Dec 28 2008
Yigal Chripun wrote:Andrei Alexandrescu wrote: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). Andreidsimcha wrote: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.== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s articleAssume 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. AndreiWalter Bright wrote: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.John Reimer wrote:Then it looks like we better leave large fixed-size integers to a library. AndreiHello Walter,yes.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?Not a chance :-(
Dec 28 2008
Andrei Alexandrescu wrote:Yigal Chripun wrote: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?Andrei Alexandrescu wrote: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). Andreidsimcha wrote: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.== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s articleAssume 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. AndreiWalter Bright wrote: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.John Reimer wrote:Then it looks like we better leave large fixed-size integers to a library. AndreiHello Walter,yes.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?Not a chance :-(
Dec 29 2008
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
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:Er, I should say that unsigned ints _can_ be used for that purpose. There are certainly plenty of perfectly-justifiable uses for them.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)
Dec 29 2008
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
Martin d'Anjou wrote:As of now it's in your mind. <makes Jedi hand gesture> You only need to write it down and contribute it to Phobos. Andreitemplate 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
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. AndreiCool, 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
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
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
Daniel Keep wrote:Chad J 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' ?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.
Dec 29 2008
Don wrote:Daniel Keep wrote:I think the bicycle shed would look hideous if it were named anything but "Int(uint bits)".Chad J 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' ?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.
Dec 30 2008
Don wrote:Daniel Keep wrote:I think Int following Fixed pretty much takes that meaning away, but that's only me.Chad J 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'.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.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
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
== Quote from Walter Bright (newshound1 digitalmars.com)'s articleYou 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
Hello dsimcha,== Quote from Walter Bright (newshound1 digitalmars.com)'s articleThat'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. -JJRYou 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
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
Hello bearophile,John Reimer:Ok, I see. thanks. -JJRThat'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
dsimcha wrote:== Quote from Walter Bright (newshound1 digitalmars.com)'s articleIt can be done (not impractical at all), the issue is is it worth while?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
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
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, bearophileIt'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
Daniel Keep wrote:bearophile 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. Andrei... 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, bearophileIt'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.
Dec 28 2008
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
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
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
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
== Quote from Walter Bright (newshound1 digitalmars.com)'s articlebearophile wrote: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.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
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
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
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
Jason House пишет:Walter Bright Wrote:Why it is impossible to use for the description "128 bit int" structure and an assembly insertion for operations over it?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
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
Don wrote:Walter Bright wrote:For the latter, file sizes come to mind:o). AndreiYou 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
Don wrote:Walter Bright wrote: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.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
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
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
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
On Sun, 28 Dec 2008 17:17:03 -0200, Miles wrote:Walter Bright wrote:Good point.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 29 2008
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
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