Hi!

I was under the impression, that new folks, who would be interested in
Squeak, could be driven away by a challenge to find the right Squeak VM. To
make their life's easier I thought "that having a 'single' VM that can
choose an appropriate core at runtime" would be a good thing (especially
"if [they] want to be able to run an older image format").

Thanks for the clarification and the detailed replies.

Alex


2013/2/5 David T. Lewis <lewis at mail.msen.com>

> 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
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130212/d6c3b865/attachment.htm