|[2 earlier articles]|
|Re: alternatives to java byte-codes email@example.com (Niall Dalton) (1999-02-01)|
|Re: alternatives to java byte-codes dgay@barnowl.CS.Berkeley.EDU (David Gay) (1999-02-03)|
|Re: alternatives to Java byte-codes firstname.lastname@example.org (1999-02-05)|
|Re: alternatives to Java byte-codes email@example.com (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 firstname.lastname@example.org (Jesus Cea Avion) (1999-02-10)|
|Re: alternatives to java byte-codes email@example.com (Niall Dalton) (1999-02-12)|
|Re: alternatives to java byte-codes firstname.lastname@example.org (David Chase) (1999-02-15)|
|From:||Niall Dalton <email@example.com>|
|Date:||12 Feb 1999 02:52:39 -0500|
|Organization:||University College Cork, Ireland|
|References:||99-01-096 99-02-006 99-02-009|
David Gay wrote:
> Hmm, I thought most optimising compilers went for variations on
> 3-address code and a control-flow graph. How many compilers use an
> abstract syntax tree for optimisation ?
At least 2:)
Franz's Phd introduced the use of semantic dictionary encoding(SDE) as a
way of avoiding problems in compilation due to the use of abstract
machines. In an elementry form, the dictionary entries repesent nodes in
a DAG, that describes the actions of the program, as an anstract syntax
treee in tabular form. A true SDE also describes generic characteristics
of potential nodes that might appear in the tree. SDEs can also contain
information that is not explicitly present in the source code of the
program. This was used to build a compiler for Oberon.
Kistler and Franz also did some work on "Slim Binary" implementations of
Java, where the Slim binary is based on abstract syntax trees.
> My gut feeling is that trees
> make some transfor- mations harder, especially if the tree is close to
> the language's source code.
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.
> Compiling from Java bytecodes has its problems (e.g. the jsrs), but
> these aren't really related to the basic decision to use bytecodes.
But there is usually a need to regenerate another representation of the
code. For example, a flow graph to do some optimizations, see Bik and
Gannon "javab - a prototype bytecode parallelization tool".
Return to the
Search the comp.compilers archives again.