[Vm-dev] Primitive table support for running older images

[David T. Lewis]

On Thu, Dec 22, 2016 at 09:48:09AM +0800, Ben Coman wrote:
>  
> On Thu, Dec 22, 2016 at 7:05 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > I discovered that a recent update in VMMaker-dtl.387 (November 2016) breaks
> > the VM for older images (including my own from about 10 or 15 years ago,
> > not good). The reason is that some obsolete numbered primitives were removed
> > to keep the primitive table in sync with Cog/Spur as much as possible.
> >
> > It is easy to revert the changes, and I plan to do that, but the issue begs
> > for a more general solution. Given that the numbered primitive assignments
> > change over time, and old primitives need to be retired to make room for
> > the new, how best to provide continued support for older images with a
> > current VM?
> >
> > The primitive table is initialized at compile time, and this works fine as
> > long as the assignments do not change too often. On the other hand, if the
> > table was initialized at run time, i.e. when first entering interpret(),
> > then in principle it would be possible for the VM to examine the image to
> > deduce its vintage, or it would be possible to explicitly request some
> > version of the primitive table by means of a command line option to the VM.
> >
> > I played around with this a bit in VMMaker, and I think that defining entire
> > versions of the primitive table at runtime would require large methods that
> > would probably to hard to understand and maintain. However, if we adopt a
> > policy of using the latest primitive assignments as they appear in Cog/Spur
> > for the default table at compile time, and then overriding those assignments
> > as needed at run time, then it should be possible to maintain backward
> > compatibility for old images without making too much of a mess out of the
> > primitive table initialization.
> >
> > Thoughts?
> 
> How far back in time do images maintain the ImageFormat in its header?
> I presume you would just work off that.

The image format numbers go back to the very first Squeak images, although
I don't think they are going to provide enough granularity. They might
get us close though, or at least be enough to provide some hints. So
for example if the image format was pre-closure, we can be fairly sure
it needs access to some of the older numbered primitives.

> 
> Could this backward compatibility be organised as a plugin?
> Or is the initialization too far advanced when plugins are loaded?
> It would be good if this code is easily separable for possibly
> producing a minimal VM for embedded devices.
> cheers -ben

The initialization needs to be in place before any primitives are called,
so it needs to happen before or at the same time as you first enter
the interpret loop. So I expect that any initialization would need to be
either passed to the VM (via command line option or some configuration),
or deduced from the image format as you suggest above.

Dave