On Thu, Apr 12, 2018 at 02:15:00PM -0700, Eliot Miranda wrote:
> Hi Bert, Hi David,

Hi,

I am hopelessly behind on emails and I probably missed a lot of the
discussion, but I'll try to catch up a bit.

Bert is right that saying that a 64 bit host VM should work with a 32 bit
image, and that this is the right thing to do. In theory it should also
be the easiest thing to do, but in practice it probably is not.

Eliot is right is saying that making a 64 bit host/32 bit image VM is
non-trivial. There probably are no big issues, but I would expect a lot
of small issues and a lot of effort required to make it happen. The general
approach of generating a single ./src base for the 32/64 bit images would
probably still work for the oscog code base, but actually doing all of
those changes, while also adding the cog code generator differences
(which I actually know very little about) does not sound like a small
project to me, and even with the best of intentions it would not get
done any time soon.

John summarized nicely below, I would add only that for the base interpreter
VM, all four combinations of 32 and 64 bit host and image worked properly
at one point, and I say "at one point" only because I have not recently
tried the 64 bit image on 32 bit host combination, and the last time I
tried it there was a bit rot regression. We also had 32/64 bit FFI working,
but that was in Mantis and never made its way into the VM.

Tim has a really good suggestion about handling image conversion at image
load time. This might work and we should give it some thought. A trivially
simple example is the interpreter VM loading Cog 6505 images, and running
and saving in its native 6504 format. I don't know how extensible this
approach is, but the general idea of a VM that can load and run a wide
variety of input formats, while saving them in its own preferred native
format, makes a lot of sense to me.

Eliot suggests using worker images to do image conversions. That will be
messy from a support and distribution point of view, but it is probably
our best and only near term solution.

One more note in line below.

> 
> On Thu, Apr 12, 2018 at 1:57 PM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> 
> > On 12 April 2018 at 22:45, John McIntosh <johnmci at smalltalkconsulting.com>
> > wrote:
> >
> >> Actually it is a 64bit compiled application that works with 32bit images,
> >> there was also a 64bit application that works with 64bit images. However
> >> was Eliot points out the format of a 64bit image is different because it
> >> has other immediate types, and different context structures. The original
> >> 64bit image type didn't have any of those changes.
> >>
> >
> +1
> 
> ???The Spur image, yes.
> >
> > But we're only talking about running a 32 bit image on a 64 bit VM. Here's
> > a refresher on the terminology:
> >
> > http://squeakvm.org/squeak64/faq.html???
> >
> 
> So am I being a prima donna by finding this page misleading?

Prima donna? no. Defensive? perhaps.

Bert was referring to that page because it clarifies the terminology. That
is a helpful thing in the context of a discussion like this.

Dave

> It's
> referring to a system that few if any people use.  It doesn't mention that
> we have a 64-bit system that is much faster, has a full FFI, etc.
> Shouldn't this page at least say that there is a more modern 64-bit system
> along with a URL, and state that this VM is effectively obsolete?  Does
> this come over like me trying to kill the old VM?  I wish people would be
> frank about their feelings (if any) here rather than keeping silent.  I
> don't want to offend, but I do want to provide high-performance functional
> systems with the person power we have available, and provide good
> information to the new user.  I do feel frustrated when I see the old
> 64-bit system still described as if it's current.  I wonder if people feel
> as strongly for the old 64-bit system.
> 
> 
> 
> > - Bert -
> >
> >
> >
> >>
> >>
> >> On Thu, Apr 12, 2018 at 1:34 PM, Bert Freudenberg <bert at freudenbergs.de>
> >> wrote:
> >>
> >>>
> >>>
> >>> On 12 April 2018 at 16:31, Tobias Pape <Das.Linux at gmx.de> wrote:
> >>>
> >>>> Hi
> >>>>
> >>>> On 12.04.2018, at 16:05, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >>>>
> >>>> Hi Bert,
> >>>>
> >>>>
> >>>> On Apr 12, 2018, at 6:03 AM, Bert Freudenberg <bert at freudenbergs.de>
> >>>> wrote:
> >>>>
> >>>> If that's indeed the case we need to make a 64 bit VM for 32 bit
> >>>> images. I think this should be just a matter of picking the right compiler
> >>>> options.
> >>>>
> >>>>
> >>>> How so?  AFAIA it is not.  It means, for example, changing every memory
> >>>> access for an instance variable from 64 to 32 bits.  It is non-trivial.
> >>>>
> >>>>
> >>>> But wasn't that done once already?
> >>>>
> >>>> I see Squeak 5.7.4.1 (John Macintosh did it I think).
> >>>> Wich advertises itself as
> >>>>
> >>>> and worked very well. Not saying every bits are there for the present
> >>>> (spur etc)
> >>>> but at least, we have been there already at least once???
> >>>>
> >>>
> >>> ???Yep. Its just the 32 bit VM compiled on a 64 bit host. This worked
> >>> without big problems on the interpreter. I don't know what additional
> >>> constraints are imposed by Cog / Spur, but I thought at least for intel,
> >>> the 32 bit instruction set was a strict subset of x64, so there should be
> >>> no big problems.
> >>>
> >>> - Bert -???
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> ============================================================
> >> ===============
> >> John M. McIntosh. Corporate Smalltalk Consulting Ltd
> >> https://www.linkedin.com/in/smalltalk
> >> ============================================================
> >> ===============
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot



>