A note concerning VMMaker merge (Re: [Vm-dev] VM Maker: VMMaker-dtl.270.mcz)

[David T. Lewis]

I have been slowly nibbling away at the problem of converging the VMMaker
branches, and this commit is another small step in that direction. My hope
is that a few more updates will bring VMMaker trunk to the point where it
will be possible to generate both a StackInterpreter and a traditional
Interpreter VM, and be able to compile either on the existing Subversion
trunk sources.

I have been working on this in the VMMaker trunk branch, as opposed to
the oscog branch, simply because I am familiar with it and I am able to
make incremental progress towards the merge while keeping the standard
intepreter healthy at each step. There are probably faster and better
ways to accomplish this, but I am happy to make progress in small steps,
so that's the approach I have been taking.

>From the point of view of doing the updates in VMMaker trunk, there
are a few key guidelines that I am trying to follow:

1) First and foremost, do no harm to the standard interpreter VM. Make
sure that each update produces generated C code that is equivalent to,
or better than, the last. Don't do anything that would make Dan Ingalls
recoil in horror.

2) Retain the 32/64 bit object memory support, and hopefully make it
available for StackInterpreter and Cog in the future. Also keep
SlangBrowser and MemoryAccess functional. Keep VMMakerTool working
while also adopting CrossPlatformVMMaker from oscog.

3) Commonize the oscog and trunk branches as quickly as possible,
particularly with respect to interpreter primitives and the portions
of object memory and interpreter that are inherently common. Where
differences are necessary, factor them out such that objective #1
still met.

I think I can safely say that converging the branches is taking a good
deal more time and effort that I might have expected, but progress is
progress, and the goal of converging the branches is certainly achievable.

So ... FWIW that's what I've been trying to do with these updates.

Dave


On Sat, Apr 28, 2012 at 04:33:55PM -0400, David T. Lewis wrote:
>  
> Commit notice too large for the list, forwarding trimmed version:
> 
> ----- Forwarded message from vm-dev-owner at lists.squeakfoundation.org -----
> 
> Delivered-To: list-vm-dev at lists.squeakfoundation.org
> Date: Sat, 28 Apr 2012 20:23:42.546 0000
> From: commits at source.squeak.org
> To: vm-dev at lists.squeakfoundation.org
> Reply-To: vm-dev at lists.squeakfoundation.org
> Subject: VM Maker: VMMaker-dtl.270.mcz
> 
> David T. Lewis uploaded a new version of VMMaker to project VM Maker:
> http://source.squeak.org/VMMaker/VMMaker-dtl.270.mcz
> 
> ==================== Summary ====================
> 
> Name: VMMaker-dtl.270
> Author: dtl
> Time: 28 April 2012, 4:23:12.307 pm
> UUID: f17e6e57-c227-47a4-876c-287e33175b48
> Ancestors: VMMaker-dtl.268
> 
> VMMaker 4.9
> 
> Add StackInterpreter and related classes, with additional changes to support ObjectMemory / Interpreter refactoring. The organization of the traditional Interpreter and ObjectMemory are now better aligned with the oscog branch of VMMaker, while the generated code for a standard VM remains equivalent to prior versions.
> 
> NewObjectMemory and StackInterpreter are not yet ready for use, and as always Cog and StackInterpreter VMs should be build from the oscog branch.
> 
> Upgrade note - If problems are experienced in generating a standard VM after loading this version of VMMaker, try recompiling the VMClass hierarchy, and reinitializing ObjectMemory and Interpreter. Pool variables are now used extensively, and in some cases a recompile may be needed to support the updates.
> 
> Changes that affect generated code:
> 
> - Allow inlining of ObjectMemory>>accessibleObjectAfter:
> 
> - All other changes are cosmetic, related to variable ordering, temp variable names, extraneous white space, etc.
> 
> - Generated code for the standard interpreter is equivalent to previous version, except that #accessibleObjectAfter: is now inlined.
> 
> Interpreter / ObjectMemory refactorings:
> 
> - Add StackInterpreter, StackInterpreterPrimitives, InterpreterStackPages, VMStructType and ReadOnlyArrayWrapper from oscog.
> 
> - Add CogClass and Cogit stub classes to support the refactoring.
> 
> - Add ObjectMemory subclass ClassicObjectMemory. Move methods that were overridden in NewObjectMemory from ObjectMemory to ClassicObjectMemory, and retain abstract implementations in ObjectMemory. Methods with 'self subclassResponsibility' are abstract and are not translated to C.
> 
> - The traditional object memory used with Interpreter is now ClassicObjectMemory, and the new object memory for StackInterpreter is NewObjectMemory, both of which are subclassed from ObjectMemory.
> 
> =============== Diff against VMMaker-dtl.268 ===============
> 
> <snip>