<br><br><div class="gmail_quote">On Wed, Oct 6, 2010 at 9:46 AM, Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
On 06.10.2010, at 09:33, David T. Lewis wrote:<br>
<br>
&gt;<br>
&gt; On Wed, Oct 06, 2010 at 09:10:46AM -0700, Bert Freudenberg wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 06.10.2010, at 08:10, David T. Lewis wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Yes, that is the intent. It should help with the transition to Cog in<br>
&gt;&gt;&gt; several ways:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1) It should now be safe to use Cog on your favorite image, even if you<br>
&gt;&gt;&gt; think you might want to go back to the old image format.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 2) If you save an image from a Cog VM in the newer image format (6505)<br>
&gt;&gt;&gt; and distribute it to folks who may not be able to run Cog for one reason<br>
&gt;&gt;&gt; or another, it will now be possible for them to load that image back<br>
&gt;&gt;&gt; into a traditional VM.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 3) If you want to use Cog to build an an image for wide distribution (the<br>
&gt;&gt;&gt; upcoming Squeak 4.2 release for example) and you want to distribute the<br>
&gt;&gt;&gt; image in the older image format (probably a prudent choice for the next<br>
&gt;&gt;&gt; round of releases), you can now load and save the image one time in a<br>
&gt;&gt;&gt; traditional VM, and the image will be put back into 6504 format.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Caveat: I just finished doing this last night and it is only lightly<br>
&gt;&gt;&gt; tested.  I don&#39;t anticipate any problems, but you never know ;)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The traditional VM should still run pre-closure images (format 6502)<br>
&gt;&gt;&gt; and will continue to save them in pre-closure 6502 format. Eliot<br>
&gt;&gt;&gt; set this up so that the conversion from 6502 pre-closure format to<br>
&gt;&gt;&gt; 6504 format happens automagically, but only when you first actually<br>
&gt;&gt;&gt; compile something with closure support. But I guess this should be<br>
&gt;&gt;&gt; tested to make sure I did not break it ;)<br>
&gt;&gt;<br>
&gt;&gt; Oh. That is great news - so you are saying that the Cog VM is able to<br>
&gt;&gt; run old images, so it is safe to upgrade the VM anyway? E.g. I should<br>
&gt;&gt; be able to run Etoys as-is on Cog, even being able to save the image,<br>
&gt;&gt; until it is converted to closures?<br>
&gt;<br>
&gt; That is a good question. I&#39;m not sure about this (and I&#39;m away from<br>
&gt; Squeak now and cannot check). I&#39;m assuming that Cog will always save<br>
&gt; the image as 6505 (closures + float reordering), and that loading<br>
&gt; it back into a standard VM would then result in a 6504 image format.<br>
&gt; It might be possible to put that image all the way back into 6502<br>
&gt; format, because it presumably would contain no actual closure bytecodes<br>
&gt; at this point. I had not actually thought about it until you asked<br>
&gt; just now.<br>
&gt;<br>
&gt; So the short answer is no, it is probably not safe to save an Etoys<br>
&gt; image from Cog if you will ever need to run it on an old pre-closure<br>
&gt; VM. But we should try it and find out for sure.<br>
&gt;<br>
&gt; Dave<br>
<br>
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.<br>
<br>
If Cog cannot do this then we need to figure out a way to cleanly install interpreter and Cog VMs side-by-side.<br></blockquote><div><br></div><div>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&#39;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.</div>
<div><br></div><div>cheers</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
- Bert -<br>
<br>
</font></blockquote></div><br>