CTFE pow()

[Iain Buclaw via Digitalmars-d]

On 12 January 2015 at 23:28, Manu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> Awesome. Really looking forward to this! :)
>
> On 13 January 2015 at 03:12, Iain Buclaw via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 2 January 2015 at 14:19, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
>>> On 1 January 2015 at 18:40, H. S. Teoh via Digitalmars-d
>>> <digitalmars-d at puremagic.com> wrote:
>>>> On Fri, Jan 02, 2015 at 02:56:16AM +1000, Manu via Digitalmars-d wrote:
>>>>> Does anyone know how to fix this? Can we please do so? It's been a
>>>>> problem for like 5 years it seems.
>>>>> It's a bit insane that we can't resolve any non-linear functions at
>>>>> compile time.
>>>>
>>>> I've been waiting for this since like, forever. We even have a D code
>>>> implementation of pow() already (thanks to Iain), which *should* have
>>>> been CTFE-able, if it weren't for CTFE limitations that prohibit
>>>> reinterpreting float values in binary, which is required for certain
>>>> basic operations like isInfinite, isNaN, etc..
>>>>
>>>> So it seems that the blocker right now is CTFE, which, unfortunately, is
>>>> not a pretty piece of code, and requires quite a bit of care to get it
>>>> done right.
>>>>
>>>
>>> The fundamental structure is in place in Target. where the paintAsType
>>> implementation encodes/decodes from a char buffer (and supports up to
>>> 512 bytes).  You can add support for painting a double as a ushort[4]
>>> by adding a loop, decodeInteger(e, buffer), decodeInteger(e,
>>> buffer+2), etc...
>>>
>>> The second part (and more crucial) is adding the capability into CTFE.
>>> Shouldn't be much work, but I've yet to get round to it.
>>>
>>> See: https://github.com/D-Programming-Language/dmd/blob/master/src/target.c#L287
>>>
>>>
>>
>> I've started a branch which works on this.  I expect it will take me a
>> week to finish with unittests.
>>

Started with CTFE floor/ceiil.

https://github.com/ibuclaw/dmd/compare/ctfepaint

Iain.