Tim Rowledge wrote:

> For a start, it wouldn't make Squeak even more portable

OK.  Forget that part.  That was a supplementary reason.

> Next, consider the appalling overheads. So far as I can work out the
> typical java vm and support libraries appear to occupy many hundreds
> of megabytes.

Indeed.  However, just as the C/Slang-based Squeak VM doesn't use much
of the available tens of megabytes of C libraries, a Java based one
wouldn't likely use much of the hundreds of megabytes of Java libraries.

More importantly, the point of this research is to create a compiler
that *doesn't* include all of those megabytes of unnecessary cruft.  And
one of the things I'm looking for is challenging compilation targets.
Compiling a Smalltalk VM implemented on the JavaVM and hoping to get
anything *like* the performance of the existing Squeak VM would
certainly be a challenge.

I have no research interest in producing valid Java code that would
work, or even .class files that a JavaVM would accept, but rather .class
files that capture the Smalltalk classes and can be fed into my
compiler, and make sure that the compiler accepts Smalltalk semantics as
well as Java semantics.  And the more I think about it, the less likely
I think it is that the set of .class files that we would generate could
be even *close* to what a JavaVM would accept.

What might come out of this is not a better Smalltalk VM (I think that
is very unlikely, and my compiler certainly doesn't target the range of
architectures that VMMaker does), but a compiler that could take a set of
Smalltalk classes out of an image and produce a small fast executable
suitable for burning into ROM for some embedded application.

> In computer science, we stand on each other's feet.  - Brian Reid

I don't know whether Tim chose this signature for this email, or if a
random sig chooser did it, but I think it's very appropriate.  In
computer science research it is often difficult to tell a priori whether
one is standing on the shoulders or the feet of others.  This research
builds on some very underdeveloped work called code coagulation, and I'm
proposing also building on the shoulders of the Squeak community that
has built this amazing environment.

I was particularly looking for a bit of technical guidance.  I would
still appreciate any that is available.  It is likely that the only
part of VMMaker that would be useful to my student is the part that
identifies the classes and methods that are needed for the VM.  All of
the code generation will be very different.

../Dave