<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 11, 2013 at 8:58 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Wed, Sep 11, 2013 at 07:55:14AM -0700, Eliot Miranda wrote:<br>
><br>
> On Tue, Sep 10, 2013 at 4:14 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
> ><br>
> > On Tue, Sep 10, 2013 at 09:50:14PM +0000, <a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a> wrote:<br>
> > ><br>
> > > Eliminate bytesPerWord in favour of wordSize (Smalltalk wordSize is<br>
> > > the model here). wordSize is shorter. However, still generate<br>
> > > BytesPerWord for wordSize since e.g. mpegtype.h has a parameter<br>
> > > named WordSize.<br>
> > ><br>
> ><br>
> > FYI a number of constants including BytesPerWord and BaseHeaderSize<br>
> > are replaced by message sends in VMM trunk as part of the changes<br>
> > that put this all under compile time control (as opposed to defining<br>
> > at code generation time). It would probably be good to apply these<br>
> > changes to oscog at some point also, although I cannot realistically<br>
> > offer to put any time into it right now.<br>
> ><br>
><br>
> Agreed. I was reluctant to do this earlier. Alas while it might allow one<br>
> to run e.g. a 64-bit ObjectMemory alongside a 32bit ObjectMemory, the<br>
> pervasive use of class and pool variables means its not possible to run an<br>
> ObjectMemory against a SpurMemoryManager. I'd rather change the code base<br>
> as little as possible than risk breaking things, so I'm happy to live with<br>
> e.g. the compact class indices staying in class/pool vars.<br>
><br>
> BTW, David, I implemented<br>
> NewObjectMemory>>eeInstantiateClassIndex:format:numSlots: (in<br>
> VMMaker.oscog-eem.369) which needs to set the Size4Bit. It contains a<br>
> comment asking you to check the code :-). I wonder if, in your copious<br>
> free time, you might do just that? No hurry, and indeed I hope to render<br>
> ObjectMemory and NewObjectMemory obsolete asap :-).<br>
<br>
</div></div>I will look at it this weekend. There is another thing that I did in trunk<br>
that might be relevant - I refactored ObjectMemory so that it has separate<br>
NewObjectMemory and ClassicObjectMemory, and no method overrides.</blockquote><div><br></div><div>Indeed. I took a tilt at this a few months back but time and energy were in short supply. There were some tricky differences :-(.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The intent<br>
is to get a clear separation of the (limited) actual differences between<br>
the two. I think this is consistent with your original design intent, so<br>
I was trying to do some follow up work in that regard. If you have a chance,<br>
please try loading <a href="http://source.squeak.org/VMMaker/update-dtl.13.mcm" target="_blank">http://source.squeak.org/VMMaker/update-dtl.13.mcm</a><br>
into a clean image and let me know if the class hierarchy for the object<br>
memory and interpreter make sense to you.<br></blockquote><div><br></div><div>They do. But the devil is in the details. The sooner we can merge the better, but there's real work here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I definitely don't think we should try to do any updates of these things<br>
while you are in the middle of the Spur work (and I would not have time<br>
to work on in now anyway), but it would be good to know if they make sense<br>
directionally.<br>
<br>
Dave<br></blockquote></div><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>