On Thursday, 30 June 2016 at 03:17:38 UTC, Stefan Koch wrote:
> Until then you can see my progress at https://github.com/UplinkCoder/dmd/tree/newCTFE
> I will try to always keep the branch in a healthy state.

I can't wait to see the benchmarks.

Keep up the good work!

On 06/30/2016 05:17 AM, Stefan Koch wrote:
> Both. Actually I could not imagine fixing the memory problem without
> doing IR interpretation.
> I will tackle compiling more difficult code later today.
> As soon as I can run my compiletime brainfuck I will open a PR.
> 
> Until then you can see my progress at
> https://github.com/UplinkCoder/dmd/tree/newCTFE
> I will try to always keep the branch in a healthy state.

Looks good and will definitely lead to a proper CTFE interpreter.

You might want to go back and look at https://github.com/MartinNowak/dmd/blob/28ffb0ab4fa6950f60c085f33f8a2ce23df7c0cd/src/interpret.c, it could already do a few more things than your interpreter atm.

[¹]: https://github.com/MartinNowak/dmd/commits/ctfe

On Thursday, 30 June 2016 at 07:15:30 UTC, Nordlöw wrote:
> On Thursday, 30 June 2016 at 03:17:38 UTC, Stefan Koch wrote:
>> Until then you can see my progress at https://github.com/UplinkCoder/dmd/tree/newCTFE
>> I will try to always keep the branch in a healthy state.
>
> I can't wait to see the benchmarks.
>
> Keep up the good work!

Currently the interpreter is about 10x-15x slower then native execution.
and about 2x-4000x faster then the old Interpreter :)

code I can currently compile :

uint test2(int x) {
	uint r = 0;
	const uint end = 9;
	for(int i = 0;i < end;++i) {
		for(int j = 0;j < 9;++j) {
			r += j;
			r += i;
		}
	}

	return r;
}

dmd's interpreter and mine return the same value :)

On 08.06.2016 03:20, Stefan Koch wrote:
> On Friday, 3 June 2016 at 15:46:27 UTC, Stefan Koch wrote:
>> On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
>>
>>> I will post more details as soon as I dive deeper into the code.
>>
>> Okay I briefly evaluated the current IR dmd uses for backend
>> communication, and it seems usable for the purposes of a
>> CTFE-Interpreter/JIT.
>>
>> The Memory-Management issue is mostly orthogonal to CTFE.
>> But nonetheless very important.
>
> I have to admit currently I am a bit stuck.
>
> @Timon Gehr cooperation would be highly appreciated.
>

Sorry, I had missed this. I see you were able to make progress.

On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote:
>
> Sorry, I had missed this. I see you were able to make progress.

It's fine.
Honestly the hardest thing was to actually get started.

Once I see something working the excitement carries me forward :)

I would appreciate a critical opinion, anytime!

On Thursday, 30 June 2016 at 14:26:29 UTC, Stefan Koch wrote:
> On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote:
>>
>> Sorry, I had missed this. I see you were able to make progress.
>
> It's fine.
> Honestly the hardest thing was to actually get started.
>
> Once I see something working the excitement carries me forward :)
>
> I would appreciate a critical opinion, anytime!

Another update.
_very_ Basic SwtichStatements work now :)

I expect a simple project like a compile-time bf interpreter to work by the end of next week.

On Monday, 4 July 2016 at 01:54:29 UTC, Stefan Koch wrote:
> On Thursday, 30 June 2016 at 14:26:29 UTC, Stefan Koch wrote:
>> On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote:
>>>
>>> Sorry, I had missed this. I see you were able to make progress.
>>
>> It's fine.
>> Honestly the hardest thing was to actually get started.
>>
>> Once I see something working the excitement carries me forward :)
>>
>> I would appreciate a critical opinion, anytime!
>
> Another update.
> _very_ Basic SwtichStatements work now :)
>
> I expect a simple project like a compile-time bf interpreter to work by the end of next week.

Nice work! Any chance that you could also improve AliasSeq algorithms, like those in std.meta to compile faster and use less memory during compilation? Or is that too different from CTFE?

On Monday, 4 July 2016 at 07:29:49 UTC, ZombineDev wrote:
> On Monday, 4 July 2016 at 01:54:29 UTC, Stefan Koch wrote:
>> On Thursday, 30 June 2016 at 14:26:29 UTC, Stefan Koch wrote:
>>> On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote:
>>>>
>>>> Sorry, I had missed this. I see you were able to make progress.
>>>
>>> It's fine.
>>> Honestly the hardest thing was to actually get started.
>>>
>>> Once I see something working the excitement carries me forward :)
>>>
>>> I would appreciate a critical opinion, anytime!
>>
>> Another update.
>> _very_ Basic SwtichStatements work now :)
>>
>> I expect a simple project like a compile-time bf interpreter to work by the end of next week.
>
> Nice work! Any chance that you could also improve AliasSeq algorithms, like those in std.meta to compile faster and use less memory during compilation? Or is that too different from CTFE?

BTW, do you plan to handle stuff like exceptions, virtual calls and associative arrays and if so how? Sounds quite challenging.

On Monday, 4 July 2016 at 07:33:48 UTC, ZombineDev wrote:
> On Monday, 4 July 2016 at 07:29:49 UTC, ZombineDev wrote:
>> Nice work! Any chance that you could also improve AliasSeq algorithms, like those in std.meta to compile faster and use less memory during compilation? Or is that too different from CTFE?
>
> BTW, do you plan to handle stuff like exceptions, virtual calls and associative arrays and if so how? Sounds quite challenging.

Templates do interact with CTFE.
They will improve as well as a consequence of CTFE being less wasteful.

I will do it bit by bit.
For now getting a simple parser to work with the new engine is the goal.
Everything else comes later.

so, we played a little game with Stefan: i wrote a simple stack-based VM implementation for our beloved bug6498, and got 270 msecs with debug build, 140 msecs with release build. can be made even faster with some simple peephole optimizer (it has two hacks to get fair times on 6498, but this is not a good peephole opt ;-). of course, it scales linearly too.

don't expect me to join the race, though: i was just curious how well stack-based VM can do.