www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Var Types

reply John Smith <John_member pathlink.com> writes:
Why not also include these variable types in D?
int1 - 1 byte
int2 - 2 bytes
int4 - 4 bytes
intN - N bytes (experimental)

It must be also guaranteed that these types will always, on every machine, have
the same size.
Nov 21 2005
next sibling parent reply "Shawn Liu" <shawn666.liu gmail.com> writes:
I think int8, int16, int32, int64 is more comfortable.

"John Smith" <John_member pathlink.com> 
wrote:dlsq7f$30hv$1 digitaldaemon.com...
 Why not also include these variable types in D?
 int1 - 1 byte
 int2 - 2 bytes
 int4 - 4 bytes
 intN - N bytes (experimental)

 It must be also guaranteed that these types will always, on every machine, 
 have
 the same size.

 

Nov 21 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <dlss62$13b$1 digitaldaemon.com>, Shawn Liu says...
I think int8, int16, int32, int64 is more comfortable.

In the interest of hearing this idea out, I'll play the devil's advocate on this one. :) What is wrong with the documented convetions laid out for the byte sizes of the current values? Would it be enough to incorporate those definitions into the (eventual) D ABI, to ensure that all D compiler vendors adhere to the same sizes? While I think there's value in having a standard that is easily grasped, I don't think its necessary to clutter things up with more keywords for already well-defined types. - EricAnderton at yahoo
Nov 21 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message 
news:dlstrd$2i4$1 digitaldaemon.com...
 What is wrong with the documented convetions laid out for the byte sizes 
 of the
 current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size. Then there's short, which I suppose makes sense on both platforms, and int, but neither gives any indication of the size. The only type that does is "byte." I'd personally like int8, int16, int32, etc. This also makes it easy to add new, larger types. What comes after int64? int128, of course. But what comes after "long?" Why, "cent." What?! Huh? But of course, none of this will ever happen / even be considered, so it's kind of an exercise in futility.
Nov 21 2005
next sibling parent reply Tomás Rossi <Tomás_member pathlink.com> writes:
In article <dlsuq9$3d9$1 digitaldaemon.com>, Jarrett Billingsley says...
"pragma" <pragma_member pathlink.com> wrote in message 
news:dlstrd$2i4$1 digitaldaemon.com...
 What is wrong with the documented convetions laid out for the byte sizes 
 of the
 current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size.

Maybe if D bit-length specifications were relative (don't know the downsides of this approach but I'm all ears). For example: ____________________________________________________________________________, TYPE | SIZE | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES | | (relative to 1 | (in bits) | (in bits) | | CPU word) | | | | (register size)| | | ---------+----------------+------------------------+------------------------+ (u)short | 1/2 | 16 | 32 | (u)int | 1 | 32 | 64 | (u)long | 2 | 64 (as VC++s __int64) | 128 | After all, isn't it ugly and less abstract to code assuming a certain sizeof for integral types (and also maybe with other types)? (sizeof brings that information to the programmer and the programmer should code relative to the 'sizeof' of a type and not assuming that size with premeditation).
Then there's 
short, which I suppose makes sense on both platforms, and int, but neither 
gives any indication of the size.  The only type that does is "byte."

Don't know if a type should be THAT explicit with it's size.
I'd personally like int8, int16, int32, etc.  This also makes it easy to add 
new, larger types.  What comes after int64?  int128, of course.  But what 
comes after "long?"  Why, "cent."  What?!  Huh?

But of course, none of this will ever happen / even be considered, so it's 
kind of an exercise in futility. 

Hehe, I agree. Tom
Nov 21 2005
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
In article <dlt3c9$87f$1 digitaldaemon.com>, Tomás Rossi says...
In article <dlsuq9$3d9$1 digitaldaemon.com>, Jarrett Billingsley says...
"pragma" <pragma_member pathlink.com> wrote in message 
news:dlstrd$2i4$1 digitaldaemon.com...
 What is wrong with the documented convetions laid out for the byte sizes 
 of the
 current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size.

Maybe if D bit-length specifications were relative (don't know the downsides of this approach but I'm all ears). For example: ____________________________________________________________________________, TYPE | SIZE | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES | | (relative to 1 | (in bits) | (in bits) | | CPU word) | | | | (register size)| | | ---------+----------------+------------------------+------------------------+ (u)short | 1/2 | 16 | 32 | (u)int | 1 | 32 | 64 | (u)long | 2 | 64 (as VC++s __int64) | 128 |

This is exactly one of the things D was designed to avoid. But it would be nice to have an official alias for the system native register sized type. / Oskar
Nov 21 2005
next sibling parent reply Tomás Rossi <Tomás_member pathlink.com> writes:
In article <dlt4tj$9va$1 digitaldaemon.com>, Oskar Linde says...
In article <dlt3c9$87f$1 digitaldaemon.com>, Tomás Rossi says...
In article <dlsuq9$3d9$1 digitaldaemon.com>, Jarrett Billingsley says...
"pragma" <pragma_member pathlink.com> wrote in message 
news:dlstrd$2i4$1 digitaldaemon.com...
 What is wrong with the documented convetions laid out for the byte sizes 
 of the
 current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size.



What's your opinion on the above?
Maybe if D bit-length specifications were relative (don't know the downsides of
this approach but I'm all ears).
For example:
____________________________________________________________________________,
 TYPE    | SIZE           | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES |  
         | (relative to 1 | (in bits)              | (in bits)              |
         | CPU word)      |                        |                        |
         | (register size)|                        |                        | 
---------+----------------+------------------------+------------------------+
(u)short | 1/2            | 16                     | 32                     |
(u)int   | 1              | 32                     | 64                     |
(u)long  | 2              | 64 (as VC++s __int64)  | 128                    |

This is exactly one of the things D was designed to avoid.

And why is that? (don't really know, is it in D presentation or docs?)
But it would be nice to have an official alias for the system native register
sized type.

Yap. Tom
Nov 21 2005
parent reply MK <MK_member pathlink.com> writes:
In article <dlt5jv$aj6$1 digitaldaemon.com>, Tomás Rossi says...
Maybe if D bit-length specifications were relative (don't know the downsides of
this approach but I'm all ears).
For example:
____________________________________________________________________________,
 TYPE    | SIZE           | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES |  
         | (relative to 1 | (in bits)              | (in bits)              |
         | CPU word)      |                        |                        |
         | (register size)|                        |                        | 
---------+----------------+------------------------+------------------------+
(u)short | 1/2            | 16                     | 32                     |
(u)int   | 1              | 32                     | 64                     |
(u)long  | 2              | 64 (as VC++s __int64)  | 128                    |

This is exactly one of the things D was designed to avoid.

And why is that? (don't really know, is it in D presentation or docs?)

From experience. Its best that Mr Bright stay away from implementation specific types. I believe its better to know absolutely what a given type is. You are programming in D, not x86.
Nov 21 2005
parent reply Tomás Rossi <Tomás_member pathlink.com> writes:
In article <dlti74$k8i$1 digitaldaemon.com>, MK says...
In article <dlt5jv$aj6$1 digitaldaemon.com>, Tomás Rossi says...
Maybe if D bit-length specifications were relative (don't know the downsides of
this approach but I'm all ears).
For example:
____________________________________________________________________________,
 TYPE    | SIZE           | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES |  
         | (relative to 1 | (in bits)              | (in bits)              |
         | CPU word)      |                        |                        |
         | (register size)|                        |                        | 
---------+----------------+------------------------+------------------------+
(u)short | 1/2            | 16                     | 32                     |
(u)int   | 1              | 32                     | 64                     |
(u)long  | 2              | 64 (as VC++s __int64)  | 128                    |

This is exactly one of the things D was designed to avoid.

And why is that? (don't really know, is it in D presentation or docs?)

From experience. Its best that Mr Bright stay away from implementation specific types.

Could you be more specific with the "from experience" part? That didn't really convince me, I mean, you didn't answer my question yet. What's the experience you're referring to?!
I believe its better to know absolutely what a given type is. You are
programming in D, not x86.

That's exactly the suggestion that started the discussion and with wich I agree in essence. There should be standard aliases (if there isn't yet) for intXX types just to be sure what is the exact precision of the integer you need in a platform independent manner. But with actual D approach, say I have a very efficient D app (in wich performance depends on the most efficient integer manipulation for the current CPU), written originally with int data type (because it was conceived for a 32bit system). When I port it to 64bit system, I'll have to make changes (say replacing int with long) to take advantages of the more powerful CPU. Tom
Nov 21 2005
next sibling parent "Kris" <fu bar.com> writes:
"Tomás Rossi" <Tomás_member pathlink.com> wrote.
 In article <dlti74$k8i$1 digitaldaemon.com>, MK says...

 But with actual D approach, say I have a very efficient D app (in wich
 performance depends on the most efficient integer manipulation for the 
 current
 CPU), written originally with int data type (because it was conceived for 
 a
 32bit system). When I port it to 64bit system, I'll have to make changes 
 (say
 replacing int with long) to take advantages of the more powerful CPU.

Can't you provide your own alias in such cases, and change it when you port? Or are you asking for a "fastint" (with a minimal width of 32-bits) to be defined within std.stdint?
Nov 21 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 22 Nov 2005 02:24:19 +0000 (UTC), Tomás Rossi wrote:

[snip]

 But with actual D approach, say I have a very efficient D app (in wich
 performance depends on the most efficient integer manipulation for the current
 CPU), written originally with int data type (because it was conceived for a
 32bit system). When I port it to 64bit system, I'll have to make changes (say
 replacing int with long) to take advantages of the more powerful CPU.

Yes, you are right. In D the 'int' always means 32-bits regardless of the architecture running the application. So if you port it to a different architecture *and* you want to take advantage of the longer integer then you will have to change 'int' to 'long'. Otherwise use aliases of your own making ... version(X86) { alias int stdint; alias long longint; } version(X86_64) { alias long stdint; alias cent longint; } longint foo(stdint A) { return cast(longint)A * cast(longint)A + cast(longint)1; } -- Derek (skype: derek.j.parnell) Melbourne, Australia 22/11/2005 1:35:33 PM
Nov 21 2005
parent reply Tomás Rossi <Tomás_member pathlink.com> writes:
In article <dcr6iol0nzuz.ovrmy3qsc18d.dlg 40tude.net>, Derek Parnell says...
On Tue, 22 Nov 2005 02:24:19 +0000 (UTC), Tomás Rossi wrote:

[snip]

 But with actual D approach, say I have a very efficient D app (in wich
 performance depends on the most efficient integer manipulation for the current
 CPU), written originally with int data type (because it was conceived for a
 32bit system). When I port it to 64bit system, I'll have to make changes (say
 replacing int with long) to take advantages of the more powerful CPU.

Yes, you are right. In D the 'int' always means 32-bits regardless of the architecture running the application. So if you port it to a different architecture *and* you want to take advantage of the longer integer then you will have to change 'int' to 'long'. Otherwise use aliases of your own making ... version(X86) { alias int stdint; alias long longint; } version(X86_64) { alias long stdint; alias cent longint; } longint foo(stdint A) { return cast(longint)A * cast(longint)A + cast(longint)1; }

So, what's the downsides of the platform dependent integer types? Currently, applying your above workaroud (wich is almost a MUST from now on), the downsides are very clear: developers will have to do this for sure in the most projects because 64-bits sytems are a reality in this days and 32-bit ones are rapidly staying behind. Plus the uglyness of having to use stdint everywhere where you would use int and the obvious consequences of type obfuscation due to alias. Tom
Nov 21 2005
parent David Medlock <noone nowhere.com> writes:
Tomás Rossi wrote:
 In article <dcr6iol0nzuz.ovrmy3qsc18d.dlg 40tude.net>, Derek Parnell says...
 
On Tue, 22 Nov 2005 02:24:19 +0000 (UTC), Tomás Rossi wrote:

[snip]


But with actual D approach, say I have a very efficient D app (in wich
performance depends on the most efficient integer manipulation for the current
CPU), written originally with int data type (because it was conceived for a
32bit system). When I port it to 64bit system, I'll have to make changes (say
replacing int with long) to take advantages of the more powerful CPU.

Yes, you are right. In D the 'int' always means 32-bits regardless of the architecture running the application. So if you port it to a different architecture *and* you want to take advantage of the longer integer then you will have to change 'int' to 'long'. Otherwise use aliases of your own making ... version(X86) { alias int stdint; alias long longint; } version(X86_64) { alias long stdint; alias cent longint; } longint foo(stdint A) { return cast(longint)A * cast(longint)A + cast(longint)1; }

So, what's the downsides of the platform dependent integer types? Currently, applying your above workaroud (wich is almost a MUST from now on), the downsides are very clear: developers will have to do this for sure in the most projects because 64-bits sytems are a reality in this days and 32-bit ones are rapidly staying behind. Plus the uglyness of having to use stdint everywhere where you would use int and the obvious consequences of type obfuscation due to alias. Tom

The downside is most programming is tailored to a task and not to a machine. Engineering of all types is based on knowing the capabilities of the raw materials we are working with. As a developer we *have* to know what the bounds of the data types we are working with. There are very few places in most software where 'the fastest integer possible' is needed. And in those cases you would be better off with an alias anyways. So far everything you have asked for is possible within the language, but you are asking for a change which requires hackery for *all the other cases*. -DavidM
Nov 23 2005
prev sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Oskar Linde wrote:
 In article <dlt3c9$87f$1 digitaldaemon.com>, Tomás Rossi says...
 
In article <dlsuq9$3d9$1 digitaldaemon.com>, Jarrett Billingsley says...

"pragma" <pragma_member pathlink.com> wrote in message 
news:dlstrd$2i4$1 digitaldaemon.com...

What is wrong with the documented convetions laid out for the byte sizes 
of the
current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size.

Maybe if D bit-length specifications were relative (don't know the downsides of this approach but I'm all ears). For example: ____________________________________________________________________________, TYPE | SIZE | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES | | (relative to 1 | (in bits) | (in bits) | | CPU word) | | | | (register size)| | | ---------+----------------+------------------------+------------------------+ (u)short | 1/2 | 16 | 32 | (u)int | 1 | 32 | 64 | (u)long | 2 | 64 (as VC++s __int64) | 128 |

This is exactly one of the things D was designed to avoid. But it would be nice to have an official alias for the system native register sized type.

I don't believe it would be nice. The language already has the most needed data types. It's really a pain in the ass to test these variable-length types using different architectures. Maybe they would result in a better c-interoperativity, but still it would make porting d programs harder. Of course you might say that you don't have to use this type, but I have a feeling that not all people ever get it right.
Nov 21 2005
next sibling parent reply Munchgreeble bigfoot.com writes:
In article <dlt9n6$dr6$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
It's really a pain in the ass to test these 
variable-length types using different architectures. Maybe they would 
result in a better c-interoperativity, but still it would make porting d 
programs harder.

Actually, the whole point of such types is to increase ease of portability. It's so that you can say "int32" and know that your code is going to work on any platform, instead of discovering that "int" on your new platform is a different length, and oh my gosh, that data I'm sending across the network is no longer the same format that it used to be, so the different versions of the code running on different machines can no longer talk to each other... and that interface spec I just sent out is now completely worthless - nobody else can talk to my application anymore either. It's not impossible to write your own types - but I've lost count of the number of times I written a types.h file. You lose the "builtin type" highlighting in your favourite editor, and everybody has slightly different naming conventions (uint8, Uint8, UInt8, uint_8, u_int8 etc.), which annoys you when you come in half way through a project where they do it different to you. It would be nice (and I'm assuming, easy) to have this in D. It won't really matter if it's missing, but it's polish - another fix for another niggle that's been there since the year dot. And of course you don't have to use those types if you only ever write single platform pure software applications with no networking capability. Just my tuppence Munch
Nov 21 2005
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Munchgreeble bigfoot.com wrote:
 In article <dlt9n6$dr6$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
 
It's really a pain in the ass to test these 
variable-length types using different architectures. Maybe they would 
result in a better c-interoperativity, but still it would make porting d 
programs harder.

Actually, the whole point of such types is to increase ease of portability. It's so that you can say "int32" and know that your code is going to work on any platform, instead of discovering that "int" on your new platform is a different length, and oh my gosh, that data I'm sending across the network is no longer the same format that it used to be, so the different versions of the code running on different machines can no longer talk to each other... and that interface spec I just sent out is now completely worthless - nobody else can talk to my application anymore either.

I can't see your point here. You see, the "int" is always 32 bits in D. You can alias it to be int32 if you want. Please read http://www.digitalmars.com/d/type.html. As you can see, "real" is the only implementation-depended type.
 
 It's not impossible to write your own types - but I've lost count of the number
 of times I written a types.h file. You lose the "builtin type" highlighting in
 your favourite editor, and everybody has slightly different naming conventions
 (uint8, Uint8, UInt8, uint_8, u_int8 etc.), which annoys you when you come in
 half way through a project where they do it different to you. It would be nice
 (and I'm assuming, easy) to have this in D. It won't really matter if it's
 missing, but it's polish - another fix for another niggle that's been there
 since the year dot. And of course you don't have to use those types if you only
 ever write single platform pure software applications with no networking
 capability.

True, but I'm still saying that D already has these types. If you don't like the current naming convention, you can always alias byte int8 alias short int16 alias int int32 alias long int64 and so on... In C you would have to use implementation specific sizeof-logic. I think Walter has chosen these keywords because they are widely used in other languages. They're also closer to the natural language.
Nov 21 2005
parent Derek Parnell <derek psych.ward> writes:
On Tue, 22 Nov 2005 00:23:27 +0200, Jari-Matti Mäkelä wrote:


[snip]

 True, but I'm still saying that D already has these types. If you don't 
 like the current naming convention, you can always
 
    alias byte int8
    alias short int16
    alias int int32
    alias long int64
 
 and so on...
 
 In C you would have to use implementation specific sizeof-logic.
 
 I think Walter has chosen these keywords because they are widely used in 
 other languages. They're also closer to the natural language.

Another small point would be the increased number of tests when using typeof, typeid, etc... -- Derek (skype: derek.j.parnell) Melbourne, Australia 22/11/2005 10:37:05 AM
Nov 21 2005
prev sibling parent reply MK <MK_member pathlink.com> writes:
In article <dltfj7$i8l$1 digitaldaemon.com>, Munchgreeble bigfoot.com says...
In article <dlt9n6$dr6$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
It's really a pain in the ass to test these 
variable-length types using different architectures. Maybe they would 
result in a better c-interoperativity, but still it would make porting d 
programs harder.

Actually, the whole point of such types is to increase ease of portability. It's so that you can say "int32" and know that your code is going to work on any platform, instead of discovering that "int" on your new platform is a different length, and oh my gosh, that data I'm sending across the network is no longer the same format that it used to be, so the different versions of the code running on different machines can no longer talk to each other... and that interface spec I just sent out is now completely worthless - nobody else can talk to my application anymore either. It's not impossible to write your own types - but I've lost count of the number of times I written a types.h file. You lose the "builtin type" highlighting in your favourite editor, and everybody has slightly different naming conventions (uint8, Uint8, UInt8, uint_8, u_int8 etc.), which annoys you when you come in half way through a project where they do it different to you. It would be nice (and I'm assuming, easy) to have this in D. It won't really matter if it's missing, but it's polish - another fix for another niggle that's been there since the year dot. And of course you don't have to use those types if you only ever write single platform pure software applications with no networking capability. Just my tuppence Munch

But that's the whole point with D. All the integral types are completely unambiguous. I'm not sure what you are asking for? You want the unambiguous integral types renamed, and you want the regular ones to become ambiguious? That sounds a lot like what we are trying to fix in the first place.
Nov 21 2005
parent Munchgreeble <Munchgreeble_member pathlink.com> writes:
In article <dltije$kju$1 digitaldaemon.com>, MK says...
But that's the whole point with D. All the integral types are completely
unambiguous. I'm not sure what you are asking for? You want the unambiguous
integral types renamed, and you want the regular ones to become ambiguious? That
sounds a lot like what we are trying to fix in the first place.

OK - my mistake. Sorry. I should have known better really - most everything else in this language has already been fixed, what made me think this might not have been? D'oh ;-) Thanks for correcting me Munch
Nov 21 2005
prev sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Jari-Matti Mäkelä wrote:
 Oskar Linde wrote:
 
 In article <dlt3c9$87f$1 digitaldaemon.com>, Tomás Rossi says...

 In article <dlsuq9$3d9$1 digitaldaemon.com>, Jarrett Billingsley says...

 "pragma" <pragma_member pathlink.com> wrote in message 
 news:dlstrd$2i4$1 digitaldaemon.com...

 What is wrong with the documented convetions laid out for the byte 
 sizes of the
 current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size.

Maybe if D bit-length specifications were relative (don't know the downsides of this approach but I'm all ears). For example: ____________________________________________________________________________, TYPE | SIZE | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES | | (relative to 1 | (in bits) | (in bits) | | CPU word) | | | | (register size)| | | ---------+----------------+------------------------+------------------------+ (u)short | 1/2 | 16 | 32 | (u)int | 1 | 32 | 64 | (u)long | 2 | 64 (as VC++s __int64) | 128 |

This is exactly one of the things D was designed to avoid. But it would be nice to have an official alias for the system native register sized type.

I don't believe it would be nice. The language already has the most needed data types. It's really a pain in the ass to test these variable-length types using different architectures. Maybe they would result in a better c-interoperativity, but still it would make porting d programs harder. Of course you might say that you don't have to use this type, but I have a feeling that not all people ever get it right.

Sorry, I was wrong. This is a big performance issue. Currently the "int" is maybe the fastest integer type for most x86 users. But now one must use some compile time macros (version/static if/etc) to ensure that the data type used will be fast enough in other environments too.
Nov 21 2005
parent James Dunne <james.jdunne gmail.com> writes:
Jari-Matti Mäkelä wrote:
 Jari-Matti Mäkelä wrote:
 
 Oskar Linde wrote:

 In article <dlt3c9$87f$1 digitaldaemon.com>, Tomás Rossi says...

 In article <dlsuq9$3d9$1 digitaldaemon.com>, Jarrett Billingsley 
 says...

 "pragma" <pragma_member pathlink.com> wrote in message 
 news:dlstrd$2i4$1 digitaldaemon.com...

 What is wrong with the documented convetions laid out for the byte 
 sizes of the
 current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size.

Maybe if D bit-length specifications were relative (don't know the downsides of this approach but I'm all ears). For example: ____________________________________________________________________________, TYPE | SIZE | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES | | (relative to 1 | (in bits) | (in bits) | | CPU word) | | | | (register size)| | | ---------+----------------+------------------------+------------------------+ (u)short | 1/2 | 16 | 32 | (u)int | 1 | 32 | 64 | (u)long | 2 | 64 (as VC++s __int64) | 128 |

This is exactly one of the things D was designed to avoid. But it would be nice to have an official alias for the system native register sized type.

I don't believe it would be nice. The language already has the most needed data types. It's really a pain in the ass to test these variable-length types using different architectures. Maybe they would result in a better c-interoperativity, but still it would make porting d programs harder. Of course you might say that you don't have to use this type, but I have a feeling that not all people ever get it right.

Sorry, I was wrong. This is a big performance issue. Currently the "int" is maybe the fastest integer type for most x86 users. But now one must use some compile time macros (version/static if/etc) to ensure that the data type used will be fast enough in other environments too.

Exactly. Fixing type sizes becomes a problem when you're switching platforms and want to retain efficieny. You want your ints to be fast. However, varying type sizes become an even bigger problem when you're trying to send out network data or store to binary files. The only real solution is two use two (or more?) different sets of types which guarantee different things. We need a set of fast types and we need a set of fixed-size types. Do you not agree? I've already posted the gist of this idea in a lower thread.
Nov 21 2005
prev sibling parent James Dunne <james.jdunne gmail.com> writes:
Tomás Rossi wrote:
 In article <dlsuq9$3d9$1 digitaldaemon.com>, Jarrett Billingsley says...
 
"pragma" <pragma_member pathlink.com> wrote in message 
news:dlstrd$2i4$1 digitaldaemon.com...

What is wrong with the documented convetions laid out for the byte sizes 
of the
current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size.

Maybe if D bit-length specifications were relative (don't know the downsides of this approach but I'm all ears). For example: ____________________________________________________________________________, TYPE | SIZE | LEN IN 32-BIT MACHINES | LEN IN 64-BIT MACHINES | | (relative to 1 | (in bits) | (in bits) | | CPU word) | | | | (register size)| | | ---------+----------------+------------------------+------------------------+ (u)short | 1/2 | 16 | 32 | (u)int | 1 | 32 | 64 | (u)long | 2 | 64 (as VC++s __int64) | 128 | After all, isn't it ugly and less abstract to code assuming a certain sizeof for integral types (and also maybe with other types)? (sizeof brings that information to the programmer and the programmer should code relative to the 'sizeof' of a type and not assuming that size with premeditation).

The problem is this: people need different guarantees about their types' sizes for different purposes. In one instance, you may need a set of types that are absolutely fixed-size for use in reading/writing out binary data to files or streams, etc. In another instance, you may need a set of types that match the processor's supported native word sizes for fast processing.
 
Then there's 
short, which I suppose makes sense on both platforms, and int, but neither 
gives any indication of the size.  The only type that does is "byte."

Don't know if a type should be THAT explicit with it's size.
I'd personally like int8, int16, int32, etc.  This also makes it easy to add 
new, larger types.  What comes after int64?  int128, of course.  But what 
comes after "long?"  Why, "cent."  What?!  Huh?

But of course, none of this will ever happen / even be considered, so it's 
kind of an exercise in futility. 


...unless certain ones designing new languages happen to be listening... I do like the int8, int16, int32, int64 names. It makes sense. Very easy to scale up the language for 128-bit processing and 256-bit processing.
 
 Hehe, I agree.
 
 Tom

Nov 21 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 21 Nov 2005 12:06:27 -0500, Jarrett Billingsley wrote:

 "pragma" <pragma_member pathlink.com> wrote in message 
 news:dlstrd$2i4$1 digitaldaemon.com...
 What is wrong with the documented convetions laid out for the byte sizes 
 of the
 current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size. Then there's short, which I suppose makes sense on both platforms, and int, but neither gives any indication of the size. The only type that does is "byte." I'd personally like int8, int16, int32, etc. This also makes it easy to add new, larger types. What comes after int64? int128, of course. But what comes after "long?" Why, "cent." What?! Huh? But of course, none of this will ever happen / even be considered, so it's kind of an exercise in futility.

Yes it is. However, my comments are that identifiers that are a mixture of alphas and digits reduce legibility. Also, why use the number of bits? Is it likely we would use a number that is not a power of 2? Or could we have an int24? Or an int30? Using a number of bytes seems more useful because I'm sure that all such integer would be one byte boundaries. -- Derek (skype: derek.j.parnell) Melbourne, Australia 22/11/2005 10:24:41 AM
Nov 21 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
Derek Parnell wrote:
 On Mon, 21 Nov 2005 12:06:27 -0500, Jarrett Billingsley wrote:
 
 
"pragma" <pragma_member pathlink.com> wrote in message 
news:dlstrd$2i4$1 digitaldaemon.com...

What is wrong with the documented convetions laid out for the byte sizes 
of the
current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size. Then there's short, which I suppose makes sense on both platforms, and int, but neither gives any indication of the size. The only type that does is "byte." I'd personally like int8, int16, int32, etc. This also makes it easy to add new, larger types. What comes after int64? int128, of course. But what comes after "long?" Why, "cent." What?! Huh? But of course, none of this will ever happen / even be considered, so it's kind of an exercise in futility.

Yes it is. However, my comments are that identifiers that are a mixture of alphas and digits reduce legibility. Also, why use the number of bits? Is it likely we would use a number that is not a power of 2? Or could we have an int24? Or an int30? Using a number of bytes seems more useful because I'm sure that all such integer would be one byte boundaries.

What would you suggest? Not saying that you're a proponent of it, but... What happens to our short, int, long language types when 256-bit processors come along? We'd find it hard to address a 16-bit integer in that system limited to only three type names.
Nov 21 2005
parent reply Tomás Rossi <Tomás_member pathlink.com> writes:
In article <dlucev$16t5$1 digitaldaemon.com>, James Dunne says...
Derek Parnell wrote:
 On Mon, 21 Nov 2005 12:06:27 -0500, Jarrett Billingsley wrote:
 
 
"pragma" <pragma_member pathlink.com> wrote in message 
news:dlstrd$2i4$1 digitaldaemon.com...

What is wrong with the documented convetions laid out for the byte sizes 
of the
current values?

Because although they're documented and strictly defined, they don't make much sense. For example, long makes sense on a 32-bit machine, but on 64-bit machines (to which everything is moving relatively soon), 64 bits is the default size. So "long" would be the "normal" size. Then there's short, which I suppose makes sense on both platforms, and int, but neither gives any indication of the size. The only type that does is "byte." I'd personally like int8, int16, int32, etc. This also makes it easy to add new, larger types. What comes after int64? int128, of course. But what comes after "long?" Why, "cent." What?! Huh? But of course, none of this will ever happen / even be considered, so it's kind of an exercise in futility.

Yes it is. However, my comments are that identifiers that are a mixture of alphas and digits reduce legibility. Also, why use the number of bits? Is it likely we would use a number that is not a power of 2? Or could we have an int24? Or an int30? Using a number of bytes seems more useful because I'm sure that all such integer would be one byte boundaries.

What would you suggest? Not saying that you're a proponent of it, but... What happens to our short, int, long language types when 256-bit processors come along? We'd find it hard to address a 16-bit integer in that system limited to only three type names.

Exactly, what would happen? Would "we" have to engineer another language, would it be D v2 :P? Certainly platform-dependent integral types are THE choice. Aliases of the type intXXX would be necessary always. Tom
Nov 22 2005
parent reply xs0 <xs0 xs0.com> writes:
What happens to our short, int, long language types when 256-bit 
processors come along?  We'd find it hard to address a 16-bit integer in 
that system limited to only three type names.

Exactly, what would happen? Would "we" have to engineer another language, would it be D v2 :P? Certainly platform-dependent integral types are THE choice. Aliases of the type intXXX would be necessary always.

I think you guys are exaggerating the problem. Even 64-bit CPUs were developed (afaik) mainly because of the need to cleanly address more than 4GB of RAM, not because there's some overwhelming need for 64-bit calculations. Considering how much RAM/disk/whatever 2^64 is, I don't think anyone will need a CPU that is 128-bit, let alone 256-bit any time soon (and even if developed because of marketing purposes, I see no reason to use 32-byte variables to have loop counters from 0 to 99). Now, if you have a working app on a 32-bit platform and you move it to a 64-bit platform, is it any help if int becomes 64 bit? No, because if it was big enough before, it's big enough now (with the notable exception of memory locations and sizes, which are taken care of with size_t and ptrdiff_t). Does it hurt? It sure can, as sizes of objects all over the place will change, breaking any interface to outside-the-app. xs0
Nov 22 2005
parent reply Tomás Rossi <Tomás_member pathlink.com> writes:
In article <dlv33k$1o7u$1 digitaldaemon.com>, xs0 says...
What happens to our short, int, long language types when 256-bit 
processors come along?  We'd find it hard to address a 16-bit integer in 
that system limited to only three type names.

Exactly, what would happen? Would "we" have to engineer another language, would it be D v2 :P? Certainly platform-dependent integral types are THE choice. Aliases of the type intXXX would be necessary always.

I think you guys are exaggerating the problem. Even 64-bit CPUs were developed (afaik) mainly because of the need to cleanly address more than 4GB of RAM, not because there's some overwhelming need for 64-bit calculations. Considering how much RAM/disk/whatever 2^64 is, I don't think anyone will need a CPU that is 128-bit, let alone 256-bit any time soon (and even if developed because of marketing purposes, I see no reason to use 32-byte variables to have loop counters from 0 to 99).

The same thing said some people about 32-bit machines before those were developed and now we have 64-bit CPUs. Plus, I´m sure that already exists 128/256-bit CPUs nowadays, maybe not for home PCs, but who say D only has to run on home computers? For example, the PlayStation2 platform is builded upon a 128-bit CPU!
Now, if you have a working app on a 32-bit platform and you move it to a 
64-bit platform, is it any help if int becomes 64 bit? No, because if it 
was big enough before, it's big enough now (with the notable exception 
of memory locations and sizes, which are taken care of with size_t and 
ptrdiff_t). Does it hurt? It sure can, as sizes of objects all over the 
place will change, breaking any interface to outside-the-app.

I can't agree with this. You port an app to 64-bit and rebuild it as a 64-bit edition, not necessarily expecting to work interfacing against a 32-bit version. Besides, why are you so sure that moving to 64-bits won't be much of a gain? "If it was big enough before, it's big enough now"???? Be careful, your ported app will still work, but'll take no benefit of the upgraded processor! If your app focus on std int performance to work better, this is much of a problem. Tom
Nov 22 2005
next sibling parent reply xs0 <xs0 xs0.com> writes:
Tomás Rossi wrote:

I think you guys are exaggerating the problem. Even 64-bit CPUs were 
developed (afaik) mainly because of the need to cleanly address more 
than 4GB of RAM, not because there's some overwhelming need for 64-bit 
calculations. Considering how much RAM/disk/whatever 2^64 is, I don't 
think anyone will need a CPU that is 128-bit, let alone 256-bit any time 
soon (and even if developed because of marketing purposes, I see no 
reason to use 32-byte variables to have loop counters from 0 to 99).

The same thing said some people about 32-bit machines before those were developed and now we have 64-bit CPUs.

Well, sure, people always make mistakes, but can you think of any application anyone will develop in the next 30 years that will need more than 17,179,869,184 GB of ram (or 512x that of disk)? Older limits, like 1MB of 8086 or 4GB of 80386 were somewhat easier to reach, I think :) I mean, even if both needs and technology double each year (and I think it's safe to say that they increase more slowly), it will take over 30 years to reach that... Plus, I´m sure that already exists
 128/256-bit CPUs nowadays, maybe not for home PCs, but who say D only has to
run
 on home computers? For example, the PlayStation2 platform is builded upon a
 128-bit CPU! 

Well, from what I can gather from http://arstechnica.com/reviews/hardware/ee.ars/ the PS2 is actually 64-bit, what is 128-bit are SIMD instructions (which actually work on at most 32-bit vals) and some of the internal buses.. My point was that there's not much need for operating with values over 64 bits, so I don't see the transition to 128 bits happening soon (again, I'm refering to single data items; bus widths, vectorized instructions' widths etc. are a different story, but one that is not relevant to our discussion)
Now, if you have a working app on a 32-bit platform and you move it to a 
64-bit platform, is it any help if int becomes 64 bit? No, because if it 
was big enough before, it's big enough now (with the notable exception 
of memory locations and sizes, which are taken care of with size_t and 
ptrdiff_t). Does it hurt? It sure can, as sizes of objects all over the 
place will change, breaking any interface to outside-the-app.

I can't agree with this. You port an app to 64-bit and rebuild it as a 64-bit edition, not necessarily expecting to work interfacing against a 32-bit version. Besides, why are you so sure that moving to 64-bits won't be much of a gain?

The biggest gain I see in 64 bits is, like I said, the ability to handle more memory, which naturally improves performance for some types of applications, like databases. I don't see much performance gain in general, because there aren't many quantities that require a 64-bit representation in the first place. Even if 64-bit ops are 50x faster on a 64-bit cpu than on a 32-bit cpu, they are very rare (at least in my experience), so the gain is small. Also note that you don't gain any speed by simply making your variables bigger, it that's all you do..
 "If it was big enough before, it's big enough now"???? Be careful, your ported
 app will still work, but'll take no benefit of the upgraded processor! 

Why not? It will be able to use more ram, and operations involving longs will be faster. Are there any other benefits a 64-bit architecture provides? If your
 app focus on std int performance to work better, this is much of a problem.

I don't understand that sentence, sorry :) xs0
Nov 22 2005
next sibling parent Munchgreeble <"a" b.com \"munchgreeble xATx bigfoot xDOTx com\"> writes:
xs0 wrote:

 Tomás Rossi wrote:
 
 xs0

I think you're mixing up address bus and data bus widths. When people talk about a 64-bit machine, they're talking about the size of the address bus. That's what affects how much RAM you can address. The data bus is completely independent of this. For example IIRC the now somewhat dated N64 had a 64 bit address bus and a 256 data bus. It's the data bus that affects the size of the ints you need, not the address bus. The address bus affects how wide your pointer types are. Caveat: I'm no hardware expert ;-) I hope this helps =) Munch
Nov 22 2005
prev sibling parent Tomás Rossi <Tomás_member pathlink.com> writes:
In article <dlvfpq$2410$1 digitaldaemon.com>, xs0 says...
Tomás Rossi wrote:

I think you guys are exaggerating the problem. Even 64-bit CPUs were 
developed (afaik) mainly because of the need to cleanly address more 
than 4GB of RAM, not because there's some overwhelming need for 64-bit 
calculations. Considering how much RAM/disk/whatever 2^64 is, I don't 
think anyone will need a CPU that is 128-bit, let alone 256-bit any time 
soon (and even if developed because of marketing purposes, I see no 
reason to use 32-byte variables to have loop counters from 0 to 99).

The same thing said some people about 32-bit machines before those were developed and now we have 64-bit CPUs.

Well, sure, people always make mistakes, but can you think of any application anyone will develop in the next 30 years that will need more than 17,179,869,184 GB of ram (or 512x that of disk)? Older limits, like 1MB of 8086 or 4GB of 80386 were somewhat easier to reach, I think :) I mean, even if both needs and technology double each year (and I think it's safe to say that they increase more slowly), it will take over 30 years to reach that... Plus, I´m sure that already exists
 128/256-bit CPUs nowadays, maybe not for home PCs, but who say D only has to
run
 on home computers? For example, the PlayStation2 platform is builded upon a
 128-bit CPU! 

Well, from what I can gather from http://arstechnica.com/reviews/hardware/ee.ars/ the PS2 is actually 64-bit, what is 128-bit are SIMD instructions (which actually work on at most 32-bit vals) and some of the internal buses..

Ok, you're right, didn't know.
My point was that there's not much need for operating with values over 
64 bits, so I don't see the transition to 128 bits happening soon 
(again, I'm refering to single data items; bus widths, vectorized 
instructions' widths etc. are a different story, but one that is not 
relevant to our discussion)

Maybe not too soon, but someday it'll happen, that's the thing. When writing a program, you code with future in mind but not so distant future (you know it'll work on 64-bits with minor changes ideally but don't care about 128-bits possibility). But when designing a language that could be implemented in so many CPU architectures, you should take that fact into account. Again, maybe not soon but someday it'll happen and what would be the solution?
Now, if you have a working app on a 32-bit platform and you move it to a 
64-bit platform, is it any help if int becomes 64 bit? No, because if it 
was big enough before, it's big enough now (with the notable exception 
of memory locations and sizes, which are taken care of with size_t and 
ptrdiff_t). Does it hurt? It sure can, as sizes of objects all over the 
place will change, breaking any interface to outside-the-app.

I can't agree with this. You port an app to 64-bit and rebuild it as a 64-bit edition, not necessarily expecting to work interfacing against a 32-bit version. Besides, why are you so sure that moving to 64-bits won't be much of a gain?

The biggest gain I see in 64 bits is, like I said, the ability to handle more memory, which naturally improves performance for some types of applications, like databases. I don't see much performance gain in general, because there aren't many quantities that require a 64-bit representation in the first place. Even if 64-bit ops are 50x faster on a 64-bit cpu than on a 32-bit cpu, they are very rare (at least in my experience), so the gain is small. Also note that you don't gain any speed by simply making your variables bigger, it that's all you do..

Not sure, but I think there are some integral operations that could be done in half the time (doing some magic at least). It's been a long time since I coded in assembly so I can't recall of an example right now.
 "If it was big enough before, it's big enough now"???? Be careful, your ported
 app will still work, but'll take no benefit of the upgraded processor! 

Why not? It will be able to use more ram, and operations involving longs will be faster. Are there any other benefits a 64-bit architecture provides?

I haven't time now, have to go, latter I'll continue with this ones. :)
If your
 app focus on std int performance to work better, this is much of a problem.

I don't understand that sentence, sorry :)

Again Tom
Nov 22 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Tomás Rossi wrote:
 In article <dlv33k$1o7u$1 digitaldaemon.com>, xs0 says...
 
What happens to our short, int, long language types when 256-bit 
processors come along?  We'd find it hard to address a 16-bit integer in 
that system limited to only three type names.

Exactly, what would happen? Would "we" have to engineer another language, would it be D v2 :P? Certainly platform-dependent integral types are THE choice. Aliases of the type intXXX would be necessary always.

I think you guys are exaggerating the problem. Even 64-bit CPUs were developed (afaik) mainly because of the need to cleanly address more than 4GB of RAM, not because there's some overwhelming need for 64-bit calculations. Considering how much RAM/disk/whatever 2^64 is, I don't think anyone will need a CPU that is 128-bit, let alone 256-bit any time soon (and even if developed because of marketing purposes, I see no reason to use 32-byte variables to have loop counters from 0 to 99).

The same thing said some people about 32-bit machines before those were developed and now we have 64-bit CPUs. Plus, I´m sure that already exists 128/256-bit CPUs nowadays, maybe not for home PCs, but who say D only has to run on home computers? For example, the PlayStation2 platform is builded upon a 128-bit CPU!

Oh, come on. The reason for 64-bit registers is purely practical: computer programs need more memory (4GB limit -> 170_000_000_000GB). Another reason is that most systems have Y2038 problems: http://en.wikipedia.org/wiki/Year_2038_problem Current technology road maps tell that memory capacity will follow Moore's law for another 20-30 years now. Currently D specification even supports 128-bit registers. It means that D programs will work at least for another 60 years without any performance issues! The 64-bit time fields won't wrap around until the world explodes! I don't know about PS2, but I believe it needs 128-bit registers to achieve bigger bandwidth. I don't think this concerns you unless you're writing a fast memcpy(). Usually this code is done in assembly => you don't need high-level 128-bit ints.
 
 
Now, if you have a working app on a 32-bit platform and you move it to a 
64-bit platform, is it any help if int becomes 64 bit? No, because if it 
was big enough before, it's big enough now (with the notable exception 
of memory locations and sizes, which are taken care of with size_t and 
ptrdiff_t). Does it hurt? It sure can, as sizes of objects all over the 
place will change, breaking any interface to outside-the-app.

I can't agree with this. You port an app to 64-bit and rebuild it as a 64-bit edition, not necessarily expecting to work interfacing against a 32-bit version. Besides, why are you so sure that moving to 64-bits won't be much of a gain? "If it was big enough before, it's big enough now"???? Be careful, your ported app will still work, but'll take no benefit of the upgraded processor! If your app focus on std int performance to work better, this is much of a problem.

He means that now you can port your applications without any modifications (may not be highest performance, but works at least - actually smart compilers will optimize your code to 64 bits anyway). If you explicitly want to make high-performance 64-bit code, use compile-time logic structures and aliases. Besides, with machine-dependent ints you would need to check your code in either case.
Nov 22 2005
parent reply Tomás Rossi <Tomás_member pathlink.com> writes:
In article <dlvi6c$278u$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
Tomás Rossi wrote:
 In article <dlv33k$1o7u$1 digitaldaemon.com>, xs0 says...
 
What happens to our short, int, long language types when 256-bit 
processors come along?  We'd find it hard to address a 16-bit integer in 
that system limited to only three type names.

Exactly, what would happen? Would "we" have to engineer another language, would it be D v2 :P? Certainly platform-dependent integral types are THE choice. Aliases of the type intXXX would be necessary always.

I think you guys are exaggerating the problem. Even 64-bit CPUs were developed (afaik) mainly because of the need to cleanly address more than 4GB of RAM, not because there's some overwhelming need for 64-bit calculations. Considering how much RAM/disk/whatever 2^64 is, I don't think anyone will need a CPU that is 128-bit, let alone 256-bit any time soon (and even if developed because of marketing purposes, I see no reason to use 32-byte variables to have loop counters from 0 to 99).

The same thing said some people about 32-bit machines before those were developed and now we have 64-bit CPUs. Plus, I´m sure that already exists 128/256-bit CPUs nowadays, maybe not for home PCs, but who say D only has to run on home computers? For example, the PlayStation2 platform is builded upon a 128-bit CPU!

Oh, come on. The reason for 64-bit registers is purely practical: computer programs need more memory (4GB limit -> 170_000_000_000GB). Another reason is that most systems have Y2038 problems: http://en.wikipedia.org/wiki/Year_2038_problem Current technology road maps tell that memory capacity will follow Moore's law for another 20-30 years now. Currently D specification even supports 128-bit registers. It means that D programs will work at least for another 60 years without any performance issues! The 64-bit time fields won't wrap around until the world explodes!

I don't know about PS2, but I believe it needs 128-bit registers to 
achieve bigger bandwidth. I don't think this concerns you unless you're 
writing a fast memcpy(). Usually this code is done in assembly => you 
don't need high-level 128-bit ints.

 
 
Now, if you have a working app on a 32-bit platform and you move it to a 
64-bit platform, is it any help if int becomes 64 bit? No, because if it 
was big enough before, it's big enough now (with the notable exception 
of memory locations and sizes, which are taken care of with size_t and 
ptrdiff_t). Does it hurt? It sure can, as sizes of objects all over the 
place will change, breaking any interface to outside-the-app.

I can't agree with this. You port an app to 64-bit and rebuild it as a 64-bit edition, not necessarily expecting to work interfacing against a 32-bit version. Besides, why are you so sure that moving to 64-bits won't be much of a gain? "If it was big enough before, it's big enough now"???? Be careful, your ported app will still work, but'll take no benefit of the upgraded processor! If your app focus on std int performance to work better, this is much of a problem.

He means that now you can port your applications without any modifications (may not be highest performance, but works at least - actually smart compilers will optimize your code to 64 bits anyway). If you explicitly want to make high-performance 64-bit code, use compile-time logic structures and aliases. Besides, with machine-dependent ints you would need to check your code in either case.

I know what he meant and I know you can do all the alias stuff (you should read the other posts). However, I can say that I could agree with you (and xs0) notwithstanding, I like the platform dependent approach because IMO it makes the language more platform independent and more independent from the current computation model. I understand it's impossible to make a language that suits perfect for everybodys taste. Regards Tom
Nov 22 2005
parent Sean Kelly <sean f4.ca> writes:
Tomás Rossi wrote:
 He means that now you can port your applications without any 
 modifications (may not be highest performance, but works at least - 
 actually smart compilers will optimize your code to 64 bits anyway). If 
 you explicitly want to make high-performance 64-bit code, use 
 compile-time logic structures and aliases. Besides, with 
 machine-dependent ints you would need to check your code in either case.

I know what he meant and I know you can do all the alias stuff (you should read the other posts). However, I can say that I could agree with you (and xs0) notwithstanding, I like the platform dependent approach because IMO it makes the language more platform independent and more independent from the current computation model.

For what it's worth, the C99 stdint header is available here: http://svn.dsource.org/projects/ares/trunk/src/ares/std/c/stdint.d It might serve as a good starting point for someone looking to experiment with platform-dependent types and such. Sean
Nov 22 2005
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Tomás Rossi wrote:
 In article <dlv33k$1o7u$1 digitaldaemon.com>, xs0 says...
 
What happens to our short, int, long language types when 256-bit 
processors come along?  We'd find it hard to address a 16-bit integer in 
that system limited to only three type names.

Exactly, what would happen? Would "we" have to engineer another language, would it be D v2 :P? Certainly platform-dependent integral types are THE choice. Aliases of the type intXXX would be necessary always.

I think you guys are exaggerating the problem. Even 64-bit CPUs were developed (afaik) mainly because of the need to cleanly address more than 4GB of RAM, not because there's some overwhelming need for 64-bit calculations. Considering how much RAM/disk/whatever 2^64 is, I don't think anyone will need a CPU that is 128-bit, let alone 256-bit any time soon (and even if developed because of marketing purposes, I see no reason to use 32-byte variables to have loop counters from 0 to 99).

The same thing said some people about 32-bit machines before those were developed and now we have 64-bit CPUs. Plus, I´m sure that already exists 128/256-bit CPUs nowadays, maybe not for home PCs, but who say D only has to run on home computers? For example, the PlayStation2 platform is builded upon a 128-bit CPU!

No, it's a fundamentally different situation. We're running up against the laws of physics. 2^64 is a fantastically large number. (a) Address buses. If you could store one bit of RAM per silicon atom, a memory chip big enough to require 65 bit addressing would be one cubic centimetre in size. Consider that existing memory chips are only 2D, and you need wiring to connect to each bit. Even if the cooling issues are overcome, it's really hard to imagine that happening. A memory chip big enough to require 129 bit addressing would be larger than the planet. The point is, that we're approaching Star Trek territory. The Enterprise computer probably only has a 128 bit address bus. Many people think that doubling the number of bits is exponential growth. It's not. Adding one more bit is exponential growth! It's exp(exp(x)) which is frighteningly fast function. Faster than a factorial! (b) Data buses I began programming with 8 bit data registers. That was limiting. Almost all useful numbers are greater than 256. 16 bits was better, but still many quanties are > 65536. But almost everything useful fits into a 32 bit register. 32 bits really is a natural size for an integer. The % of applications where each of these is inadequate is decreasing exponentially. Very few applications need 128 bit integers. But almost everything can use increased parallellism, hence 128 bit SIMD instructions. But they're still only using 32 bit integers. I think that even the 60 year timeframe for 128 bit address buses is a bit optimistic. (But I think we will see 1024-core processors long before then. Maybe even by 2015. And we'll see 64K core systems).
Nov 23 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Don Clugston wrote:
 Tomás Rossi wrote:
 In article <dlv33k$1o7u$1 digitaldaemon.com>, xs0 says...
 
 What happens to our short, int, long language types when
 256-bit processors come along?  We'd find it hard to address
 a 16-bit integer in that system limited to only three type
 names.

Exactly, what would happen? Would "we" have to engineer another language, would it be D v2 :P? Certainly platform-dependent integral types are THE choice. Aliases of the type intXXX would be necessary always.

I think you guys are exaggerating the problem. Even 64-bit CPUs were developed (afaik) mainly because of the need to cleanly address more than 4GB of RAM, not because there's some overwhelming need for 64-bit calculations. Considering how much RAM/disk/whatever 2^64 is, I don't think anyone will need a CPU that is 128-bit, let alone 256-bit any time soon (and even if developed because of marketing purposes, I see no reason to use 32-byte variables to have loop counters from 0 to 99).



(Hmm, so for(byte b=0; b<99; b++) is what one writes today?) ;-) One thing that comes to mind is cryptography. Doing serious encrypting on the fly would benefit from having, say, 1024 bit processors. Oh yes, and the NSA and other spooks really need double the width that everyone else has. This is a law of nature. :-) I remember reading about a graphics card that had a 256 bit cpu. This was so long ago that I think it's on the market already.
 The same thing said some people about 32-bit machines before those
 were developed and now we have 64-bit CPUs. Plus, I´m sure that
 already exists 128/256-bit CPUs nowadays, maybe not for home PCs,
 but who say D only has to run on home computers? For example, the
 PlayStation2 platform is builded upon a 128-bit CPU!


Anybody remember the IBM boss? Or the Intel boss? Or Bill? They all said "xxx ought to be plenty enough forever".
 No, it's a fundamentally different situation. We're running up
 against the laws of physics. 2^64 is a fantastically large number.
 
 (a) Address buses. If you could store one bit of RAM per silicon
 atom, a memory chip big enough to require 65 bit addressing would be
 one cubic centimetre in size. Consider that existing memory chips are
 only 2D, and you need wiring to connect to each bit. Even if the
 cooling issues are overcome, it's really hard to imagine that
 happening. A memory chip big enough to require 129 bit addressing
 would be larger than the planet.
 
 The point is, that we're approaching Star Trek territory. The
 Enterprise computer probably only has a 128 bit address bus.
 
 Many people think that doubling the number of bits is exponential 
 growth. It's not. Adding one more bit is exponential growth! It's
 exp(exp(x)) which is frighteningly fast function. Faster than a 
 factorial!
 
 (b) Data buses
 
 I began programming with 8 bit data registers. That was limiting.
 Almost all useful numbers are greater than 256. 16 bits was better,
 but still many quanties are > 65536. But almost everything useful
 fits into a 32 bit register. 32 bits really is a natural size for an
 integer. The % of applications where each of these is inadequate is
 decreasing exponentially. Very few applications need 128 bit
 integers.
 
 But almost everything can use increased parallellism, hence 128 bit
 SIMD instructions. But they're still only using 32 bit integers.
 
 I think that even the 60 year timeframe for 128 bit address buses is
 a bit optimistic. (But I think we will see 1024-core processors long
  before then. Maybe even by 2015. And we'll see 64K core systems).

Depends. I started doing programming on an HP handheld. It had a 4 bit cpu. (Yes, four bits.) Its address bus was wider, though. Programming it was done in assembly, although they never said it in the manual, probably so as not to frighten folks away. My next assembly I wrote on the 6502, which was an 8 bit cpu. The address bus was 16 bits. Then I went on to the PC, which was touted as a 16 bit machine. True, the 8086 was 16 bits, but because that needed an expensive motherboard and memory hardware, a cheaper version was built for the masses, the 8088, so we had 16 bit PCs with an 8 bit data bus. Slow yes, but cheaper. But still 16 bit. (The software never knew.) Currently (I believe) none of the 64 bit cpus actually have address buses that are 64 bits wide. Nobody is the wiser, but when you go to the pc vendor and ask how much memory one can put on this or that 64 bit PC, the usual answer is like "16GB". It is also conceivable (somebody here know the fact?) that most of those 64 bit modern PCs actually use a 32 bit data bus. So, historically, the data bus, the address buss, and the accumulator (where integer math is done, and the width of which is often taken to be the "width of the cpu") have usually not all had the same width -- although folks seem to believe so. --- What we however do need, is a virtual address space that is large enough to accommodate the most demanding applications and data. This makes writing software (and especially operating systems and compilers) a lot easier, because we then don't have to start constructing kludges for the situations where we bang into the end of the memory range. (This is a separate issue from running out of memory.) --- The one thing that guarantees us a 256 bit cpu on everybody's table top eventually, has nothing to do with computers per se. It's to do with the structure of the Western society, and also with our inborn genes. (What???) First, the society thing: the world (within the foreseeable future) is based on capitalism. (I'm no commie, so it's fine with me.) This in itself makes vendors compete. And that's good, otherwise we'd still all be driving T-Fords. But this leads to bigger, faster, fancier, cooler, ... ad absurdum. Laws of physics, bah. In the eighties, it was common knowledge that we wouldn't have hard disks by the time a hard disk goes beyond gigabyte size. It was supposed to be physically impossible. It would have to be some kind of solid state tech instead. And now I read about Nokia phones having internal hard disks with multi gig capacity. Second, it's in our genes. There's a revealing commercial on my TV: day care kids on a break. "My mom makes better food than yours." "My mom makes better food than both of your mothers." A teenager walks by and says "My mother makes better food than any of yours." And then this 2-year old from the other kindergarten says over the fence: "My mother makes the food all your mothers serve." (Think Nestle, Kraft, whatever.) Suits and non-nerds live to brag. "A trillion bit cpu? Naaa, get out of here!" That day is nearer than Doomsday. I don't even bother to bet on it, would be like stealing the money. --- Ever heard "no matter how big your garage, it fills up with crap, and soon your car stays outside"? Ever heard "it makes no difference how big your hard disk is, it takes the same amount of time before it gets full"? Ever heard "it makes no difference how fast the PC is, the next Windows puts it on its knees anyhow"? --- Better computer games, anybody? Who wouldn't like to have a 6-month accurate weather forecast in the pocket the day Boss asks when you'd like to have this year's vacation? We need a good computer model of the human body, so we don't have to kill mice, pigs and apes whenever a new drug is developed. Earthquakes, anybody? Speech recognition that actually works? How about a computer that the law makers can ask every time they've invented a new law? They could get an answer to how the new law _really_ would impact citizens, tax revenue, and other laws!
Nov 23 2005
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Georg Wrede wrote:
 One thing that comes to mind is cryptography. Doing serious encrypting 
 on the fly would benefit from having, say, 1024 bit processors.

I'm no CPU-engineer, but I think there must be a trade-off between extremely huge hardware registers & other cpu optimizations like parallelism. Still current apm-libraries run significantly faster on 64-bit CPUs: http://www.swox.com/gmp/32vs64.html
 Anybody remember the IBM boss? Or the Intel boss? Or Bill? They all said 
 "xxx ought to be plenty enough forever".
 

So you would like to have bigger address space than it is possible to physically implement using all the material we have on Earth?!
 Currently (I believe) none of the 64 bit cpus actually have address 
 buses that are 64 bits wide. Nobody is the wiser, but when you go to the 
 pc vendor and ask how much memory one can put on this or that 64 bit PC, 
 the usual answer is like "16GB".

These 64-bit machines cannot use traditional page tables, otherwise you would end up filling all your available memory with page tables. I think there may be other addressing problems as well, but at least you need to use inverted page tables.
 The one thing that guarantees us a 256 bit cpu on everybody's table top 
 eventually, has nothing to do with computers per se. It's to do with the 
 structure of the Western society, and also with our inborn genes.
 
 Better computer games, anybody?

The best computer games are usually small enough to fit on a single floppy disk. :)
 
 Speech recognition that actually works?

AFAIK modern speech synthesis and recognition are based on linguistics & highly sophisticated neural networks. In fact you need less space than those cut'n'paste things a decade ago. Jari-Matti
Nov 23 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Jari-Matti Mäkelä wrote:
 Georg Wrede wrote:
 
 One thing that comes to mind is cryptography. Doing serious
 encrypting on the fly would benefit from having, say, 1024 bit
 processors.

I'm no CPU-engineer, but I think there must be a trade-off between extremely huge hardware registers & other cpu optimizations like parallelism. Still current apm-libraries run significantly faster on 64-bit CPUs: http://www.swox.com/gmp/32vs64.html

Excellent example!
 Anybody remember the IBM boss? Or the Intel boss? Or Bill? They all
 said "xxx ought to be plenty enough forever".

So you would like to have bigger address space than it is possible to physically implement using all the material we have on Earth?!

Weren't we supposed to colonize other planets too? But seriously, the day a machine with "too much" address space gets brought into the software office, the Pointy Haired boss decrees every developer his own address space. And thereafter it gets all kinds of uses we just don't have the time to invent now. Not that it's what I want -- it's what's gonna happen.
 Better computer games, anybody?

The best computer games are usually small enough to fit on a single floppy disk. :)

For us here, yes!
 Speech recognition that actually works?

AFAIK modern speech synthesis and recognition are based on linguistics & highly sophisticated neural networks. In fact you need less space than those cut'n'paste things a decade ago.

That actually works, was the phrase. :-)
Nov 23 2005
prev sibling next sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <43848FF5.10909 nospam.org>, Georg Wrede says...
Don Clugston wrote:
 Tomás Rossi wrote:
 In article <dlv33k$1o7u$1 digitaldaemon.com>, xs0 says...
 
 What happens to our short, int, long language types when
 256-bit processors come along?  We'd find it hard to address
 a 16-bit integer in that system limited to only three type
 names.

Exactly, what would happen? Would "we" have to engineer another language, would it be D v2 :P? Certainly platform-dependent integral types are THE choice. Aliases of the type intXXX would be necessary always.

I think you guys are exaggerating the problem. Even 64-bit CPUs were developed (afaik) mainly because of the need to cleanly address more than 4GB of RAM, not because there's some overwhelming need for 64-bit calculations. Considering how much RAM/disk/whatever 2^64 is, I don't think anyone will need a CPU that is 128-bit, let alone 256-bit any time soon (and even if developed because of marketing purposes, I see no reason to use 32-byte variables to have loop counters from 0 to 99).



(Hmm, so for(byte b=0; b<99; b++) is what one writes today?) ;-) One thing that comes to mind is cryptography. Doing serious encrypting on the fly would benefit from having, say, 1024 bit processors. Oh yes, and the NSA and other spooks really need double the width that everyone else has. This is a law of nature. :-) I remember reading about a graphics card that had a 256 bit cpu. This was so long ago that I think it's on the market already.
 The same thing said some people about 32-bit machines before those
 were developed and now we have 64-bit CPUs. Plus, I´m sure that
 already exists 128/256-bit CPUs nowadays, maybe not for home PCs,
 but who say D only has to run on home computers? For example, the
 PlayStation2 platform is builded upon a 128-bit CPU!


Anybody remember the IBM boss? Or the Intel boss? Or Bill? They all said "xxx ought to be plenty enough forever".
 No, it's a fundamentally different situation. We're running up
 against the laws of physics. 2^64 is a fantastically large number.
 
 (a) Address buses. If you could store one bit of RAM per silicon
 atom, a memory chip big enough to require 65 bit addressing would be
 one cubic centimetre in size. Consider that existing memory chips are
 only 2D, and you need wiring to connect to each bit. Even if the
 cooling issues are overcome, it's really hard to imagine that
 happening. A memory chip big enough to require 129 bit addressing
 would be larger than the planet.
 
 The point is, that we're approaching Star Trek territory. The
 Enterprise computer probably only has a 128 bit address bus.
 
 Many people think that doubling the number of bits is exponential 
 growth. It's not. Adding one more bit is exponential growth! It's
 exp(exp(x)) which is frighteningly fast function. Faster than a 
 factorial!
 
 (b) Data buses
 
 I began programming with 8 bit data registers. That was limiting.
 Almost all useful numbers are greater than 256. 16 bits was better,
 but still many quanties are > 65536. But almost everything useful
 fits into a 32 bit register. 32 bits really is a natural size for an
 integer. The % of applications where each of these is inadequate is
 decreasing exponentially. Very few applications need 128 bit
 integers.
 
 But almost everything can use increased parallellism, hence 128 bit
 SIMD instructions. But they're still only using 32 bit integers.
 
 I think that even the 60 year timeframe for 128 bit address buses is
 a bit optimistic. (But I think we will see 1024-core processors long
  before then. Maybe even by 2015. And we'll see 64K core systems).

Depends. I started doing programming on an HP handheld. It had a 4 bit cpu. (Yes, four bits.) Its address bus was wider, though. Programming it was done in assembly, although they never said it in the manual, probably so as not to frighten folks away. My next assembly I wrote on the 6502, which was an 8 bit cpu. The address bus was 16 bits. Then I went on to the PC, which was touted as a 16 bit machine. True, the 8086 was 16 bits, but because that needed an expensive motherboard and memory hardware, a cheaper version was built for the masses, the 8088, so we had 16 bit PCs with an 8 bit data bus. Slow yes, but cheaper. But still 16 bit. (The software never knew.) Currently (I believe) none of the 64 bit cpus actually have address buses that are 64 bits wide. Nobody is the wiser, but when you go to the pc vendor and ask how much memory one can put on this or that 64 bit PC, the usual answer is like "16GB". It is also conceivable (somebody here know the fact?) that most of those 64 bit modern PCs actually use a 32 bit data bus. So, historically, the data bus, the address buss, and the accumulator (where integer math is done, and the width of which is often taken to be the "width of the cpu") have usually not all had the same width -- although folks seem to believe so. --- What we however do need, is a virtual address space that is large enough to accommodate the most demanding applications and data. This makes writing software (and especially operating systems and compilers) a lot easier, because we then don't have to start constructing kludges for the situations where we bang into the end of the memory range. (This is a separate issue from running out of memory.) --- The one thing that guarantees us a 256 bit cpu on everybody's table top eventually, has nothing to do with computers per se. It's to do with the structure of the Western society, and also with our inborn genes. (What???) First, the society thing: the world (within the foreseeable future) is based on capitalism. (I'm no commie, so it's fine with me.) This in itself makes vendors compete. And that's good, otherwise we'd still all be driving T-Fords. But this leads to bigger, faster, fancier, cooler, ... ad absurdum. Laws of physics, bah. In the eighties, it was common knowledge that we wouldn't have hard disks by the time a hard disk goes beyond gigabyte size. It was supposed to be physically impossible. It would have to be some kind of solid state tech instead. And now I read about Nokia phones having internal hard disks with multi gig capacity. Second, it's in our genes. There's a revealing commercial on my TV: day care kids on a break. "My mom makes better food than yours." "My mom makes better food than both of your mothers." A teenager walks by and says "My mother makes better food than any of yours." And then this 2-year old from the other kindergarten says over the fence: "My mother makes the food all your mothers serve." (Think Nestle, Kraft, whatever.) Suits and non-nerds live to brag. "A trillion bit cpu? Naaa, get out of here!" That day is nearer than Doomsday. I don't even bother to bet on it, would be like stealing the money. --- Ever heard "no matter how big your garage, it fills up with crap, and soon your car stays outside"? Ever heard "it makes no difference how big your hard disk is, it takes the same amount of time before it gets full"? Ever heard "it makes no difference how fast the PC is, the next Windows puts it on its knees anyhow"? --- Better computer games, anybody? Who wouldn't like to have a 6-month accurate weather forecast in the pocket the day Boss asks when you'd like to have this year's vacation? We need a good computer model of the human body, so we don't have to kill mice, pigs and apes whenever a new drug is developed. Earthquakes, anybody? Speech recognition that actually works? How about a computer that the law makers can ask every time they've invented a new law? They could get an answer to how the new law _really_ would impact citizens, tax revenue, and other laws!

You're out of your mind man but I like it :P I don't like to bound short/int/long to any specific size because we don't know for sure what will happen in the forecoming years... maybe with future quantum computers 32-bit integers would end to be a ridiculous small precision to use or may even just not exist anymore. Not making integers width platform-specific makes D a lot more "unscalable" and it'll be nice that D could be used in distant future platforms as well, without changing it's spec. Tom
Nov 23 2005
next sibling parent reply xs0 <xs0 xs0.com> writes:
Tom wrote:

 I don't like to bound short/int/long to any specific size because we don't know
 for sure what will happen in the forecoming years... maybe with future quantum
 computers 32-bit integers would end to be a ridiculous small precision to use
or
 may even just not exist anymore. Not making integers width platform-specific
 makes D a lot more "unscalable" and it'll be nice that D could be used in
 distant future platforms as well, without changing it's spec.   

Well, if I understand the article http://www.iiap.res.in/outreach/blackhole5.html correctly, any device can only process 10^44 bits a second (where any device means _any_ device, even the entire universe), so even in a trillion years, you can only get about 10^63 bits processed, which is about 2^210. Considering how much smaller part of the time-space we are, and how the universe is not trying hard to produce information useful to humans, I think it's safe to say we'll _never_ need more than 128-bit addressing, at least in this universe :) As for data itself, can you think of any single quantity one would want to commonly represent in a computer using more than 128 bits? If not, D has it all covered (btw, also note that you can't measure things with infinite precision (again regardless of technology), so something like a 2048-bit double for that extra precision is not a good answer, at least if you're not into marketing ;) xs0
Nov 23 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
xs0 wrote:
 
 Well, if I understand the article
 
 http://www.iiap.res.in/outreach/blackhole5.html

That article didn't account for the fact that because of space-time curvature under high gravitation, the actual volume of the black hole is larger than what appears when one only looks at the diameter.
 correctly, any device can only process 10^44 bits a second (where any 
 device means _any_ device, even the entire universe), so even in a 
 trillion years, you can only get about 10^63 bits processed, which is 
 about 2^210. Considering how much smaller part of the time-space we are, 
 and how the universe is not trying hard to produce information useful to 
 humans, I think it's safe to say we'll _never_ need more than 128-bit 
 addressing, at least in this universe :)

So, your figures are off by a factor of ln(2^(V/v)*c^5), where V and v are the real and the apparent volume, respectively, and c is the speed of light in vacuum.
 As for data itself, can you think of any single quantity one would want 
 to commonly represent in a computer using more than 128 bits? If not, D 
 has it all covered (btw, also note that you can't measure things with 
 infinite precision (again regardless of technology), so something like a 
 2048-bit double for that extra precision is not a good answer, at least 
 if you're not into marketing ;)

Na, just kidding.
Nov 23 2005
parent reply Tom <Tom_member pathlink.com> writes:
In article <4384DE09.7060301 nospam.org>, Georg Wrede says...
xs0 wrote:
 
 Well, if I understand the article
 
 http://www.iiap.res.in/outreach/blackhole5.html

That article didn't account for the fact that because of space-time curvature under high gravitation, the actual volume of the black hole is larger than what appears when one only looks at the diameter.

BUAAAAHHHAHAHAHAH!
 correctly, any device can only process 10^44 bits a second (where any 
 device means _any_ device, even the entire universe), so even in a 
 trillion years, you can only get about 10^63 bits processed, which is 
 about 2^210. Considering how much smaller part of the time-space we are, 
 and how the universe is not trying hard to produce information useful to 
 humans, I think it's safe to say we'll _never_ need more than 128-bit 
 addressing, at least in this universe :)

So, your figures are off by a factor of ln(2^(V/v)*c^5), where V and v are the real and the apparent volume, respectively, and c is the speed of light in vacuum.

BUAHAHAHAHAHAHAHHAAHHAHAHAHAHAHAHA! (I can't describe with onomatopoeias how I laughed after reading this, you definitively brought JOY to my day :D !!)
 As for data itself, can you think of any single quantity one would want 
 to commonly represent in a computer using more than 128 bits? If not, D 
 has it all covered (btw, also note that you can't measure things with 
 infinite precision (again regardless of technology), so something like a 
 2048-bit double for that extra precision is not a good answer, at least 
 if you're not into marketing ;)

Na, just kidding.

Ok, enough, I can't bear it anymore! I promise not to post about this issue never again, no matter what I really think about the subject! I'll be happy with actual D-way and I'll pray every night for it to stay like it is just now. God bless Walter and his magniffiecient omnipotent language... Just stop with all that PHYSICs crap!! :P PS: I can prove that God really exists, it exists because of: http://www.iiap.res.in/outreach/blackhole5.html :P Tom
Nov 23 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Tom wrote:
 In article <4384DE09.7060301 nospam.org>, Georg Wrede says...
 
Na, just kidding.

Ok, enough, I can't bear it anymore!

Thanks! Your comments made me laugh so I had tears i my eyes! georg
Nov 23 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Tom wrote:
 In article <43848FF5.10909 nospam.org>, Georg Wrede says...
 
 Better computer games, anybody?
 
 Who wouldn't like to have a 6-month accurate weather forecast in
 the pocket the day Boss asks when you'd like to have this year's
 vacation?
 
 We need a good computer model of the human body, so we don't have
 to kill mice, pigs and apes whenever a new drug is developed.
 
 Earthquakes, anybody?
 
 Speech recognition that actually works?
 
 How about a computer that the law makers can ask every time they've
  invented a new law? They could get an answer to how the new law
 _really_ would impact citizens, tax revenue, and other laws!

You're out of your mind man but I like it :P

Gotta be, DMD is getting to be the absolutely most expensive compiler I've ever used!
 I don't like to bound short/int/long to any specific size because we
 don't know for sure what will happen in the forecoming years... maybe
 with future quantum computers 32-bit integers would end to be a
 ridiculous small precision to use or may even just not exist anymore.
 Not making integers width platform-specific makes D a lot more
 "unscalable" and it'll be nice that D could be used in distant future
 platforms as well, without changing it's spec.

The current crop of int size definitions (damn, I just forgot where they were in the D documentation) is adequate, for the time being. No code breaks if we add later a few wider integral types, so that is not a problem. And anywhere it does make a difference to the programmer, he will choose a specific width for his integers anyhow. (Within his own imagination and foresight, of course.) But anywhere id does not make a difference (like in for-loop indexes, etc.), he'll use whatever is the fastest anyhow. I see no problem with this. And if you're a heavy duty mathematician/programmer writing a new GMP library, then -- compared to the overall effort -- it is a tiny thing to write a couple of conditional typedefs right at the beginning, so your code works ok on several CPU-widths or endiannesses.
Nov 23 2005
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Georg Wrede wrote:
 
 The same thing said some people about 32-bit machines before those
 were developed and now we have 64-bit CPUs. Plus, I´m sure that
 already exists 128/256-bit CPUs nowadays, maybe not for home PCs,
 but who say D only has to run on home computers? For example, the
 PlayStation2 platform is builded upon a 128-bit CPU!


Anybody remember the IBM boss? Or the Intel boss? Or Bill? They all said "xxx ought to be plenty enough forever".

With respect, Bill was an idiot, and it was obvious at the time. The infamous "64K will be enough for everyone" was made at a time when mainframes already had far more RAM than that, and were already increasing. From memory, some of the machines with ferrite core memories had 16K of RAM.
 The point is, that we're approaching Star Trek territory. The
 Enterprise computer probably only has a 128 bit address bus.
 But almost everything can use increased parallellism, hence 128 bit
 SIMD instructions. But they're still only using 32 bit integers.

 I think that even the 60 year timeframe for 128 bit address buses is
 a bit optimistic. (But I think we will see 1024-core processors long
  before then. Maybe even by 2015. And we'll see 64K core systems).

Depends.

 It is also conceivable (somebody here know the fact?) that most of those 
 64 bit modern PCs actually use a 32 bit data bus.

Actually many of the 32 bit Pentiums use a 64 bit or 128 bit data bus!
 So, historically, the data bus, the address buss, and the accumulator 
 (where integer math is done, and the width of which is often taken to be 
 the "width of the cpu") have usually not all had the same width -- 
 although folks seem to believe so.

All this is true. There's no intrinsic restriction on the width of registers. But there are just not many uses for really large fixed-precision numbers. (For arbitrary precision, there are; and the main use of wide arithmetic is to speed up the arbitrary precision case).
 
 What we however do need, is a virtual address space that is large enough 
 to accommodate the most demanding applications and data. This makes 
 writing software (and especially operating systems and compilers) a lot 
 easier, because we then don't have to start constructing kludges for the 
 situations where we bang into the end of the memory range. (This is a 
 separate issue from running out of memory.)

 ---
 
 The one thing that guarantees us a 256 bit cpu on everybody's table top 
 eventually, has nothing to do with computers per se. It's to do with the 
 structure of the Western society, and also with our inborn genes.
 
 (What???) First, the society thing: the world (within the foreseeable 
 future) is based on capitalism. (I'm no commie, so it's fine with me.) 
 This in itself makes vendors compete. And that's good, otherwise we'd 
 still all be driving T-Fords.

<cynic> And the US would still be using imperial measurement units.</cynic>
 But this leads to bigger, faster, fancier, cooler, ... ad absurdum. Laws 
 of physics, bah. In the eighties, it was common knowledge that we 
 wouldn't have hard disks by the time a hard disk goes beyond gigabyte 
 size. It  was supposed to be physically impossible. It would have to be 
 some kind of solid state tech instead. And now I read about Nokia phones 
 having internal hard disks with multi gig capacity.

Those arguments were not based on physics. They were based on assumptions about manufacturing technology. The technological changes required for a 128 bit address bus are so huge, the change in size_t would be irrelevant. To have 128 bits of addressable RAM, you need to store more than 1 bit per atom. This means quantum computers would be already well developed. Here's how I see it: High probability: Multi-CPU systems with huge number of cores. Cures for most cancers. Medium probability: Quantum computers. Cures for all cancers. Colonisation of other planets. Low probability: 128 bit physical address buses. :-) Sure, maybe we'll reach the end of that list. But the ones in the middle will have more impact (even on programmers!) than the last one. This is not something D needs to worry about. But thousand-core CPUs? Definitely.
Nov 24 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Don Clugston wrote:
 Georg Wrede wrote:
 
 Anybody remember the IBM boss? Or the Intel boss? Or Bill? They all
  said "xxx ought to be plenty enough forever".

With respect, Bill was an idiot, and it was obvious at the time.

<joke mode="I just couldn't resist. Don't answer these!"> With respect to me or to Bill? ;-) "was obvious at the time": Bill being an idiot, or xxx being plenty? </joke>
 It is also conceivable (somebody here know the fact?) that most of
  those 64 bit modern PCs actually use a 32 bit data bus.

Actually many of the 32 bit Pentiums use a 64 bit or 128 bit data bus!

Ah, thanks!
 In the eighties, it was common knowledge
 that we wouldn't have hard disks by the time a hard disk goes
 beyond gigabyte size. It  was supposed to be physically impossible.

Those arguments were not based on physics. They were based on assumptions about manufacturing technology.

True. They were advertised as being based on physics, though. And more to the point, on the unability to envision the advances in theoretical physics that are needed in today's magnetic storage technology.
 The technological changes required for a 128 bit address bus are so 
 huge, the change in size_t would be irrelevant.

I wouldn't skip size_t on that assumption. :-) Besides, there'll be smaller computers in the future too, like in gadgets. -- Aahh, and size_t is needed for the virtual address space, not the physical.
 To have 128 bits of addressable RAM, you need to store more than 1
 bit per atom. This means quantum computers would be already well
 developed.

True. Probably the address bus gets wider in the future at about the same rate the total memory of computers has grown historically. (What's that? Without googling around, I'd guess about 1 bit per year. Effectively doubling the RAM size each year.) The data bus might grow faster, though. Imagine being able to fetch a kilobyte at a time! (Hmmm, this issue gets totally f***ed up with level this or level that cache being on-chip, so forget the whole thing!)
 Here's how I see it:
 
 High probability: Multi-CPU systems with huge number of cores. Cures
 for most cancers.

Agreed.
 Medium probability: Quantum computers. Cures for all cancers. 

Disagreed. IMHO they'll go the way bubble memories went. And expert systems with AI. And Prolog.
 Colonisation of other planets.

:-) Yeah, I guess it's inevitable, knowing our genes! After all, we are incurable Imperialists.
 Low probability: 128 bit physical address buses.
 
 :-)

I agree!
 Sure, maybe we'll reach the end of that list. But the ones in the
 middle will have more impact (even on programmers!) than the last
 one.
 
 This is not something D needs to worry about. But thousand-core CPUs?
 Definitely.´

Seriously, I think there's one category we forgot. A lot of buzz has lately been heard about using Graphics Processors in math and dataprosessing. They do a decent job especially when the operations are simple and can use multiple data. (Hey, game graphics isn't much else!) I'd venture a guess that very soon we'll see expansion cards where an ATI or Nvidia chip exists just for coprosessing, i.e. without a monitor plug. Then it won't be long before they're right on the motherboard. Damn, I forgot the link, I recently visited a site dedicated to this. And already one can use the existing GP, using their library drivers. That's parallell processing for the masses. And I honestly think a D library for such would give some nice brag value to D.
Nov 24 2005
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
As a long time C programmer I still think D made a mistake when "fixing" int
size to 32 bits for a compiled language that is supposed to be compatible with
C. We are losing the abstraction that C was designed with. 

On the other hand, you absolutely need uint8, int32, etc types for communicating
with other programs, machines, etc but these types should only be used at the
point of interface.
====================================================
I will quote Paul Hsieh:
"
Misconception: Using smaller data types is faster than larger ones 

The original reason int was put into the C language was so that the fastest data
type on each platform remained abstracted away from the programmer himself. On
modern 32 and 64 bit platforms, small data types like chars and shorts actually
incur extra overhead when converting to and from the default machine word sized
data type. 

On the other hand, one must be wary of cache usage. Using packed data (and in
this vein, small structure fields) for large data objects may pay larger
dividends in global cache coherence, than local algorithmic optimization issues.
"
Nov 24 2005
next sibling parent MWolf <MWolf_member pathlink.com> writes:
In article <dm4eja$9hi$1 digitaldaemon.com>, Mark T says...
As a long time C programmer I still think D made a mistake when "fixing" int
size to 32 bits for a compiled language that is supposed to be compatible with
C. We are losing the abstraction that C was designed with. 

On the other hand, you absolutely need uint8, int32, etc types for communicating
with other programs, machines, etc but these types should only be used at the
point of interface.
====================================================
I will quote Paul Hsieh:
"
Misconception: Using smaller data types is faster than larger ones 

The original reason int was put into the C language was so that the fastest data
type on each platform remained abstracted away from the programmer himself. On
modern 32 and 64 bit platforms, small data types like chars and shorts actually
incur extra overhead when converting to and from the default machine word sized
data type. 

On the other hand, one must be wary of cache usage. Using packed data (and in
this vein, small structure fields) for large data objects may pay larger
dividends in global cache coherence, than local algorithmic optimization issues.
"

As a long time C programmer I don't agree with that. I prefer having fixed types that I can alias myself if I need. I have found that porting C code and having my basic types change size is a real headache. I prefer knowing and specifiying these instances myself. If you want a generic platform-dependant integer - alias one. Its that simple.
Nov 24 2005
prev sibling next sibling parent reply Munchgreeble <"a" b.com \"munchgreeble xATx bigfoot xDOTx com\"> writes:
But surely as a long time C programmer you've also realised that 
portability is usually a far bigger issue than speed. You know what I 
mean, usually there are a couple of sections of code that need to be 
done up real tight. These often end up with assembly language in them 
etc. and are always unportable. That's OK, you just fix those 
non-portable bits when you move platform. What is a pain though, is 
having your *main* integer type in non-portable form, so that you risk 
randomly breaking stuff all over your code when you e.g. move your code 
onto a 16-bit microcontroller.

I can understand C being the way round that it is, CPU cycles were 
somewhat scarcer 30 years ago, and portability was little thought of. 
Nowadays though portability is a big issue. You can still use "alias" to 
define a "fastint" type if you need to, but it's the exception rather 
than the rule. Would I like "fastint" (or some similar) to be built in 
to D, so that I didn't have to make an alias? Sure. If I had to choose 
between the D way and the C way though, I'd choose the D way every time. 
I rarely have to worry about the speed impacts of using the wrong sized 
integer type, but portability, networking/serialisation issues come up 
on virtually everything I've worked on recently.

Times have changed.

Just my tuppence

Munch

Mark T wrote:
 As a long time C programmer I still think D made a mistake when "fixing" int
 size to 32 bits for a compiled language that is supposed to be compatible with
 C. We are losing the abstraction that C was designed with. 
 
 On the other hand, you absolutely need uint8, int32, etc types for
communicating
 with other programs, machines, etc but these types should only be used at the
 point of interface.
 ====================================================
 I will quote Paul Hsieh:
 "
 Misconception: Using smaller data types is faster than larger ones 
 
 The original reason int was put into the C language was so that the fastest
data
 type on each platform remained abstracted away from the programmer himself. On
 modern 32 and 64 bit platforms, small data types like chars and shorts actually
 incur extra overhead when converting to and from the default machine word sized
 data type. 
 
 On the other hand, one must be wary of cache usage. Using packed data (and in
 this vein, small structure fields) for large data objects may pay larger
 dividends in global cache coherence, than local algorithmic optimization
issues.
 "

Nov 24 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Munchgreeble wrote:
 Nowadays though portability is a big issue. You can still use "alias"
 to define a "fastint" type if you need to, but it's the exception
 rather than the rule. Would I like "fastint" (or some similar) to be
 built in to D, so that I didn't have to make an alias? Sure. If I had
 to choose between the D way and the C way though, I'd choose the D
 way every time. I rarely have to worry about the speed impacts of
 using the wrong sized integer type, but portability,
 networking/serialisation issues come up on virtually everything I've
 worked on recently.

Interestingly, the different types for different cpus could (and IMHO should) be aliased in a library. No need to either define this in the language or have Walter use time coding this in DMD. Or in the <your_company_here> import files.
Nov 24 2005
parent MWolf <MWolf_member pathlink.com> writes:
In article <4385DCF1.3060100 nospam.org>, Georg Wrede says...
Munchgreeble wrote:
 Nowadays though portability is a big issue. You can still use "alias"
 to define a "fastint" type if you need to, but it's the exception
 rather than the rule. Would I like "fastint" (or some similar) to be
 built in to D, so that I didn't have to make an alias? Sure. If I had
 to choose between the D way and the C way though, I'd choose the D
 way every time. I rarely have to worry about the speed impacts of
 using the wrong sized integer type, but portability,
 networking/serialisation issues come up on virtually everything I've
 worked on recently.

Interestingly, the different types for different cpus could (and IMHO should) be aliased in a library. No need to either define this in the language or have Walter use time coding this in DMD. Or in the <your_company_here> import files.

EXACTLY! And the real bottom line is any professional who seriously needs this functionality will already have their own type aliases worked out. Its actually a benifit starting from a language that is not ambiguous about its types. I dont want my language changing on a particular platform - I will handle that myself thank you.
Nov 24 2005
prev sibling next sibling parent Tom <Tom_member pathlink.com> writes:
In article <dm4eja$9hi$1 digitaldaemon.com>, Mark T says...
As a long time C programmer I still think D made a mistake when "fixing" int
size to 32 bits for a compiled language that is supposed to be compatible with
C. We are losing the abstraction that C was designed with. 

On the other hand, you absolutely need uint8, int32, etc types for communicating
with other programs, machines, etc but these types should only be used at the
point of interface.
====================================================
I will quote Paul Hsieh:
"
Misconception: Using smaller data types is faster than larger ones 

The original reason int was put into the C language was so that the fastest data
type on each platform remained abstracted away from the programmer himself. On
modern 32 and 64 bit platforms, small data types like chars and shorts actually
incur extra overhead when converting to and from the default machine word sized
data type. 

On the other hand, one must be wary of cache usage. Using packed data (and in
this vein, small structure fields) for large data objects may pay larger
dividends in global cache coherence, than local algorithmic optimization issues.
"

mmmmhhh mmhhm mmmmmhhhhhhhh (muzzled) wish I could speak about this :D Tom
Nov 24 2005
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
 ====================================================
 I will quote Paul Hsieh:
 "
 Misconception: Using smaller data types is faster than larger ones 
 
 The original reason int was put into the C language was so that the fastest
data
 type on each platform remained abstracted away from the programmer himself. On
 modern 32 and 64 bit platforms, small data types like chars and shorts actually
 incur extra overhead when converting to and from the default machine word sized
 data type.

Yes, this was true when we went from 16-> 32 bits, but I don't think this holds for the 32 -> 64 bit transition. AMD realised that almost all useful integers fit into small sizes. AFAIK, 32 bit operations are still equal fastest on AMD64. They have the important benefit of requiring less storage, and they require less bus bandwidth. Consequently, most C++ compilers for AMD64 still keep int=32 bits. (Most of them even keep long=32 bits!). I've noticed that in the 16 bit days, my code was full of longs. 65535 is just too small, it was really annoying. But now that I have 32 bit ints, there's not much need for anything bigger. In the mid-80's I used a Pascal compiler that had 24 bit ints. They were always big enough, too. But even back then, 16 bits was not enough. 32 bits is a really useful size. I think D's got it right.
Nov 24 2005
parent Mark T <Mark_member pathlink.com> writes:
In article <dm4n1l$ikm$1 digitaldaemon.com>, Don Clugston says...
 ====================================================
 I will quote Paul Hsieh:
 "
 Misconception: Using smaller data types is faster than larger ones 
 
 The original reason int was put into the C language was so that the fastest
data
 type on each platform remained abstracted away from the programmer himself. On
 modern 32 and 64 bit platforms, small data types like chars and shorts actually
 incur extra overhead when converting to and from the default machine word sized
 data type.

Yes, this was true when we went from 16-> 32 bits, but I don't think this holds for the 32 -> 64 bit transition. AMD realised that almost all useful integers fit into small sizes. AFAIK, 32 bit operations are still equal fastest on AMD64. They have the important benefit of requiring less storage, and they require less bus bandwidth. Consequently, most C++ compilers for AMD64 still keep int=32 bits. (Most of them even keep long=32 bits!). I've noticed that in the 16 bit days, my code was full of longs. 65535 is just too small, it was really annoying. But now that I have 32 bit ints, there's not much need for anything bigger. In the mid-80's I used a Pascal compiler that had 24 bit ints. They were always big enough, too. But even back then, 16 bits was not enough. 32 bits is a really useful size. I think D's got it right.

Will this be true on 128 bit CPUs? AMD64 (x86-64)is a compromise design because the pure 64 bit CPUs such as Alpha and Itanium could not run x86-32 bit code efficiently. The game boxes, other dedicated embedded systems, etc don't have to make this compromise and have used other CPUs (I agree that for PCs the x86-64 is the proper migration path). I think many of the posters on this thread bring only a PC perspective to their arguments. C has survived a long time on many CPUs from its PDP-11 beginnings, I wonder what K + R would have to say on this topic.
Nov 24 2005
prev sibling parent Munchgreeble bigfoot.com writes:
In article <dlss62$13b$1 digitaldaemon.com>, Shawn Liu says...
I think int8, int16, int32, int64 is more comfortable.

"John Smith" <John_member pathlink.com> 
wrote:dlsq7f$30hv$1 digitaldaemon.com...
 Why not also include these variable types in D?
 int1 - 1 byte
 int2 - 2 bytes
 int4 - 4 bytes
 intN - N bytes (experimental)

 It must be also guaranteed that these types will always, on every machine, 
 have
 the same size.


I think this is a nice idea. Most projects either have network data formats to define and/or interface with hardware, both of which require you to once again write a "prim_types.h" file (in C/C++) to yet again define what a Uint8/Int8/Uint16/Int16 etc. are on the platform that you're using this time round. It doesn't take that long to do, and it's an obvious thing to use "alias" for... but it's another thing that it would be really nice to have builtin to the language instead of having to do it by hand. A key word for me in the suggestion is "also". We definitely need to be able to specify "int" as the platform-native (i.e. fastest) integer type. Just my tuppence! Munch
Nov 21 2005
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
John Smith escribió:
 Why not also include these variable types in D?
 int1 - 1 byte
 int2 - 2 bytes
 int4 - 4 bytes
 intN - N bytes (experimental)
 
 It must be also guaranteed that these types will always, on every machine, have
 the same size.
 
 

std.stdint contains aliases for those -- Carlos Santander Bernal
Nov 21 2005
parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
 std.stdint contains aliases for those

That's the wrong way around if you'd ask me. I would also like decorated types, eventually aliased to the C int/short/long (with 'int' being the platform's default). L.
Nov 22 2005
parent reply Carlos Santander <csantander619 gmail.com> writes:
Lionello Lunesu escribió:
std.stdint contains aliases for those

That's the wrong way around if you'd ask me. I would also like decorated types, eventually aliased to the C int/short/long (with 'int' being the platform's default). L.

I'm not saying it's the right or wrong way. It's just that every once in a while people come and ask exactly the same: int8, fast_int, etc., and while D doesn't have them as proper types, at least they exist as aliases in the standard library, so they're guaranteed to exist. And even with sizes, as other have mentioned, D's typesystem is all about fixed sizes, so maybe you don't get the names you want, but you get the functionality. -- Carlos Santander Bernal
Nov 22 2005
parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
 And even with sizes, as other have mentioned, D's typesystem is all about 
 fixed sizes, so maybe you don't get the names you want, but you get the 
 functionality.

Good point. But there's one reason this doesn't quite go up. Most of the time I don't care what 'int' I use. I use 'int' for any number. I use it in for-loops, in simple structs, in interfaces. Most of the time the size of the int doesn't matter and I just want a number. Only when serializing to disk or network I want fixed size types. It's nice that D fixes the size of an int, but it's not really helping me. On another platform the registers might not have 32-bits but now all my numbers I don't care about will generate excessive code since D forces them to 32-bits. It's "the wrong way around" because D makes me create and use an alias for the cases I didn't care about. Now I have to care about those cases for portability. L.
Nov 22 2005
parent Carlos Santander <csantander619 gmail.com> writes:
Lionello Lunesu escribió:
 
 But there's one reason this doesn't quite go up. Most of the time I don't 
 care what 'int' I use. I use 'int' for any number. I use it in for-loops, in 
 simple structs, in interfaces. Most of the time the size of the int doesn't 
 matter and I just want a number. Only when serializing to disk or network I 
 want fixed size types.
 
 It's nice that D fixes the size of an int, but it's not really helping me. 
 On another platform the registers might not have 32-bits but now all my 
 numbers I don't care about will generate excessive code since D forces them 
 to 32-bits.
 
 It's "the wrong way around" because D makes me create and use an alias for 
 the cases I didn't care about. Now I have to care about those cases for 
 portability.
 
 L. 
 
 

So use "auto". It won't work for all situations (like your "simple struct" example), but I think it'll work. -- Carlos Santander Bernal
Nov 23 2005
prev sibling parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
A thought occurs! (to cite Zapp Brannigan)

How about a type called "register" which is guaranteed the platform's 
register size. Notice the similarity with C's "register" keyword (which is a 
type modifier):

for(register t=0; t<99; ++t) { }

What guarantees can be made with respect to a register's size?

L. 
Nov 24 2005