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 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@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
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@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@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
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@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@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@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
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@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@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@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@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
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@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@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@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@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@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
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@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@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@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@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@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@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
And, of course, FWIW I now (also) think that the methods blockCreationPC and startpc are just fine as they are. Sorry for the noise
On Fri, May 20, 2022 at 12:14 AM Florin Mateoc florin.mateoc@gmail.com wrote:
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@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@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@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@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@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@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
vm-dev@lists.squeakfoundation.org