www.digitalmars.com         C & C++   DMDScript  

D.gnu - Runtime CG (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.

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.

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

Jan 14 2003