Re: [boost] [integer] Create (u)int_natural_t
----Original Message---- From: Simon Buchan [mailto:simon@hand-multimedia.co.nz] Sent: 29 September 2005 10:21 To: boost@lists.boost.org Subject: Re: [boost] [integer] Create (u)int_natural_t
Daryle Walker wrote:
The "int" type was supposed to match the processor's natural built-in integer processor. That was easy to maintain in the 16- and 32-bit eras, but got screwed up when we started 64-bit computing. The C and C++ communities decided to expand its integer types by keeping the current types at their 32-bit-era sizes and extended the type system with a "long long" instead of moving "int" and "long" up and adding a "short short". Now we don't have a convenient way to name the best integer type in a portable fashion. I suggest we add a "int_natural_t" typedef to <boost/cstdint.hpp> to name the best integer type (and a corresponding "uint_natural_t"). We would have to research what that type is for each compiler and/or platform combination and use #conditionals.
Isn't int the 'natural' integer type, by definition? Depends what you mean by "natural", but for a normal English meaning,
I don't think it's worth it. The performance difference between a 16-bit integer and 32-bit integer on a PDP-11 was pretty significant. Is there any noticable difference between a 32-bit and 64-bit integer on any of the 64-bit processors? probably not.
I never understood why long didn't become the 64-bit type. It seems pointless to have int and long the same size on 32-bit.
Oh god no! The thread that would not die! This has been argued to death on comp.std.c. The reason long didn't become the 64-bit type is that most commercial C compiler vendors wanted to continue to support code their customers had written that assumed long was exactly four eight-bit bytes. You can argue as long as you like that the problem is in that code (and I would agree with you). It won't change the fact that telling your customers they are wrong is not usually the route to commercial success.
Who still writes 16-bit code on desktop, anyway? :D Nobody ... but who still writes for the desktop? Think about the number of car radios (as just one example) compared to the number of PCs. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
Martin Bonner wrote:
----Original Message---- From: Simon Buchan [mailto:simon@hand-multimedia.co.nz] Sent: 29 September 2005 10:21 To: boost@lists.boost.org Subject: Re: [boost] [integer] Create (u)int_natural_t
Daryle Walker wrote:
The "int" type was supposed to match the processor's natural built-in integer processor. That was easy to maintain in the 16- and 32-bit eras, but got screwed up when we started 64-bit computing. The C and C++ communities decided to expand its integer types by keeping the current types at their 32-bit-era sizes and extended the type system with a "long long" instead of moving "int" and "long" up and adding a "short short". Now we don't have a convenient way to name the best integer type in a portable fashion. I suggest we add a "int_natural_t" typedef to <boost/cstdint.hpp> to name the best integer type (and a corresponding "uint_natural_t"). We would have to research what that type is for each compiler and/or platform combination and use #conditionals.
I don't think it's worth it. The performance difference between a 16-bit integer and 32-bit integer on a PDP-11 was pretty significant. Is there any noticable difference between a 32-bit and 64-bit integer on any of the 64-bit processors?
Isn't int the 'natural' integer type, by definition?
Depends what you mean by "natural", but for a normal English meaning, probably not.
I thought we were talking about the type that's easiest for a computer to push around?
I never understood why long didn't become the 64-bit type. It seems pointless to have int and long the same size on 32-bit.
Oh god no! The thread that would not die! This has been argued to death on comp.std.c.
Heh. Sorry :) (But really, what's different?)
The reason long didn't become the 64-bit type is that most commercial C compiler vendors wanted to continue to support code their customers had written that assumed long was exactly four eight-bit bytes.
You can argue as long as you like that the problem is in that code (and I would agree with you). It won't change the fact that telling your customers they are wrong is not usually the route to commercial success.
Oh, ok. But what about non-commercial compilers? And why did int get longer for 32-bit? (You don't have to answer that)
Who still writes 16-bit code on desktop, anyway? :D
Nobody ... but who still writes for the desktop? Think about the number of car radios (as just one example) compared to the number of PCs.
Yes, but there arn't many 64-bit "car radios", and thus not much need to have 4 different int sizes. And I don't believe in the demise of the desktop, just the demise of the desk, but that's a different argument.
On 9/29/05 6:25 AM, "Martin Bonner" <martin.bonner@pitechnology.com> wrote:
----Original Message---- From: Simon Buchan [mailto:simon@hand-multimedia.co.nz] Sent: 29 September 2005 10:21
Daryle Walker wrote:
The "int" type was supposed to match the processor's natural built-in integer processor. That was easy to maintain in the 16- and 32-bit eras, but got screwed up when we started 64-bit computing. The C and C++ communities decided to expand its integer types by keeping the current types at their 32-bit-era sizes and extended the type system with a "long long" instead of moving "int" and "long" up and adding a "short short". Now we don't have a convenient way to name the best integer type in a portable fashion. I suggest we add a "int_natural_t" typedef to <boost/cstdint.hpp> to name the best integer type (and a corresponding "uint_natural_t"). We would have to research what that type is for each compiler and/or platform combination and use #conditionals.
I don't think it's worth it. The performance difference between a 16-bit integer and 32-bit integer on a PDP-11 was pretty significant. Is there any noticable difference between a 32-bit and 64-bit integer on any of the 64-bit processors?
I don't know what the timing difference is. But it's still a penalty we would have to bear, especially for arrays of integers. (I wanted to create a type that had an array of integers, kind of like a std::bitset. I just don't want to suffer a penalty if I can avoid it.) And wouldn't the difference get worse if/when we transition to 128-bit (or 256-bit) computing and "int" stays at 32 bits?
Isn't int the 'natural' integer type, by definition? Depends what you mean by "natural", but for a normal English meaning, probably not. [TRUNCATE a longer exposition of next sentence's content]
It was supposed to always match, but vendors "betrayed" that idea to maintain compatibility. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
On Oct 11, 2005, at 8:45 PM, Daryle Walker wrote:
Isn't int the 'natural' integer type, by definition?
Depends what you mean by "natural", but for a normal English meaning, probably not.
[TRUNCATE a longer exposition of next sentence's content]
It was supposed to always match, but vendors "betrayed" that idea to maintain compatibility.
Actually on the Cray SV1 short and int were both 64 bit, since 32 or 16 bit arithmetic has to be emulated in software on these processors. This has led to quite some incompatibilities and problems when I tried to port Boost to that machine. The Cray X1 now at least allows the user to force 16 or 32 bit integers, albeit at a performance penalty, but that eases compatibility with code written assuming that and int is 32 bit. It seems to me that the real reason why int stays at 32 bit on most machines is to maintain compatibility with old codes. Matthias
On 9/29/05, Martin Bonner <martin.bonner@pitechnology.com> wrote:
----Original Message---- From: Simon Buchan [mailto:simon@hand-multimedia.co.nz] Sent: 29 September 2005 10:21 To: boost@lists.boost.org Subject: Re: [boost] [integer] Create (u)int_natural_t
Daryle Walker wrote:
The "int" type was supposed to match the processor's natural built-in integer processor. That was easy to maintain in the 16- and 32-bit eras, but got screwed up when we started 64-bit computing. The C and C++ communities decided to expand its integer types by keeping the current types at their 32-bit-era sizes and extended the type system with a "long long" instead of moving "int" and "long" up and adding a "short short". Now we don't have a convenient way to name the best integer type in a portable fashion. I suggest we add a "int_natural_t" typedef to <boost/cstdint.hpp> to name the best integer type (and a corresponding "uint_natural_t"). We would have to research what that type is for each compiler and/or platform combination and use #conditionals.
I don't think it's worth it. The performance difference between a 16-bit integer and 32-bit integer on a PDP-11 was pretty significant. Is there any noticable difference between a 32-bit and 64-bit integer on any of the 64-bit processors?
I can't speak for the Itanium and other 64-bit platforms but AMD64 does not incur a penalty for using 32-bit integers in a 64-bit application.
Isn't int the 'natural' integer type, by definition? Depends what you mean by "natural", but for a normal English meaning, probably not.
I never understood why long didn't become the 64-bit type. It seems pointless to have int and long the same size on 32-bit.
Oh god no! The thread that would not die! This has been argued to death on comp.std.c.
The reason long didn't become the 64-bit type is that most commercial C compiler vendors wanted to continue to support code their customers had written that assumed long was exactly four eight-bit bytes.
You can argue as long as you like that the problem is in that code (and I would agree with you). It won't change the fact that telling your customers they are wrong is not usually the route to commercial success.
Who still writes 16-bit code on desktop, anyway? :D Nobody ... but who still writes for the desktop? Think about the number of car radios (as just one example) compared to the number of PCs. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
participants (5)
-
Cory Nelson -
Daryle Walker -
Martin Bonner -
Matthias Troyer -
Simon Buchan