|Re: compiling C to Forth firstname.lastname@example.org (1991-12-09)|
|From:||email@example.com (Philip Koopman)|
|Summary:||It's difficult without extending Forth|
|Organization:||School of Computer Science, Carnegie Mellon|
|Date:||Mon, 09 Dec 91 13:49:54 GMT|
> Several posts in comp.lang.forth discuss C to Forth compilation
I actually wrote a back-end for GNU C that compiled to a Forth-based CPU
(the RTX 2000 from Harris). Before I get inundated with requests, it was
proprietary, and I no longer have the code (I destroyed my copies when I
left Harris). The hard part was that most current compilers assume a
register-based back end.
Here are some thoughts from my experience:
- Most Forths don't have a suitable mechanism to implement the C automatic
variable area (frame pointer area). Putting them on the Forth data stack
gets in the way of passing parameters in and out of procedures in the
traditional Forth manner. This is an especially difficult problem on a
stack-CPU that doesn't allow pointers into the data stack.
- Optimization of stack usage is difficult. Even with stack-scheduling it
is difficult to keep much data "live" on the stack. Note that global
analysis is complicated by the requirement of balancing stack depth at
branch targets. Literature in this area seems essentially non-existent.
- There are some subtle implementation differences to watch out for (Forth
83 and later uses -1 for a true flag, C uses 1).
- The existing C to Forth compiler for the RTX 2000 (really C to RTX
assembly language, which is a superset of Forth primitives) produces awful
code, mostly because it is a 1-pass compiler. A peephole optimizer helps
some, but one really needs to do extensive global analysis to make much
Phil Koopman firstname.lastname@example.org
United Technologies Research Center (203) 727-1624
411 Silver Lane East Hartford, CT 06108
Return to the
Search the comp.compilers archives again.