On Wednesday, 30 November 2016 at 13:49:01 UTC, Stefan Koch wrote:
> On Tuesday, 29 November 2016 at 23:09:08 UTC, Stefan Koch wrote:
>> On Tuesday, 29 November 2016 at 23:00:08 UTC, Stefan Koch wrote:
>>> I fixed a bug in continue break handling.
>>
>> For the record it was an off by one error.
>> The value for unresolvedGotos would add one referencing jump.
>> But the count of referencing would be initialized to zero instead of one.
>
> I just added support for assert in newCTFE.
> Also I noticed a performance regression in the bytecode generator.
> (compared to an earlier version that handled much less)
>
> Nontheless I get a solid 4x performance improvement over the old evaluator when compiled with ldc.
>
> Furthermore struct support regressed.
> It has to be rewritten anyway in order to support method-calls properly.

Every now and then it would be interesting to have a list of things that work and a list of things still to do.

Keep up the good work!

On Wednesday, 30 November 2016 at 13:49:01 UTC, Stefan Koch wrote:
> I just added support for assert in newCTFE.

Cool.

> Nontheless I get a solid 4x performance improvement over the old evaluator when compiled with ldc.

Wow.

>
> Furthermore struct support regressed.
> It has to be rewritten anyway in order to support method-calls properly.

Keep up!

On Wednesday, 30 November 2016 at 15:02:21 UTC, Andrea Fontana wrote:

>
> Every now and then it would be interesting to have a list of things that work and a list of things still to do.

That list changes. On both ends.  I constantly discover things that I thought were dealt with are indeed still work in progress.

I can give a rough overview in a few day when things have (Hopefully!) stabilized a little more.

> Keep up the good work!

I will!

I just fixed  a bug cause the non-debug build to fail on a expression that it should have bailed out on.

Currently I have troubles with this  code :

int fn(int y)
{
  int x = void;
  ++x;
  return x+y;
}

Since x is uninitialized the ctfe interpreter should fail on it.
I will need to reserve a certain value as the uninitialized flag.
since stackAddress zero can never be used it'd be perfect for the job.
This bug should be fixed by tomorrow.

On Thursday, 1 December 2016 at 17:52:02 UTC, Stefan Koch wrote:
> I just fixed  a bug cause the non-debug build to fail on a expression that it should have bailed out on.
>
> Currently I have troubles with this  code :
>
> int fn(int y)
> {
>   int x = void;
>   ++x;
>   return x+y;
> }
>
> Since x is uninitialized the ctfe interpreter should fail on it.
> I will need to reserve a certain value as the uninitialized flag.
> since stackAddress zero can never be used it'd be perfect for the job.
> This bug should be fixed by tomorrow.

I opted for bailing out as soon as void initialization is in the function.
This will need to handled properly at some point but now is not the time.

Currently I am working on the ability of returning structs.
Although those are "merely" heterogeneous arrays.
This is a very important step towards having a usable CTFE-reimplementation.

the regressed struct support.
seems to be restored. (Although I have no idea why)
Once this is done the more complex composite types have to be fit in the current model.

I have a very flat representation of values.
They are treated almost exactly as run-time values.
Which means that the ctfe engine itself needs a well defined abi.
Since I was aware of this, I have already put alot of thought into this.
However the recent onslaught of bugs have shown that I can not assume that my code is bug-free.
I expect a few hard issues in the memory-management and ABI-dependent code.

I will keep you updated,
Cheers,
Stefan

On Saturday, 3 December 2016 at 02:07:06 UTC, Stefan Koch wrote:
> Currently I am working on the ability of returning structs.
>
> I will keep you updated,

This is coming along rather nicely.
StructLiterals as Arguments regressed.
But they did rather dubious stuff in the first place.

So supported types are.

StringLiterals.
Integral Array Literals.
Dynamic int[] and uint[] Arrays.
Structs with int or uint members.
and
StructLiterals with int/uint members (regressed currently.)

64bit integrals (long) do work but only if the interpreter backend is used.

Supported operations.
All basic math. (+ - * / %)
...++ ...-- +++... --...
while(...) {...}
do ... while(...)
label :
goto label;
break;
break label;
continue;
continue label;
for(...;...;...)
... ? ... : ...
switch (...) { case ... , ... } (unreliable due to differences in case-sorting :( )
for-each on strings and arrays.
Assigning to array length. (currently without copying on reallocation :( )
Bounds-Checked :
Array-Indexing
Left-Shift Right-Shift. (always unsigned! :( )

Unsupported :
&& ||
classes (unlikely to be added in the near future)
function calls (plain and closure)
slices
pointers
static arrays.

floating point math (unlikely to be added in the near future)

On Saturday, 3 December 2016 at 18:00:10 UTC, Stefan Koch wrote:
> On Saturday, 3 December 2016 at 02:07:06 UTC, Stefan Koch wrote:
>> [...]
>
> switch (...) { case ... , ... } (unreliable due to differences in case-sorting :( )
> for-each on strings and arrays.
if (...) { ... } else { ... } (if(__ctfe) && if(!__ctfe) are special cased and non-ctfe code is removed)
assert(..., "...")
> Assigning to array length. (currently without copying on reallocation :( )
> Bounds-Checked :
> Array-Indexing
> Left-Shift Right-Shift. (always unsigned! :( )
>
> [...]

Forgot to add assert, I forget that I implemented it a few days ago.

On Saturday, 3 December 2016 at 18:16:21 UTC, Stefan Koch wrote:
> [...]

StructLiteral regressions fixed.
That one was hard to find.
Basically the for Array arguments interfered with this one.
Arguments are technically the same expression as everything else.
But in order to support targets that do have native function calls,
and in order to archive more performance for the interpreter they have to be treated quite differently from non-argument expressions.

For now they should work, but it's brittle at best.

On Saturday, 3 December 2016 at 19:28:52 UTC, Stefan Koch wrote:
> On Saturday, 3 December 2016 at 18:16:21 UTC, Stefan Koch wrote:
>> [...]
>
> StructLiteral regressions fixed.
> That one was hard to find.
> Basically the for Array arguments interfered with this one.
> Arguments are technically the same expression as everything else.
> But in order to support targets that do have native function calls,
> and in order to archive more performance for the interpreter they have to be treated quite differently from non-argument expressions.
>
> For now they should work, but it's brittle at best.

The following code now compiles with newCTFE:
struct S
{
 uint u1;
 uint u2;
}

S makeTenTen()
{
  return S(10, 10);
}

S makeS(uint a, uint b)
{
  return S(a, b);
}

uint getu2(S s)
{
  return s.u2;
}

static assert(getu2(S(10, 14)) == 14);
static assert(makeTenTen() == makeS(10, 10));