Re: alternatives to java byte-codes

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".


Regards,
niall

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