Burton,
as far as i understood you've been planning to use the linux D compiler you write for runtime code generation (ie as a library). I'm sorry to say this now... as it might be a bit late... but i've become aware of D only recently... but what i wanted to say that it might make sense to write a backend/VM based on GNU Lightning or alike.

http://www.gnu.org/software/lightning/
---CUT BEGIN---
GNU lightning is a library that generates assembly language code at run-time; it is very fast, making it ideal for Just-In-Time compilers, and it abstracts over the target CPU, as it exposes to the clients a standardized RISC instruction set inspired by the MIPS and SPARC chips.
---CUT END---

And VCode is just about the same, just that Lightning works for x86 well, and is half-broken on other systems, and VCode works perfectly on all riscs, but no official port to x86 exists, and the one i was able to find is half-broken. The aithors claim that it has to be possible to design a x86 back-end though.

VCode has been used in Tick C Compiler, TCC. "'C" Tick C is a language to write self-regenerating C code. :)
(which does not imply that it likes being cut and pasted) :>
TCC is based upon LCC.

GNU Lightning appears to have been used in GNU Smalltalk.


Both represent a set of risc-look-alike C macros (or sometimes functions), each of which generates a machine code for the target machine emulating the corresponding risc instruction. The machine code is accumulated in a buffer. Actually the command set is designed such, that it transforms into x86 code without too many perversities.

Though I haven't looked further into it, it should be possible to use this buffer, say, to generate object files. I'm planning to write a peephole optimiser for Lightning's x86 backend, so that the code makes a bit more sense. But i can't promise.

The advantage of moving to such a system would be:
 - easy porting to further systems, most of this work already done;
(i appear to know a girl which has a ton of SPARCs at home :> )
 - still stays lightweight, unlike the gcc monster (*PAIN*!!!);
 - can be split somewhere in the middle to create a cross-platform VM.

Disadvanteges:
 - it is work to do, noone knows whether anyone besides me wants it;
 - implementation of "asm" keyword would make it heavier;
 - "asm" would still be system-specific, since VCode relies upon the endianness of the target device, as well as on register count and usage.
(i suppose Lightning should be similar)
(not a real disadvantage, and could be fixed somehow in a good manner)

I was considering to write such a back-end myself. But I also think your back-end might give me a starting point.

Besides, are you aware of LCC-Win32? The documents accompanying it describe the Win32 port author's efforts in writing an x86 optimiser for LCC, and he was able to reach most of the speed of GCC.
http://www.cs.virginia.edu/~lcc-win32/
It is closed-source though and thus not further interesting.

I'd join in and help somehow out, but i'm pretty much sacked in and i doubt i'll have time during the next month or two. But i'd really like to be of any use.

-i.