[Vm-dev] VM packaging for Cog transition

[David T. Lewis]

On Mon, Nov 08, 2010 at 12:31:35PM +0100, Bert Freudenberg wrote:
> 
> On 08.11.2010, at 04:55, David T. Lewis wrote:
> 
> > On Sun, Nov 07, 2010 at 07:29:56PM -0800, Andreas Raab wrote:
> >> 
> >> On 11/7/2010 12:27 PM, David T. Lewis wrote:
> >>> The above is just my $.02 to get the discussion started. What do others 
> >>> think?
> >> 
> >> I don't really have any skin in the game since this is a Unix specific 
> >> issue (i.e., the "squeakvm" dependency) that doesn't really apply on Mac 
> >> or Windows. That said, I'll add my $.02 by saying that in our Linux 
> >> production systems we do exactly what you were proposing, i.e., we have 
> >> fallback VMs installed side-by-side with the latest and symlink the 
> >> desired VM. That makes it very easy to switch the default *and* allows 
> >> you to be explicit where you want to (i.e., by executing from the 
> >> linked-to location).
> >> 
> > 
> > Well that is Bert's suggestion exactly, and it is consistent with John's
> > point of view as well, so it sounds like this is the right thing to do.
> > 
> > Dave
> 
> So we would ship two VMs. One is the old interpreter. The other is cog,
> or the stack interpreter, depending on the machine's architecture.
> 
> The two new ones should be in one source archive, IMHO.

Yes it should be exactly as you say, but I think we should be cautious
about setting expectations. It may take a while to get this accomplished,
and in the December time frame the important thing is to deliver solid
working Cog and interpreter VMs. If we can merge all the code bases etc
that is great, but let's not make it a precondition for the December VM
and Squeak 4.2 release cycle. We have all seen what happens when a release
team gets caught up in unrealistic development objectives, so let's not
go there ;)

> At build time either
> cog or stack VM would be selected depending on the machine's architecture.
> What should the name be for those binaries? Just use "squeakvm-cog" even
> if it's the Stack VM because it can run the same images?

Someone recently submitted a magic file with good names (Subbu? I can't
find the link). I think the names were squeak-cog, squeak-stack,
squeak-interp or somthing similar. In any case, "interp" can refer to the
traditional interpreter, "stack" can refer to the portable stack interpreter
positioned as a replacement for "interp", and "cog" can refer to the high
performance VM.

> Would we drop development on the old interpreter? If plugins were compatible
> between it and the newer VMs (are they?) it should not be much effort to
> keep it alive.

It's no real trouble to keep it alive and I intend to do so.

The plugins should definitely be identical. The C code generator should
also be the same (I'm currently fumbling my ameteurish way through adoption
of Eliot's enhancements into VMMaker trunk, but it's obvious that the end
result should be the same). Hopefully we will get the old interpreter merged
with Eliot's version (more work than I might have expected) but even if we
can't do that short term, maintaining the old interpreter is easy and I'm
quite happy to continue doing so as needed. Likewise for VMMakerTool, some
folks may not need to use it but it is little or no work to maintain it,
and I use it myself on a regular basis so keeping it alive is no problem.

> What about 64 bit images? We don't need extra sources for those VMs,
> since it's just a build flag. But we need a naming scheme for these too.

This is something that is only in the trunk VMMaker. I am assuming that
it would be good to merge this with the Cog VMMaker, although it is a fair
amount of work with no direct benefit to the Cog VM so I should defer
to Eliot on this. The changes are straightforward, but a lot of code gets
touched and this is an example of something that may take some time and
effort to merge.

Dave