<p>On 24 Feb 2013 01:41, "Daniel Murphy" <<a href="mailto:yebblies@nospamgmail.com">yebblies@nospamgmail.com</a>> wrote:<br>
><br>
> "Iain Buclaw" <<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.com</a>> wrote in message<br>
> news:mailman.1489.1361640428.22503.digitalmars-d@puremagic.com...<br>
> ><br>
> > I don't use any part of the dmd backend. :o)<br>
> ><br>
><br>
> I know, I'm just saying there's a lot to do for the frontend.<br>
><br>
> > Constant folding and ctfe wouldn't be high priorities for this type.<br>
> > Support in frontend would be more equal to, say how vectors are handled.<br>
> ><br>
><br>
> Last time I tried I ran into a bunch of issues where dmd made assumptions<br>
> about what it could do with integral types.  Maybe there's an easy way<br>
> around this I didn't see.<br>
></p>
<p>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.</p>

<p>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.  :)</p>

<p>Regards.<br>
----<br>
Iain Buclaw</p>
<p>*(p < e ? p++ : p) = (c & 0x0f) + '0';<br>
</p>