Thread overview | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 05, 2020 newCTFE is getting ported to 2.092 | ||||
---|---|---|---|---|
| ||||
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 |
June 05, 2020 Re: newCTFE is getting ported to 2.092 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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 |
June 05, 2020 Re: newCTFE is getting ported to 2.092 | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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.
|
June 05, 2020 Re: newCTFE is getting ported to 2.092 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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
|
June 05, 2020 Re: newCTFE is getting ported to 2.092 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 :)
|
June 05, 2020 Re: newCTFE is getting ported to 2.092 | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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 |
June 06, 2020 Re: newCTFE is getting ported to 2.092 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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! |
June 06, 2020 Re: newCTFE is getting ported to 2.092 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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.
|
June 07, 2020 Re: newCTFE is getting ported to 2.092 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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 :)
|
June 07, 2020 Re: newCTFE is getting ported to 2.092 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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.
|
Copyright © 1999-2021 by the D Language Foundation