On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

I just found more states we get into, that should be impossible to ever get into.
I am stumped.
Baffled.
And seriously befuddled!

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

I just fixed the static assert((null ~ null) is null);
Hence I can now enable string-concat!

On Wednesday, 12 April 2017 at 09:19:39 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> I just found more states we get into, that should be impossible to ever get into.
> I am stumped.
> Baffled.
> And seriously befuddled!

So .. this is partially because we assume the stack to be zeroed if we have not written to it yet. It is zero-initialized after all, however If we are returning from a function that wrote to the stack and then we are calling another function, that function will see the state the previous function left there...

which just means ... we have to zero our temporaries and locals on function entery.
implementing this however breaks incremental code-generation.

Awwwww ....

On Wed, Apr 12, 2017 at 01:18:13PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
> 
> I just fixed the static assert((null ~ null) is null);
> Hence I can now enable string-concat!
[...]

Good news!


T

-- 
Век живи - век учись. А дураком помрёшь.

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

Comma expressions should now work.

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

Hi I want to share another story.
I was pretty happy to have recursive function calls working.
So happy in fact that I overlooked that they were actually generated twice.
Let me illustrate what happend.

Suppose we have the following module :
void fn(uint rcount)
{
  uint ctr = rcount;

  while (rcount--)
    ctr += fn(rcount);

  return ctr;
}

pragma(msg, fn(26));

the compiler hits the pragma(msg) and goes on to evaluate fn(26)
newCTFE receives the functionBody as an ast-node.
it starts processing (function 1)
and hits the fn(rcount)

it checks if it has the code for fn already.
this check returns false since fn has not been completely generated yet.

when this check returns it will write the FunctionBody in it's todo list.
it wires up the call to the entry in the todo list. (function 2)
it then hits the end of fn  (function 1)and saves it in its code-cache.

now it processes the TODO list
it finds that it has to process fn.
it starts processing fn (function 2)
it hits the call.
This time it does find an entry in the code cache for fn (funcion 1)
it wires of the call
and returns.

The generate pseudo-code looks like :

... fn_0 (...) {
 ...
 call (fn_1, ...)
 ...
}
... fn_1 (...) {
  ...
  call (fn_0, ...)
  ...
}

It was very surprised then I saw this :)

Cheers,
Stefan

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> { ... }

Wonderful news!
Most of the Byteocode macros are gone!
meaning less templates and faster bytecode generartion!

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.
>
> [...]

The llvm backend is back in a fully working state.
It's about 2times slower in my then my interpreter ;)

On Saturday, 15 April 2017 at 10:10:54 UTC, Stefan Koch wrote:
> 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.
>>
>> [...]
>
> The llvm backend is back in a fully working state.
> It's about 2times slower in my then my interpreter ;)

Huh. In all cases, or only in trivial ones? Because I would have expected the overhead of jitting to become less relevant the more complex stuff you interpret vs jit.

On Saturday, 15 April 2017 at 10:30:57 UTC, Moritz Maxeiner wrote:
> On Saturday, 15 April 2017 at 10:10:54 UTC, Stefan Koch wrote:
>> 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.
>>>
>>> [...]
>>
>> The llvm backend is back in a fully working state.
>> It's about 2times slower in my then my interpreter ;)
>
> Huh. In all cases, or only in trivial ones? Because I would have expected the overhead of jitting to become less relevant the more complex stuff you interpret vs jit.

It's an average number.
on tests the represent the usual usage of ctfe.