newCTFE Status November 2018

[Iain Buclaw]

On Mon, 10 Dec 2018 at 14:00, Stefan Koch via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Monday, 10 December 2018 at 11:04:47 UTC, kinke wrote:
> > 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.
>
> ctfloat depends on the C runtime, and therefore it's
> implementation dependent.
> I'd rather go with an implementation which I have verified myself.
> And where I can give meaningful statements about what it can, and
> can't support.
>
> I'd love to not re-invent the weel; But we don't have a wheel.
>

Then fix the wheel - you've already gone as far as taking one
soft-float implementation, use it for the alias to real_t!

-- 
Iain