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

[David T. Lewis]

Apologies, I see that I failed to read Bert's note carefully. The
Scratch image is *not* using any numbered primitives in the range
200 - 229, which is the area of possible conflict with the newer Cog
and closures usages. So my question below concerning backward compatibility
is moot.

Regarding Bert's question:

> 
> Do we have a list of old primitive numbers and their corresponding
> new named equivalents?
> 

As far as I know we do not have such a list. There are comments in
the initializePrimitiveTable method indicating prior assignments, but
aside from that, it's necessary to refer to the older versions in
Monticello.

Dave


On Sat, May 12, 2012 at 05:34:20PM -0400, David T. Lewis wrote:
>  
> 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