[Issue 16474] CTFE pow

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16474

kinke at gmx.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke at gmx.net

--- Comment #11 from kinke at gmx.net ---
(In reply to uplink.coder from comment #10)
> (In reply to kinke from comment #9)
> > 
> > So how does newCTFE interact with CTFloat at the moment? This is an
> > important piece for cross-compilers. And is there an estimate for when
> > newCTFE will land?
> 
> It does currently not use CTFloat at all.
> It only implements add, sub, mul and div and mod for floats/doubles.
> As well as float <=> double <=> long/int casts.

[Sorry about hijacking this issue.] Okay, but as guys clearly expect most of
the math functionality to be available at CTFE too, newCTFE will eventually
have to feature a similar system of CTFE builtins (ddmd.builtin). Currently, it
plugs into function calls and tries to match the callee name in a map of
mangled name => CTFE implementation. The builtins are required for functions
whose source code isn't available for CTFE, such as compiler intrinsics, inline
assembly and C library functions.

So newCTFE discriminates between 32-bit float and 64-bit double but lacks
support for real_t, as opposed to the current interpreter, which uses real_t
exclusively (in RealExp). So the current floating-point builtin implementations
expect host/compiler-specific real_t values, but extending those to allow for
all 3 (float, double, real_t) should be straightforward.

newCTFE should at some point support real_t and use it to represent target
reals at compile-time. It's most likely the host real type, but it may also be
a software implementation as custom type with overloaded binops (GDC afaik,
possibly LDC at some point), with a specific size and alignment, and more
advanced functionality provided by helper struct CTFloat.

--