<div dir="ltr"><div><div>Hi!<br><br></div>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").<br>
</div><div><br>Thanks for the clarification and the detailed replies.<br><br></div><div>Alex<br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/2/5 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Feb 04, 2013 at 10:08:35PM +0100, Alexander Lazarevi?? wrote:<br>
> Hi!<br>
><br>
> Just to get myself up to date on the latest. Is it still true, that we got<br>
> three independent VMs?<br>
><br>
> 1. Interpreter VM<br>
> 2. Stack VM<br>
> 3. Cog<br>
<br>
</div>That's more or less right for any given operating system.<br>
<div class="im"><br>
><br>
> So as I recall the Stack VM was planned to replace the Interpreter VM<br>
> entirely.<br>
<br>
</div>Currently the Stack VM (and Cog) is developed in a separate branch of<br>
both the Smalltalk (VMMaker) and the platform support code. Much of the<br>
Smalltalk code for StackInterpreter and related classes has been merged<br>
into the "trunk" VMMaker, but this is not complete and at the present<br>
time a Stack VM cannot be generated from that code base. The platform<br>
support code remains in separate branches at this time.<br>
<div class="im"><br>
> Or are there any cases were one only could use an Interpreter VM<br>
> (or cog)? Or is the Stack VM the all versatile VM by now? What are the<br>
> requirements for cog to run?<br>
<br>
</div>You would use a standard interpreter VM (not stack) if you want to be<br>
able to run an older image format (Squeak 3.6 or 3.8), if you want a VM<br>
compiled in 64 bit mode, if you want to run the experimental 64-bit object<br>
image, or if you need a VM for an architecture not yet supported by Cog.<br>
<br>
You would use Cog for any Intel-like platform, especially if you care<br>
about performance.<br>
<div class="im"><br>
><br>
><br>
> It might not come as a surprise, but I haven't looked into the VM code<br>
> lately. But I recall that the linux VM at least uses the modules framework<br>
> to have different display, sound, etc. plugins for the VM. I don't know how<br>
> interleaved the VMs from above are, but would it be out of scope to have<br>
> _one_ VM that could have different object engines as VM plugins? So the VM<br>
> could check the architecture it's running on and the image that should be<br>
> loaded and decide on that what object engine to load/use?<br>
<br>
</div>I'm not sure that I understand the question, but one of the things that<br>
Eliot introduced in Cog is a better separation of the interpreter from<br>
the object memory in VMMaker. If you now look at the "trunk" VMMaker<br>
(for in interpreter VM), you will find that this organization has been<br>
adopted there as well. In principle (if not in practice) different kinds<br>
of object memories might be paired with different kinds of interpreters.<br>
<br>
The VM plugins are Ian Piumarta's mechanism for loading VM subsystems<br>
in the Unix VM (which would include both Cog and the interpreter VM).<br>
Presumably it would be possible to use this mechanism to load different<br>
variations of object memory or interpreter, although I would not expect<br>
any of this to be a trivial amount of work.<br>
<div class="im"><br>
><br>
> The obvious benefit for the enduser I see is: *There is only one VM !*<br>
<br>
</div>For unix VMs (and possibly others), by far the simplest way to achive<br>
this for the end user is by means of a shell script that selects an<br>
appropriate VM based on the image format. If you look at Ian's most<br>
recent start script (usually installed as /usr/local/bin/squeak if<br>
you have installed the interpreter VM) you will find that much of this<br>
is already in place, including hooks for Cog.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> The benefit for VM developers might be that they only need to focus on the<br>
> object engines and they would share a common VM frame.<br>
><br>
> This might be a "well yes, but too much work" thing, but nevertheless it's<br>
> something I would like to share.<br>
><br>
> (If turns out that the energy would better invested into something<br>
> different, there is also the possibility to use the package system on<br>
> debian derived systems, that would take care to install the right VMs on<br>
> such system, so that the enduser wouldn't need to worry about this. And I<br>
> guess there is a similar mechanism for windows and mac)<br>
><br>
> Alex<br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div>