On Sat, Jun 25, 2022 at 11:16 AM David T. Lewis <lewis at mail.msen.com> wrote:

> On Sat, Jun 25, 2022 at 10:30:54AM -0700, Eliot Miranda wrote:
> > On Sun, May 29, 2022 at 7:03 AM David T. Lewis <lewis at mail.msen.com>
> wrote:
> >
> > > On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
> > > > Hi,
> > > > I wonder what?s changed that the images starting from
> > > Squeak6.0beta-21772-64bit on won?t start with the previous release VM
> > > (squeak.cog.spur_win64x64_202003021730) or even with pre-release new
> VMs
> > > (e.g. version 3154).
> > > >
> > > > I?m on Win10, the process explorer (windows) shortly runs
> WerFault.exe
> > > and than the Squeak process is closed/disappears.
> > > >
> > >
> > > The change is here:
> > >
> > >
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
> > >
> > > The current release candidate image does not have this, but it will be
> > > applied as soon as you update that image, and it expected to be part of
> > > the final release. The update applies a new image format number to the
> > > saved image files (stored in the first 4 bytes of the image file) when
> > > multiple bytecode set support is required from the VM. Effectively, the
> > > means that the image is using the Sista bytecode set. Older VMs can
> > > run the Sista bytecodes but do not yet have the code for recognizing
> > > the additional image format number.
> > >
> >
> > So given that older VMs supported the bytecode set and have (as do all
> Cog
> > VMs) a VM parameter flag bit to indicate this, what's the rationale for
> the
> > image format number including whether the image chooses to use the
> bytecode
> > set or not?
> >
>
> To the best of my recollection, it's something that we all agreed on a
> few years ago. The commit notice in ImageFormat-dtl.37 refers to our
> oversight board meeting of 2019-05-15. You were part of that discussion.
>

And of course I've long forgotten.  It feels over complicated to me now.
Bit I do see that setting the flags from the image via a
primitive (preferably vmParameterAt: rather than a whole bespoke primitive
for 1 parameter) is better than having the VM note when it's using a
particular bytecode set.

BTW, part of the commit comment is probably wrong.  I would expect both
fields 0 implying a pre-Sista (V3) bytecode set. I would expect 0, 1 to
imply V3 primary, SistaV1 secondary, etc.

> Getting the update into the VM took longer than originally anticipated.
>

No matter. We have it now and you explained the fix to Jaromir, who wants
to do this for special reasons (testing that the suspend fallback code
functions properly, even though this isn't strictly necessary).

> Dave
>

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