Igor Stasenko writes:
More broader explanation why i need this.. I want to allow direct stack manipulation for native methods to some extent.
In code, one can write:
(object1 expression1) push. (object2 expression2) push. address call.
Now i need to make sure that Exupery will produce correct stack frame for a call, regardless what code inlined in expression1/expression2 it should not interfere with top stack layout, which should be:
<result of expression1> <result of expression2> <return address>
when entering routine at (address call).
Are you talking about the C stack or the Smalltalk stack?
If you're talking about the Smalltalk stack then in Exupery it's only dealt with in the front half of Exupery. It's handled in the ByteCodeReader and IntermediateSimplifier. Exupery uses exactly the same stack locations as the interpreter so doesn't need to check the stack height. It'll break for exactly the same methods that will cause the interpreter to crash. Exupery does model the stack in both classes so it would be fairly easy to monitor stack height if you were interested.
The C stack is maintained by Exupery, and is currently a fixed size but will be dynamically sized sometime in the future. Exupery will fail to compile if it uses more C stack than exists. The amount of C stack used isn't known until after register allocation because that's where registers are spilled to.
It's also possible to spill directly into the context (into the Smalltalk stack) which is done for stack registers. That's new in 0.14 and will be extended to temporaries as well.
Bryce