On Wed, Nov 19, 2008 at 2:43 PM, Michael van der Gulik <mikevdg at gmail.com>wrote:

>
>
> On Thu, Nov 20, 2008 at 11:33 AM, Michael van der Gulik <mikevdg at gmail.com
> > wrote:
>
>>
>>
>> On Mon, Nov 17, 2008 at 4:11 PM, Igor Stasenko <siguctua at gmail.com>wrote:
>>
>>>
>>>
>>> The only cause of this can be compiler.
>>> Instead of generating an instruction for sending #class message, it
>>> generates a bytecode to fetch the class from receiver oop , instead of
>>> sending real message.
>>>
>>
>> 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.
>>
>> See this:
>> http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_chapter28.html<http://users.ipa.net/%7Edwighth/smalltalk/bluebook/bluebook_chapter28.html>
>>
>> The send bytecode in question is decimal 199. This pushes the receiver's
>> class on the stack, no questions asked.
>>
>> I've looked at modifying the compiler, but I'm finding it to be a daunting
>> piece of software.
>>
>> 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".
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>
>
> ...which worked!
>
> To make #class a normal message send, do this:
>
> Inspect "Smalltalk specialObjectsArray".
> Find item 24, inspect it. This should be the special selectors array, but
> it might not be.
> Find item 47 in the special objects array. It should be "#class", but it
> might not be.
> In the special objects array inspector, evaluate "self at: 47 put:
> #primitiveClass".
> Evaluate "VariableNode initialize".
>
> -- or --
>
> Evaluate "(Smalltalk specialObjectsArray at: 24) at: 47 put:
> #primitiveClass"
> (but that would be less fun)
>
> and then recompile your code.
>
> Why does the VM need access to this special selectors array?


Read the blue book VM chapters (
http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_imp_toc.html).
 The special selectors kill two birds with one stone.

a) they allow the VM to optimize certain sends to certain types (static type
prediction).  e.g. #+ compiles to bytecode 176 and this will add two
integers or two floats or a float receiver and an integer without doing a
send.

b) they save space in the literal frame because the selector isn't stored,
instead it is implicit in the bytecode.

But if one of the special selector operations can't be handled inline (e.g.
integer addition overflows, or you try and add a Fraction, or compare two
strings, or...) or isn't handled inline (e.g. next, nextPut: etc) then the
VM needs to send the message implied by the bytecode.  It does that my
accessing the selector (and perhaps the argument count)from the special
selector array.

In VisualWorks there's an extended special selector scheme just to save
space.  (I'm proud of this because I suggested it to Peter Deutsch when I
was a student at York and he gave a talk on programming environments to the
department).  The blue book defines a 16-bit Smalltalk, but we've all moved
on to 32-bits.  Since in a 32-bit Smalltalk a literal takes 4 bytes, a
typical send takes therefore 5 bytes, 4 for the literal and 1 for the
bytecode.  By using a two byte bytecode whose second byte is the index into
the special selectors, and extending the special selectors to 256 + 16
entries, you can encode an additional 256 of the most common sends in only 2
bytes.


>
> Gulik.
>
> --
> http://people.squeakfoundation.org/person/mikevdg
> http://gulik.pbwiki.com/
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081119/ee4cbdd9/attachment.htm