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
Well Tim was involved in a project where they changed the SLANG compiler to extrude assembler. (SLANG to ARM Assembler).
That port is lurking, ask Tim or myself for a copy.
I'm sure I saw a port to Obj-C, see http://www.metaobject.com/ downloads/Squeak/, let's see,, mmm yes here is a snippet from interp.m
-(int)isPointers:(int )oop { return ([self formatOf:oop] <= 4); }
Remember SLANG is a subset of Smalltalk to allow you to generate non- complex basic generic C code, so going to JAVA is much simpler than to say assembler.
I first would suggest confirming you can create a basic VM without INLINING, althought the performance is poor, the code is much cleaner and clearer. I could assist you with any fixes required to do this since I recall you can't directly create a compile error free version at the moment, inlining actually removes 2 or 3 compiler errors by folding out the incorrectly generated C code.
Note I have code that sets the return type of the routine to int/ char* or void depending on the method type declares. This isn't part of the Squeak VM, but might be also required to make certain other languages happy with typing issues.
On 19-Sep-05, at 4:39 AM, Dave Mason wrote:
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
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Dave Mason dmason@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@rowledge.org, http://www.rowledge.org/tim To be, or not to be, those are the parameters.
squeak-dev@lists.squeakfoundation.org