Smalltalk › Squeak › Squeak VM

minor image version numbers?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Eliot Miranda-2

minor image version numbers?

Hi David, Hi All,

here's an example of an occasional problem. I'm looking at the free tree in Spur and I have an unused field in each free chunk that is a remnant of an old attempt at a compaction algorithm I've long abandoned. I'd like to eliminate the field (2nd slot in a free chunk) but that means either breaking the loading of existing Spur images or some version marker in the image header to indicate whether the image contains old format free chunks or new format. This is the kind of internal micro-change that I don't think warrants taking a bit from the image version field.

However, it /would/ be nice to have a field there-in for a minor version number that the VM implementor could simply increment when they want to make such a minor change. What do you think? Currently the unused bits in the image format are

ImageFormat availableBits printStringBase: 2 '1111111,11111110,11100110,00000000'

(the top bit is reserved for an extension bit).

So we could use the top 7 bits for a 0-127 field that will probably last me for a long time, and it would be easy to mask it out of the version field.

An alternative is for me to use some other field in the Spur image header. I'm happy to do that if the above scheme smells to anyone. There's a 16-bit field in Cog image headers I can use (see the2ndUnknownShort in VMMaker.oscog).
--

best,

Eliot

David T. Lewis

Re: minor image version numbers?

On Fri, Jan 16, 2015 at 11:55:40AM -0800, Eliot Miranda wrote:

>
> Hi David, Hi All,
>
> here's an example of an occasional problem. I'm looking at the free
> tree in Spur and I have an unused field in each free chunk that is a
> remnant of an old attempt at a compaction algorithm I've long abandoned.
> I'd like to eliminate the field (2nd slot in a free chunk) but that means
> either breaking the loading of existing Spur images or some version marker
> in the image header to indicate whether the image contains old format free
> chunks or new format. This is the kind of internal micro-change that I
> don't think warrants taking a bit from the image version field.
>
> However, it /would/ be nice to have a field there-in for a minor version
> number that the VM implementor could simply increment when they want to
> make such a minor change. What do you think? Currently the unused bits in
> the image format are
>
> ImageFormat availableBits printStringBase: 2
> '1111111,11111110,11100110,00000000'
>
> (the top bit is reserved for an extension bit).
>
> So we could use the top 7 bits for a 0-127 field that will probably last me
> for a long time, and it would be easy to mask it out of the version field.

This sounds like a very reasonable idea to me. It does not make the image
header any more difficult to parse, and it leaves plenty of free bits available
to represent other image/VM requirements in the future.

>
> An alternative is for me to use some other field in the Spur image header.
> I'm happy to do that if the above scheme smells to anyone. There's a
> 16-bit field in Cog image headers I can use (see the2ndUnknownShort in
> VMMaker.oscog).

>From my POV this is also fine. It does not seem quite as nice as your idea
of using 7 bits out of the image format number, but on the other hand it
does have one advantage if you think of it from the point of view of someone
who runs a VM/image combination and gets one of those error messages that
says "this interpreter (vers. xxxx) cannot read image file (vers. yyyy)".
In that case, it might be nicer to have a small set of Spur image numbers
that a user would easily recognize. From that perspective, you might prefer
to have to "minor version number" information stored in a separate field
in the header.

But again, I like your idea, and either approach would be fine in terms of
keeping track of the various formats in circulation.

As an aside, I think that our current image file header format could really
stand some improvement. Given that Spur provides a convenient break point
in terms of maintaining backward compatibility, this might be a good time
to rethink the notion of an "image file header". IMO we should have something
that can be represented as an object (like class ImageFileHeader, but it
does not need to be that), and that can be read from or written to a stream
(socket), or from a file header. It should also be adaptable to Android or
other environments that may not think in terms of files and sockets.
Andreas had some proposals in that area that should be revisited. It should
provide a recognizable /etc/magic number, and it should not need to worry
about machine endianness.

Dave