D.gnu - Runtime CG (Burton!)
- Ilya Minkov (55/55) Jan 14 2003 Burton,
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.
Jan 14 2003