CTFE Status

[Stefan Koch via Digitalmars-d]

On Monday, 7 November 2016 at 14:13:04 UTC, Stefan Koch wrote:
> On Monday, 7 November 2016 at 10:02:37 UTC, Stefan Koch wrote:
>> On Sunday, 6 November 2016 at 22:07:05 UTC, Stefan Koch wrote:
>>> On Sunday, 6 November 2016 at 15:31:24 UTC, Stefan Koch wrote:
>>>>
>>>> Phobos and druntime unittests do compile now.
>>>> After the ability for returning errors is added all unitests 
>>>> will be passed. (Most likely if there are not more bugs 
>>>> inside the engine)
>>>
>>> I just have just implemented the ability to error out.
>>> And I am still not passing interpret3.d.
>>> That is one hard unit-test.
>>>
>>> Currently I pass around 25% of interpret3.d.
>>
>> I consider the engine ready to be merged into the feature 
>> branch.
>> There are still a few obscure failures.
>> But nothing preventing an alpha release.
>
> Update I tracked down a bug that prevented a function from 
> std.allocator to execute correctly.
>
> Slowly but steadily new ctfe becomes more robust.

Another bug was identified.
There are severe issues with the interpreter back-end and it's 
32bit only legacy.
Fixing these issues will degrade performance of the interpreter 
by roughly 7-15%.

Maybe there is still a way around it, but so far my more 
performance-oriented approaches  are failing to fix the problems.

Errors now know their location, and most of the time assertions 
thrown be the new engine are close enough to the old interpreters 
one.
However my errors have less information in them due to design 
limitations.
It is possible to lift those but only with significant effort.

Slightly OT.
I feel like I hit every bump in the road to a faster interpreter, 
and I know there are a a lot more ahead.

Today I spent 3 hours to find a bug which caused a division by 
zero.
It turned out that 64bit large function arguments where silently 
skipped.
Causing the interpreter to read zero initialized memory instead 
of the actual arguments. However I suspected the division code to 
be at fault and wasted a lot of time of second-guessing correct 
code.

Having these implementation challenges intermixed with design and 
performance considerations can be taxing sometimes.

Without my bytecode-unitests which are ctfeable it would be 
almost impossible to for me to work at the pace I am working.
Simply because I get direct feedback if something goes wrong 
because the compile will abort after less then a second.

These kinds of things are the true strength of ctfe.
CTFE is the one of the greatest development assets one can have.
Because it transforms the compile-debug-edit cycle into a 
compile-edit cycle.