www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - newCTFE is getting ported to 2.092

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

just a short message.
Since the tools which I wrote for a better workflow developing on 
dmd.
namely "asttypename.d"
are working again I have decided to port newCTFE which was 
written against
2.074.1 to 2.092
Which should be there after this weekend.

nested switches and re-throwing on exceptions are broken.

Associative Arrays are not implemented yet.
reals are not supported (and are not really on the agenda due to 
portability issues)

That's it.
The rest should work.

Cheers,

Stefan
Jun 05 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 05, 2020 at 08:24:10PM +0000, Stefan Koch via Digitalmars-d wrote:

 Hi Guys,
 
 just a short message.
 Since the tools which I wrote for a better workflow developing on dmd.
 namely "asttypename.d"
 are working again I have decided to port newCTFE which was written
 against 2.074.1 to 2.092
 Which should be there after this weekend.
 
 nested switches and re-throwing on exceptions are broken.
 
 Associative Arrays are not implemented yet.
 reals are not supported (and are not really on the agenda due to
 portability issues)
 
 That's it.
 The rest should work.


[...]

How close are we to newCTFE being mergeable?  Been slobbering over it
since it was first announced way back when, can't wait for it to arrive
already!


T

-- 
They say that "guns don't kill people, people kill people." Well I think the
gun helps. If you just stood there and yelled BANG, I don't think you'd kill
too many people. -- Eddie Izzard, Dressed to Kill
Jun 05 2020
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 5 June 2020 at 21:09:37 UTC, H. S. Teoh wrote:

 On Fri, Jun 05, 2020 at 08:24:10PM +0000, Stefan Koch via 
 Digitalmars-d wrote:

 newCTFE port to 2.092


 How close are we to newCTFE being mergeable?  Been slobbering 
 over it since it was first announced way back when, can't wait 
 for it to arrive already!


Trust me once it's merged you'll be disappointed because the 
problem were templates all along (hence my work on type functions)

As far as I can tell it's quite far from being merged.
It's a lot of code. It's rather clean but there are 14_000 lines 
of it.
It has to emulate most of the runtime library, and a few platform 
facilities like exception handling after all.

It's written on top of a code-generation API and it includes 
multiple backends for it. (most of them barely functional by now)

The newCTFE-ABI has to be documented.
As well as the codegen-API itself.

Don't hold your breath :)
But it least you can play with it soon, if you build your own dmd.
Jun 05 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/5/20 5:46 PM, Stefan Koch wrote:

 On Friday, 5 June 2020 at 21:09:37 UTC, H. S. Teoh wrote:

 On Fri, Jun 05, 2020 at 08:24:10PM +0000, Stefan Koch via 
 Digitalmars-d wrote:

 newCTFE port to 2.092


 How close are we to newCTFE being mergeable?  Been slobbering over it 
 since it was first announced way back when, can't wait for it to 
 arrive already!


 Trust me once it's merged you'll be disappointed because the problem 
 were templates all along (hence my work on type functions)


But without newCTFE the cure is worse than the disease.

I think it's going to allow more possibilities of replacing templates 
with CTFE handling.

I have some ideas to do type functions without specialized compiler 
support. But I think it would be painful without a better CTFE engine.

-Steve
Jun 05 2020
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 5 June 2020 at 21:52:05 UTC, Steven Schveighoffer 
wrote:

 On 6/5/20 5:46 PM, Stefan Koch wrote:

 On Friday, 5 June 2020 at 21:09:37 UTC, H. S. Teoh wrote:

 On Fri, Jun 05, 2020 at 08:24:10PM +0000, Stefan Koch via 
 Digitalmars-d wrote:

 newCTFE port to 2.092


 How close are we to newCTFE being mergeable?  Been slobbering 
 over it since it was first announced way back when, can't 
 wait for it to arrive already!


 Trust me once it's merged you'll be disappointed because the 
 problem were templates all along (hence my work on type 
 functions)


 But without newCTFE the cure is worse than the disease.

 I think it's going to allow more possibilities of replacing 
 templates with CTFE handling.

 I have some ideas to do type functions without specialized 
 compiler support. But I think it would be painful without a 
 better CTFE engine.

 -Steve


As long as you code sensibly.
I.E. not relay on the GC for everything or on "~=" to be fast.
Or use library facilities like Appender. (Which are fine for 
runtime but too expensive to be interpreted)

CTFE is really not an issue at all.

But yes, I would like to have newCTFE as a substrate.
And I do want this shadow to be gone :)
Jun 05 2020
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 5 June 2020 at 21:52:05 UTC, Steven Schveighoffer 
wrote:

 On 6/5/20 5:46 PM, Stefan Koch wrote:

 On Friday, 5 June 2020 at 21:09:37 UTC, H. S. Teoh wrote:

 On Fri, Jun 05, 2020 at 08:24:10PM +0000, Stefan Koch via 
 Digitalmars-d wrote:

 newCTFE port to 2.092


 How close are we to newCTFE being mergeable?  Been slobbering 
 over it since it was first announced way back when, can't 
 wait for it to arrive already!


 Trust me once it's merged you'll be disappointed because the 
 problem were templates all along (hence my work on type 
 functions)


 But without newCTFE the cure is worse than the disease.

 I think it's going to allow more possibilities of replacing 
 templates with CTFE handling.

 I have some ideas to do type functions without specialized 
 compiler support. But I think it would be painful without a 
 better CTFE engine.

 -Steve


I have a meaningless performance number for you.

for this code:
uint f(uint x)
{
     uint acc;
     foreach(i; 0 .. x) acc += x;
     return acc;
}

pragma(msg, f(ushort.max * 2));

oldCtfeTime: 150 milliseconds.
newCtfeTime:  12 milliseconds.

around a 12x speedup for simple stuff like this.
For more complicated cases the numbers are going to be more 
varied.
Jun 06 2020
parent Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 6 June 2020 at 22:43:03 UTC, Stefan Koch wrote:

 for this code:
 uint f(uint x)
 {
     uint acc;
     foreach(i; 0 .. x) acc += x;
     return acc;
 }

 pragma(msg, f(ushort.max * 2));

 oldCtfeTime: 150 milliseconds.
 newCtfeTime:  12 milliseconds.

 around a 12x speedup for simple stuff like this.
 For more complicated cases the numbers are going to be more 
 varied.


Hi Stefan,

Like many others here, I can't wait to use newCTFE :)
Jun 07 2020
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 5 June 2020 at 21:09:37 UTC, H. S. Teoh wrote:

 On Fri, Jun 05, 2020 at 08:24:10PM +0000, Stefan Koch via 
 Digitalmars-d wrote:

 Hi Guys,
 
 just a short message.
 Since the tools which I wrote for a better workflow developing 
 on dmd.
 namely "asttypename.d"
 are working again I have decided to port newCTFE which was 
 written
 against 2.074.1 to 2.092
 Which should be there after this weekend.
 
 nested switches and re-throwing on exceptions are broken.
 
 Associative Arrays are not implemented yet.
 reals are not supported (and are not really on the agenda due 
 to
 portability issues)
 
 That's it.
 The rest should work.


 [...]

 How close are we to newCTFE being mergeable?  Been slobbering 
 over it since it was first announced way back when, can't wait 
 for it to arrive already!


 T


Done. Those were 5 hours I'll never get back.
https://github.com/dlang/dmd/compare/master...UplinkCoder:newCTFE_2092?expand=1
Jun 05 2020
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 5 June 2020 at 22:31:23 UTC, Stefan Koch wrote:

 Done. Those were 5 hours I'll never get back.
 https://github.com/dlang/dmd/compare/master...UplinkCoder:newCTFE_2092?expand=1


Note that the branch newCTFE_2092 on 
https://github.com/UplinkCoder/dmd
Still has bugs and therefore enables all debug output by default.

To get rid of it, go into src/dmd/ctfe/ctfe_bc.d and comment out 
"debug = ctfe;"
Also go into src/dmd/ctfe/bc.d and comment out "debug = bc;"
If you still get unexpected output after that, it's likely that I 
forgot to comment out one of my "DEBUGLINEs" before pushing.
Go into src/dmd/ctfe/ctfe_bc.d and search for parts of the 
unexpected output which seems static.
You should see something like:

writeln("Unexpected ***** :", ....) // DEBUGLINE

Just comment that line.

I am aware of many bugs that are there.
But none of them _should_ cause newCTFE to miscompile code.

So please open an issue on my fork of dmd, If you see something 
evaluating to the wrong result with newCTFE.

Such a behavior is absolutely unacceptable for a compiler and I 
need to know as soon as possible!
Jun 06 2020
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Friday, 5 June 2020 at 20:24:10 UTC, Stefan Koch wrote:

 Hi Guys,

 just a short message.
 Since the tools which I wrote for a better workflow developing 
 on dmd.
 namely "asttypename.d"
 are working again I have decided to port newCTFE which was 
 written against
 2.074.1 to 2.092
 Which should be there after this weekend.

 nested switches and re-throwing on exceptions are broken.

 Associative Arrays are not implemented yet.
 reals are not supported (and are not really on the agenda due 
 to portability issues)

 That's it.
 The rest should work.

 Cheers,

 Stefan


I have build your branch and I don't know where to start.

1. there are issues with the new check for printf format.  
(commented them to go further)
2. "dparse" doedsn't build
3. "iz" doesn't build
4. "styx" doesn't build
5. segfault when building "dmd-fe" using the sdl description
6. overhaul too much stuff are logged (esp. the bailouts)
7. I've managed to get simple packages to get compiled ("x11", 
"imageformats")

I'll eventually just send you scripts for what does not work.
Or maybe tomorrow morning I'll be on IRC I think... as I prefer 
live chats for these kind of things.
Jun 07 2020
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 7 June 2020 at 13:19:59 UTC, Basile B. wrote:

 On Friday, 5 June 2020 at 20:24:10 UTC, Stefan Koch wrote:

 I have build your branch and I don't know where to start.

 1. there are issues with the new check for printf format.  
 (commented them to go further)
 2. "dparse" doedsn't build
 3. "iz" doesn't build
 4. "styx" doesn't build
 5. segfault when building "dmd-fe" using the sdl description
 6. overhaul too much stuff are logged (esp. the bailouts)
 7. I've managed to get simple packages to get compiled ("x11", 
 "imageformats")

 I'll eventually just send you scripts for what does not work.
 Or maybe tomorrow morning I'll be on IRC I think... as I prefer 
 live chats for these kind of things.


Ah yes.
Default constructed classes get zero initialized rather than 
being set to the appropriate values.
There are bugs in exception handling as well.
Anything which depends on phobos will likely not work.

My next step is to clean duplicated sections of the code.
And unify the way default initialization off aggregates is done.
Jun 07 2020
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 7 June 2020 at 13:38:02 UTC, Stefan Koch wrote:

 On Sunday, 7 June 2020 at 13:19:59 UTC, Basile B. wrote:

 On Friday, 5 June 2020 at 20:24:10 UTC, Stefan Koch wrote:

 I have build your branch and I don't know where to start.

 1. there are issues with the new check for printf format.  
 (commented them to go further)
 2. "dparse" doedsn't build
 3. "iz" doesn't build
 4. "styx" doesn't build
 5. segfault when building "dmd-fe" using the sdl description
 6. overhaul too much stuff are logged (esp. the bailouts)
 7. I've managed to get simple packages to get compiled ("x11", 
 "imageformats")

 I'll eventually just send you scripts for what does not work.
 Or maybe tomorrow morning I'll be on IRC I think... as I 
 prefer live chats for these kind of things.


 Ah yes.
 Default constructed classes get zero initialized rather than 
 being set to the appropriate values.


Not a problem for what I tried.


 There are bugs in exception handling as well.


Not a problem for what I tried.


 Anything which depends on phobos will likely not work.


The problems are then certainly caused by this then.
(Note that I just remembered that I forgot to checkout druntime 
and phobos to v2.092.0)
Jun 07 2020
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 7 June 2020 at 13:43:45 UTC, Basile B. wrote:

 Ah yes.
 Default constructed classes get zero initialized rather than 
 being set to the appropriate values.


 Not a problem for what I tried.


 There are bugs in exception handling as well.


 Not a problem for what I tried.


 Anything which depends on phobos will likely not work.


 The problems are then certainly caused by this then.
 (Note that I just remembered that I forgot to checkout druntime 
 and phobos to v2.092.0)


That's because phobos uses a lot classes end exceptions.
Most likely it hits some of the unsupported cases.
Jun 07 2020