<br><br><div class="gmail_quote">On Thu, Jul 8, 2010 at 5:38 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5"><br>
On Wed, Jul 07, 2010 at 06:01:42PM -0700, Andreas Raab wrote:<br>
><br>
> On 7/7/2010 3:11 PM, David T. Lewis wrote:<br>
> >Personally, I do not have a good sense of how this should be handled.<br>
> >I expect that we will want to keep the traditional SqueakVM alive<br>
> >and healthy for at least a few years into the future, but I do not<br>
> >know if it is better to merge it with the StackVM, or just let it<br>
> >be separatedly maintained for some period of time.<br>
><br>
> Eliot needs to comment on this but the intention was always to keep the<br>
> "classic" Squeak VM working and add the context-to-stack mapping<br>
> (StackInterpreter) and the JIT (CoInterpreter). So the real work would<br>
> be to merge the Interpreter sources and promote any necessary changes to<br>
> [Stack|Co]Interpreter as needed.<br>
<br>
</div></div>So possibly the common portions of Interpreter and StackInterpreter could<br>
be moved into a shared base class? The hierarchy looks a bit tortured,<br>
but it should keep both the simulators and the C code generator happy.<br>
<br>
ObjectMemory<br>
InterpreterBase<br>
NewObjectMemory<br></blockquote><div><br><br>I am completly ignorant, but cannnot we have a better name than NewObjectMemory? What if then we have a even newer one?<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
StackInterpreter<br>
CoInterpreter<br>
CogVMSimulator ...<br>
Interpreter<br>
InterpreterSimulator ...<br>
<br>
The above structure could be accomplished in steps as time permits,<br>
checking at each update to ensure that the generated interp.c remains<br>
unchanged for both Interpreter and CoInterpreter.<br>
<br>
If it turns out that the methods in StackInterpreter are more or less<br>
a superset of those in Interpreter (I have not checked in detail), then<br>
the InterpreterBase class would go away:<br>
<br>
ObjectMemory<br>
Interpreter<br>
InterpreterSimulator ...<br>
NewObjectMemory<br>
StackInterpreter<br>
CoInterpreter<br>
CogVMSimulator ...<br>
<br>
Dave<br>
<br>
</blockquote></div><br>