newCTFE Status November 2018

[kinke]

On Sunday, 9 December 2018 at 15:23:30 UTC, Joakim wrote:
> On Sunday, 9 December 2018 at 14:48:31 UTC, H. S. Teoh wrote:
>> Looks like we'll somehow need a way to tell the CTFE engine 
>> what the target arch should be, and when something doesn't 
>> match the host type, it should run a software emulation 
>> instead of using the host's `real`.
>
> Yes, Iain says gdc already uses such multi-precision 
> soft-float, and kinke mentioned earlier in this thread that 
> he'd like to do the same with ldc. The reason I brought this 
> issue up is that Stefan initially mentioned doing something 
> similar for dmd.

My point being that it's not just the CTFE engine that needs to 
support compile-time reals (real_t) of at least target `real` 
precision. FP literals have to be parsed by the front-end, need 
to be printable to string (template instantiations, header 
generation etc.) and stored, and this is currently taken care of 
by the `real_t` type and the dmd.root.ctfloat module.
So ideally, newCTFE would just keep on relying on that 
infrastructure, just like the current interpreter (+ dmd.builtin 
module) does, instead of trying to reinvent the wheel.