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

[Florin Mateoc]

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/20220519/982564da/attachment-0001.html>