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

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.

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.

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

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!

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; } ();

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

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

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

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