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

[Florin Mateoc]

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/20220519/b121cb6c/attachment.html>