On Sat, Mar 19, 2011 at 10:36 AM, David T. Lewis <lewis@mail.msen.com> wrote:

On Sat, Mar 19, 2011 at 04:39:05PM +0100, Igor Stasenko wrote:
>
> On 19 March 2011 17:09, <squeak-dev-noreply@lists.squeakfoundation.org> wrote:
> >
> > Dave Lewis uploaded a new version of VMMaker to project VM Maker:
> > http://www.squeaksource.com/VMMaker/VMMaker-dtl.222.mcz
> >
> > ==================== Summary ====================
> >
> > Name: VMMaker-dtl.222
> > Author: dtl
> > Time: 19 March 2011, 11:09:09 am
> > UUID: 809d5eb5-6f73-4e6a-a595-428ed4536dc0
> > Ancestors: VMMaker-dtl.221
> >
> > Fix MiscPrimitivePluginTest to properly test behavior of #primitiveFindSubstring and verify presence of a fix in TMethod>>argConversionExprFor:stackIndex: that performs type checking on string arguments.
> >
> >
>
> Dave, could you check it for oscog branch too?

Hi Igor,

Actually I was going to reply to your earlier question about
tests that you can run in an image (without VMMaker) that provide
coverage for the VM. But as soon as I looked at it I realized that
I has screwed this one up, so I fixed it and this the change you see
posted here.

There are a number of tests in the VMMaker package, mostly accumlated
during bug fixing but also some stuff to support the work I did
to support 64 and 32 bit images from a single code base (hence not
immediately relevant for inclusion in oscog). The two tests that
might be useful outside of VMMaker are JPEGReadWriter2PluginTest
and MiscPrimitivePluginTest, so I am attaching fileouts for these
two. Have a look and see if you thing they should go in the main
Squeak/Pharo images, or stay in VMMaker(s). These two along with
BitBltSimulationTest would also be suitable to include in oscog.

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)

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?

best,

Eliot

Dave