From: | bothner@cygnus.com (Per Bothner) |
Newsgroups: | comp.lang.java,comp.compilers |
Date: | 30 Jan 1996 21:47:56 -0500 |
Organization: | Cygnus Support, Mountain View, CA |
References: | 96-01-037 96-01-089 96-01-109 |
Keywords: | interpreter, translator |
In article 96-01-109,
David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk> wrote:
>Here is my estimation of how hard it would be to translate various languages
>to the JVM. YMMV.
>...
>Requires extensive VM changes:
> Smalltalk, Scheme, CLOS, other Lisps, Dylan, Self
Depends on what you mean by "VM changes". There are three levels
of extension one could use to implement another language:
(a) New library classes written in Java.
(b) New library classes with native methods (written in C).
(c) Modifications to the VM core (i.e. the byte codes, the
interpreter, the garbage collector etc).
Only (c) is what I would consider a "VM change." And I believe
only (a) is strictly required to implement any of these languages.
For example closures and generic arithmetic can be easily implemented
in Java. (That does not mean it would be efficient.)
>Impossible automatically:
> C, C++
Likewise. For example, it is easy to implement C pointer semantics
using "fat pointers". A fat pointer has two parts: A pointer to an
array, plus an offset in the array. Pointer arithmetic is implemented
as arithmetic on the offset. Pointers to non-arrays can be handled
various ways. A simple but inefficient solution to wrap evarything in
a one-element arrray. Optimizations are left as an exercise for the
reader.
Any local variable whose address is taken would have to be allocated
on the heap.
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.
--
--Per Bothner
Cygnus Support bothner@cygnus.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.