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

Fri May 20 04:14:15 UTC 2022

Well, the name is wrong for this method, I take it back :)
It should actually be called something like pcAfterBlockPush (and changing
the statement "^pc - 1" to "^pc + 2").
Then it could also be implemented in BlockClosure with the same name and
semantics

On Thu, May 19, 2022 at 2:43 AM Florin Mateoc <florin.mateoc at gmail.com>
wrote:

> 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/20220520/b1234989/attachment.html>