Hi Vanessa,

On Tue, Jul 21, 2020 at 4:52 PM Vanessa Freudenberg <vanessa at codefrau.net>
wrote:

>
>
> On Tue, Jul 21, 2020 at 12:30 PM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>> 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.
>>
>
let's discuss this in the context of the thread David started.


>
> 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
> set".
>
> 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.
>

Alas no.  We already mix bytecode sets.  IOne can set the preference do
some compiling, change the preference, do some compiling, etcd.  And so far
I've been too lazy to make the quick method generation use the preference.
All quick methods are in the original bytecode set (since quick methods
don't really use a bytecode other than the primitive bytecode).


But as I ask, I think we should discuss this in the thread David created.


> - Vanessa -
>
>
>

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