Primitive table support for running older images

>
> 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?

>  
> On Thu, Dec 22, 2016 at 7:05 AM, David T. Lewis <[hidden email]> 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.

>  On Thu, Dec 22, 2016 at 3:50 AM, David T. Lewis <[hidden email]>
> wrote:
>
>>
>>  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?
>>
>
> In SqueakJS I have a single flag oldPrims to switch between two set of
> primitives. This appears to work fine all the way back to Squeak 1.x. The
> flag is set based on whether the image format has closures or not.
>
> Just search for "oldPrims" in
> https://github.com/bertfreudenberg/SqueakJS/blob/master/vm.js
>
> - Bert -
>

>  
> Bert Freudenberg wrote on Thu, 22 Dec 2016 16:40:51 +0100
> > In SqueakJS I have a single flag??oldPrims??to switch between two set of primitives.
> > This appears to work fine all the way back to Squeak 1.x. The flag is set based on
> > whether the image format has closures or not.
>
> I had the impression, based on some difficulties on getting the
> simulator to work (around 2008, I think), that at one point an instance
> variable in a key class (Process, most likely) stopped being used and
> then a few versions later it got reused in a different way. This also
> happened to a numbered primitive or two. And the version number stayed
> 6502 though all these changes. So a newer VM would appear to run an
> older image just fine but once in a while you got a really strange
> crash.
>
> My hope is that this was just some horrible nightmare of mine and not
> actual memories, but I will have to take some time searching through old
> email messages to be sure.
>