<br><br><div class="gmail_quote">On Tue, Jun 22, 2010 at 6:52 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>Does the Cog VM update to a new image format version number when<br>
snapshotting?</blockquote><div><br></div><div>Yes it does. It and the Stack VM set the image format to 6505. This reflects the platform-order floats change which is not backwards-compatible.</div><div><br></div><div>Note that Cog also insists on a 6504 or 6505 format image to start-u, i.e. it won;t attempt to start-up non-closure images.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> If not, then I have the following proposal:<br>
<br>
An image that is snapshotted by a Cog VM is going to expect Cog<br>
support when next loaded. It would be good if the image snapshot<br>
declares this explicitly so the VM can exit in a controlled manner<br>
if unable to provide the required support.<br>
<br>
I propose that we add a Cog bit to the image format version number,<br>
as illustrated in the attached change set. This can be extended in<br>
the future such that an image that requires "foo" support from a VM<br>
will set the "foo bit".<br>
<br>
The original Squeak images had image format number 6502. With closure<br>
support, this became 6504. Requiring Cog implies a requirement for<br>
closure support, so an image that requires Cog support would be 6505.<br>
For 64-bit images, the corresponding image format numbers are 68000,<br>
68002, and 68003. Note that bit 0 was previously unused, which means<br>
that Cog would become the recipient of the highly-coveted bit zero<br>
position ;)<br></blockquote><div><br></div><div>:) Looks like I accidentally chose the right bit :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
There are plenty of free bits available to be allocated for future<br>
capabilities, and the high order bit would be reserved for expansion<br>
if the need ever arises.<br>
<br>
Dave<br>
<br>
<br></blockquote></div><br>