On 05/21/2016 11:18 PM, Martin Nowak wrote:
> The debugging metaphor would be comparing a program that only uses pointer arithmetic against one that is memory safe, the former can randomly write everywhere from anywhere, the latter could use the wrong reference.

It's also similar to comparing assembly code to C.

On Saturday, 21 May 2016 at 21:20:54 UTC, Martin Nowak wrote:
> On 05/21/2016 11:18 PM, Martin Nowak wrote:
>> The debugging metaphor would be comparing a program that only uses pointer arithmetic against one that is memory safe, the former can randomly write everywhere from anywhere, the latter could use the wrong reference.
>
> It's also similar to comparing assembly code to C.

I am just working on a change that introduces a temporary-Stack to the memory management of dmd.
So far it crashes :)

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
> Hi Guys,
>
> I have been looking into the DMD now to see what I can do about CTFE.

> I will post more details as soon as I dive deeper into the code.

Update :
int bug6498(int x)
{
    int n = 0;
    while (n < x)
        ++n;
    return n;
}
static assert(bug6498(10_000_000)==10_000_000);
This compiles now for me. Although it still takes 10 seconds ;)

On Friday, 27 May 2016 at 23:31:24 UTC, Stefan Koch wrote:
> On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I have been looking into the DMD now to see what I can do about CTFE.
>
>> I will post more details as soon as I dive deeper into the code.
>
> Update :
> int bug6498(int x)
> {
>     int n = 0;
>     while (n < x)
>         ++n;
>     return n;
> }
> static assert(bug6498(10_000_000)==10_000_000);
> This compiles now for me. Although it still takes 10 seconds ;)

Big Whoop!
Just make the number slightly lager and it fails again.

On Saturday, 28 May 2016 at 12:27:26 UTC, Stefan Koch wrote:
> On Friday, 27 May 2016 at 23:31:24 UTC, Stefan Koch wrote:
>> On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
>>> Hi Guys,
>>>
>>> I have been looking into the DMD now to see what I can do about CTFE.
>>
>>> I will post more details as soon as I dive deeper into the code.
>>
>> Update :
>> int bug6498(int x)
>> {
>>     int n = 0;
>>     while (n < x)
>>         ++n;
>>     return n;
>> }
>> static assert(bug6498(10_000_000)==10_000_000);
>> This compiles now for me. Although it still takes 10 seconds ;)
>
> Big Whoop!
> Just make the number slightly lager and it fails again.
but smaller than 2_147_483_647 right :)

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:

> I will post more details as soon as I dive deeper into the code.

Okay I briefly evaluated the current IR dmd uses for backend communication, and it seems usable for the purposes of a CTFE-Interpreter/JIT.

The Memory-Management issue is mostly orthogonal to CTFE.
But nonetheless very important.

On Friday, 3 June 2016 at 15:46:27 UTC, Stefan Koch wrote:
> On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
>
>> I will post more details as soon as I dive deeper into the code.
>
> Okay I briefly evaluated the current IR dmd uses for backend communication, and it seems usable for the purposes of a CTFE-Interpreter/JIT.
>
> The Memory-Management issue is mostly orthogonal to CTFE.
> But nonetheless very important.

I have to admit currently I am a bit stuck.

@Timon Gehr cooperation would be highly appreciated.

First small code example compiles!

int bug6498(int x) {
 int n = 0;

 while (n < x) {
  n++;
 }

 return n;
}

evaluation of bug6498(100_000_00) took 226 msecs.
evaluation of bug6498(100_000_000) took 2228 msecs.

The memory allocated by the Evaluator is exactly 12 bytes.

On Thursday, 30 June 2016 at 01:20:08 UTC, Stefan Koch wrote:
> First small code example compiles!
>
> int bug6498(int x) {
>  int n = 0;
>
>  while (n < x) {
>   n++;
>  }
>
>  return n;
> }
>
> evaluation of bug6498(100_000_00) took 226 msecs.
> evaluation of bug6498(100_000_000) took 2228 msecs.
>
> The memory allocated by the Evaluator is exactly 12 bytes.

The speedup comes from interpreting the IR or fixing the memory leaking?

On Thursday, 30 June 2016 at 01:32:47 UTC, Martin Nowak wrote:
> On Thursday, 30 June 2016 at 01:20:08 UTC, Stefan Koch wrote:
>> First small code example compiles!
>>
>> int bug6498(int x) {
>>  int n = 0;
>>
>>  while (n < x) {
>>   n++;
>>  }
>>
>>  return n;
>> }
>>
>> evaluation of bug6498(100_000_00) took 226 msecs.
>> evaluation of bug6498(100_000_000) took 2228 msecs.
>>
>> The memory allocated by the Evaluator is exactly 12 bytes.
>
> The speedup comes from interpreting the IR or fixing the memory leaking?

Both. Actually I could not imagine fixing the memory problem without doing IR interpretation.
I will tackle compiling more difficult code later today.
As soon as I can run my compiletime brainfuck I will open a PR.

Until then you can see my progress at https://github.com/UplinkCoder/dmd/tree/newCTFE
I will try to always keep the branch in a healthy state.