[Vm-dev] startpc (method) of full block closures

[Florin Mateoc]

And, of course, FWIW I now (also) think that the methods blockCreationPC
and startpc are just fine as they are.
Sorry for the noise

On Fri, May 20, 2022 at 12:14 AM Florin Mateoc <florin.mateoc at gmail.com>
wrote:

> Well, the name is wrong for this method, I take it back :)
> It should actually be called something like pcAfterBlockPush (and changing
> the statement "^pc - 1" to "^pc + 2").
> Then it could also be implemented in BlockClosure with the same name and
> semantics
>
> On Thu, May 19, 2022 at 2:43 AM Florin Mateoc <florin.mateoc at gmail.com>
> wrote:
>
>> This is what I came up with (as an implementation for the method
>> blockCreationPC in FullBlockClosure,
>> taking advantage of the fact that FullBlockClosure instances only exist
>> in Sista). Sorry for the formatting, Gmail messes it up
>>
>> blockCreationPC
>> "self allInstances do: [:e | e blockCreationPC]"
>> | method encoderClass end byte pc extA byte2 |
>>
>> method := startpcOrMethod outerCode.
>> pc := method initialPC.
>> end := method endPC.
>> encoderClass := method encoderClass.
>> [pc <= end] whileTrue:
>> [extA := 0.
>> [byte := method at: pc.
>> pc := pc + 1.
>> byte >= 224 and: [byte <= 225]] whileTrue:
>> [| extByte |
>> extByte := method at: pc.
>> pc := pc + 1.
>> byte = 224
>> ifTrue:
>> [extA := extByte]].
>> byte = 249 ifTrue:
>> [byte2 := method at: pc.
>> (method literalAt: (extA bitShift: 8) + byte2 + 1) == startpcOrMethod
>> ifTrue:
>> [^pc - 1]].
>> pc := pc + (encoderClass bytecodeSize: byte) - 1].
>> ^self halt
>>
>> On Thu, May 19, 2022 at 12:37 AM Florin Mateoc <florin.mateoc at gmail.com>
>> wrote:
>>
>>> Brown paper bag time - I only showed my ignorance above. The method in
>>> BlockClosure is not redundant, since it does different things for Sista vs
>>> V3
>>>
>>> On Thu, May 19, 2022 at 12:34 AM Florin Mateoc <florin.mateoc at gmail.com>
>>> wrote:
>>>
>>>> Ha, this is funny!
>>>>
>>>> As I opened an image to go implement a method doing said scanning, I
>>>> noticed that BlockClosure and FullBlockClosure already have a category
>>>> called scanning.
>>>> I looked inside and, lo and behold, there is a method there called
>>>> blockCreationPC. But the funniest thing is that the method in BlockClosure
>>>> is essentially redundant,
>>>> since it always answers startpc - 4, whereas in FullBlockClosure, where
>>>> it would be useful, it is overridden to say #shouldNotImplement
>>>>
>>>>
>>>>
>>>> On Thu, May 19, 2022 at 12:15 AM Florin Mateoc <florin.mateoc at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Marcel,
>>>>>
>>>>> Thank you, scanning the bytecodes of the compiledCode holder to get
>>>>> the matching pc seems like a good idea.
>>>>> It will add some overhead, but it is a pretty fast operation.
>>>>>
>>>>> All the best,
>>>>> Florin
>>>>>
>>>>> On Wed, May 18, 2022 at 4:55 AM Marcel Taeumel <marcel.taeumel at hpi.de>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi Florin --
>>>>>>
>>>>>> I think the semantics of the message #startpc did not change. With
>>>>>> FullBlockClosure,
>>>>>> the respective byte codes are not inlined anymore in the #homeMethod
>>>>>> but have their
>>>>>> own CompiledBlock. The trick to use #startpc as a position in the
>>>>>> surrounding method
>>>>>> thus does not work anymore. Hmm....
>>>>>>
>>>>>> However, it should be possible to look up the pc in #homeMethod
>>>>>> provided a FullBlockClosure
>>>>>> or CompiledBlock. Well, I think you have to scan the byte codes of
>>>>>> #homeMethod until you find
>>>>>> that "pushFullClosure:" part that matches your specific literal,
>>>>>> which is the CompiledBlock.
>>>>>>
>>>>>> Well, provided that CompiledBlock is not re-used across multiple
>>>>>> CompiledMethods,
>>>>>> which I do not know, one could add an extra literal to encode the pc
>>>>>> in that block's
>>>>>> #homeMethod. Still, I would not change #startpc in FullBlockClosure
>>>>>> for that property as
>>>>>> it seems to be a different kind of thing. Some AST-related
>>>>>> information which may only be
>>>>>> visible in the byte codes by accident. Hmm....
>>>>>>
>>>>>> Best,
>>>>>> Marcel
>>>>>>
>>>>>> Am 18.05.2022 07:08:01 schrieb Florin Mateoc <florin.mateoc at gmail.com
>>>>>> >:
>>>>>> Hi,
>>>>>>
>>>>>> I have found an issue (that I don't think it has been discussed here
>>>>>> before), and I wanted to ask for advice on how to handle it:
>>>>>>
>>>>>> The startpc method overridden in FullBlockClosure does not have the
>>>>>> same
>>>>>> semantics as the method it overrides (from BlockClosure).
>>>>>> In BlockClosure, startpc points to where the block starts within its
>>>>>> parent's bytecodes, whereas in FullBlockClosure the startpc method
>>>>>> returns
>>>>>> the initialPC of the closure within its own method, so it points to
>>>>>> where
>>>>>> the block starts within its own bytecodes.
>>>>>> This is not just a change in semantics, but it is also a disconnect
>>>>>> from
>>>>>> what a decompiled block node's pc is showing. The decompiled node's
>>>>>> pc
>>>>>> still has the old semantics, even though the block node is now
>>>>>> translated
>>>>>> to a full block closure.
>>>>>>
>>>>>> This old semantics (of an address within the parent) was a quite
>>>>>> useful
>>>>>> feature, since it allowed one to match a closure to its corresponding
>>>>>> block
>>>>>> node in the AST (even though the pc was only set correctly by the
>>>>>> decompiler and not by the compiler), but this now seems impossible.
>>>>>> Or
>>>>>> maybe I just don't see it. Any idea on how to solve this ?
>>>>>>
>>>>>> Thank you,
>>>>>> Florin
>>>>>> Hi,
>>>>>>
>>>>>> I have found an issue (that I don't think it has been discussed here
>>>>>> before), and I wanted to ask for advice on how to handle it:
>>>>>>
>>>>>> The startpc method overridden in FullBlockClosure does not have the
>>>>>> same semantics as the method it overrides (from BlockClosure).
>>>>>> In BlockClosure, startpc points to where the block starts within its
>>>>>> parent's bytecodes, whereas in FullBlockClosure the startpc method returns
>>>>>> the initialPC of the closure within its own method, so it points to where
>>>>>> the block starts within its own bytecodes.
>>>>>> This is not just a change in semantics, but it is also a disconnect
>>>>>> from what a decompiled block node's pc is showing. The decompiled node's pc
>>>>>> still has the old semantics, even though the block node is now translated
>>>>>> to a full block closure.
>>>>>>
>>>>>> This old semantics (of an address within the parent) was a quite
>>>>>> useful feature, since it allowed one to match a closure to its
>>>>>> corresponding block node in the AST (even though the pc was only set
>>>>>> correctly by the decompiler and not by the compiler), but this now seems
>>>>>> impossible. Or maybe I just don't see it. Any idea on how to solve this ?
>>>>>>
>>>>>> Thank you,
>>>>>> Florin
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20220520/bb8cd0b5/attachment-0001.html>