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

Florin Mateoc florin.mateoc at gmail.com
Thu May 19 04:34:06 UTC 2022


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/725ab61f/attachment-0001.html>


More information about the Vm-dev mailing list