im curious - when a D compiler is made for 64bit processors (in the near future lets hope :) what will the size of an int be? I assume it will be 8, and long will be 16. So then what will a 2 byte integer be? It cant be a short because that will be a 4 byte integer.

I assume that floating point names will stay the same, as they are defined by the IEEE.

The sizes will be the same as they are now, for all the obvious benefits.

It does seem to me that we should have an additional integral type, say pint, that is an integer of the natural size of the architecture, for maximal efficiency.


"imr1984" <imr1984_member@pathlink.com> wrote in message news:c6b398$f01$1@digitaldaemon.com...
> im curious - when a D compiler is made for 64bit processors (in the near future lets hope :) what will the size of an int be? I assume it will be 8, and long will be 16. So then what will a 2 byte integer be? It cant be a short because that will be a 4 byte integer.
>
> I assume that floating point names will stay the same, as they are defined by the IEEE.
>
>

imr1984 wrote:

>im curious - when a D compiler is made for 64bit processors (in the near future
>lets hope :) what will the size of an int be? I assume it will be 8, and long
>will be 16. 
>
I think this is the C++ way but not the D way.  Sizes should stay fixed (makes ports easier).  There is already a 64 bit long and a 128 bit reserved cent.  See http://www.digitalmars.com/d/type.html.  If your worried simply create alias.

-- 
-Anderson: http://badmama.com.au/~anderson/

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c6b4nj$hdq$1@digitaldaemon.com...
> imr1984 wrote:
>
> >im curious - when a D compiler is made for 64bit processors (in the near
future
> >lets hope :) what will the size of an int be? I assume it will be 8, and long will be 16.
> >
> I think this is the C++ way but not the D way.  Sizes should stay fixed (makes ports easier).  There is already a 64 bit long and a 128 bit reserved cent.  See http://www.digitalmars.com/d/type.html.  If your worried simply create alias.

Well, the point is that using an inappropriately sized integer for a given architecture will have a performance cost. Therefore, anyone using an integer for "normal" counting and such will be at a disadvantage when porting between different sized architectures. To avoid this *every* programmer who is aware of the issue will end up creating their own versioned alias. Therefore, I think it should be part of the language, or at least part of Phobos. Does this not seem sensible?

In article <c6b4ik$h62$1@digitaldaemon.com>, Matthew says...
>
>The sizes will be the same as they are now, for all the obvious benefits.

Will D code be inefficient on 128 bit processors in the future or will all future CPUs just be x86 in disguise?

>It does seem to me that we should have an additional integral type, say pint, that is an integer of the natural size of the architecture, for maximal efficiency.

I made a similar argument quite a while back that D should use C int (size changes with CPU) citing the 16 bit to 32 bit PC migration as an example and personal experience porting code from 32 bit UNIX to 64 bit DEC Alpha UNIX. Properly coded algorithms moved quite easily. Most of the issues were with interfaces and programmers misusing integer types to hold pointers.

Because of the popularity of the x86 most people these days don't use any other CPU architectures (exception: the embedded world).

Matthew wrote:

>
>Well, the point is that using an inappropriately sized integer for a given
>architecture will have a performance cost. Therefore, anyone using an integer for
>"normal" counting and such will be at a disadvantage when porting between
>different sized architectures. To avoid this *every* programmer who is aware of
>the issue will end up creating their own versioned alias. Therefore, I think it
>should be part of the language, or at least part of Phobos. Does this not seem
>sensible?
>  
>
It does.  However on 64 bit machines won't 32 bit integers still be faster because they can be sent two at a time (under certain conditions)?  The same can be said for 16-bit at the moment.

-- 
-Anderson: http://badmama.com.au/~anderson/

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c6b5ta$j67$1@digitaldaemon.com...
>
> "J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c6b4nj$hdq$1@digitaldaemon.com...
> > imr1984 wrote:
> >
> > >im curious - when a D compiler is made for 64bit processors (in the
near
> future
> > >lets hope :) what will the size of an int be? I assume it will be 8,
and long
> > >will be 16.
> > >
> > I think this is the C++ way but not the D way.  Sizes should stay fixed (makes ports easier).  There is already a 64 bit long and a 128 bit reserved cent.  See http://www.digitalmars.com/d/type.html.  If your worried simply create alias.
>
> Well, the point is that using an inappropriately sized integer for a given architecture will have a performance cost. Therefore, anyone using an
integer for
> "normal" counting and such will be at a disadvantage when porting between different sized architectures. To avoid this *every* programmer who is
aware of
> the issue will end up creating their own versioned alias. Therefore, I
think it
> should be part of the language, or at least part of Phobos. Does this not
seem
> sensible?

I vote for putting them in the architecture-specific modules in phobos. Aliases for native int, long, etc. I have a few C library wrappers where I've made up my own aliases but having standard names would help.

I'm not a hardware-Johny, but it's my understanding that using 32-bit integers on 64-bit architectures will be less efficient than using 64-bit integers.

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c6b8uq$okp$1@digitaldaemon.com...
> Matthew wrote:
>
> >
> >Well, the point is that using an inappropriately sized integer for a given architecture will have a performance cost. Therefore, anyone using an integer
for
> >"normal" counting and such will be at a disadvantage when porting between different sized architectures. To avoid this *every* programmer who is aware
of
> >the issue will end up creating their own versioned alias. Therefore, I think
it
> >should be part of the language, or at least part of Phobos. Does this not seem sensible?
> >
> >
> It does.  However on 64 bit machines won't 32 bit integers still be faster because they can be sent two at a time (under certain conditions)?  The same can be said for 16-bit at the moment.
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c6b91g$oo3$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c6b5ta$j67$1@digitaldaemon.com...
> >
> > "J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c6b4nj$hdq$1@digitaldaemon.com...
> > > imr1984 wrote:
> > >
> > > >im curious - when a D compiler is made for 64bit processors (in the
> near
> > future
> > > >lets hope :) what will the size of an int be? I assume it will be 8,
> and long
> > > >will be 16.
> > > >
> > > I think this is the C++ way but not the D way.  Sizes should stay fixed (makes ports easier).  There is already a 64 bit long and a 128 bit reserved cent.  See http://www.digitalmars.com/d/type.html.  If your worried simply create alias.
> >
> > Well, the point is that using an inappropriately sized integer for a given architecture will have a performance cost. Therefore, anyone using an
> integer for
> > "normal" counting and such will be at a disadvantage when porting between different sized architectures. To avoid this *every* programmer who is
> aware of
> > the issue will end up creating their own versioned alias. Therefore, I
> think it
> > should be part of the language, or at least part of Phobos. Does this not
> seem
> > sensible?
>
> I vote for putting them in the architecture-specific modules in phobos. Aliases for native int, long, etc. I have a few C library wrappers where I've made up my own aliases but having standard names would help.

The only downside to this is that it's less visible/obvious, and many people could write much code before becoming aware of the issue, and be left with similar porting nasties that we currently have in C/C++, and which D is intended to avoid/obviate.

Therefore, my preference is that we add a new type, "native", which is an integer of the ambient architecture size. If "native" is listed up there with the other integer types, it will be something that people will learn very early in their use of D, and will therefore not be forgotten or overlooked as is likely with the library approach.

Matthew wrote:

>could write much code before becoming aware of the issue, and be left with
>similar porting nasties that we currently have in C/C++, and which D is intended
>to avoid/obviate.
>
>Therefore, my preference is that we add a new type, "native", which is an integer
>of the ambient architecture size. If "native" is listed up there with the other
>integer types, it will be something that people will learn very early in their
>use of D, and will therefore not be forgotten or overlooked as is likely with the
>library approach.
>  
>
> The only downside to this is that it's less visible/obvious, and many people


I think that people who are un-aware of the issue are more concerned about there code running, rather then running fast.  People who are concern with speed would learn this kinda thing pretty soon.

-- 
-Anderson: http://badmama.com.au/~anderson/