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

[Chris Muller]

Great, thanks for the update and for seeing this through Dave!

On Sat, Apr 28, 2012 at 5:41 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>
> 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>