[squeak-dev] Image conversions (was Re: Squeak Trunk V3 Update Stream)

Eliot Miranda eliot.miranda at gmail.com
Thu Feb 15 19:20:27 UTC 2018


Hi David,

On Thu, Feb 15, 2018 at 9:50 AM, David T. Lewis <lewis at mail.msen.com> wrote:

> On Thu, Feb 15, 2018 at 07:05:26AM -0800, Eliot Miranda wrote:
> > Hi David, Hi Casey,
> >
> > > On Feb 15, 2018, at 6:05 AM, David T. Lewis <lewis at mail.msen.com>
> wrote:
> > >
> > >> On Thu, Feb 15, 2018 at 09:33:59AM +0100, Tobias Pape wrote:
> > >>
> > >>> On 15.02.2018, at 07:46, Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
> > >>>
> > >>> For the long term, I would love to have an "Export as..." in the
> world menu of a regular (trunk) image. :-)
> > >>
> > >> Or even better: have the vm detect whether it loads an image matching
> its bit-ness (is this a word?)
> > >> and if not, convert it (maybe with a "please wait" info). I mean, it
> works for RSqueak and IIRC SqueakJS???
> > >>
> > >> -t
> > >
> > > These are great ideas!
> > >
> > > Does anybody know any smart grad students looking for a challenging
> project?
> >
> >
> > My dream conversion would be taking the Smalltalk-80 image I have from
> the original Xerox tape and replacing its compiler and other relevant
> methods so that it used closures and Spur, and a conventional
> file/directory interface, but otherwise remained the simple bitblt based
> system with some 2000 methods and 200 classes.
> >
> > Such a system is great for learning because it is small enough for one
> person to learn all of it.  Of course it would be a bit bigger; the closure
> compiler is more complicated, but not by much.  But projects like replacing
> repainting windows by windows with a backing store, are afternoon projects
> in this context.
>
> That idea is crazy enough that it just might work :-)
>
> So just to explore the idea: If someone wanted to actually do this, how
> might they proceed?
>
> My guess would be that the fastest path might be to start with a modern
> oscog VMMaker image, and write enough new simulator support to handle the
> object memory and interpreter of the original Xerox system.
>

I would definitely go the other way.  The Spur bootstrap used the Simulator
to allow using the host to compile methods and inject them into the image.
So I would proceed as follows:

1. write a loader for the 16-bit Smalltalk-80 v2 image that brought in the
objects in their native format. This would involve writing a simple memory
manager sufficient for the very simple 16-bit object representation

2. write a converter that took this loaded image and constructed a Spur
format 32- or 64- bit image

3. using the host compiler, recompile all the methods in the Spur-format
image to use the current bytecode set, installing them in the image

4. excising specific classes (specifically the compiler classes) and
replacing them with a clone of the host compiler

Another way might be to take the Smnalltalk-80 source file, p[roduce an
edit that contained the system compiler, and then write a bootstrap (which
could use Pavel Krivanek's work for Pharo) from source.



> If the old Xerox image could be hosted in a modern simulator, then it
> should be possible to translate the object image into a format that could
> be executed directly on a Spur VM.
>

Right.


>
> But that is only a piece of the problem, because such an image would be
> useless without the updated compiler and file system interface, and I can't
> quite picture how those bootstrapping steps might be done.
>

Once one has an image in the simulator arbitrary manipulations are
possible.  So creating a clone of the compiler within the simulator and
switching over to it is quite possible.


>
> Dave
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180215/d9cd5d8f/attachment.html>


More information about the Squeak-dev mailing list