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

[Florin Mateoc]

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/953f39d9/attachment.html>