Compiling to Heap for CTFE

[BC]

On Tue, 18 Dec 2007 20:59:48 -0000, Bruce Adams  
<tortoise_74 at yeah.who.co.uk> wrote:

> 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.

maybe a x86 emulator could be used instead... just a thought