Compiling to Heap for CTFE
Bruce Adams
tortoise_74 at yeah.who.co.uk
Tue Dec 18 12:59:48 PST 2007
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.
More information about the Digitalmars-d
mailing list