| |
 | Posted by kinke@gmx.net |  Permalink Reply |
|
kinke@gmx.net 
| https://issues.dlang.org/show_bug.cgi?id=16474
kinke@gmx.net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kinke@gmx.net
--- Comment #11 from kinke@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.
--
|
