newCTFE Status July 2017

Stefan Koch via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 13 05:45:19 PDT 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.



More information about the Digitalmars-d mailing list