• bearophile (13/13) Jun 24 2010 This is one of the last dmd changes:
• Stewart Gordon (12/18) Jun 24 2010
• bearophile (4/7) Jun 24 2010 D1 is mostly in debug mode now. In my opinion specs and other more compl...
• Stewart Gordon (4/13) Jun 26 2010 If that's the case, it's time Walter's pretences of interest in making D...
• Justin Johansson (10/19) Jun 26 2010 Sounds to me in other words that
• Stewart Gordon (6/8) Jun 26 2010
• bearophile (4/6) Jun 26 2010 I don't know, writing the full D1 specs and docs, for example.
• Stewart Gordon (4/9) Jun 27 2010 What do you mean? Writing the language spec has been an ongoing process...
• Jonathan M Davis (9/49) Jun 24 2010 cent and ucent are not currently implemented and have no need to be
• bearophile (4/5) Jun 24 2010 Isn't changeset 557 showing some work to implement them?
• Don (4/11) Jun 24 2010 No, it's back-end only. The opcodes emitted in 32-bit code for long and
• bearophile (4/5) Jun 25 2010 Thank you Don.

bearophile <bearophileHUGS lycos.com> writes:

This is one of the last dmd changes:
http://www.dsource.org/projects/dmd/changeset/557

cent/ucent are probably easy to implement, their implementation can require
little code on 64 bit systems, and operations done among them are probably fast
on 64 bit systems.

128 bit unsigned numbers can represent:
340_282_366_920_938_463_463_374_607_431_768_211_455
Many normal programs don't overflow such numbers. A cent number can also be
used to store safely the result of many operations done on 64 bit values. And
generally I like the idea of having them...

But while I know of few scientific computations situations where quadruple
precision floating point numbers can be useful, in practice I don't know of
situations where cent/ucent can be useful.

One possible situation where ucent can be useful is to perform bitwise
operations on 128-bits-wide SSE registers. But a good D compiler can use
exactly the same CPU instructions when those operators are used among uint[4]
fixed-sized arrays.

So unless some significant application can be found, I suggest to not add
cent/ucent. All features in the language need a purpose, adding useless things
is bad. They can be kept among reserved keywords (as 'macro') for possible
128-bit CPUs.

On the other hand instead of cent/ucent I have several situations (not related
with cryptography) where I'd like in D a built-in "bint" or "bigint", that is
the multi-precision integers (currently in a std.bigint module... well, the
module was present in 2.046, I can't see it in Phobos of 2.047, I don't know
why). Having it built-in allows for better multi-precision literals.

(There are other number types that probably are more useful than cent/ucent,
like a decimal floating point (IEEE standard 854-1987), useful for concurrency.)

Bye,
bearophile

Stewart Gordon <smjg_1998 yahoo.com> writes:

bearophile wrote:
 This is one of the last dmd changes:
 http://www.dsource.org/projects/dmd/changeset/557
 
 cent/ucent are probably easy to implement, their implementation can 
 require little code on 64 bit systems, and operations done among them 
 are probably fast on 64 bit systems.

<snip>

Whether it's implemented any time soon or not, I'd like the "feature" 
whereby trying to use cent/ucent is a _syntax_ error to be finally 
removed.  In the current state of things, making code forward compatible 
is a nightmare, and the later it's left the less backward compatible any 
code using cent/ucent can expect to be.

http://d.puremagic.com/issues/show_bug.cgi?id=785

Unfortunately it's now too late for libraries targeting D 1.0 to make 
use of it.  But still, would it make sense to drop the fix into D1, 
given that there is still work to do on the spec anyway?

Stewart.

bearophile <bearophileHUGS lycos.com> writes:

Stewart Gordon:
 Unfortunately it's now too late for libraries targeting D 1.0 to make 
 use of it.  But still, would it make sense to drop the fix into D1, 
 given that there is still work to do on the spec anyway?

D1 is mostly in debug mode now. In my opinion specs and other more complex jobs
about D1 are going to be delayed indefinitely by Walter. So I think future
changes to D1 will need to come from the community, like Tango users interested
in keeping D1 alive.

Bye,
bearophile

Stewart Gordon <smjg_1998 yahoo.com> writes:

bearophile wrote:
 Stewart Gordon:
 Unfortunately it's now too late for libraries targeting D 1.0 to make 
 use of it.  But still, would it make sense to drop the fix into D1, 
 given that there is still work to do on the spec anyway?

 
 D1 is mostly in debug mode now. In my opinion specs and other more
 complex jobs about D1 are going to be delayed indefinitely by Walter.
 So I think future changes to D1 will need to come from the community,
 like Tango users interested in keeping D1 alive.

If that's the case, it's time Walter's pretences of interest in making D 
implementable by third parties be removed from the docs.

Stewart.

Justin Johansson <no spam.com> writes:

bearophile wrote:
 Stewart Gordon:
 Unfortunately it's now too late for libraries targeting D 1.0 to make 
 use of it.  But still, would it make sense to drop the fix into D1, 
 given that there is still work to do on the spec anyway?

 
 D1 is mostly in debug mode now. In my opinion specs and other more complex
jobs about D1 are going to be delayed indefinitely by Walter. So I think future
changes to D1 will need to come from the community, like Tango users interested
in keeping D1 alive.
 
 Bye,
 bearophile

Sounds to me in other words that

Though D1 is now brain dead (c.f. more complex jobs about D1 are going 
to be delayed indefinitely by Walter),
D1 might be kept on life support (i.e. via an intravenous drip of Tango 
juice or similar)

Either way it is pretty much apparent that D1 has already died of 
natural causes.

Cheers
Justin Johansson

Stewart Gordon <smjg_1998 yahoo.com> writes:

Justin Johansson wrote:
<snip>
 Though D1 is now brain dead (c.f. more complex jobs about D1 are going 
 to be delayed indefinitely by Walter),

<snip>

What "more complex jobs" would they be, let alone ones that don't 
equally affect D2?

Stewart.

bearophile <bearophileHUGS lycos.com> writes:

Stewart Gordon:
 What "more complex jobs" would they be, let alone ones that don't 
 equally affect D2?

I don't know, writing the full D1 specs and docs, for example.

Bye,
bearophile

Stewart Gordon <smjg_1998 yahoo.com> writes:

bearophile wrote:
 Stewart Gordon:
 What "more complex jobs" would they be, let alone ones that don't 
 equally affect D2?

 
 I don't know, writing the full D1 specs and docs, for example.

What do you mean?  Writing the language spec has been an ongoing process 
probably since D's inception.

Stewart.

Jonathan M Davis <jmdavisProg gmail.com> writes:

bearophile wrote:

 This is one of the last dmd changes:
 http://www.dsource.org/projects/dmd/changeset/557
 
 cent/ucent are probably easy to implement, their implementation can
 require little code on 64 bit systems, and operations done among them are
 probably fast on 64 bit systems.
 
 128 bit unsigned numbers can represent:
 340_282_366_920_938_463_463_374_607_431_768_211_455
 Many normal programs don't overflow such numbers. A cent number can also
 be used to store safely the result of many operations done on 64 bit
 values. And generally I like the idea of having them...
 
 But while I know of few scientific computations situations where quadruple
 precision floating point numbers can be useful, in practice I don't know
 of situations where cent/ucent can be useful.
 
 One possible situation where ucent can be useful is to perform bitwise
 operations on 128-bits-wide SSE registers. But a good D compiler can use
 exactly the same CPU instructions when those operators are used among
 uint[4] fixed-sized arrays.
 
 So unless some significant application can be found, I suggest to not add
 cent/ucent. All features in the language need a purpose, adding useless
 things is bad. They can be kept among reserved keywords (as 'macro') for
 possible 128-bit CPUs.
 
 On the other hand instead of cent/ucent I have several situations (not
 related with cryptography) where I'd like in D a built-in "bint" or
 "bigint", that is the multi-precision integers (currently in a std.bigint
 module... well, the module was present in 2.046, I can't see it in Phobos
 of 2.047, I don't know why). Having it built-in allows for better
 multi-precision literals.
 
 (There are other number types that probably are more useful than
 cent/ucent, like a decimal floating point (IEEE standard 854-1987), useful
 for concurrency.)
 
 Bye,
 bearophile

cent and ucent are not currently implemented and have no need to be 
implemented at this point. They are reserved for when they will be deemed 
useful enough to implement (perhaps when we actually have 128-bit machines). 
In the meantime, I see no need to worry about it. They'll get implemented 
when it's appropriate. For now, we can just leave them as reserved and not 
worry about them. The fact that they exist makes it possible to implement 
them later without breaking backwards compatibility.

- Jonathan M Davis

bearophile <bearophileHUGS lycos.com> writes:

Jonathan M Davis:
 cent and ucent are not currently implemented and

Isn't changeset 557 showing some work to implement them?

Bye,
bearophile

Don <nospam nospam.com> writes:

bearophile wrote:
 Jonathan M Davis:
 cent and ucent are not currently implemented and

 
 Isn't changeset 557 showing some work to implement them?
 
 Bye,
 bearophile

No, it's back-end only. The opcodes emitted in 32-bit code for long and 
ulong are exactly the same as the ones for cent and ucent in 64-bit 
code. Including them is *much* simpler than not including them.

bearophile <bearophileHUGS lycos.com> writes:

Don:
 Including them is *much* simpler than not including them.

Thank you Don.

Bye,
bearophile