On Thu, Oct 17, 2019 at 5:10 PM tim Rowledge <tim at rowledge.org> wrote:

>
> > On 2019-10-17, at 4:19 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> > But I still think that the right way is to export one's code as packages
> and rebuild.  Most code "just works", but nothing is going to automagically
> replace one's use of someObject/nextObject, or the assumption that Float is
> the only float class, so the user is still going to have to test their code
> carefully.
>
> Extra hassles come from images where a great deal of setup was done and is
> not necessarily encoded in, err, code... and of course a lot of these older
> images are using older code for some important parts. Updating them can
> easily be a barrier too far.
>
> A VM capable of running a 32bit image is clearly possible. One might
> consider simplifying the problem a little by asserting that since 32bit
> Spur images are easy to convert there is no need to worry about handling
> them with this VM. That also removes the need to deal with the clevernesses
> added since the advent of the Spur images, which should simplify things a
> tad. To be honest, it's probably best to just run a plain(ish) interpreter
> VM (perhaps the stackvm enhancements would be smart to use) and accept that
> such old images will just be a bit slow by comparison.
>
> We already have VMs with most of these attributes so with luck the
> remaining work is, surely,  mostly making sure that 32 bit values do not
> get incorrectly promoted.
>
> tim
>

Those VMs do not work anymore because OS vendors (particularly Apple) like
to deprecate and then disable old APIs. So the VM needs to be updated to
keep on top of that.

The easiest might be to take a current VM and replace its object engine
with an old interpreter.

- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191017/ca832c57/attachment.html>