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

Arch Robison wrote:


> ... In contrast, the Java VM bytecode is simply a compact
> representation of the source, and loses little information that
> might be useful for optimization. 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".


Perhaps not. Java VM code is pretty much of the same level as any
other VM. If you modified JVM addressing of operands to refer to
offsets in stack, rather than bringing operands which happenned to be
not at the top using stack management instructions, then you'll get
what one used to see in other machines "virtual or not". And this I
assume was not done to enable reverse compilation, Java VM chose not
to define object reference size or representation - hence locals
generally should not be allocated by javac. Method invocation/binding
is again different due to mobility of Java.


I'm far from being a Java or JVM lawyer, I rather belong to C++
cast. I'd say that JVM is not "just VM" because it's so much Java and
not quite friendly/efficient for use with other languages. One java
lawyer posted a reply in comp.compilers (quite some time ago) to those
who requested expansion of JVM to suite C++, saying "why C++ people do
not come up with VM for C/C++?". Indeed, why not?!


--

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