[Vm-dev] mantis http://bugs.squeak.org/view.php?id=7349

[Igor Stasenko]

2009/5/6 Eliot Miranda <eliot.miranda at gmail.com>:
>
> Hi Bert,
>
> On Wed, May 6, 2009 at 3:34 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>
>>
>> On 06.05.2009, at 02:36, David T. Lewis wrote:
>>
>>>
>>> On Tue, May 05, 2009 at 11:37:43AM -0700, John M McIntosh wrote:
>>>>
>>>> Folks should try the fix and see
>>>>
>>>> Ihttp://idisk.mac.com/bertfreudenberg-Public/temp
>>>>
>>>> Double-click EtoysToGo.app and drop in wendy.pr  for it to explode,
>>>> well or not after the fix is applied.
>>>
>>> I did not try the exploding wendy.pr test,
>>
>> Well what I uploaded there is just our not-yet-finished "Etoys To Go" project that's supposed to be runnable from an USB flash drive, on any platform. The VMs for Win and Linux there are not yet updated. Etoys actually does not need closure support (yet) but a feature to resolve relative directories (so the user data will also land on the flash drive). John put that feature in his 4.0 series which supports closures, so I needed to use that one. And then I noticed it blows up on entering sandbox mode.
>>
>>> but your ClosureVMPopKiller-M7349
>>> definitely fixes some stack balance bugs, so I loaded it in the VMMaker project
>>> on SqS in VMMaker-dtl.122.
>>>
>>> The Mantis 7349 issue is marked as status "testing" since I did not actually
>>> perform the wendy.pr test. I'll move it to "resolved" next week if no one cites
>>> evidence to the contrary.
>>>
>>> r.e. your notes in Mantis 7349:
>>>>
>>>> was there not some recovery code for unbalanced stacks somewhere? My
>>>> concern is there other example of this which we not yet crashed over.
>>>> So how would we fix the VM to avoid? Or do we need to check all the plugin
>>>> prim code for coding issues.
>>>
>>> Yes there are sure to be more unbalanced stack bugs, and yes somebody should
>>> probably check all the plugin code. Most likely nobody will get around to doing
>>> that but no worries, the stack VM seems to do an excellent job of finding
>>> these bugs :)
>>
>>
>> How costly would it be to always do this:
>>
>>        interpreterProxy pop: interpreterProxy methodArgumentCount + 1 thenPush: result
>>
>> or
>>
>>        interpreterProxy pop: interpreterProxy methodArgumentCount
>>
>> to return self?
>
> Do  the right thing:
>      interpreterProxy pop: interpreterProxy methodArgumentCount + 1 thenPush: result
> It is not hugely expensive compared to the other costs associated with the primitive call, and the interpreterProxy indirection.
> In Cog & the StackVM we check the argument count of primitive calls on return and fail the primitive if the stack is incorrect.  So checking is easier.
> But my main reason for suggesting you do the right thing is that soon enough the execution machinery is going to change and get substantially faster.  Igor has some good ideas for eliminating interpreterProxy, deferring whether one uses function pointers or direct references to functions until the time a plugin is compiled, and this makes all these calls much faster.  You would still write
>         interpreterProxy pop: interpreterProxy methodArgumentCount + 1 thenPush: result
>
> but the code generator would spit out
> ...
> #if EXTERNAL
> void (*popthenPush)(sqInt,sqInt);
> sqInt (*methodArgumentCount);
> #endif
> ...
>          popThenPush(methodArgumentCount() + 1, result);
> and the function pointers would be intialized in the plugin initializer.
> I want eventually to get away from explicit stack manipulation in plugins and write them all rather like smart plugins and have the code generator create vanilla C functions for them, with varargs for primitives that need them.  Primitives would return their result, returning 0 (all zeros) to indicate failure.  This would eliminate calls on interpreterProxy for argument access and return, leaving conversion, allocation etc.  Combining this with Igor's scheme should be a fair bit faster and cleaner than what we have now.
> So at least for the moment go for correctness and use smart syntax plugins as much as possible.
>

Its could be tedious, but i think that to make things faster it would
be better to use the return value from primitive function directly,
and stop using the successFlag. While for internal plugins, setting a
success flag is as simple as write to memory, for external plugins
this costs in additional function call.

For old plugins, we could simply change the code generator to declare
successFlag locally.
But there are some evil cases, where primitive function calls another
platform code, and this code sets successFlag directly, instead of
returning a error result, or something else, to indicate failure.
That's why i'm saying it could be a bit tedious.

-- 
Best regards,
Igor Stasenko AKA sig.