• Ilya Minkov (55/55) Jan 14 2003 Burton,

Ilya Minkov <midiclub 8ung.at> writes:

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.