Register spilling mechanism

[bryce at kampjes.demon.co.uk]

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