[Vm-dev] Push/pop considered harmful

[Eliot Miranda]

On Tue, Mar 3, 2009 at 10:52 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> 2009/3/3 Andreas Raab <andreas.raab at gmx.de>:
> >
> > Igor Stasenko wrote:
> >>
> >> But it seems that it disabled by default.
> >> Yes it would be nice to replace push/pops with single method, like
> >> #primitiveArgumentAt: index
> >> where index = 0 is receiver
> >> 1 .. n - rest of arguments.
> >
> > I think that is a brilliant idea, right in line with what we were doing.
> > Finally you can use left-to-right access to method args ;-)
> >
> >> Another thing, that most primitives never check a number of arguments
> >> on stack. This is also a potential risk, when you calling primitive
> >> with wrong number of arguments from a language side.
> >
> > Right. One thing we can do here is to add a check to primArgAt: that just
> > fails the primitive if you try to access arguments that aren't provided.
> >
> yes, this check could be put in #primArgAt:
> but i feel little unpleased that it will be performed more than once.
> It would be better to have a slang directive, like:
> self expectedArguments: 3.  " 1== receiver only, 2 == receiver +
> single arg ... "


self expectedNumArgs: 0
    => self only
self expectedNumArgs: 1
    => self plus one argument
self expectedNumArgsBetween: m and: n
    for var-args primitives like perform:[with:*] and value[:[value:*]]

Perhaps checkNumArgs: or failUnlessNumArgs: are better names?


>
> in primitie code, and put it as first check in primitive entry. Then
> code generator could produce a code which checks the number of
> arguments, and automatically fail primitive if they are not same as
> expected.
>
> >> Apart from this, what you suppose to do with primitives who switching
> >> the active context (entering block closure,signaling semaphore,
> >> scheduling etc)?
> >> In this situation you shouldn't try to validate the stack pointer, as
> >> well as primitive return value is useless.
> >
> > Yes. push and pop will still be there for internal use - it is only the
> > plugins that will get updated. So anything that wants to munge the stack
> in
> > such a way will have to be builtin VM primitive which seems fair to me.
> >
> > Cheers,
> >  - Andreas
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090303/ddbbce06/attachment.htm