www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - newCTFE Status Janurary 2018

reply Stefan Koch <uplink.coder googlemail.com> writes:
Hi Guys,

I've just done a small refactoring which I have been putting off 
for a while now.
It should greatly help with reducing ABI bugs, and it cuts the 
dependencies between the DMD-dependent and the independent parts 
of newCTFE.

Furthermore I fixed handling of 64bit values which where 
truncated to 32bit in some cases.
I've found those while working on ctfe-able float-to-string 
conversion.

However there are still many bugs which can crash newCTFE or even 
worse, make it produce wrong output (most of those are related to 
classes and vtbl-handling).

I expect it'll take me multiple full-time days to make 
significant progress on the vtbl issues. Because first I'll have 
to get debug-system into shape. It only really works if there is 
just one function in the context being compiled, as virtual 
functions by definition require multiple functions to live in the 
compilation context, it makes the debug-system useless .... sigh.

Unfortunately my time budget is pretty tight this and the 
following months as I am also preparing a Dconf presentation.

Let's see how far I can get during the next weekends.

Cheers,

Stefan
Jan 13 2019
next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:

 Let's see how far I can get during the next weekends.


Thanks and keep up the good work!
Jan 13 2019
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:

 Cheers,

 Stefan


Did you mean 2019 by any chance? ;)

Glad to see some progress though!
Jan 13 2019
prev sibling next sibling parent reply JN <666total wp.pl> writes:
On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:

 Hi Guys,

 I've just done a small refactoring which I have been putting 
 off for a while now.
 It should greatly help with reducing ABI bugs, and it cuts the 
 dependencies between the DMD-dependent and the independent 
 parts of newCTFE.


I'm not very familiar with the project, although I've seen the 
name pop up from time to time. What benefits does it provide? Is 
it only for DMD or will GDC/LDC make use of it too?
Jan 13 2019
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 13 January 2019 at 21:00:28 UTC, JN wrote:

 On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:

 Hi Guys,

 I've just done a small refactoring which I have been putting 
 off for a while now.
 It should greatly help with reducing ABI bugs, and it cuts the 
 dependencies between the DMD-dependent and the independent 
 parts of newCTFE.


 I'm not very familiar with the project, although I've seen the 
 name pop up from time to time. What benefits does it provide? 
 Is it only for DMD or will GDC/LDC make use of it too?


It will benefit all compiler which chose to use the frontend of 
DMD.
That includes GDC and LDC.
It will also benefit the D programming language as a whole in a 
less tangible way, but I don't want to spoil it before Dconf :)

Cheers,
Stefan
Jan 13 2019
prev sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Sun, 13 Jan 2019 21:00:28 +0000, JN wrote:

 On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:

 Hi Guys,

 I've just done a small refactoring which I have been putting off for a
 while now.
 It should greatly help with reducing ABI bugs, and it cuts the
 dependencies between the DMD-dependent and the independent parts of
 newCTFE.


 
 I'm not very familiar with the project, although I've seen the name pop
 up from time to time. What benefits does it provide? Is it only for DMD
 or will GDC/LDC make use of it too?


D's compile-time function evaluation is powerful. It's also slow and 
memory-hungry. newCTFE will let us run code at compile time using a more 
advanced interpreter, one that will be significantly faster and probably a 
lot gentler with memory.
Jan 13 2019
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:

 [ ... ]


Another small update: I've just fixed problems with 
class-constructor and vtbl handling.
meaning the following code does compile now.

class B {}
class C : B
{
   int _i = 2;
   int i() {return ( 1); }
}
class D : C
{
   override int i() {return 2;}
   float f() { return 1.0f; }
}
class E : D
{
   int _x;
   this(int _x)
   {
     this._x = 3;
   }
   override int i() {return _x;}
   override float f() { return 2.0f; }
}
int testClassStuff ()
{
   B b1;
   C c1, c2, c3;
   D c4;
   c1 = new C();
   c2 = new D();
   c3 = new E(3);
   b1 = new D();

   D e = new E(3);
   assert(cast(int)e.f() == 2);
   assert(c2 is c2, "Identity is broken ?");
   assert((cast(D)c3), "Dynamic cast not working");
   assert(!(cast(E)c2), "Dynamic cast not working");
   assert((cast(C)b1), "Dynamic cast not working");

   return c1.i + c2.i + c3.i;
}
static assert(testClassStuff == 1 + 2 + 3);
// the second static assert used to fail, because of stale vtbl 
pointers.
static assert(testClassStuff == 1 + 2 + 3);
static assert(testClassStuff == 1 + 2 + 3);

--

Cheers,

Stefan
Jan 26 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Jan 26, 2019 at 09:52:58PM +0000, Stefan Koch via Digitalmars-d wrote:

 On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:

 [ ... ]


 
 Another small update: I've just fixed problems with class-constructor
 and vtbl handling.


[...]

Good to hear progress is still happening!  Still looking forward to
newCTFE landing in master, whenever that will be.


T

-- 
Never criticize a man until you've walked a mile in his shoes. Then when
you do criticize him, you'll be a mile away and he won't have his shoes.
Jan 28 2019
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Monday, 28 January 2019 at 17:35:12 UTC, H. S. Teoh wrote:

 On Sat, Jan 26, 2019 at 09:52:58PM +0000, Stefan Koch via 
 Digitalmars-d wrote:

 On Sunday, 13 January 2019 at 14:47:59 UTC, Stefan Koch wrote:

 [ ... ]


 
 Another small update: I've just fixed problems with 
 class-constructor and vtbl handling.


 [...]

 Good to hear progress is still happening!  Still looking 
 forward to newCTFE landing in master, whenever that will be.


 T


I am proud to announce that the class-layout seems to work so far.

alias twice = long; alias once = int;
class B {once more = 0x123; twice the_fun = 0xFFF;}

class C : B
{
   int a = 12; int b = 13; int c = 14;

   final int[5] toArray()
   {
     int[5] arr;
     arr = [a, b, c, cast(int) more, cast(int) the_fun];
     return arr;
   }

}

immutable int[5] expectedData = [12, 13, 14, 0x123, 0xFFF];

auto testLayout()
{
     auto c = new C();
     // currently default ctors don't work
     // therefore we need to do this by hand
     c.a = 12; c.b = 13; c.c = 14;
     c.the_fun = 0xFFF;
     c.more = 0x123;

     return c.toArray;
}

static assert (() { return testLayout() == expectedData; } ());
// passes
Jan 30 2019