Achilleas Margaritis wrote:
> It seems like a good language, but does the world really need yet another
> C++ clone ? D is enough, I think.

It's not at all the same direction as D. It shall never become as popular as D may. It's quite interesting though. And it's approximately the same kind of C++ clone as you or myself are monkey clones. :)

-i.

Well, you should know that long has to be at least as large as int.  If you're going to typecast a pointer to an integer, you should definitely use long if you want to be portable.  There is no guarantee in C/C++ that any given integer will fit a pointer (ok, long is all but guaranteed to fit a pointer, but it may be wasteful).

Maybe D should have a type similar to C++'s pseudotype ptrdiff_t that is always the integer representation of a pointer.  Same size as normal pointers on the machine, and unsigned and signed versions should exist.

Not sure what you'd call them.

We really would need another type these days.. 128-bit cpu's are starting to come out, and some of them let you do 128-bit arithmetic.  D has the cent keyword for this, but what about the next one, 256?  Anyway today, we need software emulation for cent type, just like 16-bit cpu's needed to software emulate 32-bit math, and 8-bit cpu's had to emulate 16-bit math.  ;)

In C, those 4 types would just continue to slide over to cover the area (breaking old code in the process, I might add).  In D at least the sizes are fixed, even though this might potentially hurt D's portability (what if a platform doesn't support a 32-bit integer register?)

Sean

"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:bhqbjl$6eu$1@digitaldaemon.com...
> C++ is misunderstood. Int and long are two different data types. It is
just
> a coincidence that they have the same range on 32-bit machines. Int is a wildcard: it has the size of the native CPU's word. So it is 16 bits on 16-bit CPUs, 32-bits on 32 bit CPUs and 64 bits on 64-bit CPUs. On the
other
> hand, 'long' is always 32 bits.
>
> Since C/C++ is a language that can be used to write operating systems,
there
> is a need to treat pointers as integers. That is the reason why 'int' exists; in other words, it is a native data type that pointer values can
be
> stored into.

> We really would need another type these days.. 128-bit cpu's are starting to come out, and some of them let you do 128-bit arithmetic. D has the cent keyword for this, but what about the next one, 256? Anyway today, we need software emulation for cent type, just like 16-bit cpu's needed to software emulate 32-bit math, and 8-bit cpu's had to emulate 16-bit math.  ;)

Hm, IMHO there are little uses for 64bit-arithmetic, very little uses for 128bit-arithmetic, and I can't imagine why I would want 256bit arithmetic. In the time I've been coding, 32bit has always been a very sweet spot in terms of integer range - you very rarely need more in pratical applications. I remember lots of coding 32bit-with-16bit- arithmetic in my 16bit-times. The amount of occassions I've been doing 64bit-arithmetic is significantly lower, and the only reason for 128bit I can readily imagine is because the product of two 64bit-values fits in that range; I truly can't imagine one single reason for having individual 256bit values (4 64bit values packed in 256bits for SIMD, maybe; but one single 256bit chunk?)

-fg

I don't think they'll replace 32-bit values anytime soon, but yeah, they're for measuring really large quantities, such as nanoseconds since the Egyptians built the pyramids, or millimeters to Alpha Centauri.  ;)  You already find 64-bit values in CPU cycle timers, and if they get another order of magnitude faster it'll be 128 before you know it.

You can think of an integer as the mantissa of a really high precision fraction in the range 0 to 1, and then scale that conceptually to any range you wish (you need double precision to hold temporary results of multiplications!).  People are always wanting more precision.  If you gave a film studio 3D hardware that had a 64-bit z-buffer they'd probably go insane with glee.

Maybe it will stop at 128 bits.  I don't see register size growth slowing completely to a halt, ever, not so long as the ram keeps getting larger, we'll need integers big enough to address it.  Either that or use page selectors (remember segment registers?)

Maybe the cpu vendors are using register size to sell increased ram capacity and faster buses, since the bigger the registers, the more ram taken to hold a value, which means you need more ram and a faster bus, which means you need a new computer, which has bigger registers... hehehe.

Sean

"Fabian Giesen" <rygNO@SPAMgmx.net> wrote in message news:bhu9ph$30d9$1@digitaldaemon.com...
> Hm, IMHO there are little uses for 64bit-arithmetic, very little uses for 128bit-arithmetic, and I can't imagine why I would want 256bit arithmetic. In the time I've been coding, 32bit has always been a very sweet spot in terms of integer range - you very rarely need more in pratical applications. I remember lots of coding 32bit-with-16bit- arithmetic in my 16bit-times. The amount of occassions I've been doing 64bit-arithmetic is significantly lower, and the only reason for 128bit I can readily imagine is because the product of two 64bit-values fits in that range; I truly can't imagine one single reason for having individual 256bit values (4 64bit values packed in 256bits for SIMD, maybe; but one single 256bit chunk?)
>
> -fg

Fabian Giesen wrote:
>>We really would need another type these days.. 128-bit cpu's are
>>starting to come out, and some of them let you do 128-bit arithmetic.
>>D has the cent keyword for this, but what about the next one, 256?
>>Anyway today, we need software emulation for cent type, just like
>>16-bit cpu's needed to software emulate 32-bit math, and 8-bit cpu's
>>had to emulate 16-bit math.  ;)
> 
> 
> Hm, IMHO there are little uses for 64bit-arithmetic, very little uses
> for 128bit-arithmetic, and I can't imagine why I would want 256bit
> arithmetic. In the time I've been coding, 32bit has always been a very
> sweet spot in terms of integer range - you very rarely need more in
> pratical applications. I remember lots of coding 32bit-with-16bit-
> arithmetic in my 16bit-times. The amount of occassions I've been doing
> 64bit-arithmetic is significantly lower, and the only reason for 128bit
> I can readily imagine is because the product of two 64bit-values fits in
> that range; I truly can't imagine one single reason for having individual
> 256bit values (4 64bit values packed in 256bits for SIMD, maybe; but one
> single 256bit chunk?)
> 
> -fg

I agree that there are not many uses for 64 bit values or pointers.  All of our software is designed from the ground up in 64-bit land, but our needs in EDA are the exception.

Personally, I don't like the 'cent' keyword.  It reminds me of Verilog's 'time' keyword.  Yuk.  Here I am writing wide bus interfaces, and I keep using variables of type 'time'.  It's only a matter of time before we start using 'cent' to represent all kinds of non-money related values.

Why not allow types like int32 and uint32?  That convention scales, and is easier to read than byte, short, int, long, and cent.  All you have to do is parse keywords of the form "int[0-9]*", and assign a bit width to the token returned.  The default width would be 32.  You could still put aliases in Phobos to get the traditional keywords.

If we can't get the more generic mechanism, then changing 'cent' to 'hyper' would be an improvement IMO.

Bill

P.S.  Here's a somewhat contrived use for 256 bit values:  computing standard deviations of 'cent' values.