Re: Language for byte-code-compiling?

Christopher Zach <cmzach@sztma.tu-graz.ac.at> writes:
|> I am working on a compiler (translator) project for my own programming
|> language, and I want to split the compiler into a front end (language ->
|> byte code) and a back end (byte-code -> C, Asm or interpreted). I would
|> like to know a good idea for the intermediate language, which should be
|> easy to translate into C with good optimization.
|>
|> Usual stack languages (e.g. Emacs Lisp byte code compiler) are easy, but I
|> think it is rather difficult to translate the byte code to C with good
|> optimization (because C is not a postfix language).


If you want to translate to C, I would leave the optimization to the C
compiler. Translating from postfix code to efficient C is easy: You have a
number of variables where you keep the stack items, say s0, s1, .... And
you have C templates for all postfix code instructions, e.g., for "+":


{ Item x = Stack(0)+Stack(1); Pop(1); Stack(0)=x; }


for "swap":


{ Item x = Stack(0); Item y=Stack(1); Stack(0)=x; Stack(1)=y; }


Now your backend just has to replace the Stack(.) in the templates with
the variables and has to keep track of what variable represents what stack
position. E.g., compiling "+ swap", starting with the following
correspondence between stack locations and variables:


/* Stack(0)=s3; Stack(1)=s2; Stack(2)=s1; ... */
{ Item x = s3+s2; s2=x; }
/* Stack(0)=s2; Stack(1)=s1; Stack(2)=s0; Courtesy of Pop(1) */
{ Item x = s2; Item y=s1; s2=x; s1=y; }
/* Stack(0)=s2; Stack(1)=s1; Stack(2)=s0; */


The register allocator and the copy elimination of the C compiler will see
to it that the executable code will be efficient. Unless your front end
generates unbalanced code, you do not have to worry about implementing a
real stack (i.e. one with a stack pointer at run-time).


- anton
--
M. Anton Ertl anton@mips.complang.tuwien.ac.at
--

Return to the comp.compilers page.
Search the comp.compilers archives again.