[squeak-dev] The Inbox: Files-dtl.166.mcz

Eliot Miranda eliot.miranda at gmail.com
Thu Sep 22 18:09:59 UTC 2016

Hi David,

On Mon, Sep 5, 2016 at 7:14 AM, David T. Lewis <lewis at mail.msen.com> wrote:

> On Mon, Sep 05, 2016 at 01:08:38PM +0800, Ben Coman wrote:
> > On Mon, Sep 5, 2016 at 11:38 AM, David T. Lewis <lewis at mail.msen.com>
> wrote:
> > > On Mon, Sep 05, 2016 at 02:33:43AM +0200, Eliot Miranda wrote:
> > >> Hi Both,
> > >>
> > >>     the adoptInstance: code fails on V3 because of compact classes.
> One cannot change a 1-word header instance if a compact class into a 1-word
> header of a non-compact class; there is no room in a 1-word header for the
> 32-bit non/compact class reference.
> > >>
> > >
> > > Hi Eliot,
> > >
> > > Right. You have documented this clearly in VMMaker. It is a reasonable
> and
> > > expected limitation.
> > >
> > >> David, fur give me for broaching what may be an emotionally painful
> topic.  I have no desire to cause you pain, but IMO this is important.
> > >>
> > >> We should /NOT/ hamstring code for either Spur or V3 with needless
> and expensive compatibility.  David, you're going to have to accept that
> the two will diverge.  Instead, try and think of a mechanism that supports
> tracking the differences instead of trying to keep the code bases the same.
> IMO effort put into keeping the two the same is effort wasted.
> > >
> > > My initial attempt to do this is http://www.squeaksource.com/
> TrunkUpdateStreamV3.
> > > For example, to see differences in the Collections package, use
> Monticello from
> > > trunk Squeak to look at differences in the Collections.V3 package in
> the
> > > TrunkUpdateStreamV3 repository. The other differences are in
> Compiler.V3,
> > > Kernel.V3, and System.V3 (along with the trivial difference in
> Files.V3 that
> > > was the subject of this thread).
> > >
> > > My question concerning the Files package arises directly from this.
> Aside
> > > from a single optimization in Files, all other significant differences
> > > have been contained within the Compiler, Collections, System, and
> Kernel
> > > packages.
> > >
> > >> Instead one could put effort into a Spur interpreter VM,
> > >
> > > I do not want to volunteer to start a new VM project until I finish the
> > > last one that I committed to do. I have said this before. And it's
> really
> > > just not someething that I can take on right now.
> >
> > Dave, Just to clarify... If there happen to be a Context Interpreter
> > Spur VM, you would not be concerned about V3 compatibility?
> >
> Hi Ben,
> Ideally we would like to be able to have the context and stack interpreters
> built from the same code base, and in that scenario the context interpreter
> would be of little interest for a Spur object memory. The stack interpreter
> already exists for both V3 and Spur, and it is an improvement on the
> traditional
> context interpreter.
> That said, there are things in the VMMaker code base for the interpreter VM
> that could usefully be moved to the VMMaker.oscog code base, and Eliot is
> quite rightly trying to encourage someone to step forward and make that
> happen.

Thanks for this list!  I agree with all of it except where I've commented.

> If anyone is interested, I'll be happy to help where I can (but it's not
> a project that I want to try to undertake myself right now). Off the top
> of my head, here are some things that might be of interest from the VMMaker
> code base:
> - Refactor interpreter and object memory hierarchies, methods specific
>   to context versus stack interpreters in their own hierarchies, no method
>   overrides, use #subclassResponsibility in common superclasses
> - For methods specific to the context interpreter, update them from the
>   more recent code in VMMaker
> - 32 versus 64 bit object word size as a compile time option (not as part
>   of source code generation), single generated C code base

This is infeasible.  The way Spur 64- vs 32- bit is architected is
different from V3.  There are distinct subclasses of SpurMemoryManager
(Spur32BitMemoryManager, Spur32BitCoMemoryManager, Spur64BitMemoryManager,
Spur64BitCoMemoryManager) which works well in being able to optimize the
code for each variant, but makes it very difficult to generate #if SPUR64
style code.  Further, the generation of the Cogit is one file per processor.

The separate generation works fine.  We have compile time options for
fairly small changes, such as IMMUTABILITY and Pharo vs Squeak (which
affects the FilePlugin).  But for something as pervasive as 64- vs 32- bits
it's not practical and IMO of little benefit.

> - Ensure that context and stack interpreters (not necessarily Cog) compile
>   and run on 64-bit platforms (no 32-bit libraries)
> - Add support for loading older 6504 images (should work with stack
> interpreter)
> - Memory access C macros reimplemented in slang, allow similator to execute
>   the lowest level functions in Smalltalk
> - Browse generated C code for methods in Squeak browsers

and just to be clear, start the work from the oscog fork, not the VMMaker
trunk, since so many changes have been made to Slang to get the Cog and
Spur systems going.

> Dave

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160922/a51ceabf/attachment.htm

More information about the Squeak-dev mailing list