Re: Why Virtual Machines? (was: C++ -> Java VM compiler)

Arch Robison <robison@kai.com>
29 Jan 1997 11:45:56 -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) jhummel@esp.ICS.UCI.EDU (Joe Hummel) (1997-01-30)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) haahr@netcom.com (1997-02-02)
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: Arch Robison <robison@kai.com>
Newsgroups: comp.compilers
Date: 29 Jan 1997 11:45:56 -0500
Organization: Kuck & Associates, Inc.
References: <01bbfca0$a284a6f0$041b6682@tecel> 97-01-094 97-01-120 97-01-139
Keywords: design, portable

p.froehlich@link-m.de writes:
> The first VM I can remember is the pCode-Interpreter for Pascal,
>and AFAIK it was dumped for efficiency reasons.
...
>So, the final question: Why base the future on a 70's design?


The Java VM is not a 70's design.


About the only thing the JVM has in common with Pascal pcode is the
name "virtual machine" and "stack". As far as I know, Pascal p-code
was simply object code for a traditional stack machine. The p-code
did not allow reconstruction of useful source information. In
contrast, the Java VM bytecode is simply a compact representation of
the source, and loses little information that might be useful for
optimization. (I would argue no useful information is lost, but one
person's information that is "useful for optimization" is another
persons "unnecessary crutch" or even "nuisance to maintain".) E.g.,
comments and names of local variables disappear in the translation of
Java source to Java bytecodes, but variables still have separate
identities. In traditional object code (virtual or not), all local
variables are glommed together in one stack frame. Other symbolic
entities that are maintained at symbolic level in Java bytecodes are
inheritance hierarchies and exception handling.


Perhaps a better term for Java bytecode would be "preparsed source".


Arch D. Robison Kuck & Associates Inc.
robison@kai.com 1906 Fox Drive
217-356-2288 Champaign IL 61820
Lead Developer for KAI C++ http://www.kai.com/C_plus_plus/index.html
--


Post a followup to this message

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