Tracing special messages [WAS] Re: [Vm-dev] Re: normalSend, specialObjectsArray and VM

Mariano Martinez Peck marianopeck at gmail.com
Tue Oct 5 19:00:31 UTC 2010


On Tue, Oct 5, 2010 at 8:48 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
> On Tue, Oct 5, 2010 at 11:20 AM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>>
>>
>> On Tue, Oct 5, 2010 at 7:50 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On Tue, Oct 5, 2010 at 9:23 AM, Mariano Martinez Peck <
>>> marianopeck at gmail.com> wrote:
>>>
>>>>
>>>> Hi. So....if I want to intercept ALL message sends....going to
>>>> #normalSend is not enough since I have #class, #==, Float>>#+   etc that are
>>>> executed directly like bytecodes. So...my questions are now:
>>>>
>>>> 1) Those special selectors are those that are in "Smalltalk
>>>> specialSelectors" ?  are there more?  all from there are special?
>>>>
>>>> 2) All those "Smalltalk specialSelectors"  have their associated
>>>> bytecode primitive in Interpreter??  If true, then I should modify all
>>>> bytecodePrim*  in Interpreter. I am right?   If I do that, that's all ? I am
>>>> intercepting everything?
>>>>
>>>
>>> Right.  Just modify all of them to eliminate the optimized code and to
>>> revert to normalSend.
>>>
>>
>> Thanks Eliot. I didn't understand. What is the optimized code?   I checked
>> all bytecodePrim* and the ones that DO NOT send "self normalSend" at the
>> end, are very few. The problem is that some return before returning "self
>> normalSend". So...I should modify all those who DO NOT call "self
>> normalSend" at the end and those which return before.
>>
>
> Change them all so they do a normalSend and nothing else, e.g.
>
> bytecodePrimAdd
> messageSelector := self specialSelector: 0.
>  argumentCount := 1.
> self normalSend
>
>
Ok, but suppose I DON'T want to slow down the system.... what if I change to
this for example

bytecodePrimAdd
    | rcvr arg result |
    rcvr := self internalStackValue: 1.
    arg := self internalStackValue: 0.
    (self areIntegers: rcvr and: arg)
        ifTrue: [result := (self integerValueOf: rcvr) + (self
integerValueOf: arg).
                (self isIntegerValue: result) ifTrue:
                    [self internalPop: 2 thenPush: (self integerObjectOf:
result).
                    self markObjectUsage: rcvr.
                    ^ self fetchNextBytecode "success"]]
        ifFalse: [successFlag := true.
                self externalizeIPandSP.
                self primitiveFloatAdd: rcvr toArg: arg.
                self internalizeIPandSP.
                successFlag ifTrue: [self markObjectUsage: rcvr. ^ self
fetchNextBytecode "success"]].

    messageSelector := self specialSelector: 0.
    argumentCount := 1.
    self normalSend

Ok...I have to manually check each method, but I don't have problem.

Should that work and be almost as fast as normally?



> Or change the part of the bytecode table that specifies the special
> selector primitives to read
>  (176 207 sendSpecialSelectorBytecode)
>
> sendSpecialSelectorBytecode
> | selectorIndex specialSelectors |
>  selectorIndex := (currentBytecode - 176) * 2.
> specialSelectors := self splObj: SpecialSelectors.
>  messageSelector := self fetchPointer: selectorIndex
> ofObject: specialSelectors.
>  argumentCount := self fetchInteger: selectorIndex + 1
> ofObject: specialSelectors.
>  self normalSend
>
> But most of all try and slow down and understand what is going on; then you
> will be able to answer your own questions.  Reading the blue book<http://www.mirandabanda.org/bluebook/bluebook_imp_toc.html>will help.
>
>

hehehehehe what an idea :) I didn't know I could do that. Thanks for the
blue book. I read the vm chapters but several months ago. I should read it
again since the first time I didn't understand very much hehehehe.


>
>>
>>
>>> Providing you also look at the perform and method evaluation primitives I
>>> think you'll get all sends.
>>>
>>>
>> #primitivePerform*   and #primitiveExecuteMethod*    ???
>>
>>
>>> There is another way.  Modify the Smalltalk compiler to to use the
>>> special selector sends.
>>>
>>>
>> Thanks Eliot for the idea. Can you explain me a little more (sorry, newbie
>> here!). You mean that with the Compiler I can do that all method sends use
>> the normal send instead of special bytecodes or primitives?
>>
>
> Yes.  If you modify the compiler not to use the StdSelectors then the
> compiler will emit normal sends for all the special selectors.   Again I
> think if you slowed down and started playing ore you would discover this for
> yourself and in the end be more productive.  I know its hard and frustrating
> initially.  But my own competence comes directly from having played around
> in this way.
>
>
Thanks Eliot. I will consider this alternative also.

Best regards.

Mariano


> best,
> Eliot
>
>
>> Thank you very much.
>>
>> Mariano
>>
>>
>>>
>>>> Thanks a lot in advance,
>>>>
>>>> Mariano
>>>>
>>>>
>>>>
>>>> On Sun, Oct 3, 2010 at 11:09 PM, Craig Latta <craig at netjam.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> > Craig Latta has done all this work, talk to him.
>>>>>
>>>>>     Sure, I'd be happy to discuss it.
>>>>>
>>>>>
>>>>> -C
>>>>>
>>>>> --
>>>>> Craig Latta
>>>>> www.netjam.org
>>>>> + 31 020 894 6247
>>>>> +  1 415 287 3547
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20101005/675176d1/attachment-0001.htm


More information about the Vm-dev mailing list