Re: Generating Java Bytecode

Stefan Heinzmann <>
24 Nov 1996 16:26:32 -0500

          From comp.compilers

Related articles
[12 earlier articles]
Re: Generating Java Bytecode (Bruce Stephens) (1996-11-21)
Re: Generating Java Bytecode (1996-11-21)
Re: Generating Java Bytecode kuznetso@MIT.EDU (1996-11-21)
Re: Generating Java Bytecode (Bill Mangione-Smith) (1996-11-21)
Re: Generating Java Bytecode (1996-11-21)
Re: Generating Java Bytecode (Andrew Lynch) (1996-11-24)
Re: Generating Java Bytecode (Stefan Heinzmann) (1996-11-24)
Re: Generating Java Bytecode (1996-11-26)
Re: Generating Java Bytecode (1996-11-26)
Re: Generating Java Bytecode (Nor Jaidi) (1996-11-26)
Re: Generating Java Bytecode (1996-12-01)
Re: Generating Java Bytecode (1996-12-01)
Re: Generating Java Bytecode (Jeremy Greene) (1996-12-01)
[3 later articles]
| List of all articles for this month |

From: Stefan Heinzmann <>
Newsgroups: comp.compilers
Date: 24 Nov 1996 16:26:32 -0500
Organization: Compilers Central
References: 96-11-108 96-11-121 96-11-134
Keywords: Java, UNCOL

The moderater groused:
> [Before you head down this path, you really should look at the
> history and learn why all the previous UNCOL projects failed. They
> all looked great with one or two input languages and targets, then
> collapsed of heat death when they tried to generalize more. -John]

Bruce Stephens wrote:
> Has this happened to ANDF yet? ANDF strikes me (as an idea; I have no
> experience of it in practice) as a Good Thing, because it keeps lots
> of high-level information which is of potential use in producing
> machine code from ANDF. For example, although array bounds checks
> would be lovely, I'd like my final code to contain very few of them,
> particularly inside loops! I can imagine it being difficult to safely
> remove bounds checks in a poorly designed bytecode: one would
> potentially have to reconstruct the loops and things.
> On the other hand, ANDF probably isn't appropriate for chips to execute.
> [Haven't heard much about ANDF lately, perhaps Stavros M. can point us
> at recent info. -John]

Last time I looked ANDF was a technology to distribute applications in a
universal format which gets compiled into machine code during the setup
process of the application, not 'just-in-time'. This does not look like a
good idea for web applets to me.

Another technology which keeps lots of high-level information is Slim
Binaries (aka Juice) which originates at the ETHZ (Wirth's group) and
has migrated to California. This is geared explicitly towards
just-in-time compilation and could be what you want. Unfortunately the
only source language currently supported is Oberon, and I burn to see
this technology applied to Java.

To be honest, I dislike the whole concept of the JVM. It is meant to be
a platform independent environment (this is absolutely essential for web
applets) but just when it catches on Sun announces special Java chips
that implement this environment directly. The wintel architecture gets a
companion: The JVM architecture. This must piss off the manufacturers of
all other micros because they automatically suffer a disadvantage. What
is the difference between simulating a virtual Java machine and
simulating a virtual DOS machine? DEC has even produced a 'just-in-time'
compiler from 80X86 machine language to Alpha machine language.

(Sorry for leaving the subject of the thread somewhat, I had to get it

Stefan Heinzmann, 64 Turnpike Lane, London N8 0PR, United Kingdom
Tel/Fax: +44-181-8816795 email:

Post a followup to this message

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