|Generating Java Bytecode email@example.com (1996-11-18)|
|Re: Generating Java Bytecode firstname.lastname@example.org (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 email@example.com (Bill Purvis) (1996-11-19)|
|Re: Generating Java Bytecode firstname.lastname@example.org (Stavros Macrakis) (1996-11-19)|
|Re: Generating Java Bytecode email@example.com (nicolas (n.) chapados) (1996-11-19)|
|Re: Generating Java Bytecode firstname.lastname@example.org (Gunnar R|nning) (1996-11-19)|
|Re: Generating Java Bytecode email@example.com (1996-11-19)|
|Re: Generating Java Bytecode firstname.lastname@example.org (John Carter) (1996-11-21)|
|[18 later articles]|
|From:||kuznetso@MIT.EDU (Eugene Kuznetsov)|
|Date:||19 Nov 1996 00:28:09 -0500|
> 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.
[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]
Return to the
Search the comp.compilers archives again.