Re: Is there any generator generator, not parser generator?

David Chase <chase@world.std.com>
17 Oct 1998 01:41:08 -0400

          From comp.compilers

Related articles
Is there any generator generator, not parser generator? baehj@oz.co.kr (Bae, Hyun-jik) (1998-10-13)
Re: Is there any generator generator, not parser generator? chase@world.std.com (David Chase) (1998-10-17)
Re: Is there any generator generator, not parser generator? dwight@pentasoft.com (1998-10-17)
Is there any generator generator, not parser generator? KPRASAD@us.oracle.com (KPRASAD.US.ORACLE.COM) (1998-10-17)
Re: Is there any generator generator, not parser generator? assmann@ipd.info.uni-karlsruhe.de (Uwe Assmann) (1998-10-17)
Re: Is there any generator generator, not parser generator? anton@mips.complang.tuwien.ac.at (1998-10-18)
Re: Is there any generator generator, not parser generator? chase@world.std.com (David Chase) (1998-10-21)
| List of all articles for this month |

From: David Chase <chase@world.std.com>
Newsgroups: comp.compilers
Date: 17 Oct 1998 01:41:08 -0400
Organization: Compilers Central
Keywords: code, tools

> Is there a code generator generator?


Sort of. I've used a couple over the years, and looked at LCC (which
uses one) but the general problem is that they don't solve all the
problems of code generation, and the other problem solutions mesh
somewhat imperfectly. If you are willing to live with
acceptable-to-mediocre code quality, you can probably get by with a
combination of tree pattern- matching and sethi-ullman numbering (that
is, you could build a tool that would incorporate these two things).
The resulting code would lack the low-level optimizations usually
associated with register allocation, instruction scheduling, and
peephole optimization (though tree pattern-matching does a decent job
of that from the get-go). There are other ways to approach this; on a
machine with many registers (i.e., not x86) you could pessimistically
pre-allocate registers; during pattern- matching you'd discover that
you weren't using those registers after all, but you might do well
enough anyway. You could perform some amount of "semantic"
scheduling/pipelining, in which you simply assumed that each abstract
operation had a latency associated with it, and work from that; I've
done things like this in the past, and it generally helps performance.


But, note that I am not describing a tool, I am describing an approach
towards using or augmenting an incomplete tool.


That said, you could look at LCC, or you could look at "iburg" or
"jburg", not sure where those are on the net nowadays.


David Chase
NaturalBridge LLC


Post a followup to this message

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