Re: Generating Java Bytecode

kuznetso@MIT.EDU (Eugene Kuznetsov)
19 Nov 1996 00:28:09 -0500

          From comp.compilers

Related articles
Generating Java Bytecode (1996-11-18)
Re: Generating Java Bytecode (1996-11-19)
Generating Java Bytecode nasser@apldbio.COM (Nasser Abbasi) (1996-11-19)
Re: Generating Java Bytecode kuznetso@MIT.EDU (1996-11-19)
Generating Java Bytecode (Bill Purvis) (1996-11-19)
Re: Generating Java Bytecode (Stavros Macrakis) (1996-11-19)
Re: Generating Java Bytecode (nicolas (n.) chapados) (1996-11-19)
Re: Generating Java Bytecode (Gunnar R|nning) (1996-11-19)
Re: Generating Java Bytecode (1996-11-19)
Re: Generating Java Bytecode (John Carter) (1996-11-21)
[18 later articles]
| List of all articles for this month |

From: kuznetso@MIT.EDU (Eugene Kuznetsov)
Newsgroups: comp.compilers
Date: 19 Nov 1996 00:28:09 -0500
Organization: Compilers Central
References: 96-11-108
Keywords: Java, UNCOL wrote:

> Does anyone have an opinion on generating bytecode for languages other
> than java ?
> [Universal machine intermediate languages go back to the 1950s, and
> they've never worked. From what I've seen of the Java intermediate
> language, it works fine for Java, OK for Ada, not so great for anything
> else. In particular, it specifically doesn't include C's wild 'n' crazy
> pointer rules. -John]

While I have not myself attempted this, it is certainly possible.
Some languages are certainly much easier than others (one of the
Scheme dialects can already be compiled to java bytecode, Ada, CLU and
several other languages would not be significantly more difficult).

Indeed, C and C++ are more difficult, but possible. Having a virtual
machine that does not attempt to do too much error checking or verify
the bytecode could be helpful... But casting aside solutions which
require a modified java VM (there are some VM's in development, from
what I hear, that include more "natural" support for languages other
than java), there is nothing preventing one from compiling even the
messiest C code to java bytecode. For some of the more painful
pointer manipulations it would be necessary to rewrite the code
significantly and probably sacrifice a great deal of performance, but
it could be done.

The next question is why you would want to do this. Java is not all
that different from C++ (well, except for that depressing
multiple-inheritance problem), so it could be used in its place for
many new developments. As to things for which C is more appropriate,
does it really make sense for them to be executed by a virtual

Not to say that it wouldn't be interesting to do. Or that some
languages (such as interpreted scheme, for example) would probably
receive a performance boost.

                                                                                                                        Eugene Kuznetsov
[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]


Post a followup to this message

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