Re: Smalltalk VM -> Java VM

Chris Laffra (laffra@morgan.com) wrote:
: Has anyone considered developing a Smalltalk VM to Java VM
: translator? Is such a thing feasible?
: What will it take to develop a Smalltalk app, convert the
: generated byte codes to Java byte codes, and run them
: on a remote Java-enabled browser.


This would be quite plausible in the case of transfering code
via a cross-assembler between two similar processors (ie 32bit,
16bit), but most smalltalk VMs are designed with shortcuts in their
instruction sets that provide more speed or flexibility. The problem
is that some instructions (ex. load argument 1 into a register) will
not map well into the new VM. The biggest problem that I forsee with
the Java VM is that the byte-codes guarantee that the types for each
operation are known in advance. The VM would inspect the translated
code and would present a problem in some cases. Smalltalk VMs don't
pay attention to the object type that is being operated on because
the context that is currently in use manages the environment
surrounding the method call. In the Java VM, the instructions for
loading the member data elements won't fit well with the access
methods dictated through these contexts. Beyond that, some newer
smalltalk VMs now employ an optimization technique that generates
real assembly for the underlying architecture and when a method is
called, the VM will jump into the code (running native) and thread
back out into the VM on exit.


I think that a better approach would be to begin with a
version of smalltalk where they have evolved past the bootstrap
compiler (the one written in C or whatever) ; if the actual
compilation to byte codes happens in the image (ie. the whole
compiler is in smalltalk), then you could attack the problem at that
level and just re-write the back end so that it produces the
appropriate byte codes for the Java VM. I still see problems here
because there is quite a reliance on the environment of the VM when
compiling - how would the contexts of the objects be created in the
newly generated code? If you look at ParcPlace smalltalk for
instance, you will see heavy use of primitives to gain access to the
internals. You might have to patch the Java VM to afford similar
access.


Cheers,
Chris




--

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