On Mon, Feb 04, 2013 at 10:08:35PM +0100, Alexander Lazarevi?? wrote:
> Hi!
> 
> Just to get myself up to date on the latest. Is it still true, that we got
> three independent VMs?
> 
> 1. Interpreter VM
> 2. Stack VM
> 3. Cog

That's more or less right for any given operating system.

> 
> So as I recall the Stack VM was planned to replace the Interpreter VM
> entirely.

Currently the Stack VM (and Cog) is developed in a separate branch of
both the Smalltalk (VMMaker) and the platform support code. Much of the
Smalltalk code for StackInterpreter and related classes has been merged
into the "trunk" VMMaker, but this is not complete and at the present
time a Stack VM cannot be generated from that code base. The platform
support code remains in separate branches at this time.

> Or are there any cases were one only could use an Interpreter VM
> (or cog)? Or is the Stack VM the all versatile VM by now? What are the
> requirements for cog to run?

You would use a standard interpreter VM (not stack) if you want to be
able to run an older image format (Squeak 3.6 or 3.8), if you want a VM
compiled in 64 bit mode, if you want to run the experimental 64-bit object
image, or if you need a VM for an architecture not yet supported by Cog.

You would use Cog for any Intel-like platform, especially if you care
about performance.

> 
> 
> It might not come as a surprise, but I haven't looked into the VM code
> lately. But I recall that the linux VM at least uses the modules framework
> to have different display, sound, etc. plugins for the VM. I don't know how
> interleaved the VMs from above are, but would it be out of scope to have
> _one_ VM that could have different object engines as VM plugins? So the VM
> could check the architecture it's running on and the image that should be
> loaded and decide on that what object engine to load/use?

I'm not sure that I understand the question, but one of the things that
Eliot introduced in Cog is a better separation of the interpreter from
the object memory in VMMaker. If you now look at the "trunk" VMMaker
(for in interpreter VM), you will find that this organization has been
adopted there as well. In principle (if not in practice) different kinds
of object memories might be paired with different kinds of interpreters.

The VM plugins are Ian Piumarta's mechanism for loading VM subsystems
in the Unix VM (which would include both Cog and the interpreter VM).
Presumably it would be possible to use this mechanism to load different
variations of object memory or interpreter, although I would not expect
any of this to be a trivial amount of work.

> 
> The obvious benefit for the enduser I see is: *There is only one VM !*

For unix VMs (and possibly others), by far the simplest way to achive
this for the end user is by means of a shell script that selects an
appropriate VM based on the image format. If you look at Ian's most
recent start script (usually installed as /usr/local/bin/squeak if
you have installed the interpreter VM) you will find that much of this
is already in place, including hooks for Cog.

> 
> The benefit for VM developers might be that they only need to focus on the
> object engines and they would share a common VM frame.
> 
> This might be a "well yes, but too much work" thing, but nevertheless it's
> something I would like to share.
> 
> (If turns out that the energy would better invested into something
> different, there is also the possibility to use the package system on
> debian derived systems, that would take care to install the right VMs on
> such system, so that the enduser wouldn't need to worry about this. And I
> guess there is a similar mechanism for windows and mac)
> 
> Alex
>