[Vm-dev] VM Maker: VMMaker-dtl.222.mcz

[David T. Lewis]

Hi Eliot, sorry I could not reply earlier.

Yes I agree it is worthwhile (and tedious) to get to one main line.
I'm pretty good at being tedious, so I can probably help with some
of that ;)  Other comments in line below, mainly related to the
VMMaker package as opposed to support code, build processes, etc.

On Sat, Mar 19, 2011 at 11:33:36AM -0700, Eliot Miranda wrote:
>  
> On Sat, Mar 19, 2011 at 10:36 AM, David T. Lewis <lewis at mail.msen.com>wrote:
> 
> >

<snip>

> >
> > I have stayed away from committing anything directly to the oscog
> > branch out of concern that it may lead to confusion between the
> > two branches if my 'dtl' initials start showing up there. I do
> > have some changes that can be applied to oscog (mostly to get
> > rid of cosmetic differences between the two branches that clutter
> > up the Montecello browser). I've sent a few of these to Eliot but
> > I don't know if that is the preferred approach going forward.
> > Advice welcome, as I do want to put some more effort into reconciling
> > the code bases pretty soon.
> >
> 
> I think we urgently need to merge.  I haven't looked yet but has Interpreter
> been refactored out from under ObjectMemory?  If it hasn't would you be
> happy for me to do that?  Things that I think need to be done to Interpreter
> are
> 
> a) refactor it out from under ObjectMemory and under InterpreterPrimitives
> b) use NewObjectMemory (it's a tad faster)
> c) throw away four of the method cache fields used only by Jitter, which de
> facto is now obsolete, and use the StackInterpreter's folding of
> primitiveIndex and primitiveFunction (it's a tad faster)
> d) also use platform-order floats (it's a tad faster)

No, I have not done any of this refactoring. So far I have only
incorporated simple things when I am confident that I understand
the impact. Which makes for slow going giving the range of things
I don't understand. I've also focused on trying to tidy up things
that show up as "lots of changes" in a Monticello browser, but
which are often just minor changes or cosmetic differences.

If you are able to step in and do some of the more complex refactoring,
that will get the job done much faster and better than waiting for
me to figure it out, so yes please!!! The only concern here is that
along the way we maintain the ability of the interpreter to read
and write old (6502 and 68000) images, and to continue to be able
to build the 64-bit image interpreter from the single code base.
It hopefully is a non-issue, but in any case I think I can help
with that aspect of it, so between us I'm sure we can make it work.

> 
> What is useful about Interpreter is
> a) it doesn't need a threaded or interrupt-driven heartbeat so it is simpler
> to port to bare metal
> b) it uses contexts and lacks all the complexity of context-to-stack mapping
> and so for many VM experiments it is significantly simpler to understand and
> extend, and for certain context-intensive computations it may be faster
> 
> So for me its worth keeping all these VMs, but the merge task is tedious and
> expensive so I would like there to be only one main line.
> 
> are we, the VM devs (Ian, Andreas, David, Igor, Myself, others?) in
> agreement?

I agree.

Thanks,
Dave