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

[Marcel Taeumel]

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/20220518/66306579/attachment.html>