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

Hi Guys,

ref variable handing is coming soon!
(only int/uint for now)...

Also I have suspicions that there is a bug in my ctfe_evaluator in which the first default arguments can overridden with the this pointer :)

I will test "this" tomorrow :)

Also I submitted my talk proposal a few hours ago;
Of course it's about newCTFE.

Cheers,
Stefan

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

Simple ref calls work now.
Meaning the following code will compile :)

uint sum(uint[] arr)
{
  uint sum;
  foreach(uint i;0 .. cast(uint)arr.length)
  {
    addToSum(sum, arr[i]);
  }
  return sum;
}
void addToSum(ref uint sum, uint element)
{
  sum = sum + element; // works now as well
  return ;
}

static assert([1,2,3,4,5].sum == 15);

On Monday, 27 February 2017 at 23:48:13 UTC, Stefan Koch wrote:
> Simple ref calls work now.
> Meaning the following code will compile :)

Great work.

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

Hi Guys,

The implementation of ref parameters by itself was successful.
However they hey have one bug, which is a consquence of newCTFE not touching dmd's state.
They cannot modify an outer parameter. (where outer means that the parameter does not originate from a ctfe-evaluation further up the call stack)

uint add8ret3(ref uint a) {a += 8; return 3;}

pragma (msg, (uint outer) { outer += add8ret3(a); return outer;}(1)); // will print 4

pragma (msg, (uint outer) { uint inner = outer; inner += add8ret3(inner); return inner; }(1)); // will print 12 as expected.

There are two options I could take:
The first one is to disallow having refs of outer parameters taken.
(and bailing out in this case)
The second option is to implement the logic necessary to modify these expression nodes.

Both options require me to detect if we have an outer ref parameter. but that should be easy to do.

Cheers,
Stefan

On Thursday, 2 March 2017 at 03:09:56 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>

> uint add8ret3(ref uint a) {a += 8; return 3;}
>
> pragma (msg, (uint outer) { outer += add8ret3(a); return outer;}(1)); // will print 4

was supposed to say:
pragma (msg, (uint outer) { outer += add8ret3(outer); return outer;}(1)); // will print 4

On Thursday, 2 March 2017 at 03:09:56 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> Hi Guys,
>
> The implementation of ref parameters by itself was successful.
> However they hey have one bug, which is a consquence of newCTFE not touching dmd's state.
> They cannot modify an outer parameter. (where outer means that the parameter does not originate from a ctfe-evaluation further up the call stack)
>
> Cheers,
> Stefan


It turn out that this was not the problem.
It was rather old code in the byte-code evaluator that dated from a time where parameters were not considered stack values.
causing that code to copy the parameters into a temporary.
When I removed the distinction between parameters and normal stack values I deleted the code that kept track of the parameters that were copied into temporaries.

Since I forgot to remove the creation of those temporaries.
We ended up with the situation described above.

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

Time for an update.

I am currently working on integrating 64bit values into codegen API.
However, a backend may not have native 64bit registers or arithmetic (the x86/arm architectures come to mind)
For those a common fallback is to be implemented such that not every architecture has to implement their 64bit arithmetic on their own.

Also work is underway to finally support slicing, which is crucial to using phobos algorithms.

On Fri, Mar 10, 2017 at 11:32:14AM +0000, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
> 
> Time for an update.
> 
> I am currently working on integrating 64bit values into codegen API. However, a backend may not have native 64bit registers or arithmetic (the x86/arm architectures come to mind) For those a common fallback is to be implemented such that not every architecture has to implement their 64bit arithmetic on their own.

Makes sense to me.


> Also work is underway to finally support slicing, which is crucial to using phobos algorithms.

This is awesome news!  Glad to hear there's steady progress being made on the new CTFE engine.  Can't wait for it to be done and merged into master!  There are so many awesome things I wanna do with CTFE that currently would be unacceptably slow.  Can't wait to take D compile-time capabilities to a whole 'nother level!


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - Natural Intelligence, Inc.

On Friday, 10 March 2017 at 11:32:14 UTC, Stefan Koch wrote:
> Also work is underway to finally support slicing, which is crucial to using phobos algorithms.

Incredible diligence.

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

Basic Slicing support is in;
The following code will now compile with the newCTFE_slicing branch:

static immutable uint[] OneToTen = [1,2,3,4,5,6,7,8,9,10];

const(uint[]) SliceOf1to10(uint lwr, uint upr) {
    return OneToTen[lwr .. upr];
}

static assert(SliceOf1to10(2,8) == [3u, 4u, 5u, 6u, 7u, 8u]);

Contrary to the old interpreter no copies are made.
newCTFE slices reference memory just as runtime slices do.

Cheers, Stefan;