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
next sibling 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
parent "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
prev sibling next sibling parent "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
prev sibling 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 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 next sibling parent 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
prev sibling next sibling 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
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
--90e6ba614ff0049b6904d661bd27
Content-Type: text/plain; charset=ISO-8859-1

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'; --90e6ba614ff0049b6904d661bd27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Feb 23, 2013 3:57 AM, &quot;Daniel Murphy&quot; &lt;<a href=3D"mailto:ye= bblies nospamgmail.com">yebblies nospamgmail.com</a>&gt; wrote:<br> &gt;<br> &gt; &quot;Iain Buclaw&quot; &lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuc= law ubuntu.com</a>&gt; wrote in message<br> &gt; news:yhylqjyqkfrebukidkfb forum.dlang.org...<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; Aren&#39;t supposed to go away at some point ?<br> &gt; &gt;<br> &gt; &gt; Maybe... but as they got added as being semantically valid in 2.0= 61,<br> &gt; &gt; requires minimal changes to make it handled by the compiler backe= nd for<br> &gt; &gt; gdc.<br> &gt; &gt;<br> &gt;<br> &gt; Not quite, they became syntactically valid only.<br> &gt;<br> &gt; I guess just pick a couple of letters?<br> &gt;<br> &gt;</p> <p>N and Q ?=A0 That&#39;s pretty much what&#39;s left to choose from. </p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --90e6ba614ff0049b6904d661bd27--
Feb 23 2013
parent "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
prev sibling 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 next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b472810adc3f404d66604f6
Content-Type: text/plain; charset=ISO-8859-1

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. --047d7b472810adc3f404d66604f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Feb 23, 2013 1:52 PM, &quot;Daniel Murphy&quot; &lt;<a href=3D"mailto:ye= bblies nospamgmail.com">yebblies nospamgmail.com</a>&gt; wrote:<br> &gt;<br> &gt; &quot;Iain Buclaw&quot; &lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuc= law ubuntu.com</a>&gt; wrote in message<br> &gt; news:mailman.1477.1361615271.22503.digitalmars-d puremagic.com...<br> &gt; &gt;<br> &gt; &gt; N and Q ? =A0That&#39;s pretty much what&#39;s left to choose fro= m.<br> &gt; &gt;<br> &gt;<br> &gt; I guess, use one as a prefix like bearophile suggested.<br> &gt;<br> &gt; How much frontend support are you planning on adding?<br> &gt;</p> <p>No reason not to allow all typical numeric operations.=A0 Of course you&= #39;ll need explicit casts to do &#39;long =3D cent&#39; operations, and &#= 39;cent =3D long+long&#39; should not require a cast.</p> <p>Overall, there&#39;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.</p> <p>Regards<br> Iain. </p> --047d7b472810adc3f404d66604f6--
Feb 23 2013
parent "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
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
--00248c768dc660c09704d6679df1
Content-Type: text/plain; charset=ISO-8859-1

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 =


 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

 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'; --00248c768dc660c09704d6679df1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Feb 23, 2013 4:41 PM, &quot;Daniel Murphy&quot; &lt;<a href=3D"mailto:ye= bblies nospamgmail.com">yebblies nospamgmail.com</a>&gt; wrote:<br> &gt;<br> &gt; &quot;Iain Buclaw&quot; &lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuc= law ubuntu.com</a>&gt; wrote in message<br> &gt; news:mailman.1485.1361633569.22503.digitalmars-d puremagic.com...<br> &gt; &gt;<br> &gt; &gt; No reason not to allow all typical numeric operations. =A0Of cour= se you&#39;ll<br> &gt; &gt; need explicit casts to do &#39;long =3D cent&#39; operations, and= &#39;cent =3D long+long&#39;<br> &gt; &gt; should not require a cast.<br> &gt; &gt;<br> &gt; &gt; Overall, there&#39;s nothing that looks too special about the typ= e, and<br> &gt; &gt; support<br> &gt; &gt; for it appears to work just fine when testing simple working case= s on<br> &gt; &gt; 32bit.<br> &gt; &gt;<br> &gt;<br> &gt; The problem is in adding complete support to the frontend, you need 12= 8-bit<br> &gt; integer literals, constant folding, ctfe and range propagation. =A0The= re&#39;s<br> &gt; probably more work involved in adding it to the dmd frontend than the = dmd<br> &gt; backend.<br> &gt;</p> <p>I don&#39;t use any part of the dmd backend. :o)</p> <p>Constant folding and ctfe wouldn&#39;t be high priorities for this type.= =A0 Support in frontend would be more equal to, say how vectors are handled= .</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --00248c768dc660c09704d6679df1--
Feb 23 2013
parent "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
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--e89a8f921a1e1281df04d6751a9c
Content-Type: text/plain; charset=ISO-8859-1

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'; --e89a8f921a1e1281df04d6751a9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p>On 24 Feb 2013 01:41, &quot;Daniel Murphy&quot; &lt;<a href=3D"mailto:ye= bblies nospamgmail.com">yebblies nospamgmail.com</a>&gt; wrote:<br> &gt;<br> &gt; &quot;Iain Buclaw&quot; &lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuc= law ubuntu.com</a>&gt; wrote in message<br> &gt; news:mailman.1489.1361640428.22503.digitalmars-d puremagic.com...<br> &gt; &gt;<br> &gt; &gt; I don&#39;t use any part of the dmd backend. :o)<br> &gt; &gt;<br> &gt;<br> &gt; I know, I&#39;m just saying there&#39;s a lot to do for the frontend.<= br> &gt;<br> &gt; &gt; Constant folding and ctfe wouldn&#39;t be high priorities for thi= s type.<br> &gt; &gt; Support in frontend would be more equal to, say how vectors are h= andled.<br> &gt; &gt;<br> &gt;<br> &gt; Last time I tried I ran into a bunch of issues where dmd made assumpti= ons<br> &gt; about what it could do with integral types. =A0Maybe there&#39;s an ea= sy way<br> &gt; around this I didn&#39;t see.<br> &gt;</p> <p>If it proves to be problematic can always had hooks to gcc&#39;s backend= as it can handle 128bit computations through a double_int type (pair of lo= ngs for high and low) - would possibly need a corresponding type in the fro= ntend though as cannot convert between double_int and dinteger_t without ov= erflowing the 64bit type.</p> <p>On the note of structs, it would be grand if the real_t type was a synth= etic float as well. Don&#39;t suppose anyone thought about cross-compilatio= n and problems using the hosts long double type as opposed to a transitiona= l type that can work with the targeted platform/arch from any host with con= sistent results in ctfe.=A0 :)</p> <p>Regards.<br> ----<br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;<br> </p> --e89a8f921a1e1281df04d6751a9c--
Feb 24 2013