Register spilling mechanism

[bryce at kampjes.demon.co.uk]

Igor Stasenko writes:
 > Don't worry about it. I'm planning to overthrow the rule of C and make
 > every bit in VM be implemented as native methods
 > which can be compiled at run time. :)
 > So, i care little about what calling convention C or other libraries having.
 > All foreign calls will be handled by FFI class(es) (compiled as
 > anything else as well), while inside i'll have methods compiled to
 > machine code and i'm free to choose any calling convention for them,
 > as well as choose own stack layout which will be convenient for GC and
 > object memory.
 > That's why i asked how i can control these aspects with Exupery.

If an signal comes in from the OS, then the signal will be executed on
the machine (C) stack, so the stack pointer must always be correct. If
not you risk having your C stack trashed by the signal.

 > >
 > >   > Can be there any contracts between Exupery and caller, where i can
 > >   > state that code should compile under certain rules, like:
 > >   > - specify a set of registers, which should be preserved after given
 > >   > code done working
 > >   > - specify, what registers code expects to be preserved when doing calls
 > >   > - specify, what registers should be reverted just before ret/non-local
 > >   > jump instructions
 > >
 > >  It would be possible to control what you want to, but there's no
 > >  published interface. The intermediate languages will change as
 > >  Exupery evolves.
 > >
 > 
 > Thank you for explanation. I will look forward for any updates
 > concerning these features.
 > Maybe, as temporary solution, i can patch register allocator to get
 > some feedback on how many stack space i need, and then
 > re-run it again.
 > Or i can try to measure maximum number of live temps in code by own.

The best bet would be to read the final stack height from the register
allocator. Though for now it'll always be 64 bytes big. Look
at SpillInserter and MachineX86>>newSpillSlot. That's the code
responsible for managing the stack.

Also look at the loadStack and the storeStack instructions as they
generate the Smalltalk stack loading and storing instructions in the
register allocator after all spills have been made. This is to avoid
loading spilled values from the Smalltalk stack.

Bryce