Compiling to Heap for CTFE

[Bruce Adams]

On Tue, 18 Dec 2007 15:53:27 -0000, Chad J  
<gamerChad at _spamIsBad_gmail.com> wrote:

> Craig Black wrote:
>> Currently, CTFE only supports a subset of the language, and it relies  
>> on the compiler acting as an interpreter, which is slow.  It just  
>> occured to me that if we could compile code to the heap, there would be  
>> no need for a CTFE interpreter.  CTFE code could be compiled to the  
>> heap and executed at full speed.  Further, all the features of D would  
>> be available at compile time.
>>  Thoughts?
>>  -Craig
>
> In response to concerns about cross-compilation and security concerns:
>
> Perhaps if D had a VM then we could do it?  At compile time, compile all  
> of the CTFE code to bytecode, and interpret it.  The intrepreter would  
> be compiled by whatever is compiling the compiler, so it should make  
> cross-compiling easier.  Also, the VM and compiler can sandbox the CTFE  
> code.  Bytecode interpretation is not native speed execution, but  
> probably close enough, and this approach allows use of D's high level  
> features.
>
> Only problem is, that would be a lot of work.  It involves writing a D  
> backend for the bytecode, implementing security restrictions, and maybe  
> even implementing the VM itself (if we can't find a ready-made one).

It would complete the set to have a D front end to one a VM and to have a  
D compiler/front end in D.
There are plenty of VMs out there that may or may not be suitable. Its just
a different target. You'd need the front end to support cross compilation  
and it
would be nice to have a command line switch like gcc does.
I don't think I've seen a VM used as a target for gcc otherwise gdc would  
already
have most of the functionality needed. Probably because p-code and gcc  
itself is so
damned ugly inside. Someone should port it to D - and clean up the mess.  
It would
make a good community project but I guess porting is less satisfying than  
re-inventing
the wheel, especially when you have better constructs to work with from  
the start.

With regard to VMs to target apart from the obvious JVM and .NET/Mono  
(makes my unix bones
shudder in horror) there's also Neko which is supposedly designed to be  
ported to
http://nekovm.org/. But there is no reason why you couldn't port to your  
favourite language (tm)'s
VM with enough hard work. A D VM would be best able to exploit the  
language features but would
be a hell of a lot of work (albeit highly rewarding).

Bruce.