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

David T. Lewis lewis at mail.msen.com
Mon Sep 5 14:14:10 UTC 2016


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.

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 
- 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

Dave



More information about the Squeak-dev mailing list