Re: alternatives to java byte-codes

Niall Dalton <>
12 Feb 1999 02:52:39 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: alternatives to java byte-codes (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 (1999-02-05)
Re: alternatives to Java byte-codes (Thomas Kistler) (1999-02-07)
Re: alternatives to Java byte-codes (Paulo Machado) (1999-02-10)
Re: alternatives to java byte-codes (Jesus Cea Avion) (1999-02-10)
Re: alternatives to java byte-codes (Niall Dalton) (1999-02-12)
Re: alternatives to java byte-codes (David Chase) (1999-02-15)
| List of all articles for this month |

From: Niall Dalton <>
Newsgroups: comp.compilers
Date: 12 Feb 1999 02:52:39 -0500
Organization: University College Cork, Ireland
References: 99-01-096 99-02-006 99-02-009
Keywords: code

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


Post a followup to this message

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