Related articles |
---|
[3 earlier articles] |
Re: alternatives to java byte-codes dgay@barnowl.CS.Berkeley.EDU (David Gay) (1999-02-03) |
Re: alternatives to Java byte-codes jerpat@iastate.edu (1999-02-05) |
Re: alternatives to Java byte-codes kistler@ics.uci.edu (Thomas Kistler) (1999-02-07) |
Re: alternatives to Java byte-codes Paulo@PlanetSmart.com (Paulo Machado) (1999-02-10) |
Re: alternatives to java byte-codes jcea@argo.es (Jesus Cea Avion) (1999-02-10) |
Re: alternatives to java byte-codes niall@cuc.ucc.ie (Niall Dalton) (1999-02-12) |
Re: alternatives to java byte-codes chase@world.std.com (David Chase) (1999-02-15) |
From: | David Chase <chase@world.std.com> |
Newsgroups: | comp.compilers |
Date: | 15 Feb 1999 23:25:10 -0500 |
Organization: | NaturalBridge, LLC |
References: | 99-01-096 99-02-006 99-02-009 99-02-053 |
Keywords: | optimize |
X-Accept-Language: | en |
> David Gay wrote:
> > My gut feeling is that trees
> > make some transfor- mations harder, especially if the tree is close to
> > the language's source code.
Niall Dalton wrote:
> Well, trees in general are common in compilers, for example expression
> trees as an internal representation for functional languages and you may
> generate locally optimal code using Sethi-Ullman numbers from an
> appropiate tree representation of a program.
Yes, but. What I have seen over the years is that the syntactically
supplied trees are not necessarily the ones that you want to use. For
instance, in the case of C, C++, and Java, the use of expression
operators and comma operators gunks up your syntax trees with ordering
constraints, and they may not even be the largest possible trees. It
is a relatively simple exercise (well, I thought it was simple) to
walk the instructions of a basic block and construct a
largest-possible true expression tree before doing your Sethi-Ullman
numbering.
David Chase
NaturalBridge LLC
Return to the
comp.compilers page.
Search the
comp.compilers archives again.