Related articles |
---|
Compiling C for stack engines koopman+@cs.cmu.edu (1992-05-28) |
Re: Compiling C for stack engines pazsan@Informatik.TU-Muenchen.DE (1992-06-01) |
Re: Compiling C for stack engines watt@osf.org (1992-06-03) |
Newsgroups: | comp.lang.forth,comp.compilers |
From: | pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan) |
Originator: | pazsan@hphalle6f.informatik.tu-muenchen.de |
Keywords: | C, forth, optimize |
Organization: | Technische Universitaet Muenchen, Germany |
References: | 92-05-152 |
Date: | Mon, 1 Jun 1992 17:57:38 GMT |
I think it isn't very difficult to implement a C->Forth compiler. C has
three types of variables: Global (this is trivial to convert), local and
invisible during term evaluation. Term evaluation is certainly done on a
push and pop stack. Locals are a higher level, because you can't declare
locals within a term. So if you shot the stack of C while it is working,
you will look at something like this:
low addresss
---------------------------------------
Some Stack Entries for term evaluation
---------------------------------------
Locals
the old frame pointer
calling parameters
---------------------------------------
locals of the caller
Other than Forth, the stack effects of terms are defined. A C statement
has NO stack effect. This is why you have to add the word VOID if you
don't want the result of a term (VOID is the equivalent for DROP in this
case). As you always know, how many temporaries you have on the stack, you
can PICK the locals and the parameters, thus you don't need a frame
pointer. I think, we should add another stack word, that stores the value
on the TOS into a local. I call this PIN ( x1 .. xn x n -- x .. xn ), so
<n> PICK <n> PIN is a noop; 0 PIN is a DROP.
--
Bernd Paysan
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.