"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?

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.

"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.

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';

"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.

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';