[Vm-dev] Help/advice tracking down a squeak-vm regression

David T. Lewis lewis at mail.msen.com
Sat May 12 21:34:20 UTC 2012


On Fri, May 11, 2012 at 01:40:15PM -0700, Eliot Miranda wrote:
>  
> On Fri, May 11, 2012 at 11:33 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:
> 
> >
> >
> > On 11.05.2012, at 19:43, Eliot Miranda wrote:
> >
> >
> >
> > On Fri, May 11, 2012 at 6:46 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:
> >
> >>
> >> I just checked. Most, if not all of the problems, come from Scratch's use
> >> of numbered primitives. They were deprecated in favor of named primitives.
> >>
> >> IMHO it would be reasonably simple to re-instate these primitives in the
> >> VM. Right now they are simply mapped to primitiveFail. This would get us
> >> back the ability to run many old images, unmodified.
> >>
> >
> > Alas I've used a few of these for Cog:
> >
> >  #(#(161 #primitiveSetIdentityHash)
> >     #(169 #primitiveNotIdentical)
> >     #(175 #primitiveBehaviorHash)
> >     #(176 #primitiveMaxIdentityHash)
> >     #(185 #primitiveExitCriticalSection)
> >     #(213 #primitiveContextXray)
> >     #(214 #primitiveVoidVMState)
> >     #(215 #primitiveVoidVMStateForMethod)
> >     #(218 #primitiveDoNamedPrimitiveWithArgs)
> >     #(240 #primitiveUTCMicrosecondClock)
> >     #(241 #primitiveLocalMicrosecondClock)
> >     #(242 #primitiveSignalAtUTCMicroseconds)
> >     #(243 #primitiveUpdateTimezone))
> >
> > I think your change set is the way to go.
> >
> >
> > Well, as David suggested, we could switch them based on the image magic
> > number.
> >
> 
> Good point.  Excuse me for missing that David.
> 

This seems like a workable enough approach (although I won't have a
chance to try it until next week). But I'm worried about one possible
side effect:

If we arrange for the interpreter to use an old primitive table when
the image format is either 6502 or 68000, and use the current primitive
table with closure support for all others, then we presumably will get
the backward compatibility to support older images.  But what happens
if someone wants to add closure support to Scratch? They would need
to go through the bootstrapping process that Eliot provides and that
Juan has successfully done for Cuis. If our VM just decides to turn
off the closure primitives when it detects a 6502 image, I expect
that this would be a problem for the closure bootstrapping.

Eliot, my assumption would be that in order to add closure support
to an older 6502 image, it is first necessary to have a VM with the
closure primitives in place. Is that correct? If so, I think that
we could still provide the backward compatibility strategy (which
Miriam Ruiz pointed out would be useful for some images other than
Scratch), but we would then want to *also* provide a way to tell
the VM that we really do want closure support in place. I am thinking
of e.g. an "-imageformat 6504" command line parameter to tell the
interpreter that the image expects closure support even though the
file header says 6502.

Dave



More information about the Vm-dev mailing list