Re: Possible to write compiler to Java VM?

One poster suggested that translating C or C++ to the Java VM was
``impossible, automatically''. Over in comp.lang.poplog, there was
recent mention of a C system for Poplog. In case anyone doesn't know
what poplog is,


- there was a British AI programming language called Pop-2
- Sussex developed a new implementation for VAXes called Pop-11
- the language has Lisp-like data structures (in fact it has had
some good things longer than Lisp has) implemented in the usual
Lisp-on-stock-hardware sort of way. It also came with its own
screen editor called VED, similar in spirit to Emacs but massively
different in detail. I never got the hang of VED, but seemingly
many people loved it.
- Chris Mellish developed a Prolog system for it, which *DID*
require extensive additions to the VM in order to approach
efficiency (knowing a bit about what was involved, this gives
me reason to believe that Prolog-on-Java would run like a sloth
in a tarpit without similar extensive additions)
- Pop-11 was ported from VAX-VMS to VAX-UNIX and thence to a range
of other 32-bit UNIX machines
- Common Lisp was added; the net consequence of this was some
minor changes to the Poplog VM, but Pop's dynamic binding ended
up being overthrown by Lisp's lexical binding
- ML was also added, not a _fast_ implementation but a good one.


None of the compilers for these Poplog languages was a world beater
(even the Pop compiler was allegedly beaten by a Mac Pop) but none of
them was all that bad either, and the key point was that they all
interoperated smoothly in one not-excessively-large VM, with
integrated editor, HELP, and TEACH files. (Porting the back end is
rather easier than porting GCC and you currently get four languages
for the price of one.)


As mentioned above, there is now an experimental C system that plugs
into it (this time apparently without any changes to the VM). NOT a
world beater in terms of speed, but said to be a _great_ debugging
tool for C. Think of it as a competitor to CodeCenter (was Sabre C)
rather than gcc.


This suggests to me that a C to Java-VM compiler combined with a
Java-VM to native on-the-fly compiler might be a very useful tool, and
that it wouldn't have a hope of matching a native C compiler.


Per Bothner wrote:
>Of course such an implementation of C is not very useful. It would be
>slow, and would be incompatible with existing ABIs (libraries). But I
>bet you can implement the ANSI spec completely and by the book.


On the contrary, it would be very useful, if the Java system is
capable of giving good diagnostics. Saber C was a very powerful
debugging tool. (By the way, an Application Binary Interface is an
interface, not a library.) And to be perfectly frank, if I could have
C code that worked *unmodified* on Windows, Mac, and UNIX-X with the
same graphics interface on all of them, I wouldn't _care_ if it didn't
match my code up with the SPARC/System V ABI.


--
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
--

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