Re: optimizer data structures, was alternatives to Java byte-codes

Bernd Schoeller <Bernd.Schoeller@ks.sel.alcatel.de>
15 Feb 1999 23:33:54 -0500

          From comp.compilers

Related articles
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: optimizer data structures, was alternatives to Java byte-codes Bernd.Schoeller@ks.sel.alcatel.de (Bernd Schoeller) (1999-02-15)
| List of all articles for this month |

From: Bernd Schoeller <Bernd.Schoeller@ks.sel.alcatel.de>
Newsgroups: comp.compilers
Date: 15 Feb 1999 23:33:54 -0500
Organization: Alcatel SEL AG Stuttgart
References: 99-02-023 99-02-029
Keywords: optimize

Thomas Kistler <kistler@ics.uci.edu> writes:


> jerpat@iastate.edu (Jeremiah S Patterson) wrote:
> > AST's are typically hard to optimize
> > because (at least this is my experience) it is difficult to come up
> > with general optimizations that are not trivial. Byte codes, on the
> > other hand, provide a linear (step-by-step) structure rather than a
> > tree structure which makes it easy to define "atomic" sections of code
> > and optimize those sections.
>
> I strongly have to object.
> [a lot of good reasons deleted]


Yes - this is correct. It is really much harder to optimize a linear
stream of commands than to optimize a tree like syntax structure. Also
security checks are much easier because the scope of variables and
other structures is clearer.


If you are looking for a _very interesting_ approach towards producing
protable code have a look at "Slim Binaries" (I don't know the
homepage, but you might look at Altavista for "Slim Binaries",
"Oberon" and/or "Juice" -- actually the paper is rather old).


IMHO Java Bytecode is _the_ weak point of the Java concept. Not only
is it slow and clumsy, but also downloading-times are quite large.


Slim Binaries store compressed parsing trees. These parsing trees are
- after download - given to a fast Just-In-Time compiler (well actualy
just the compiler-backend, cause there is nothing to parse). The
actual size of the slim binaries is less than 386-Code that ran
through the LZH compression alogrithm.


Slim Binaries have already proven themselves in two applications:
First there is a plugin for Netscape/IE that enables you to download
"Juice" (the Slim Binary appletformat) applets and integrate them into
your web-page, just like java-applets. Second some versions of the
Oberon Operating System are running completly under slim binaries. So
the same oberon system runs _natively_ on the old 680x0 and the new
PowerPC Macs.


MfG,
Bernd
--
Bernd Schoeller +49-711-821-43416 Alcatel SEL Stuttgart
Software Developer -- Novedia Berlin Dept.: US/EE Room: 60/1/29
schoelle@lts.sel.alcatel.de Lorenzstrasse 10 / D-70435 Stuttgart


Post a followup to this message

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