• Stefan Koch (35/35) Jun 12 2018 Good day ladies and gentleman,
• Cym13 (5/40) Jun 12 2018 That's very nice! Out of curiosity, what was the reason to avoid
• Stefan Koch (17/21) Jun 12 2018 It was an initial design decision. (I addressed it briefly in my
• Per =?UTF-8?B?Tm9yZGzDtnc=?= (2/6) Jun 12 2018 Nice!

Stefan Koch <uplink.coder googlemail.com> writes:

Good day ladies and gentleman,

it is my distinct please to announce that a new feature just 
landed in newCTFE.

!!! DELEGATES !!!

this means the following code will now work:
int square_of_x_plus_x(int x) pure
{
     int passThrough(int y) pure
     {
         assert(x == y);
         int y2 = x;
         assert(y2 == y);

         int fnC() pure
         {
             auto z = (x * y);
             assert(y2 == x);
             assert(x == y);
             return z;
         }
         return fnC();
     }
     return x + passThrough(x);
}

pragma(msg, square_of_x_plus_x(7));
static assert(square_of_x_plus_x(5) == (5*5)+5);

the reason why this was quite tricky to implement is that
in the newCTFE architecture there is no concept of a function 
touching
the stack-frame of another function _at all_.
(Infact there is  no conventional stack, rather the virtual 
registers themselves stack)
Sharing of the stack frames gets emulated via a hidden parameter 
and a linked-list structure.

Cheers,
Stefan

Cym13 <cpicard openmailbox.org> writes:

On Wednesday, 13 June 2018 at 05:57:31 UTC, Stefan Koch wrote:
 Good day ladies and gentleman,

 it is my distinct please to announce that a new feature just 
 landed in newCTFE.

 !!! DELEGATES !!!

 this means the following code will now work:
 int square_of_x_plus_x(int x) pure
 {
     int passThrough(int y) pure
     {
         assert(x == y);
         int y2 = x;
         assert(y2 == y);

         int fnC() pure
         {
             auto z = (x * y);
             assert(y2 == x);
             assert(x == y);
             return z;
         }
         return fnC();
     }
     return x + passThrough(x);
 }

 pragma(msg, square_of_x_plus_x(7));
 static assert(square_of_x_plus_x(5) == (5*5)+5);

 the reason why this was quite tricky to implement is that
 in the newCTFE architecture there is no concept of a function 
 touching
 the stack-frame of another function _at all_.
 (Infact there is  no conventional stack, rather the virtual 
 registers themselves stack)
 Sharing of the stack frames gets emulated via a hidden 
 parameter and a linked-list structure.

 Cheers,
 Stefan

That's very nice! Out of curiosity, what was the reason to avoid 
a conventional stack? Or was it a consequence more than a design 
decision? (If you've explained it before, feel free to just throw 
the old post at me)

Stefan Koch <uplink.coder googlemail.com> writes:

On Wednesday, 13 June 2018 at 06:10:26 UTC, Cym13 wrote:
 That's very nice! Out of curiosity, what was the reason to 
 avoid a conventional stack? Or was it a consequence more than a 
 design decision? (If you've explained it before, feel free to 
 just throw the old post at me)

It was an initial design decision. (I addressed it briefly in my 
2017 talk on newCTFE)
https://www.youtube.com/watch?v=crHnumzsLUs&t=2420

The main reason was to avoid the debugging nightmare that messing 
with the stack-pointer causes. I thought the most effective way 
to not have this problem was to simply eliminate the stack 
pointer.
Another reason is that I am noticing a tendency in real hardware 
to have multiple-stacked versions of the register set. Doing the 
same with my virtual cpu would be forward compatible :)

All in all I do not regret that decision at all.

It doubtlessly saved weeks of debugging!
(And harmonizes delegates with closures (since in newCTFE _all_ 
delegates have to be closures.))

Cheers,
Stefan

Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

On Wednesday, 13 June 2018 at 05:57:31 UTC, Stefan Koch wrote:
 Good day ladies and gentleman,
 it is my distinct please to announce that a new feature just 
 landed in newCTFE.
 !!! DELEGATES !!!

Nice!