[Vm-dev] Push/pop considered harmful

Igor Stasenko siguctua at gmail.com
Tue Mar 3 19:01:40 UTC 2009


2009/3/3 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
>
> 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?

as you like.. i bother only about concept :)

>>
>>
>> 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.
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list