<br><br><div class="gmail_quote">On Thu, Nov 20, 2008 at 11:33 AM, Michael van der Gulik <span dir="ltr"><<a href="mailto:mikevdg@gmail.com">mikevdg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div class="Ih2E3d">On Mon, Nov 17, 2008 at 4:11 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div><br>
<br>
</div></div>The only cause of this can be compiler.<br>
Instead of generating an instruction for sending #class message, it<br>
generates a bytecode to fetch the class from receiver oop , instead of<br>
sending real message.<br>
</blockquote></div><div><br>Yes, the Compiler and Smalltalk bytecode set is doing this. I need this change too at some stage, so I've spent some time on it.<br><br>See this: <a href="http://users.ipa.net/%7Edwighth/smalltalk/bluebook/bluebook_chapter28.html" target="_blank">http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_chapter28.html</a><br>
</div></div><br>The send bytecode in question is decimal 199. This pushes the receiver's class on the stack, no questions asked.<br><br>I've looked at modifying the compiler, but I'm finding it to be a daunting piece of software.<br>
<br>The send bytecode is written to the compiled method stream in SelectorNode>>emit:args:on:super: at the top of the method as a "short send". <br><br>The SelectorNode instance is initialised as a shared class variable called "StdSelectors" in VariableNode>>initialize. As you can see there, its values are retrieved from the SystemDictionary. Once initialised as a class variable, it is again copied in Encoder>>initScopeAndLiteralTables.<br>
<br>So the special selectors array lives in the SystemDictionary's special objects array in slot 24, meaning that the VM also refers to these selectors. I'm not sure why the VM wants them.<br><br>As with fixing this, I guess that replacing the value in the special selectors array and then running VariableNode>>initialize might do the trick. Or it might crash the VM.<br>
<font color="#888888"></font></blockquote><div><br><br>...which worked!<br><br>To make #class a normal message send, do this:<br><br>Inspect "Smalltalk specialObjectsArray".<br>Find item 24, inspect it. This should be the special selectors array, but it might not be.<br>
Find item 47 in the special objects array. It should be "#class", but it might not be.<br>In the special objects array inspector, evaluate "self at: 47 put: #primitiveClass".<br>Evaluate "VariableNode initialize".<br>
</div></div><br>-- or --<br><br>Evaluate "(Smalltalk specialObjectsArray at: 24) at: 47 put: #primitiveClass"<br>(but that would be less fun)<br><br>and then recompile your code.<br><br>Why does the VM need access to this special selectors array?<br>
<br>Gulik.<br><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a><br>