<div dir="ltr"><div>This is what I came up with (as an implementation for the method blockCreationPC in FullBlockClosure, <br></div><div>taking advantage of the fact that FullBlockClosure instances only exist in Sista). Sorry for the formatting, Gmail messes it up<br></div><div><br></div>blockCreationPC<br>"self allInstances do: [:e | e blockCreationPC]"<br>| method encoderClass end byte pc extA byte2 |<br><br>method := startpcOrMethod outerCode.<br>pc := method initialPC.<br>end := method endPC.<br>encoderClass := method encoderClass.<br>[pc <= end] whileTrue:<br>[extA := 0.<br>[byte := method at: pc.<br>pc := pc + 1.<br>byte >= 224 and: [byte <= 225]] whileTrue:<br>[| extByte |<br>extByte := method at: pc.<br>pc := pc + 1.<br>byte = 224<br>ifTrue:<br>[extA := extByte]].<br>byte = 249 ifTrue:<br>[byte2 := method at: pc.<br>(method literalAt: (extA bitShift: 8) + byte2 + 1) == startpcOrMethod ifTrue:<br>[^pc - 1]].<br>pc := pc + (encoderClass bytecodeSize: byte) - 1].<br>^self halt</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 19, 2022 at 12:37 AM Florin Mateoc <<a href="mailto:florin.mateoc@gmail.com">florin.mateoc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 19, 2022 at 12:34 AM Florin Mateoc <<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Ha, this is funny!</div><div><br></div><div>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.</div><div>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, <br></div><div>since it always answers startpc - 4, whereas in FullBlockClosure, where it would be useful, it is overridden to say #shouldNotImplement</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 19, 2022 at 12:15 AM Florin Mateoc <<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Marcel,</div><div><br></div><div>Thank you, scanning the bytecodes of the compiledCode holder to get the matching pc seems like a good idea.</div><div>It will add some overhead, but it is a pretty fast operation.</div><div><br></div><div>All the best,</div><div>Florin<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 18, 2022 at 4:55 AM Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div id="gmail-m_-552664842753704226gmail-m_-7545775218162322801gmail-m_2692984222542856342gmail-m_4557832374081783508__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr">
Hi Florin --<div><br></div><div>I think the semantics of the message #startpc did not change. With <span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">FullBlockClosure,</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">the respective </span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">byte codes are not inlined anymore in the #homeMethod but have their</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">own CompiledBlock. </span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">The trick to use #startpc as a position in the surrounding method</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">thus does not work </span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">anymore. Hmm....</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">However, it should be possible to look up the pc in #homeMethod provided a FullBlockClosure</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">or CompiledBlock. Well, I think you have to scan the byte codes of #homeMethod until you find</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">that "pushFullClosure:" part that matches your specific literal, which is the CompiledBlock.</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Well, provided that CompiledBlock is not re-used across multiple CompiledMethods,</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">which I do not know, one could add an extra literal to encode the pc in that block's</span></div><div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">#homeMethod. Still, I would not change #startpc in FullBlockClosure for that property as</span></span></div><div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">it seems to be a different kind of thing. Some AST-related information which may only be</span></span></div><div><span style="font-family:Arial,Helvetica,sans-serif"><span style="font-size:13px">visible in the byte codes by accident. Hmm....</span></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Best,</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Marcel</span></div><div></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">
<p style="color:rgb(170,170,170);margin-top:10px">Am 18.05.2022 07:08:01 schrieb Florin Mateoc <<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Hi,
<br>
<br>I have found an issue (that I don't think it has been discussed here
<br>before), and I wanted to ask for advice on how to handle it:
<br>
<br>The startpc method overridden in FullBlockClosure does not have the same
<br>semantics as the method it overrides (from BlockClosure).
<br>In BlockClosure, startpc points to where the block starts within its
<br>parent's bytecodes, whereas in FullBlockClosure the startpc method returns
<br>the initialPC of the closure within its own method, so it points to where
<br>the block starts within its own bytecodes.
<br>This is not just a change in semantics, but it is also a disconnect from
<br>what a decompiled block node's pc is showing. The decompiled node's pc
<br>still has the old semantics, even though the block node is now translated
<br>to a full block closure.
<br>
<br>This old semantics (of an address within the parent) was a quite useful
<br>feature, since it allowed one to match a closure to its corresponding block
<br>node in the AST (even though the pc was only set correctly by the
<br>decompiler and not by the compiler), but this now seems impossible. Or
<br>maybe I just don't see it. Any idea on how to solve this ?
<br>
<br>Thank you,
<br>Florin
<br><div dir="ltr"><div>Hi,</div><div><br></div><div>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:</div><div><br></div><div>The startpc method overridden in FullBlockClosure does not have the same semantics as the method it overrides (from BlockClosure). <br></div><div>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.</div><div>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. <br></div><div><br></div><div>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 ?</div><div><br></div><div>Thank you,</div><div>Florin<br> </div></div>
<br></div></blockquote></div></blockquote></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>