www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - newCTFE Status November 2018

reply Stefan Koch <uplink.coder googlemail.com> writes:
Hi All,

I have short but good news, non-default class-constructors work 
now.
(this was tricky because of my unorthodox vtbl layout).

And another exciting news item, newCTFE is going to support 
cross-platform floating-point as soon as I got around to 
re-implementing, the qemu fork of softfloat-2.


That'll result in a compile-time testable floating point 
implementation ;) Pretty cool, huh.

I'll give an update as soon as the compiler tests pass again.

newCTFE is currently developed against 2.074.1 on the 
newCTFE_reboot_20741 branch.

Cheers,

Stefan
Dec 07 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 08, 2018 at 12:32:58AM +0000, Stefan Koch via Digitalmars-d wrote:

 Hi All,
 
 I have short but good news, non-default class-constructors work now.
 (this was tricky because of my unorthodox vtbl layout).
 
 And another exciting news item, newCTFE is going to support
 cross-platform floating-point as soon as I got around to
 re-implementing, the qemu fork of softfloat-2.
 
 
 That'll result in a compile-time testable floating point
 implementation ;) Pretty cool, huh.
 
 I'll give an update as soon as the compiler tests pass again.
 
 newCTFE is currently developed against 2.074.1 on the
 newCTFE_reboot_20741 branch.


[...]

Very happy to see progress on newCTFE.  For a while I feared whether it
was abandoned...  Still can't wait for it to land in master, even if
that's years away.


T

-- 
Being able to learn is a great learning; being able to unlearn is a greater
learning.
Dec 07 2018
prev sibling next sibling parent sarn <sarn theartofmachinery.com> writes:
On Saturday, 8 December 2018 at 00:32:58 UTC, Stefan Koch wrote:

 And another exciting news item, newCTFE is going to support 
 cross-platform floating-point as soon as I got around to 
 re-implementing, the qemu fork of softfloat-2.


 That'll result in a compile-time testable floating point 
 implementation ;) Pretty cool, huh.


Nice :) Glad to hear you have a solution.
Dec 07 2018
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 8 December 2018 at 00:32:58 UTC, Stefan Koch wrote:

 Hi All,

 I have short but good news, non-default class-constructors work 
 now.
 (this was tricky because of my unorthodox vtbl layout).

 And another exciting news item, newCTFE is going to support 
 cross-platform floating-point as soon as I got around to 
 re-implementing, the qemu fork of softfloat-2.


What do you mean by "cross-platform floating-point," using the 
same implementation everywhere without calling _any_ libc/arch 
intrinsics?


 That'll result in a compile-time testable floating point 
 implementation ;) Pretty cool, huh.


How does that differ from the current implementation?

Btw, do you know some way to get the current compile-time real's 
precision in D code? It would be useful to avoid static asserts 
from overflowing when the runtime real's precision exceeds the 
compile-time real's precision, which doesn't happen with dmd but 
can with ldc:

https://github.com/dlang/phobos/pull/6790#discussion_r238633160
Dec 07 2018
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 8 December 2018 at 04:06:11 UTC, Joakim wrote:

 On Saturday, 8 December 2018 at 00:32:58 UTC, Stefan Koch wrote:

 Hi All,

 I have short but good news, non-default class-constructors 
 work now.
 (this was tricky because of my unorthodox vtbl layout).

 And another exciting news item, newCTFE is going to support 
 cross-platform floating-point as soon as I got around to 
 re-implementing, the qemu fork of softfloat-2.


 What do you mean by "cross-platform floating-point," using the 
 same implementation everywhere without calling _any_ libc/arch 
 intrinsics?


Yes that is what I mean. It has always been the plan, but until 
recently,
I saw no way to actually realize it.


 That'll result in a compile-time testable floating point 
 implementation ;) Pretty cool, huh.


 How does that differ from the current implementation?


Currently it relies on the host fpu.  or rather the hosts float 
implementation.
Which I intent to replace with a pure software solution, which 
operates independently
from the host float math.
And can therefore be made to behave like the targets (more or 
less, it's emulation).


 Btw, do you know some way to get the current compile-time 
 real's precision in D code?


this _may_ work:
static immutable ctRealPerc = () { return real.mant_dig; } ();
Dec 07 2018
next sibling parent reply kinke <noone nowhere.com> writes:
On Saturday, 8 December 2018 at 07:08:54 UTC, Stefan Koch wrote:

 On Saturday, 8 December 2018 at 04:06:11 UTC, Joakim wrote:

 Btw, do you know some way to get the current compile-time 
 real's precision in D code?


 this _may_ work:
 static immutable ctRealPerc = () { return real.mant_dig; } ();


Nope, these FP type properties represent the target type's. 
There's just no way of knowing the compile-time precision at the 
moment, at least for LDC (DMD is x86 only and currently always 
uses a x87 `real_t`). For LDC, it's the host `real` precision, 
except for MSVC hosts, where it uses x87 (Rainer's custom 
implementation in dmd.root.longdouble).
Dec 08 2018
parent reply Nathan S. <no.public.email example.com> writes:
On Saturday, 8 December 2018 at 15:56:46 UTC, kinke wrote:

 On Saturday, 8 December 2018 at 07:08:54 UTC, Stefan Koch wrote:

 On Saturday, 8 December 2018 at 04:06:11 UTC, Joakim wrote:

 Btw, do you know some way to get the current compile-time 
 real's precision in D code?


 this _may_ work:
 static immutable ctRealPerc = () { return real.mant_dig; } ();


 Nope, these FP type properties represent the target type's. 
 There's just no way of knowing the compile-time precision at 
 the moment, at least for LDC (DMD is x86 only and currently 
 always uses a x87 `real_t`). For LDC, it's the host `real` 
 precision, except for MSVC hosts, where it uses x87 (Rainer's 
 custom implementation in dmd.root.longdouble).


This infallibly determines the precision used for calculations 
involving `real` in CTFE:

----
enum ctfeRealExponentBits =
() {
     real f = 2;
     foreach (i; 1 .. 2000)
     {
         real g = f * f;
         if (g == f)
             return i;
         f = g;
     }
     assert(0, "algorithm failure");
}();

enum ctfeMantissaBits =
() {
     real a = 1;
     real b = 0.5;
     int bits = 0;
     while (a + b != a)
     {
         bits = bits + 1;
         b = b / 2;
     }
     // Result matches what would be reported by mant_dig
     // (1 greater than the actual number of mantissa bits
     // except for 80-bit extended precision).
     return bits + 1;
}();
----
Dec 09 2018
next sibling parent Joakim <dlang joakim.fea.st> writes:
On Sunday, 9 December 2018 at 16:32:49 UTC, Nathan S. wrote:

 On Saturday, 8 December 2018 at 15:56:46 UTC, kinke wrote:

 [...]


 This infallibly determines the precision used for calculations 
 involving `real` in CTFE:

 ----
 enum ctfeRealExponentBits =
 () {
     real f = 2;
     foreach (i; 1 .. 2000)
     {
         real g = f * f;
         if (g == f)
             return i;
         f = g;
     }
     assert(0, "algorithm failure");
 }();

 enum ctfeMantissaBits =
 () {
     real a = 1;
     real b = 0.5;
     int bits = 0;
     while (a + b != a)
     {
         bits = bits + 1;
         b = b / 2;
     }
     // Result matches what would be reported by mant_dig
     // (1 greater than the actual number of mantissa bits
     // except for 80-bit extended precision).
     return bits + 1;
 }();
 ----


Heh, yes, checking the precision manually with a compile-time 
while loop works: he meant there's no "FP type properties" that 
will easily give it to you.
Dec 09 2018
prev sibling parent kinke <noone nowhere.com> writes:
On Sunday, 9 December 2018 at 16:32:49 UTC, Nathan S. wrote:

 This infallibly determines the precision used for calculations 
 involving `real` in CTFE:


Compiled code shouldn't have to know, it just needs to be 
sufficiently high. - I'm not so sure about 'infallibly', there's 
a theoretical chance for the super-duper IBM doubledouble format 
being used too.
Dec 09 2018
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 8 December 2018 at 07:08:54 UTC, Stefan Koch wrote:

 On Saturday, 8 December 2018 at 04:06:11 UTC, Joakim wrote:

 On Saturday, 8 December 2018 at 00:32:58 UTC, Stefan Koch 
 wrote:

 Hi All,

 I have short but good news, non-default class-constructors 
 work now.
 (this was tricky because of my unorthodox vtbl layout).

 And another exciting news item, newCTFE is going to support 
 cross-platform floating-point as soon as I got around to 
 re-implementing, the qemu fork of softfloat-2.


 What do you mean by "cross-platform floating-point," using the 
 same implementation everywhere without calling _any_ libc/arch 
 intrinsics?


 Yes that is what I mean. It has always been the plan, but until 
 recently,
 I saw no way to actually realize it.


 That'll result in a compile-time testable floating point 
 implementation ;) Pretty cool, huh.


 How does that differ from the current implementation?


 Currently it relies on the host fpu.  or rather the hosts float 
 implementation.
 Which I intent to replace with a pure software solution, which 
 operates independently
 from the host float math.
 And can therefore be made to behave like the targets (more or 
 less, it's emulation).


OK, got that from the first question, but I was referring to what 
you called "compile-time testable?" I didn't understand what 
using a fully soft-float implementation added in that regard.


 Btw, do you know some way to get the current compile-time 
 real's precision in D code?


 this _may_ work:
 static immutable ctRealPerc = () { return real.mant_dig; } ();


No, as kinke says, it doesn't work with ldc.

On Saturday, 8 December 2018 at 15:42:43 UTC, H. S. Teoh wrote:

 On Sat, Dec 08, 2018 at 04:06:11AM +0000, Joakim via 
 Digitalmars-d wrote: [...]

 Btw, do you know some way to get the current compile-time 
 real's precision in D code? It would be useful to avoid static 
 asserts from overflowing when the runtime real's precision 
 exceeds the compile-time real's precision, which doesn't 
 happen with dmd but can with ldc:
 
 https://github.com/dlang/phobos/pull/6790#discussion_r238633160


 Doesn't real.dig give the (approximate) precision of real? Or 
 is that
 hard-coded in the frontend?


Just so we're clear, the issue is what the precision of reals are 
when running CTFE code to initialize a constant, as opposed to 
the precision of the real at runtime. For dmd, this doesn't 
really matter since it only supports x86/x64 chips, but ldc uses 
the host's real at compile-time, which can obviously vary from 
the target. That's why I mentioned to you in another thread that 
some stdlib math tests assert when cross-compiling from x64 to 
Android/AArch64, because of that mismatch in host->target 
precision for reals.

real.dig has the same problem as real.mant_dig above, it only 
gives the target's precision. Compiling this snippet with ldc, 
`void main() { pragma(msg, "precision is ", real.dig);}`, I get 
18 when compiling natively on linux/x64, but 33 when 
cross-compiling to Android/AArch64, ie it always gives the target 
real's precision.
Dec 08 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 08, 2018 at 05:19:59PM +0000, Joakim via Digitalmars-d wrote:
[...]

 On Saturday, 8 December 2018 at 15:42:43 UTC, H. S. Teoh wrote:

 On Sat, Dec 08, 2018 at 04:06:11AM +0000, Joakim via Digitalmars-d
 wrote: [...]

 Btw, do you know some way to get the current compile-time real's
 precision in D code? It would be useful to avoid static asserts
 from overflowing when the runtime real's precision exceeds the
 compile-time real's precision, which doesn't happen with dmd but
 can with ldc:
 
 https://github.com/dlang/phobos/pull/6790#discussion_r238633160


 
 Doesn't real.dig give the (approximate) precision of real? Or is
 that hard-coded in the frontend?


 
 Just so we're clear, the issue is what the precision of reals are when
 running CTFE code to initialize a constant, as opposed to the
 precision of the real at runtime. For dmd, this doesn't really matter
 since it only supports x86/x64 chips, but ldc uses the host's real at
 compile-time, which can obviously vary from the target. That's why I
 mentioned to you in another thread that some stdlib math tests assert
 when cross-compiling from x64 to Android/AArch64, because of that
 mismatch in host->target precision for reals.


Ahhh, so *that's* the reason for the failure.

But I'd think that's more than just a floating-point issue; wouldn't
CTFE in general be problematic if there's a mismatch between host
built-in types vs. target built-in types when cross-compiling? I suppose
D's fixed-sized types help a lot in this regard (imagine the mess if
`int` varies in size across host/target archs -- the kind of mess C/C++
have to deal with). But `real` is a fly in the ointment.

I'd imagine difference in endianness would be another cause of problems
in cross-compilation, though for the most part typical D code wouldn't
be affected by this at least as far as CTFE is concerned (since casting
/ reinterpretation of unions is not currently allowed).



 real.dig has the same problem as real.mant_dig above, it only gives
 the target's precision. Compiling this snippet with ldc, `void main()
 { pragma(msg, "precision is ", real.dig);}`, I get 18 when compiling
 natively on linux/x64, but 33 when cross-compiling to Android/AArch64,
 ie it always gives the target real's precision.


Which it should, since any code that depends on real.dig is ostensibly
expecting the target arch's precision, not the host's which may change
depending on which host you use to compile it.

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


T

-- 
Claiming that your operating system is the best in the world because more
people use it is like saying McDonalds makes the best food in the world. --
Carl B. Constantine
Dec 09 2018
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 9 December 2018 at 14:48:31 UTC, H. S. Teoh wrote:

 On Sat, Dec 08, 2018 at 05:19:59PM +0000, Joakim via 
 Digitalmars-d wrote: [...]

 [...]


 Ahhh, so *that's* the reason for the failure.

 [...]


size_t theoretically also but here practically there are only two 
sizes to take care of 4 and 8.


 [...]
Dec 09 2018
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Dec 09, 2018 at 03:16:16PM +0000, Patrick Schluter via Digitalmars-d
wrote:

 On Sunday, 9 December 2018 at 14:48:31 UTC, H. S. Teoh wrote:

 On Sat, Dec 08, 2018 at 05:19:59PM +0000, Joakim via Digitalmars-d
 wrote: [...]

 [...]


 
 Ahhh, so *that's* the reason for the failure.
 
 [...]


 
 size_t theoretically also but here practically there are only two
 sizes to take care of 4 and 8.


[...]

Since size_t is an alias to a concrete fixed-sized int type, I don't
think it would actually be a problem. The alias AFAIK depends only on
the version identifiers, which are always set for the target arch, so
size_t will always alias to the correct target type even when run in
CTFE on a host with a different size_t.


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and
now it's killing me! -- Schoolboy
Dec 09 2018
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 9 December 2018 at 14:48:31 UTC, H. S. Teoh wrote:

 On Sat, Dec 08, 2018 at 05:19:59PM +0000, Joakim via 
 Digitalmars-d wrote: [...]

 On Saturday, 8 December 2018 at 15:42:43 UTC, H. S. Teoh wrote:

 On Sat, Dec 08, 2018 at 04:06:11AM +0000, Joakim via 
 Digitalmars-d wrote: [...]

 Btw, do you know some way to get the current compile-time 
 real's precision in D code? It would be useful to avoid 
 static asserts from overflowing when the runtime real's 
 precision exceeds the compile-time real's precision, which 
 doesn't happen with dmd but can with ldc:
 
 https://github.com/dlang/phobos/pull/6790#discussion_r238633160


 
 Doesn't real.dig give the (approximate) precision of real? 
 Or is
 that hard-coded in the frontend?


 
 Just so we're clear, the issue is what the precision of reals 
 are when running CTFE code to initialize a constant, as 
 opposed to the precision of the real at runtime. For dmd, this 
 doesn't really matter since it only supports x86/x64 chips, 
 but ldc uses the host's real at compile-time, which can 
 obviously vary from the target. That's why I mentioned to you 
 in another thread that some stdlib math tests assert when 
 cross-compiling from x64 to Android/AArch64, because of that 
 mismatch in host->target precision for reals.


 Ahhh, so *that's* the reason for the failure.


Specifically, real.max overflows when it tries to evaluate that 
expression, as it tries to stick the 128-bit real.max in the 
80-bit x87 real and overflows to Inf, tripping the static assert.


 But I'd think that's more than just a floating-point issue; 
 wouldn't CTFE in general be problematic if there's a mismatch 
 between host built-in types vs. target built-in types when 
 cross-compiling? I suppose D's fixed-sized types help a lot in 
 this regard (imagine the mess if `int` varies in size across 
 host/target archs -- the kind of mess C/C++ have to deal with). 
 But `real` is a fly in the ointment.


Yes, this is called out in the spec:

"Functions executed via CTFE can give different results from run 
time in the following scenarios:

- floating point computations may be done at a higher precision 
than run time"
https://dlang.org/spec/function.html#interpretation

Of course, that was likely written before we started supporting 
64-bit and 128-bit reals, so it was probably assumed that 80-bit 
x87 reals would always be used at compile-time and at worst would 
be _more_ precise. That's not the case with ldc anymore, since 
ldc running on an ARM host will do CTFE at 64-bit precision and 
80-bit on an x64 host isn't enough when cross-compiling to 
128-bit AArch64 reals.


 I'd imagine difference in endianness would be another cause of 
 problems in cross-compilation, though for the most part typical 
 D code wouldn't be affected by this at least as far as CTFE is 
 concerned (since casting / reinterpretation of unions is not 
 currently allowed).


Unsure.


 real.dig has the same problem as real.mant_dig above, it only 
 gives the target's precision. Compiling this snippet with ldc, 
 `void main() { pragma(msg, "precision is ", real.dig);}`, I 
 get 18 when compiling natively on linux/x64, but 33 when 
 cross-compiling to Android/AArch64, ie it always gives the 
 target real's precision.


 Which it should, since any code that depends on real.dig is 
 ostensibly expecting the target arch's precision, not the 
 host's which may change depending on which host you use to 
 compile it.


I tried various other ways before, like checking an enum's 
precision or inside a __ctfe block, but they all give the 
target's precision, as kinke says, even though they're running at 
compile-time.


 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.
Dec 09 2018
parent reply kinke <noone nowhere.com> writes:
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.
Dec 10 2018
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Dec 10 2018
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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
Dec 10 2018
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
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.
Dec 10 2018
prev sibling parent reply kinke <noone nowhere.com> writes:
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. :)
Dec 10 2018
parent Joakim <dlang joakim.fea.st> writes:
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.
Dec 10 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 08, 2018 at 04:06:11AM +0000, Joakim via Digitalmars-d wrote:
[...]

 Btw, do you know some way to get the current compile-time real's
 precision in D code? It would be useful to avoid static asserts from
 overflowing when the runtime real's precision exceeds the compile-time
 real's precision, which doesn't happen with dmd but can with ldc:
 
 https://github.com/dlang/phobos/pull/6790#discussion_r238633160


Doesn't real.dig give the (approximate) precision of real? Or is that
hard-coded in the frontend?


T

-- 
Genius may have its limitations, but stupidity is not thus handicapped. --
Elbert Hubbard
Dec 08 2018
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 8 December 2018 at 00:32:58 UTC, Stefan Koch wrote:

 Hi All,

 I have short but good news, non-default class-constructors work 
 now.
 (this was tricky because of my unorthodox vtbl layout).

 And another exciting news item, newCTFE is going to support 
 cross-platform floating-point as soon as I got around to 
 re-implementing, the qemu fork of softfloat-2.


 That'll result in a compile-time testable floating point 
 implementation ;) Pretty cool, huh.

 I'll give an update as soon as the compiler tests pass again.

 newCTFE is currently developed against 2.074.1 on the 
 newCTFE_reboot_20741 branch.

 Cheers,

 Stefan


Its December, but awesome nonetheless!
Dec 07 2018
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 08/12/2018 1:32 PM, Stefan Koch wrote:

 And another exciting news item, newCTFE is going to support 
 cross-platform floating-point as soon as I got around to 
 re-implementing, the qemu fork of softfloat-2.


D..Does that mean that root/ctfloat.d is being replaced?

https://issues.dlang.org/show_bug.cgi?id=18810
Dec 08 2018
parent kinke <noone nowhere.com> writes:
On Saturday, 8 December 2018 at 10:04:19 UTC, rikki cattermole 
wrote:

 On 08/12/2018 1:32 PM, Stefan Koch wrote:

 And another exciting news item, newCTFE is going to support 
 cross-platform floating-point as soon as I got around to 
 re-implementing, the qemu fork of softfloat-2.


 D..Does that mean that root/ctfloat.d is being replaced?

 https://issues.dlang.org/show_bug.cgi?id=18810


That would be a bad idea. As I said somewhere a year ago or so, 
newCTFE should probably just rely on `real_t` providing the 
required operations (custom operators etc.). The host needs to 
store compile-time FP values in a format suited for the target, 
and that's where a `real_t` (for the full front-end, not just 
CTFE) comes in.

GDC already uses a software `real_t` AFAIK; LDC will eventually 
too, probably based on https://www.mpfr.org/.
Dec 08 2018