Dave Mason <dmason at sarg.ryerson.ca> wrote:

> Tim Rowledge wrote:
> 
> > For a start, it wouldn't make Squeak even more portable
> 
> OK.  Forget that part.  That was a supplementary reason.
Fair enough; unless you've been involved in Squeak a while there isn't
any real reason you would know about all the ports done.

> 
> > 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.

I'll have to take you word on that simce I simply don't do java. My
exposure is to things like openoffice (neooffice?) which appears to use
a vast amount of ram, virtual memory and cpu to produce a really
appalling user experience.

> 
> More importantly, the point of this research
Ah, now if you're doing this for research then best of luck. Though I
dislike java on so many levels, I can happily support the idea of
trying out stuff just to see what happens.

You'll find the general framework of VMMaker and VMMakerTool (the UI)
reasonably useful I expect. There is a fair bit of explicatory info on
the swiki as to how it works and is used. You will need to explore the
ObjectMemory, Interpreter and related classes to see how they get used
by VMM. Also look for the VMMaker related extensions to other classes -
you'll find Monticello useful there.

The Slang->C translation is pretty simpleminded textual substitution in
most cases. This works because the syntax and semantics understood is
very restricted and in places positively demented. What you absolutely
will _not_ be able to do is
>>  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.
since that would involve converting general Smalltalk code which is way
outside the CCodeGenerator remit.

Part of the problem you'd face is that you can't generally hope to pull
out a set of Smalltalk classes and compile them without the rest of the
image being there to support them. You can take a Spoon approach
(Craig, start explaining here!) whereby you pull in needed code at
runtime from a method-server but I don't know of any definite way to
say "I'll need this set of methods and not these" a priori.

To do such a tool you would have to start pretty much from scratch and
develop a really well package based system with clear design and
documentation and testing tools and protocols and patterns of practice.
All doable in theory but I don't see much evidence (over 20 years of
involvement) of software dweebs being willing to actually put effort
into doing a job properly. What me, cynical?  My middle name, mate. 

>> 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.
Scarily, this is a product of my random chooser. I think it's laughing
at me. It's certainly smarter and wittier than a goodly proportion of
the people I've worked with.

tim
--
Tim Rowledge, tim at rowledge.org, http://www.rowledge.org/tim
To be, or not to be, those are the parameters.