[squeak-dev] trunk and new vm etiquette

Vanessa Freudenberg vanessa at codefrau.net
Tue Jul 21 23:51:28 UTC 2020

On Tue, Jul 21, 2020 at 12:30 PM Eliot Miranda <eliot.miranda at gmail.com>

> Hi David,
> On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <lewis at mail.msen.com>
> wrote:
>> This might also be an opportune time to add
>> primitiveMultipleBytecodeSetsActive
>> if you are so inclined. It requires trunk users to update their VM before
>> the image format number can be updated, so it would be convenient if
>> it could come along with the primitiveAt[Put] changes.
> We still have to discuss this.  I'm sorry, been too busy to do so.  I
> still don't understand the intent here.  The VM already provides a status
> bit in parameter 65 which says whether the VM supports multiple bytecode
> sets.  If the intent is to mark an image when multiple bytecode sets have
> been used then the primitive doesn't appear to me to do what's required.
> I'll try and answer in the context of the thread soon, because I agree it's
> important.  Ideally there would be a pair of flags set somewhere that said
> if the current image had ever executed a method in either bytecode set.

All VMs check the image format to see if they can run the image. That's the
only check they perform, as far as I know.

That's why it seems appropriate to use a bit in the image format to mean
"no, you can't run this if your VM does not understand the new byte code

Otherwise e.g. SqueakJS or other Spur-compatible VMs would have to look at
every single CompiledMethod to see if the alt byte code flag was set.

Btw, Squeak is not going to mix bytecode sets - it's going to recompile all
methods, so when snapshotting, they all use one or the other. In that
scenario, a simple primitive call like David's should work, if it's done
right after recompiling all.

- Vanessa -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/6dba5aaa/attachment.html>

More information about the Squeak-dev mailing list