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

Ben Coman btc at openinworld.com
Thu Dec 22 01:48:09 UTC 2016


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.

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


More information about the Vm-dev mailing list