[Vm-dev] Push/pop considered harmful

John M McIntosh johnmci at smalltalkconsulting.com
Tue Mar 3 15:09:00 UTC 2009

Do you think we could change Slang so that it wouldn't return anything  
if the procedure returns nothing? Thus avoid all these sqInt foo() {}   
**warning does not return value messages

On 2-Mar-09, at 11:24 PM, Andreas Raab wrote:

> Folks -
> Ever since we started to use the Stack VM we had a series of subtle  
> crashes, many of which we could trace to stack imbalances (i.e.,  
> mismatching numbers of push/pops in primitives). Since the Stack VM  
> is much more affected by this we have been looking to fix these  
> issues once and for all.
> One thing that occurred to us is that practically all primitives do  
> the same: They pop the number of arguments and they push an optional  
> return value. There are many ways in which this can get wrong,  
> sometimes it's a subtle early return, sometimes the fact that the  
> primitive has actually failed before the prim returns etc.
> One thing that all of the uses (in plugins) have in common that all  
> the plugin *really* needs to do, is to provide a return value and  
> leave the push/pop to be done by the VM. In this case the stack  
> invariants wouldn't even be exposed to the plugin.
> What we are doing right now is along those lines - basically we are  
> replacing push/pop in the interpreter proxy by variants that don't  
> actually do push and pop. Rather than that, pop is ignored (it only  
> remembers how many times you popped so we can track inconsistencies)  
> and push remembers the return value.
> This should definitely be replaced at some point by a proper  
> #primitiveReturnValue: call. I was wondering what people think about  
> the possibility of automatically rewriting plugins to fix those  
> uses? It should be reasonably easy to find all the uses of  
> "interpreterProxy pop: foo" and just remove them and replace  
> "interpreterProxy push[Float|Int]:" with "interpreterProxy  
> primitiveReturn[Float|Int]:".
> Cheers,
>  - Andreas

John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com

More information about the Vm-dev mailing list