[dmd-internals] Painting literals in CTFE

[Don Clugston]

There are actually two operations being performed.
(1) Converting an IEEE float <-> int and double<->long.  This is 100%
portable. It does not depend on endianness. (Unless endianness of floating
point values is different from endianness of integer values, but I don't
think you could define BigEndian/LittleEndian in that case, so I'm not sure
that D could ever support such a system, and according to Wikipedia there
are no such systems which support IEEE754).

(2) Converting the compilers internal representation, into an IEEE float.
This is not portable.

In theory, CTFE only needs (1). But, because it is currently using the
compiler's internal representation, it's using (2).

I plan to move CTFE to a JIT-compatible implementation, which will mean it
will only be using (1) internally. But it will still need (2) when doing
the CTFE compile step.

Really what should happen is that (2) should be put into port.c/target.c.
To some degree I'm waiting for the D port, when we will have defined sizes
for builtin types.



On 27 August 2013 17:42, Iain Buclaw <ibuclaw at ubuntu.com> wrote:

> On 20 August 2013 13:03, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
> > Hi,
> >
> > Question aimed vaguely at Don.
> >
> > The routine paintFloatInt in ctfeexpr.c is not portable across
> > compilers (gdc implements its own way of painting float<->int,
> > double<->long through something other than using a union).   Would it
> > be possible to split this off somewhere, such as port.c/target.c -
> > depending on how much of the front-end we need access to in order to
> > carry out the operation?
> >
> >
>
> Ping on this.
>
>
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20130828/30c0f58f/attachment.html>