[Vm-dev] A proposal to split VMMaker into subpackages WAS: [ VM Maker: VMMaker-dtl.304.mcz ]

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Mar 19 20:29:53 UTC 2013


2013/3/19 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
>
> On Tue, Mar 19, 2013 at 5:19 AM, David T. Lewis <lewis at mail.msen.com> wrote:
>>
>>
>> On Tue, Mar 19, 2013 at 12:51:02PM +0100, Esteban Lorenzano wrote:
>> >
>> > yes... in that case, since some time now I want to propose a VMMaker package split.
>> > I still do not have a real suggestion now, but looks to me that we should be able to split it in something like:
>> >
>> > VMMaker-Core
>> >       VMMaker-Cog
>> >       VMMaker-Interpreter
>> >       VMMaker-Plugins
>> >               VMMaker-Plugin1
>> >               ...
>> >               VMMaker-PluginN
>> > VMMaker-InterpreterSimulation
>> > VMMaker-JITSimulation
>> >
>> > etc...
>> >
>> > (hierarchy for dependences)
>> >
>> > this time we can reduce the granularity and restrain the changes just to where it is needed...
>> >
>> > what do you think?
>> >
>>
>> This will be a good idea when, and only when, we have achieved real progress
>> in merging the oscog and trunk branches. We are not there yet.
>>
>> I would be interested to hear from Eliot, but from my point of view this would
>> make it much more difficult to manage the changes between the two branches.
>>
>> I have some experience in dealing with this in the OSProcess and CommandShell,
>> and I found that in some cases splitting things into too many packages can
>> cause a lot of unnecessary work with little real benefit. I would rather live
>> with the wasted disk space and rely on Monticello to manage the changes.
>>
>> Clearly though it is a good objective longer term, and we will get there.
>>
>> Dave
>
>
> Personally I like the following broad separation:
>
> 1. VM (Interpreter, StackInterpreter, CoInterpreter, Cogit, Simulation)
> 2. Plugins
> 3. Slang + VMMaker
>
> The VM and the simulator are too tightly bound to separate and I don't see much use in separating off the simulator; it's not that large.  Note that the processor support for simulation of the Cog VM is in Cog already.
>
> Plugins are logically distinct and it would be a step towards merging the trunk interpreter and Cog if plugins were in a separate package and merged.  I'd be for doing this quite soon.
>
> With Slang + VMMaker separated we might find it easier to experiment with e.g. using the Cog Slag on the Interpreter (the other way round isn't going to work, sicne Cog requires lots of Slang extensions, especially with record types such as CogMethod).
>
> But the main problem I see here is that there's lots of Slang dependencies on the class side of Interpreter classes, all of the translation protocol for example.  That might be quite hard to tease out.  I think separating plugins is the worthwhile step now.  What do y'all think?
> --
> best,
> Eliot
>

My opinion is that starting the separation now might help pointing out
the commonalities/differences between interpreter and COG branch and
force a faster convergence.

Trying to backport the LargeInteger v2 plugins, I saw that there is an
important difference in the shared variables, notably class variables
vs poolDictionary, for example VMBIGENDIAN is not accessible in
Interpreter plugins. So it would probably be the first job.

>From my far sighted POV, your suggestion seems OK as a first stage.

On a second stage, one thing that upsets me is the obsolete VM
interpreter code in oscog branch and already obsolete StackInterpreter
code in interpreter trunk...
So I would welcome a separation of these two pieces, but there is
surely too much inheritance involved right now, so I trust you if you
say it's not a practical idea.

Nicolas


More information about the Vm-dev mailing list