[Vm-dev] VM Maker: VMMaker.oscog-eem.363.mcz

[Eliot Miranda]

On Wed, Sep 11, 2013 at 8:58 AM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Wed, Sep 11, 2013 at 07:55:14AM -0700, Eliot Miranda wrote:
> >
> > On Tue, Sep 10, 2013 at 4:14 PM, David T. Lewis <lewis at mail.msen.com>
> wrote:
> >
> > >
> > > On Tue, Sep 10, 2013 at 09:50:14PM +0000, commits at source.squeak.orgwrote:
> > > >
> > > > Eliminate bytesPerWord in favour of wordSize (Smalltalk wordSize is
> > > > the model here).  wordSize is shorter.  However, still generate
> > > > BytesPerWord for wordSize since e.g. mpegtype.h has a parameter
> > > > named WordSize.
> > > >
> > >
> > > FYI a number of constants including BytesPerWord and BaseHeaderSize
> > > are replaced by message sends in VMM trunk as part of the changes
> > > that put this all under compile time control (as opposed to defining
> > > at code generation time). It would probably be good to apply these
> > > changes to oscog at some point also, although I cannot realistically
> > > offer to put any time into it right now.
> > >
> >
> > Agreed.  I was reluctant to do this earlier.  Alas while it might allow
> one
> > to run e.g. a 64-bit ObjectMemory alongside a 32bit ObjectMemory, the
> > pervasive use of class and pool variables means its not possible to run
> an
> > ObjectMemory against a SpurMemoryManager.  I'd rather change the code
> base
> > as little as possible than risk breaking things, so I'm happy to live
> with
> > e.g. the compact class indices staying in class/pool vars.
> >
> > BTW, David, I implemented
> > NewObjectMemory>>eeInstantiateClassIndex:format:numSlots: (in
> > VMMaker.oscog-eem.369) which needs to set the Size4Bit.  It contains a
> > comment asking you to check the code :-).  I wonder if, in your copious
> > free time, you might do just that?  No hurry, and indeed I hope to render
> > ObjectMemory and NewObjectMemory obsolete asap :-).
>
> I will look at it this weekend. There is another thing that I did in trunk
> that might be relevant - I refactored ObjectMemory so that it has separate
> NewObjectMemory and ClassicObjectMemory, and no method overrides.


Indeed.  I took a tilt at this a few months back but time and energy were
in short supply.  There were some tricky differences :-(.


> The intent
> is to get a clear separation of the (limited) actual differences between
> the two. I think this is consistent with your original design intent, so
> I was trying to do some follow up work in that regard. If you have a
> chance,
> please try loading http://source.squeak.org/VMMaker/update-dtl.13.mcm
> into a clean image and let me know if the class hierarchy for the object
> memory and interpreter make sense to you.
>

They do.  But the devil is in the details.  The sooner we can merge the
better, but there's real work here.


> I definitely don't think we should try to do any updates of these things
> while you are in the middle of the Spur work (and I would not have time
> to work on in now anyway), but it would be good to know if they make sense
> directionally.
>
> Dave
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130911/aec7ef42/attachment-0001.htm