On Tue, Jul 07, 2015 at 05:31:38PM +0200, Tobias Pape wrote:
> 
> On 07.07.2015, at 17:26, Chris Muller <asqueaker at gmail.com> wrote:
> 
> >>> Interpreter VM will not be able to run Spur images going forward.
> >> 
> >> Pardon?
> > 
> > Download latest Spur image and changes:
> > 
> >    http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.image
> > 
> >   http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.changes
> > 
> > and latest interpreter VM.  Then try:
> > 
> >   squeak trunk46-spur.image
> > 
> > Results:
> > 
> > This interpreter (vers. 0) cannot read image file (vers. 6521).
> > Press CR to quit...
> 
> 
> Well, your sentence sounded as if there's no intention of making the interpreter 
> VM SPUR-aware whatsoever. Surely I got that wrong, didn't I?
>

We are probably tripping over some terminology issues here.

We used to refer to the "standard VM" as distinct from the "experimental"
Cog VMs. That terminology is no longer appropriate, because most people
now use Cog (and Spur), and IMHO the terms "standard" and "experimentalt"
are no longer helpful.

When Eliot and Andreas began the work that led to Cog (and now Spur), the
first step (see Eliot's blog) was development of the stack-oriented interpreter,
which was an improvement over the original context-based interpreter of the
standard Squeak VM. The idea was (and still is) that the standard interpreter
VMs would migrate to the stack interpreter model.

If you look at the VMMaker package (as opposed to VMMaker.oscog) you will
find additional refactoring of the interpreter and object memory classes to
support that original design intent. The VMs that we now call "interpreter
VM" are generated from that code base, currently building from the context
interpreter classes rather than the stack interpreter classes.

There is some work remaining to be done in order to be able to generate
an "interpreter VM" from the stack interpreter classes in the VMMaker
package. Once that is accomplished, the context interpreter will become
a historical artifact, and the "interpreter VM" builds will in fact deliver
the stack based interpreter VM as developed by Eliot and maintained in
the VMMaker.oscog branch.

Beyond that, my powers of prediction are less clear. There is significant
code merge work remaining to be done, but regardless of how (or when or
by whom) that gets done, there is no reason that the new Spur object model
should not be adopted, and no reason why an "interpreter VM" should not
be able to support it.

Dave