On Mon, 10 Dec 2018 at 14:00, Stefan Koch via Digitalmars-d <digitalmars-d@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

On Monday, 10 December 2018 at 13:20:32 UTC, Iain Buclaw wrote:
> On Mon, 10 Dec 2018 at 14:00, Stefan Koch via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> 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!

Yes that is what I am going to do as soon as it works for newCTFE.

The library will take a while to reverse-engineer and rewrite in D though.
It is under the BSD licence, and I don't know if that'll be accepted for ldc/gdc or even dmd.

When I have gone though that of course it should be used in the whole frontend.

But as I said, it'll take a while.

On Monday, 10 December 2018 at 13:20:32 UTC, Iain Buclaw wrote:
> On Mon, 10 Dec 2018 at 14:00, Stefan Koch via Digitalmars-d
>> ctfloat depends on the C runtime, and therefore it's
>> implementation dependent.

For DMD, yes; GDC obviously doesn't use the C runtime, and LDC does partially (which should be fixed at some point).

>> 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.

Again, that's the case for DMD. Considering DMD only supports x86 targets with x87 reals and isn't really usable/used for cross-compilation, one could argue that using a software real_t for DMD is overkill, reducing CTFE speed for host-C-runtime-independent results (which might lead to new runtime/compile-time divergences).

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

My impression was that Stefan was about to port some implementation, that's why I interfered, in the hopes of accelerating newCTFE deployment. ;) - So if it's already implemented and fully in D, then perfect, I'll be more than happy to incorporate it as LDC's real_t. :)

On Monday, 10 December 2018 at 14:36:36 UTC, kinke wrote:
> On Monday, 10 December 2018 at 13:20:32 UTC, Iain Buclaw wrote:
>> On Mon, 10 Dec 2018 at 14:00, Stefan Koch via Digitalmars-d
>>> ctfloat depends on the C runtime, and therefore it's
>>> implementation dependent.
>
> For DMD, yes; GDC obviously doesn't use the C runtime, and LDC does partially (which should be fixed at some point).
>
>>> 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.
>
> Again, that's the case for DMD. Considering DMD only supports x86 targets with x87 reals and isn't really usable/used for cross-compilation, one could argue that using a software real_t for DMD is overkill, reducing CTFE speed for host-C-runtime-independent results (which might lead to new runtime/compile-time divergences).
>
>> Then fix the wheel - you've already gone as far as taking one soft-float implementation, use it for the alias to real_t!
>
> My impression was that Stefan was about to port some implementation, that's why I interfered, in the hopes of accelerating newCTFE deployment. ;) - So if it's already implemented and fully in D, then perfect, I'll be more than happy to incorporate it as LDC's real_t. :)

I think they're implying he already got newCTFE working with a BSD-licensed softfloat-2 written in C, and he plans to rewrite its functionality in D and Boost-license it.

Might be a good idea for ldc to use that C softfloat-2 library too, since ldc's BSD-licensed anyway, as opposed to the LGPL-licensed MPFR.