Hi Igor,

GCC (C compilers in general?!) is not a statement by statement compiler,  
it shuffels around common subexpressions etc, even if not being asked for  
optimizations. Also many the methods of the VM are inlined, and moreover  
values are kept in registers until pressure occurs (also done without  
being asked for optimizations).

I have not counted the cases where something returned would be useful v.s.  
not useful but, for the Smalltalk developer this would be counting the  
beans (in a dedicated Workspace?) one way or the other :)

Do you have metrics of the C-generated code for justifying the current  
v.s. your suggested form?

What can be seen crystal clear from the code architecture of the VM is: if  
something is inlined then GCC most likely has the value of the success  
variable (which you've set before Slang returns from that method) in a  
register. If something isn't inlined then the frequency of call (which you  
associate with accessing the success value) is of no importance (but the  
CPU's pipe+cache might still know that value).

If by "primitive function" you meant only the bytecode primitives and the  
numbered primitives then I'd say case 2 of the previous paragraph applies.

/Klaus

On Fri, 07 Dec 2007 13:11:23 +0100, Igor Stasenko wrote:

> Currently, a VM expects nothing in return from primitive function
> (actually functions have format sqInt (*)(void)  but result is not
> used).
>
> I'm wondering, why in VM , to indicate success, a successFlag global
> variable used instead of just returning 0 or 1 to indicate if call was
> successfull or not?
>
> To what i see, if not using the successFlag , then speed can be
> improved, because there will be less frequent reads and writes to
> successFlag by simply reusing a return value from function which is
> currently ignored.
>
> The good point in using a successFlag is, that it can be set anywhere
> in primitive and then do something else, and only then return from
> function.
> But a common scenarion is often look like:
>
> something isWrong: [ ^ interpreterProxy primitiveFail ]
>
> where primitiveFail internally sets successFlag to false.
>
> So, can anyone provide arguments, why its done in such way?
>