On Thursday, 17 November 2016 at 09:19:57 UTC, Stefan Koch wrote:
> On Thursday, 17 November 2016 at 08:39:57 UTC, Andrea Fontana wrote:
>>
>> I follow this thread every day. I hope you'll write an article on dlang blog when the work will be completed :)
>
> Mike Parker is going to write an short article about it based on information I gave him via mail.
>
> I am afraid my blog-writing skills are a bit under-developed.
>
> On the topic of CTFE :
> My attempts of half-automatically generating a string-concat macro have yet to succeed.
>
> I am currently busy fixing bugs :)
> I apologize for the seemingly slow progress.
> However,
> such is the nature of low-level code.
> There is really no way around it,
> if we are aiming for performance.

I just fixed the bug with multiple ArraysLiterals as arguments.
We are not out of the mud yet. This will most likely not play nice with nested arrays.
But let's cross that bridge when we come to it :)

On Friday, 18 November 2016 at 15:09:02 UTC, Stefan Koch wrote:

> I just fixed the bug with multiple ArraysLiterals as arguments.
This means the following code will now compile and properly execute:

uint Sum3Arrays (uint[] a1, uint[] a2, uint[] a3)
{
  uint result;
  for(int i; i != a1.length; i++)
  {
    result += a1[i];
  }
  for(int i; i != a2.length; i++)
  {
    result += a2[i];
  }
  for(int i; i != a3.length; i++)
  {
    result += a3[i];
  }

  return result;
}

static assert(Sum3Arrays([2,3],[],[]) == 5);
static assert(Sum3Arrays([2],[],[3]) == 5);
static assert(Sum3Arrays([3],[1],[1]) == 5);

On Friday, 18 November 2016 at 17:21:10 UTC, Stefan Koch wrote:
> On Friday, 18 November 2016 at 15:09:02 UTC, Stefan Koch wrote:
>
>> I just fixed the bug with multiple ArraysLiterals as arguments.
> This means the following code will now compile and properly execute:
>
> uint Sum3Arrays (uint[] a1, uint[] a2, uint[] a3)
> {
>   uint result;
>   for(int i; i != a1.length; i++)
>   {
>     result += a1[i];
>   }
>   for(int i; i != a2.length; i++)
>   {
>     result += a2[i];
>   }
>   for(int i; i != a3.length; i++)
>   {
>     result += a3[i];
>   }
>
>   return result;
> }
>
> static assert(Sum3Arrays([2,3],[],[]) == 5);
> static assert(Sum3Arrays([2],[],[3]) == 5);
> static assert(Sum3Arrays([3],[1],[1]) == 5);

Another small update.
I just fixed the bailout mechanism.
Before it would ignore failiures in argument processing and start the interpreter with bogus as arguments.
This of course looked like miscompiled code.
I am happy it was just the bailout :)

Another small update.
I got rid of the heapClearing overhead.
By using ddmds allocator.
Because of that I was able to shave off 20ms overhead.

On Saturday, 19 November 2016 at 09:42:33 UTC, Stefan Koch wrote:
> Another small update.
> I got rid of the heapClearing overhead.
> By using ddmds allocator.
> Because of that I was able to shave off 20ms overhead.

Allocation of dynamic arrays works :)
The following code will work just fine with the new engine.
uint[] repeat(uint[] a, uint cnt)
{
  uint[] result = [];
  uint pos;
  result.length = cast(uint) (a.length * cnt);
  while(cnt--) foreach(c;a)
  {
    result[pos++] = c;
  }

  return result;
}

static assert(repeat([1,2,3,4], 4) ==
  [1,2,3,4, 1,2,3,4, 1,2,3,4, 1,2,3,4]
);

On Saturday, 19 November 2016 at 11:22:18 UTC, Stefan Koch wrote:
> On Saturday, 19 November 2016 at 09:42:33 UTC, Stefan Koch wrote:
>> Another small update.
>> I got rid of the heapClearing overhead.
>> By using ddmds allocator.
>> Because of that I was able to shave off 20ms overhead.
>
> Allocation of dynamic arrays works :)
> The following code will work just fine with the new engine.
> uint[] repeat(uint[] a, uint cnt)
> {
>   uint[] result = [];
>   uint pos;
>   result.length = cast(uint) (a.length * cnt);
>   while(cnt--) foreach(c;a)
>   {
>     result[pos++] = c;
>   }
>
>   return result;
> }
>
> static assert(repeat([1,2,3,4], 4) ==
>   [1,2,3,4, 1,2,3,4, 1,2,3,4, 1,2,3,4]
> );

There is an important change coming up.
I am going to rewrite the 64 bit support.

The after the change the interpreter will be slower when working with 64bit values.
However it will be much easier for the jit.

Also I have a lead on howto fix the bugs in break and continue handling.

A nice weekend to all of you!

On Sunday, 20 November 2016 at 09:02:30 UTC, Stefan Koch wrote:
> On Saturday, 19 November 2016 at 11:22:18 UTC, Stefan Koch wrote:
>> On Saturday, 19 November 2016 at 09:42:33 UTC, Stefan Koch wrote:
>>> Another small update.
>>> I got rid of the heapClearing overhead.
>>> By using ddmds allocator.
>>> Because of that I was able to shave off 20ms overhead.
>>
>> Allocation of dynamic arrays works :)
>> The following code will work just fine with the new engine.
>> uint[] repeat(uint[] a, uint cnt)
>> {
>>   uint[] result = [];
>>   uint pos;
>>   result.length = cast(uint) (a.length * cnt);
>>   while(cnt--) foreach(c;a)
>>   {
>>     result[pos++] = c;
>>   }
>>
>>   return result;
>> }
>>
>> static assert(repeat([1,2,3,4], 4) ==
>>   [1,2,3,4, 1,2,3,4, 1,2,3,4, 1,2,3,4]
>> );
>
> There is an important change coming up.
> I am going to rewrite the 64 bit support.
>
> The after the change the interpreter will be slower when working with 64bit values.
> However it will be much easier for the jit.
>
> Also I have a lead on howto fix the bugs in break and continue handling.
>
> A nice weekend to all of you!

I discovered a new bug in the handling of do-while statements.
Which I subsequently fixed.

I also fixed the C backend.
It would interpret a certain conditional different from all other back-ends.

This makes it oblivious that better documentation of the code-gen interface is needed.
Furthermore I need to extend my bc_tests. to make sure the interpretation is the same.
Such that this bug cannot happen again.

As always a happy weekend to all of you.
- I really need a drink ... preferably root-beer.

On Sunday, 20 November 2016 at 15:37:50 UTC, Stefan Koch wrote:
> Furthermore I need to extend my bc_tests. to make sure the interpretation is the same.
> Such that this bug cannot happen again.

I have extended my test-suite to test this case.
It is crucial that the c backend and the interpreter back-ends  do always return the same correct value. As those are both testable at CTFE.

I have plans to implement a small CTFEable instruction-set-simulator for the intel 486 processor.
That way I can make sure that my x86-backend does what it is supposed to do.
However this is further down the road :)

On Sunday, 20 November 2016 at 16:27:24 UTC, Stefan Koch wrote:
> On Sunday, 20 November 2016 at 15:37:50 UTC, Stefan Koch wrote:
>> Furthermore I need to extend my bc_tests. to make sure the interpretation is the same.
>> Such that this bug cannot happen again.
>before.
> I have extended my test-suite to test this case.
> It is crucial that the c backend and the interpreter back-ends  do always return the same correct value. As those are both testable at CTFE.
>
> I have plans to implement a small CTFEable instruction-set-simulator for the intel 486 processor.
> That way I can make sure that my x86-backend does what it is supposed to do.
> However this is further down the road :)

A bug in Do-While handling appeared that was hidden by the previously incorrect behavior.
When writing do { ... } while(true/false)
The IR generated would tell the interpreter to evaluate the condition flag.
However the load of a constant does not modify the condition flag and therefore if the loop is executed or not, depends on the result of a previous comparison.
The fix is simple check for the (false/true) constants.
(DMD has a shortcut for this, awkwardly named isBool() )
with an even more awkward usage.

if (expression.isBool(true)) { // this expression is a constant which evaluates to true }
else if (expression.isBool(false)) {// this expression is a constant false
else { // this value is not a constant }

On Monday, 21 November 2016 at 10:51:01 UTC, Stefan Koch wrote:
> When writing do { ... } while(true/false)
> The IR generated would tell the interpreter to evaluate the condition flag.

This Bug is now fixed.
At the same time a superfluous jump could be eliminated.
I have also fixed another bug in the bailout system.
Such that we now bail out when we could not interpret the right-hand-side of an arrayLength Assignment.