On Sep 18, 2006, at 20:09 , Jecel Assumpcao Jr wrote:

> Ron Teitelbaum wrote:
>> If we accepted that the base VM is C++ then couldn't plugins still  
>> be slang,
>> (or the slang plugins still be supported by the base Strongtalk vm)  
>> or is
>> this too much for the squeak community to accept?
>
> Note that when the Squeak project was started there was already an  
> Open
> Source (BSD license) Smalltalk VM written in C++. I am talking about
> Self 4.0 hosting GNU Smalltalk, which at the time outperformed all
> available VMs including the commercial ones. And this work had been  
> done
> by the group from which one of Squeak's creators had come from, so we
> can be sure he was very familiar with it.

The Klein Paper lists what they perceived to be problematic about the C 
++ VM:

- 120KLOC of C++
- replicated code:  common ops implemente 3 times (runtime, slow+fast  
compiler)
- debugging difficult: difficult to access self objects as such from  
the VM level
- slow turnaround:  change to C++ headers caused > 5 min. recompile
- complexity + brittleness

and how they wanted to address these problems:

- use a (pure) dynamic OO language
- be metacircular, using the same language for VM+environment means  
lots of code sharing
- foster code reuse through language features, architecture,  
environmental support
- allow VM to be changed quickly, even while running
- exploiting mirror-based reflection for debugging the VM

Of course, they were a long way from producing a practically useful VM.

Squeak's Slang addresses a few of these problems, making it possible  
to pseudo-test changes very quickly by running the Slang code within  
an existing image ('pseudo-test because there can be issues in the  
translated/compiled code that do not show up in Slang).  However,  
Slang isn't really an OO language, it's really BCPL with Smalltalk  
syntax, and therefore none of the code-reuse or other OO benefits  
apply, and having the non-applicable syntax/semantics is rather  
confusing.  But it *is* practical, up to a point.

I think the fundamental problem is that for some bits of a VM, C/C++  
is much better suited, whereas for other parts, a high-level OO  
language is the better choice.  However it's either/or and the systems  
listed, as well as Strongtalk and the commercial VMs, have to make the  
coice one way or another and then try to deal with the consequences.

<BrokenRecord>
Objective-C shows that the choice doesn't have to be either/or, it can  
be a smooth blend of "a bit of both" where needed.  For example,  
Objective-Smalltalk heavily leverages the Foundation classes  
(dictionaries, arrays, etc.) in its "VM" implementation, but those  
same classes are also available to the Objective-Smalltalk programs  
running on top.

It is also quite possible to start a particular implementation with  
objects and then incrementally replace these with lower-level C  
constructs, all without crossing any boundaries.  For example, my  
first implementation of message sending stored the evaluated arguments  
of a message expression in an array object (an NSArray).  Profiling  
showed that this was taking a lot of time so I changed it to  
allocating an array of object pointers on the C stack (no object), and  
performance was duly improved.  However, this means that the API for  
message-sending isn't pure objects any longer, so I might change it a  
bit so it uses a light-weight, stack-allocated array object in the  
future.

And yes, due to the fact that Objective-C is a dynamic OO language,  
recompiles don't take minutes but seconds, making exploration possible.
</BrokenRecord>

Marcel