On Wednesday, 19 December 2012 at 07:22:45 UTC, Walter Bright
wrote:
On 12/18/2012 11:04 PM, Rob T wrote:
I'm not claiming to be an expert in this area either, however
it seems obvious
that there are significant theoretical and practical
advantages with using the
bytecode concept.
Evidently you've dismissed all of my posts in this thread on
that topic :-)
I really am trying to understand your POV, but I'm having a
difficult time with the point concerning performance.
Using the JS code as an example, you are stating that the JS
source code itself could just as well be viewed as the
"bytecode", and therefore given what I previously wrote
concerning the "advantages", I could replace "bytecode" with "JS
source code" and achieve the exact same result. Am I Correct?
I will agree that the bytecode could be encoded as JS (or as
another language) and used as a common base for interpretation or
compilation to machine code. I can also agree that other
languages can be "compiled" into the common "bytecode" language
provided that it is versatile enough, so from that POV I will
agree that you are correct.
I thought that transforming source code into bytecode was an
optimization technique intended to improve interpretation
performance while preserving portability across architectures,
i.e., the bytecode language was designed specifically to improve
interpretation performance - but you say that the costs of
performing the transformations from a high-level language into
the optimized bytecode language far outweigh the advantages of
leaving it as-is, i.e., whatever performance gains you get
through the transformation is not significant enough to justify
the costs of performing the transformation.
Is my understanding of your POV correct?
What I'm having trouble understanding is this:
If the intention of something like the Java VM was to create a
portable virtualized machine that could be used to execute any
language, then would it not make sense to select a common
bytecode language that was optimized for execution performance,
rather than using another common language that was not
specifically designed for that purpose?
Do you have a theory or insight that can explain why a situation
like the Java bytecode VM came to be and why it persists despite
your suggestion that it is not required or of enough advantage to
justify using it (may as well use Java source directly)?
--rt
