On Wed, Oct 6, 2010 at 9:46 AM, Bert Freudenberg <bert@freudenbergs.de> wrote:


On 06.10.2010, at 09:33, David T. Lewis wrote:

>
> On Wed, Oct 06, 2010 at 09:10:46AM -0700, Bert Freudenberg wrote:
>>
>> On 06.10.2010, at 08:10, David T. Lewis wrote:
>>>
>>> Yes, that is the intent. It should help with the transition to Cog in
>>> several ways:
>>>
>>> 1) It should now be safe to use Cog on your favorite image, even if you
>>> think you might want to go back to the old image format.
>>>
>>> 2) If you save an image from a Cog VM in the newer image format (6505)
>>> and distribute it to folks who may not be able to run Cog for one reason
>>> or another, it will now be possible for them to load that image back
>>> into a traditional VM.
>>>
>>> 3) If you want to use Cog to build an an image for wide distribution (the
>>> upcoming Squeak 4.2 release for example) and you want to distribute the
>>> image in the older image format (probably a prudent choice for the next
>>> round of releases), you can now load and save the image one time in a
>>> traditional VM, and the image will be put back into 6504 format.
>>>
>>> Caveat: I just finished doing this last night and it is only lightly
>>> tested.  I don't anticipate any problems, but you never know ;)
>>>
>>> The traditional VM should still run pre-closure images (format 6502)
>>> and will continue to save them in pre-closure 6502 format. Eliot
>>> set this up so that the conversion from 6502 pre-closure format to
>>> 6504 format happens automagically, but only when you first actually
>>> compile something with closure support. But I guess this should be
>>> tested to make sure I did not break it ;)
>>
>> Oh. That is great news - so you are saying that the Cog VM is able to
>> run old images, so it is safe to upgrade the VM anyway? E.g. I should
>> be able to run Etoys as-is on Cog, even being able to save the image,
>> until it is converted to closures?
>
> That is a good question. I'm not sure about this (and I'm away from
> Squeak now and cannot check). I'm assuming that Cog will always save
> the image as 6505 (closures + float reordering), and that loading
> it back into a standard VM would then result in a 6504 image format.
> It might be possible to put that image all the way back into 6502
> format, because it presumably would contain no actual closure bytecodes
> at this point. I had not actually thought about it until you asked
> just now.
>
> So the short answer is no, it is probably not safe to save an Etoys
> image from Cog if you will ever need to run it on an old pre-closure
> VM. But we should try it and find out for sure.
>
> Dave

If Cog could run an unmodified pre-closure image that would solve most compatibility issues indeed. Being able to save in the old 6502 format would be an added bonus, but might not even be necessary.

If Cog cannot do this then we need to figure out a way to cleanly install interpreter and Cog VMs side-by-side.

Neither of the Cog VMs can run pre-closure images.  They depend on the closure change to allow context-to-stack mapping.  I go into this in detail on my blog but essentially executing BLockContexts forces non-stack discipline (non-LIFO) for activations and requires synchronising the VM's hidden stack state with context stack state, whereas the closure scheme produces only stack discipline (LIFO) and eliminates any need to synchronise hidden stack state with context stack state.

cheers
Eliot

- Bert -