Re: Java virtual machine as target language for C/C++

pardo@cs.washington.edu (David Keppel) writes:
>Thus, the UNCOL lesson is that you *can* use a VM, but the performance
>won't be as good as with direct n-code generation in which you can
>optimize across both the source level constructs and the machine-level
>constructs.


This remark brings up an issue that distinguishes the Java VM from other VM
that I have seen in the past. For most VM instruction sets, the translation
from source to VM code loses much information that is useful for
optimization. But the Java VM seems to operate at a much more symbolic
level. Is there any information (relevant to optimization) that is lost
when compiling Java source to Java bytecodes? So far, I have noticed only
two pieces of information that are lost:


1. Comments. These seem relatively useless for optimization,
unless they are hiding some annotation of an extended Java.


2. Structured flow control. Java has no goto, but the JVM bytecodes
have only gotos. However, the JVM docs. imply that JVM code always
has reducible graphs, so the structure should be trivial to
recover.


So, for the case of Java, is there an example where direct code generation
from Java source can do better than code generation from byte codes? Or
phrased another way, is the Java VM code really nothing but a
machine-readable version of the source?


Notice that I am not suggesting that one can generate "good" code from Java
VM bytecodes, only that it should be no worse than code generated from Java
source.


Arch D. Robison Kuck & Associates Inc.
robison@kai.com 1906 Fox Drive
217-356-2288 Champaign IL 61820
--

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