Jump to page: 1 215  
Page
Thread overview
CTFE Status 2
Feb 17
Lurker
Feb 17
Temtaime
Feb 17
jmh530
Feb 18
Satoshi
Feb 28
Nordlöw
Mar 10
Nordlöw
Mar 13
Kagamin
Mar 11
Nordlöw
Mar 13
Joakim
Mar 13
Meta
Mar 15
Nordlöw
Mar 15
Nordlöw
Mar 17
Kagamin
Apr 01
Inquie
Apr 08
crimaniak
Apr 08
crimaniak
Apr 09
crimaniak
Apr 28
Nordlöw
Apr 28
Nordlöw
May 03
Kagamin
May 03
Nordlöw
5 days ago
Stefan Koch
2 days ago
Stefan Koch
3 days ago
Stefan Koch
3 days ago
Stefan Koch
February 16
Hi Guys, due to the old CTFE status thread getting to page 30, I am now starting a new one.

First let me summerize which features are currently working:
In order of date, the latest features come first.

- fixed continue and break for DoWhileStatements
- non-toplevel Function Pointers as arguments
- basic function pointers
--- phobos, druntime & dmd unit-tests pass ----
- Method Calls (now range foreach will work)
- 1-level Pointers
- recursive function calls
- fixed continue and break for ForStatements (includes foreach which is lowered)
- basic Function Calls
- static immutable globals
- fixed continue & break for WhileStatemens
- 1d array literals
- ternary expressions ? :
- struct literals.
- basic struct support.
- Slice and Array boundschecks
- 1d array and slice indexing
- do while statements
- break and continue support
- gotos and labels
- foreach over arrays
- for statements
- integer math
.... (and I few a forgot to list)

unsupported features are
- anything with strings (due to missing unicode handling)
- slicing & concat (due to missing memeory-manager)
- floating point math
- classes (due to missing vtbl and ref support)
- exceptions (due to missing stack-unwinding support and side-band channels)
- more complex structs i.e. with struct-members (due to incomplete type-handling)
-----------

Currently I am having trouble caused by a bug in dmds inliner that only happens on when dmd is compiled as a 32bit executable until I have  isolated / fixed this development is slowed down.

--
I hope this thread is informative and will continue to be that way.

Cheers,
Stefan (aka UplinkCoder)
February 16
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> Cheers,
> Stefan (aka UplinkCoder)

Stupid question: is your online alias a reference to the game Uplink?
February 16
On Thursday, 16 February 2017 at 21:19:14 UTC, Jack Stouffer wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> Cheers,
>> Stefan (aka UplinkCoder)
>
> Stupid question: is your online alias a reference to the game Uplink?

Yes it is.
Uplink Hackers Elite is a great game.
February 16
On Thu, Feb 16, 2017 at 09:05:51PM +0000, Stefan Koch via Digitalmars-d wrote:
> Hi Guys, due to the old CTFE status thread getting to page 30, I am now starting a new one.
> 
> First let me summerize which features are currently working: In order of date, the latest features come first.
> 
> - fixed continue and break for DoWhileStatements
> - non-toplevel Function Pointers as arguments
> - basic function pointers
> --- phobos, druntime & dmd unit-tests pass ----
[...]

This is great!  The fact that you got it to the point unittests pass is awesome.  Can't wait for the new CTFE engine to be released!

Do you have any estimate as to when it will be mergeable into master?


T

-- 
There are three kinds of people in the world: those who can count, and those who can't.
February 17
On Thursday, 16 February 2017 at 23:16:34 UTC, H. S. Teoh wrote:
> On Thu, Feb 16, 2017 at 09:05:51PM +0000, Stefan Koch via Digitalmars-d wrote:
>> Hi Guys, due to the old CTFE status thread getting to page 30, I am now starting a new one.
>> 
>> First let me summerize which features are currently working: In order of date, the latest features come first.
>> 
>> - fixed continue and break for DoWhileStatements
>> - non-toplevel Function Pointers as arguments
>> - basic function pointers
>> --- phobos, druntime & dmd unit-tests pass ----
> [...]
>
> This is great!  The fact that you got it to the point unittests pass is awesome.  Can't wait for the new CTFE engine to be released!
>
> Do you have any estimate as to when it will be mergeable into master?
>
>
> T

I estimate that newCTFE 1.0 as outlined in the vision document will be ready around April.

This estimate is a lower bound as it assumes that things go smoothly, and the past 6 months have shown that the CTFE-work does not go smoothly most of the time.
As an upper bound:
I have the personal goal to get it merged before DConf.

At this point most parts of the actual engine are done, the remaining work mostly involves either making the runtime ctfeable or building runtime-feature support into dmd.
These things are outside of my domain knowledge and therefore take much more time then they should.

February 17
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [...]
> I hope this thread is informative and will continue to be that way.
>
> Cheers,
> Stefan (aka UplinkCoder)

Yes, it is!

February 17
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> Hi Guys, due to the old CTFE status thread getting to page 30, I am now starting a new one.
>
> ...
> --
> I hope this thread is informative and will continue to be that way.
>
> Cheers,
> Stefan (aka UplinkCoder)

Thanks Stefan for your work, and for documenting it. Very exciting to read the progress! I wish more people were as devoted as you are! Keep up the good work!
February 17
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> Hi Guys, due to the old CTFE status thread getting to page 30, I am now starting a new one.
>
> First let me summerize which features are currently working:
> In order of date, the latest features come first.
>
> - fixed continue and break for DoWhileStatements
> - non-toplevel Function Pointers as arguments
> - basic function pointers
> --- phobos, druntime & dmd unit-tests pass ----
> - Method Calls (now range foreach will work)
> - 1-level Pointers
> - recursive function calls
> - fixed continue and break for ForStatements (includes foreach which is lowered)
> - basic Function Calls
> - static immutable globals
> - fixed continue & break for WhileStatemens
> - 1d array literals
> - ternary expressions ? :
> - struct literals.
> - basic struct support.
> - Slice and Array boundschecks
> - 1d array and slice indexing
> - do while statements
> - break and continue support
> - gotos and labels
> - foreach over arrays
> - for statements
> - integer math
> .... (and I few a forgot to list)
>
> unsupported features are
> - anything with strings (due to missing unicode handling)
> - slicing & concat (due to missing memeory-manager)
> - floating point math
> - classes (due to missing vtbl and ref support)
> - exceptions (due to missing stack-unwinding support and side-band channels)
> - more complex structs i.e. with struct-members (due to incomplete type-handling)
> -----------
>
> Currently I am having trouble caused by a bug in dmds inliner that only happens on when dmd is compiled as a 32bit executable until I have  isolated / fixed this development is slowed down.
>
> --
> I hope this thread is informative and will continue to be that way.
>
> Cheers,
> Stefan (aka UplinkCoder)

Just get LDC.
Make it use JIT.
And you'll get all the features working.
Writing slow interpreter is ... wasting efforts.
February 17
On Friday, 17 February 2017 at 19:44:10 UTC, Temtaime wrote:
>
> Just get LDC.
> Make it use JIT.
> And you'll get all the features working.
> Writing slow interpreter is ... wasting efforts.

For your information LLVM takes about 5 milliseconds to start up, it also takes a lot of time to generate code even when completely unoptimized.
For usual one-shot CTFE functions this leads to a _HUGE_ pessimisation of performance.
For the quite common usecase of returning a literal out of function templates newCTFE takes UNDER a MICROsecond.
There is no way LLVM could even come close no matter how many caching layers one adds.
February 17
On 2/17/17 8:44 PM, Temtaime wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> I hope this thread is informative and will continue to be that way.
>>
>> Cheers,
>> Stefan (aka UplinkCoder)
>
> Just get LDC.
> Make it use JIT.
> And you'll get all the features working.
> Writing slow interpreter is ... wasting efforts.

This is a common misconception. LLVM as AoT optimizing compiler is great, but for the JIT compiler it's actually far too slow at codegen to be a sensible choice.

---
Dmitry Olshansky
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11