Re: C++ -> Java VM compiler

kuznetso@MIT.EDU (Eugene Kuznetsov)
17 Jan 1997 23:22:57 -0500

          From comp.compilers

Related articles
Re: C++ -> Java VM compiler aszs@enternet.com (1997-01-12)
Re: C++ -> Java VM compiler gah@u.washington.edu (1997-01-16)
Re: C++ -> Java VM compiler kuznetso@MIT.EDU (1997-01-17)
Why Virtual Machines? (was: C++ -> Java VM compiler) p.froehlich@link-m.de (1997-01-25)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) robison@kai.com (Arch Robison) (1997-01-29)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) albaugh@agames.com (1997-01-29)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) nr@adder.cs.virginia.edu (Norman Ramsey) (1997-02-02)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) Bronikov@srv2.ic.net (Dmitri Bronnikov) (1997-02-02)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) apalanis@students.uwf.edu (1997-02-03)
[6 later articles]
| List of all articles for this month |

From: kuznetso@MIT.EDU (Eugene Kuznetsov)
Newsgroups: comp.lang.c++,comp.lang.java.misc,comp.compilers
Date: 17 Jan 1997 23:22:57 -0500
Organization: Compilers Central
References: <01bbfca0$a284a6f0$041b6682@tecel> 97-01-094 97-01-120
Keywords: C++, Java

gah@u.washington.edu (G. Herrmannsfeldt) wrote:
> I would be interested to hear from anyone else with any thoughts
> about this problem.


Many people seem to be interested in this problem, both from a
commercial and academic standpoint. In my mind most of this problem
can be condensed into the following parts:


1. Theoretically, since both Java & C++ are Turing universal, one of them
can be implemented using the other.
2. Practically, performance is a serious concern in any real application,
so some emulation techniques can be prohibitive.
3. Not all JVM's are created equal, and some may relax the spec. In
addition, some vendors are working on "unified VM's" that are similar to
the Java VM, but also include additions for executing C++ & C code more
efficiently.


Based solely on #1, it is clear that primitive datatype pointer casts
could be emulated using a byte output stream or similar device. Struct
access and casting can be faked with creative calls to defineClass().
Multiple inheritance can be done with tagged data and some interfaces.
The JDK 1.1 object serialization interfaces give one even more
opportunities for these sorts of perversions. On the other hand,
having a more permissive VM, as in #3, may be more efficient.
However, if the goal is to make the code more portable, it seems that
using some kind of a custom VM (which is probably available on only
one platform) is self-defeating.


If anyone is seriously considering some kind of a project (or knows of
definite commercial works in progress), please send me a note.


                                                                                                              Eugene Kuznetsov
                                                                                                              kuznetso@mit.edu
--


Post a followup to this message

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