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