newCTFE Status July 2017

Hi Guys,

It has been suggested that I open a new thread every month.
I am happy to do that as it will make documenting the progress in newCTFE easier.

Let me start with a funny error I just fixed :)
The following code :

static assert(() { return ulong(ushort.max | ulong(ushort.max) << 32); }() == 281470681808895LU);

resulted in the following error:

static assert  (*function () => 281470681808895LU)() == 281470681808895LU is false

Because the value was : 65535UL.
Which is the value when truncated to 32bit.
The reason for this was that the interpreter was initially built for 32bit.
On the switch-over to 64bit support I added the ability to work with 64bit values.
However since I did not want to bloat the instructions beyond 64bit;
An 64bit Immediate Set (which is equivalent to a movq) is encoded in two instructions:

Set(lhs, imm32(imm64Value & uint.max));
SetHigh(lhs, imm32(imm64Value >> 32));

However I did forget to issue the SetHigh.
Which resulted in the observed behavior.


Funnily enough I found this issue because I suspected an ABI in how ulong and long struct members are handeld.
And sure enough on top of the above described bug there was an abi bug as well.
which is now fixed as well.

While theses bugs are lurking the development of the ctfe-debugger is impeded.

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote: > [ ... ] Hi Guys, I've just added stack-map support to my debug output Although this is purely internal, I am proud enough of the improvement to post it. The following is Bytecode part of a foreach-loop. Printout without stackMap 290: Line #21 292: Set SP[208], #0 294: Set SP[212], SP[20] 296: Lt SP[208, SP[212] 298: Flg SP[216] 300: JmpZ SP[216, &358 302: Set SP[220, SP[208] 304: Line #23 Prinout with stackMap: 290: Line #21 292: Set __key64, #0 294: Set __limit65, resultLength 296: Lt __key64, __limit65 298: Flg SP[216] 300: JmpZ SP[216], &358 302: Set i, __key64 304: Line #23 I really wish I had added the stackMap 6 months ago :) I really don't miss the heaps of paper handwritten address to name translation tables. Cheers, Stefan

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote: > [ ... ] Hi Guys, fresh ABI bugs! Even with my improved debugging facilities they are still a pain in the neck. see for yourself : https://www.youtube.com/watch?v=eX93aWDmiqE

On Saturday, 15 July 2017 at 07:50:28 UTC, Dmitry wrote: > On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote: >> ... > > Hi. Have you any public roadmap (or somethilng like this) of newCTFE? > Will be useful to see what planned, what finished, etc. All I have are the CTFE status threads, where one can see what I consider a working feature set. What is planed is simple to state: "Re-implement the full functionality of the current ctfe-interpreter in the new IR-based system" It is hard for me to say in advance which features will be working, or indeed regress next. Since the interactions between features form a complex system which by definition is very hard to predict. My current goal is to make complex structs work. Meaning structs with other structs inside it. For example struct SimpleStruct { float c; uint a; ulong b; } struct complexStruct { SimpleStruct[2] a; complexStruct* next; } The complex struct will currently produce a vaild IR type. But will generate invalid code, since the ABI is currently in the process of changing. And different parts of the code will interpret the data differently. On top of that I have to rebuild a few of the expression handling routines to switch from the old reference based ABI to the new hybrid ABI.

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote: > [ ... ] I fixed my struct ABI issues for now. The problem was the lowering of the IR types. Since before everything was expressible as pointer, it was fine to convert everything to integers and treat them as pointer. Since structs treated are value-types now we can no longer just point to them. However due to the premature conversion we would stick random intgeres with the pointer values inside the struct. This is what should happen: *(cast (struct_t*)targetMemory) = *(cast(struct_t*) sourceMemory); And this is what actually did happen: *(cast(size_t*) targetMemory) = cast(size_t) sourceMemory; Due to bizarre coincidences this wrong behavior would actually pass a few tests which were supposed to catch this mistake :) long story short. This bug is now fixed. I am assuming that there are still a few issues with arrayLiterals. But I will fix those another day. I am spent. Have a nice day, Stefan.

On Saturday, 15 July 2017 at 09:02:02 UTC, Stefan Koch wrote: > On Saturday, 15 July 2017 at 07:50:28 UTC, Dmitry wrote: >> ... > > All I have are the CTFE status threads, where one can see what I consider a working feature set. > What is planed is simple to state: "Re-implement the full functionality of the current ctfe-interpreter in the new IR-based system" > > It is hard for me to say in advance which features will be working, or indeed regress next. > Since the interactions between features form a complex system which by definition is very hard to predict. > > ... It would indeed be nice to have a GitHub issue (or similar) with progress checkboxes of what works, what's in progress, and what is yet to be done.

On Saturday, 15 July 2017 at 11:31:30 UTC, Tourist wrote: > On Saturday, 15 July 2017 at 09:02:02 UTC, Stefan Koch wrote: >> On Saturday, 15 July 2017 at 07:50:28 UTC, Dmitry wrote: >>> ... >> > > It would indeed be nice to have a GitHub issue (or similar) with progress checkboxes of what works, what's in progress, and what is yet to be done. here is the current newCTFE test. /UplinkCoder/dmd/blob/newCTFE_on_master/test/compilable/ctfeTest.d Eveything in there is supported by newCTFE . Modulo regressions.

On Saturday, 15 July 2017 at 17:43:04 UTC, Stefan Koch wrote: > On Saturday, 15 July 2017 at 11:31:30 UTC, Tourist wrote: >> On Saturday, 15 July 2017 at 09:02:02 UTC, Stefan Koch wrote: >>> On Saturday, 15 July 2017 at 07:50:28 UTC, Dmitry wrote: >>>> ... >>> >> >> It would indeed be nice to have a GitHub issue (or similar) with progress checkboxes of what works, what's in progress, and what is yet to be done. > > here is the current newCTFE test. > /UplinkCoder/dmd/blob/newCTFE_on_master/test/compilable/ctfeTest.d > Eveything in there is supported by newCTFE . Modulo regressions. Nice, but it's not as clear, and doesn't specify what's left to be done.

On Saturday, 15 July 2017 at 21:35:30 UTC, Tourist wrote: > > Nice, but it's not as clear, and doesn't specify what's left to be done. features left to be done are: - && and || - multi-dimensional slices/arrays - associative arrays - complex structs - classes - unions - unicode support.

Forums