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?
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?
On 07/12/2007, Klaus D. Witzel klaus.witzel@cobss.com 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.
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
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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: MD: Move and Drop bits
squeak-dev@lists.squeakfoundation.org
-
Igor Stasenko -
Klaus D. Witzel -
tim Rowledge