Success flag and using return value of primitive function

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?

--
Best regards,
Igor Stasenko AKA sig.

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:

On 07/12/2007, Klaus D. Witzel <[hidden email]> wrote:
> 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).
>
Ah, yes, i forgot about codegenerator inlining.
Yes, keeping right order of things under such circumstances are harder.

> 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?
>
Of course not, but to my feel, it would be better to use return value.
But because of manual (codegenerator) inlining i see that this is hard
to achieve.

--
Best regards,
Igor Stasenko AKA sig.

The prim code could most certainly be rewritten to avoid use of a  
global flag but it is a big job that no one has felt able to tackle as  
yet. We even considered doing this at Interval, 10 years ago. Since we  
had four or five fulltime people that could have worked on it you can  
assume that we really did think it to be a large amount of work.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MD: Move and Drop bits