Re: UNCOL = Uncool? (Anton Ertl)
31 Oct 2000 14:41:00 -0500

          From comp.compilers

Related articles
[6 earlier articles]
Re: UNCOL = Uncool? (Chris F Clark) (2000-10-23)
Re: UNCOL = Uncool? (2000-10-26)
Re: UNCOL = Uncool? (2000-10-26)
Re: UNCOL = Uncool? (Pred.) (2000-10-26)
Re: UNCOL = Uncool? (2000-10-26)
Re: UNCOL = Uncool? (Chris F Clark) (2000-10-31)
Re: UNCOL = Uncool? (2000-10-31)
Re: UNCOL = Uncool? (2000-11-04)
| List of all articles for this month |

From: (Anton Ertl)
Newsgroups: comp.compilers
Date: 31 Oct 2000 14:41:00 -0500
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 00-10-139 00-10-173
Keywords: UNCOL
Posted-Date: 31 Oct 2000 14:41:00 EST (VBDis) writes:
>"SRS" <> schreibt:
>>[Given the uniform failure of all previous UNCOL attempts, I'd be pretty
>>sceptical. I agree it's possible if you limit the source languages and
>>targets enough, but then it's usually not very interesting, either. -John]
>Some source languages really cannot be mapped to other models, with
>regards to code creation. I only know Forth and Lisp as concrete
>languages, which are incompatible with e.g. C,

Well, you can translate a subset of Forth into efficient C without too
much effort (see [ertl&maierhofer95]), so Forth is not fundamentally
incompatible with C. However, C is missing some features, in
particular run-time code generation, that are required for a
full-blown Forth system; there exists `C (C extended with run-time
code generation), but it is unclear whether the run-time code
generator of tcc (the `C compiler) would produce decent code given the
translation schemes we used (which rely heavily on a copy propagating
compiler), and whether it is fast enough to satisfy the expectations
of Forth users. Similar issues are probably involved with Lisp.

However, for many languages there are also large idiomatic differences
between these languages and C, and a C compiler will probably not
optimize well what comes out of a straightforward translation of the
other language. E.g., Forth code has a much higher call frequency
than C (every third or fourth operation is a call or return); Lisp
code has a higher call frequency, frequent tail-calls, and run-time
type checking. Other people have mentioned exception handling as a
frequent troublemaker. If these issues are addressed in the
front-end, the front end becomes complicated, and a part of the UNCOL
appeal is lost. OTOH, addressing them in the generic optimizer seems
hard to do.

    author = {M. Anton Ertl and Martin Maierhofer},
    title = {Translating Forth to Efficient C},
    crossref = {euroforth95},
    url = {},
    abstract = {An automatic translator can translate Forth into C
                                    code which the current generation of optimizing C
                                    compilers compiles to efficient machine code. I.e.,
                                    the resulting code keeps stack items in registers
                                    and rarely updates the stack pointer. This paper
                                    presents a simple translation method that produces
                                    efficient C code, describes an implementation of the
                                    method and presents results achieved with this
                                    implementation: The translated code is 4.5--7.5
                                    times faster than Gforth (the fastest measured
                                    interpretive system), 1.3--3 times faster than
                                    BigForth 386 (a native code compiler), and smaller
                                    than Gforth's threaded code.}

    title = "EuroForth~'95 Conference Proceedings",
    booktitle = "EuroForth~'95 Conference Proceedings",
    year = "1995",
    key = "EuroForth '95",
    address = "Schloss Dagstuhl, Germany",

- anton
M. Anton Ertl Some things have to be seen to be believed Most things have to be believed to be seen

Post a followup to this message

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