How about a 100% CTFE?

[Don]

On 07.11.2011 19:59, Martin Nowak wrote:
> On Mon, 07 Nov 2011 17:49:30 +0100, Don <nospam at nospam.com> wrote:
>
>> On 07.11.2011 14:13, Gor Gyolchanyan wrote:
>>> After reading
>>>
>>> http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
>>> https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
>>>
>>> I had a thought:
>>> Why not compile and run CTFE code in a separate executable, write it's
>>> output into a file, read that file and include it's contents into the
>>> object file being compiled?
>>> This would cover 100% of D in CTFE, including external function calls
>>> and classes;
>>> String mixins would simply repeat the process of compiling and running
>>> an extra temporary executable.
>>>
>>> This would open up immense opportunities for such things as
>>> library-based build systems and tons of unprecedented stuff, that I
>>> can't imagine ATM.
>>
>> First comment: classes and exceptions now work in dmd git. The
>> remaining limitations on CTFE are intentional.
>>
>> With what you propose:
>> Cross compilation is a _big_ problem. It is not always true that the
>> source CPU is the same as the target CPU. The most trivial example,
>> which applies already for DMD 64bit, is size_t.sizeof. Conditional
>> compilation can magnify these differences. Different CPUs don't just
>> need different backend code generation; they may be quite different in
>> the semantic pass. I'm not sure that this is solvable.
>>
>> version(ARM)
>> {
>> immutable X = armSpecificCode(); // you want to run this on an X86???
>> }
>>
>
> I've always thought that it would be worthwhile to experiment with
> LLVM's JIT engine here.
> But as has been said quite some care will be necessary for cross
> compilation.
> Allowing arbitrary non-pure functions would cause lots troubles.

Yeah, I think JIT for CTFE would be *very* interesting. But mainly for 
reasons of speed rather than functionality.