www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mangling for cent/ucent

reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
http://dlang.org/abi.html

This is undocumented - and probably should be raised as a bug as 
is not defined.

Thanks
Iain.
Feb 22 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 February 2013 at 13:31:18 UTC, Iain Buclaw wrote:

 http://dlang.org/abi.html

 This is undocumented - and probably should be raised as a bug 
 as is not defined.

 Thanks
 Iain.


Aren't supposed to go away at some point ?
Feb 22 2013
next sibling parent reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
On Friday, 22 February 2013 at 13:44:09 UTC, deadalnix wrote:

 On Friday, 22 February 2013 at 13:31:18 UTC, Iain Buclaw wrote:

 http://dlang.org/abi.html

 This is undocumented - and probably should be raised as a bug 
 as is not defined.

 Thanks
 Iain.


 Aren't supposed to go away at some point ?


Maybe... but as they got added as being semantically valid in 
2.061, requires minimal changes to make it handled by the 
compiler backend for gdc.


Single letters that not currently in use (as far as I can see):  
N, Q, and z


Regards
Iain
Feb 22 2013
next sibling parent "Iain Buclaw" <ibuclaw ubuntu.com> writes:
On Friday, 22 February 2013 at 13:55:51 UTC, Iain Buclaw wrote:

 On Friday, 22 February 2013 at 13:44:09 UTC, deadalnix wrote:

 On Friday, 22 February 2013 at 13:31:18 UTC, Iain Buclaw wrote:

 http://dlang.org/abi.html

 This is undocumented - and probably should be raised as a bug 
 as is not defined.

 Thanks
 Iain.


 Aren't supposed to go away at some point ?


 Maybe... but as they got added as being semantically valid in 
 2.061, requires minimal changes to make it handled by the 
 compiler backend for gdc.


Also, the current error is "cent and ucent types not implemented" 
- not "cent and ucent types not implemented, technically 
deprecated, and thus never will be, have a nice day *waves*"
Feb 22 2013
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message 
news:yhylqjyqkfrebukidkfb forum.dlang.org...

 Aren't supposed to go away at some point ?


 Maybe... but as they got added as being semantically valid in 2.061, 
 requires minimal changes to make it handled by the compiler backend for 
 gdc.


Not quite, they became syntactically valid only.

I guess just pick a couple of letters?
Feb 22 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On Feb 23, 2013 3:57 AM, "Daniel Murphy" <yebblies nospamgmail.com> wrote:

 "Iain Buclaw" <ibuclaw ubuntu.com> wrote in message
 news:yhylqjyqkfrebukidkfb forum.dlang.org...

 Aren't supposed to go away at some point ?


 Maybe... but as they got added as being semantically valid in 2.061,
 requires minimal changes to make it handled by the compiler backend for
 gdc.


 Not quite, they became syntactically valid only.

 I guess just pick a couple of letters?


N and Q ?  That's pretty much what's left to choose from.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Feb 23 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Iain Buclaw:


 N and Q ?  That's pretty much what's left to choose from.


Maybe "Nc" "Nu" for cent/ucent, and leave "Q" as a prefix for 
future additions?

Bye,
bearophile
Feb 23 2013
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message 
news:mailman.1477.1361615271.22503.digitalmars-d puremagic.com...

 N and Q ?  That's pretty much what's left to choose from.


I guess, use one as a prefix like bearophile suggested.

How much frontend support are you planning on adding?
Feb 23 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On Feb 23, 2013 1:52 PM, "Daniel Murphy" <yebblies nospamgmail.com> wrote:

 "Iain Buclaw" <ibuclaw ubuntu.com> wrote in message
 news:mailman.1477.1361615271.22503.digitalmars-d puremagic.com...

 N and Q ?  That's pretty much what's left to choose from.


 I guess, use one as a prefix like bearophile suggested.

 How much frontend support are you planning on adding?


No reason not to allow all typical numeric operations.  Of course you'll
need explicit casts to do 'long = cent' operations, and 'cent = long+long'
should not require a cast.

Overall, there's nothing that looks too special about the type, and support
for it appears to work just fine when testing simple working cases on 32bit.

Regards
Iain.
Feb 23 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message 
news:mailman.1485.1361633569.22503.digitalmars-d puremagic.com...

 No reason not to allow all typical numeric operations.  Of course you'll
 need explicit casts to do 'long = cent' operations, and 'cent = long+long'
 should not require a cast.

 Overall, there's nothing that looks too special about the type, and 
 support
 for it appears to work just fine when testing simple working cases on 
 32bit.


The problem is in adding complete support to the frontend, you need 128-bit 
integer literals, constant folding, ctfe and range propagation.  There's 
probably more work involved in adding it to the dmd frontend than the dmd 
backend.
Feb 23 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On Feb 23, 2013 4:41 PM, "Daniel Murphy" <yebblies nospamgmail.com> wrote:

 "Iain Buclaw" <ibuclaw ubuntu.com> wrote in message
 news:mailman.1485.1361633569.22503.digitalmars-d puremagic.com...

 No reason not to allow all typical numeric operations.  Of course you'll
 need explicit casts to do 'long = cent' operations, and 'cent =




long+long'

 should not require a cast.

 Overall, there's nothing that looks too special about the type, and
 support
 for it appears to work just fine when testing simple working cases on
 32bit.


 The problem is in adding complete support to the frontend, you need


128-bit

 integer literals, constant folding, ctfe and range propagation.  There's
 probably more work involved in adding it to the dmd frontend than the dmd
 backend.


I don't use any part of the dmd backend. :o)

Constant folding and ctfe wouldn't be high priorities for this type.
Support in frontend would be more equal to, say how vectors are handled.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Feb 23 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message 
news:mailman.1489.1361640428.22503.digitalmars-d puremagic.com...

 I don't use any part of the dmd backend. :o)


I know, I'm just saying there's a lot to do for the frontend.


 Constant folding and ctfe wouldn't be high priorities for this type.
 Support in frontend would be more equal to, say how vectors are handled.


Last time I tried I ran into a bunch of issues where dmd made assumptions 
about what it could do with integral types.  Maybe there's an easy way 
around this I didn't see.
Feb 23 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 24 Feb 2013 01:41, "Daniel Murphy" <yebblies nospamgmail.com> wrote:

 "Iain Buclaw" <ibuclaw ubuntu.com> wrote in message
 news:mailman.1489.1361640428.22503.digitalmars-d puremagic.com...

 I don't use any part of the dmd backend. :o)


 I know, I'm just saying there's a lot to do for the frontend.


 Constant folding and ctfe wouldn't be high priorities for this type.
 Support in frontend would be more equal to, say how vectors are handled.


 Last time I tried I ran into a bunch of issues where dmd made assumptions
 about what it could do with integral types.  Maybe there's an easy way
 around this I didn't see.


If it proves to be problematic can always had hooks to gcc's backend as it
can handle 128bit computations through a double_int type (pair of longs for
high and low) - would possibly need a corresponding type in the frontend
though as cannot convert between double_int and dinteger_t without
overflowing the 64bit type.

On the note of structs, it would be grand if the real_t type was a
synthetic float as well. Don't suppose anyone thought about
cross-compilation and problems using the hosts long double type as opposed
to a transitional type that can work with the targeted platform/arch from
any host with consistent results in ctfe.  :)

Regards.
----
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Feb 24 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
deadalnix:


 Aren't supposed to go away at some point ?


I have never read an official statement of them going away, and
I'd like the cent/ucent types.

On the other hand Andrei has instead suggested to introduce a
fixnum struct in Phobos, that is able to replace a "cent" in many
cases (I don't know if he wants to replace ucent too):

alias cent = Fixnum!128;

Maybe such Fixnum risks being less efficient than a cent (unless
its operations get fully inlined, and this is quite possible if
it's a struct).

If there isn't a perfect inlining, then there is some lost
performance. A D compiler performs optimizations on built-in
integral numbers based on the mathematical properties of such
numbers.

Maybe a way to remove or reduce that lost inefficiency with a
user-defined integral struct value like Fixnum is to introduce in
D annotations like  commutative and  associativity that applied
to such struct definition allows the compiler to perform some
integral-related optimizations. The compiler is not able to
enforce that annotations like  commutative are actually correct
for the user code.

A more "big guns" approach is something like the Axioms that
weren't added to C++11, this is a quite interesting article:

http://akrzemi1.wordpress.com/2012/01/11/concept-axioms-what-for/

axioms allow you to write a concept for integers-like numbers,
usable for a Fixnum, that later the compiler is able to use to
perform those optimizations:


concept IntegerLike<typename T> : CopyConstructible<T> {
      T::T( int );
      T operator*( T, T );

      axiom Commutativity( T x, T y ) {
          x * y <=> y * x;
      }
      axiom Associativity( T x, T y, T z ) {
          (x * y) * z <=> x * (y * z);
      }
      axiom ValuePropagation( int x, int y ) {
          T(x) * T(y) <=> T(x * y);
      }
}


The advantage of  commutative and  associativity is that they are
probably simpler to implement. The disadvantage is that
concept+axiom is much more flexible, allowing you to model other
algebraic properties.

Bye,
bearophile
Feb 22 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 22, 2013 14:44:08 deadalnix wrote:

 On Friday, 22 February 2013 at 13:31:18 UTC, Iain Buclaw wrote:

 http://dlang.org/abi.html
 
 This is undocumented - and probably should be raised as a bug
 as is not defined.
 
 Thanks
 Iain.


 
 Aren't supposed to go away at some point ?


Why would they? They're set aside for the possibility of implementing 128 bit 
integers. If that never happens, then they'll never be used, but it probably 
will happen at some point, and they're reserved until then. I don't believe 
that either Walter or Andrei has ever suggested getting rid of them.

- Jonathan M Davis
Feb 22 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 I don't believe that either Walter or Andrei has ever
 suggested getting rid of them.


Andrei has suggested few times to implement a fixnum in Phobos 
instead of the built-in cent/ucent, and he was quite against a 
recent change that makes allows programmers to know if the 
current D compiler has implemented cent/ucent:

https://github.com/D-Programming-Language/dmd/pull/672

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

Bye,
bearophile
Feb 22 2013