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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.