https://issues.dlang.org/show_bug.cgi?id=16474
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #11 from [email protected] --- (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. --
