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

[David T. Lewis]

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

Dave