[Vm-dev] primitivePerform (prim 83) | primitivePerformInSuperclass (100)

Eliot Miranda eliot.miranda at gmail.com
Mon Dec 12 03:07:43 UTC 2011


Hi Stefan,

    can you mail me your tests?

On Sun, Dec 11, 2011 at 4:59 PM, Stefan Marr <squeak at stefan-marr.de> wrote:

>
> Hi Eliot:
>
> Are there any known issues with primitivePerformInSuperclass?
>
> And, ehm, what is the functionality that is supposed to be supported?
>
> I try with a doit, and everything works fine.
> But when it is used in a TestCase, it crashes :-/
>
> """
> Exception Type:  EXC_BAD_ACCESS (SIGBUS)
> Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
>
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   org.squeakfoundation.Squeak         0x0004ef5a
> primitivePerformInSuperclass + 42
>
> Thread 1:  Dispatch queue: com.apple.libdispatch-manager
> [...]
> """
>
>
> With regard to the supported functionality, I would expect it to mirror
> perform more or less exactly, but the image I use, only knows 'perform:
> selector withArguments: argArray inSuperclass: lookupClass' which uses an
> explict array for the arguments.
> However, from the doIt, the code below seems to work.
> And, well, when I use the debugger, it works of course too...
>
> performSuper: aSymbol
>        <primitive: 100>
>        ^ self perform: aSymbol withArguments: (Array new: 0) inSuperclass:
> self class superclass
>
> performSuper: aSymbol with: anObject
>        <primitive: 100>
>        ^ self perform: aSymbol withArguments: (Array with: anObject)
> inSuperclass: self class superclass
>
>
> I also tried to put the code from the doit into a class, and see whether
> that indirection makes a difference, since I remember that you have some
> special treatment for doits in Cog, right?
>
> Thanks
> Stefan
>
>
> On 08 Dec 2011, at 03:01, Eliot Miranda wrote:
>
> > Hi Stefan,
> >
> > On Wed, Dec 7, 2011 at 4:09 PM, Stefan Marr <squeak at stefan-marr.de>
> wrote:
> >
> > Hi:
> >
> > >From the current implementation, which I find in the interpreter, and
> from testing on Cog I assume that primitive 83, that is 'perform:', does
> easily handle an arbitrary number of parameters.
> >
> > Is that correct, or does for instance Cog do something else? (it does
> not seem so)
> >
> > That's correct. The primitive (InterpreterPrimitives>>primitivePerform)
> is written in terms of argumentCount and so should cope with any number of
> arguments up to the maximum (15 is the limit in CompiledMethod, 31 in the
> bytecode set I believe).
> >
> > I am just asking, because the number of parameters of the
> Object>>#perform:with: variants goes only up to three. And, the comment
> does not mention it. (at least in a recent Pharo image)
> >
> > Furthermore, I guess, there is an upper limit on the number of arguments
> with regard to frame size?
> >
> > Not in the StackVM or the Cog VM since these are running on a stack, not
> in a context, and so there's always plenty of headroom to push args on the
> stack during a perform.  At least the method/bytecode set's limit on
> argumentCount is going to bite before the stack size.  Similarly with
> perform:withArguments:, as long as the number of arguments is <=
> LargeFrameSize (56 slots?) the primitive will push arguments.  Of course,
> the number of arguments must match the method that is found, and so the
> real limits are CompiledMethod's and the bytecode set's.
> >
> > cheers,
> >
> >
> > Thanks
> > Stefan
> >
> > --
> > Stefan Marr
> > Software Languages Lab
> > Vrije Universiteit Brussel
> > Pleinlaan 2 / B-1050 Brussels / Belgium
> > http://soft.vub.ac.be/~smarr
> > Phone: +32 2 629 2974
> > Fax:   +32 2 629 3525
> >
> >
> >
> >
> > --
> > best,
> > Eliot
> >
>
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20111211/f24954ca/attachment.htm


More information about the Vm-dev mailing list