Hi Dave
On 08.07.2015, at 02:25, David T. Lewis <lewis at mail.msen.com> wrote:

> 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.

Thanks for the quite enlightening explanation. :)
Together with Eliot's reply this makes going on a lot more predictable for
me. Thanks!

Best regards
	-Tobias