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

rfg@monkeys.com (Ronald F. Guilmette) writes:


      UNCOL is a beautiful idea which has been shown to never work in
      practice.


Oh? Whole branches of the computer industry live on interpreted
bytecodes or bytecodes that are compiled on-the-fly. I think it is
quite possible that more compute cycles are spent in the world on
executing code compiled to bytecodes than code compiled to native
code. Just because it hasn't taken your workstation by storm doesn't
mean it isn't used widely. (And don't forget about all the scripting
languages that use bytecode intermediate formats, and the crop
of emulators for Intel-on-something-else.)


      But it has such allure that people keep coming back to
      it time and time again. In just the recent past, we have been
      offered ANDF, which is dying (has died?) without too much fanfare
      (i.e. a whimper rather than any spec- tacular bang).


      Now Java bytes codes are being held out to the computing community
      as the new solution to universal code portability.


You misinterpret what JVM is trying to do. JVM is not ANDF or UNCOL,
and it isn't Omniware either. JVM has more specific goals (it also a
considerably more powerful runtime). While you could compile any
language to JVM, JVM is primarily intended as a runtime for Java. JVM
is "universal" only in the sense that it lets you execute Java
programs on any machine with a JVM, a universality property shared
with hundreds of other successful and widely used virtual machines.


However, as it turns out, Java is actually a pretty good general
purpose programming language. That means that JVM can actually easily
be a target for a wide range of _applications_, even though JVM
doesn't try to be a target for a wide range of
_programming_languages_.


      I gather that Java byte codes have already acheived more success in
      the marketplace than have most of its predecessors, but that fact
      doesn't imply that the fundamental problems with the age-old
      UNCOL idea have been eliminated.


You are hand-waving. What are those "fundamental problems"? The only
possible negative impact that use of an intermediate machine has is on
speed (space is usually better anyway). But speed only matters in a
small part of the code of most programs (and most of those parts have
migrated into vendor supplied libraries). Furthermore, a large part
of the market is much more concerned with fast and easy development,
compatibility, and functionality than with performance. Most
importantly, however, natively compiled JVM performance is actually
nearly indistinguishable from equivalent, compiled C/C++ code.


      As usual with these schemes, the inherient problems have just been
      cleverly side- stepped (for the moment and for a limited set of
      targets) through the judicious application of appreciable
      quantities of labor. --


Many languages and APIs in use today are already tightly coupled to a
limited set of target architectures. Maybe the only reason why things
may seem different to you is because all the architectures that don't
conform have disappeared from the market. The point is that you
always have to make choices among specific target architectures. I
suspect, however, that JVM is easier to implement (both interpreted
and compiled) across diverse architectures than C++ or even C.


Using an intermediate virtual machine, in particular if it is for a
specific language, does actually seem to reduce the amount of work
that needs to be invested in frontends, tools, and development
environments, even if native code generation were somewhat harder
in the end.


Thomas.
[The goal of UNCOL was to have a universal intermediate language which would
let you mix and match multiple language front ends and multiple architecture
back ends. I don't think anyone denies that if you have a single source
language, there are plenty of multi-targeted systems that work well. Do
recall that this particular line of discussion started with the suggestion
that languages like C and C++ might be compiled into JVM as a way to achieve
universal portability. -John]
--

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