<br><br><div class="gmail_quote">On Thu, Jul 8, 2010 at 5:38 AM, David T. Lewis <span dir="ltr">&lt;<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>&gt;</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>
&gt;<br>
&gt; On 7/7/2010 3:11 PM, David T. Lewis wrote:<br>
&gt; &gt;Personally, I do not have a good sense of how this should be handled.<br>
&gt; &gt;I expect that we will want to keep the traditional SqueakVM alive<br>
&gt; &gt;and healthy for at least a few years into the future, but I do not<br>
&gt; &gt;know if it is better to merge it with the StackVM, or just let it<br>
&gt; &gt;be separatedly maintained for some period of time.<br>
&gt;<br>
&gt; Eliot needs to comment on this but the intention was always to keep the<br>
&gt; &quot;classic&quot; Squeak VM working and add the context-to-stack mapping<br>
&gt; (StackInterpreter) and the JIT (CoInterpreter). So the real work would<br>
&gt; be to merge the Interpreter sources and promote any necessary changes to<br>
&gt; [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>