Register spilling mechanism

[bryce at kampjes.demon.co.uk]

Igor Stasenko writes:
 > 2008/4/22  <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.
 > >
 > 
 > No, forget about Smalltalk stack, i plan to use Exupery at lower
 > levels to produce machine code fed by my own compiler.
 > 
 > >  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.
 > >
 > 
 > I don't know what you mean under 'C stack'.
 > Isn't Exupery compiles directly to machine code? Then why you speaking
 > about C stack at all? ;)

The machine stack which C also uses. The stack follow's C's
conventions for calls and returns. It's the stack that the C
in the interpreter uses.

 > As i understand (correct me if i'm wrong) by fixed size stack you
 > mean, that after done register allocation, Exupery determines the
 > exact size of stack, and then it inserts an instruction in method's
 > preamble to allocate it, like:
 > 
 > push %ebp
 > mod %ebp, %esp
 > sub %esp, stacksize
 > 
 > and at return point it does reverse:
 > 
 > add %esp, stacksize
 > pop %ebp
 > ret
 > 
 > or, does just 'ret' , in case if caller are responsible from cleaning
 > the stack and can restore %ebp.

It generates sequences like you suggest but they're generated
as low level intermediate then instruction selected before
register allocation. So the size is set before the number of
spills is known. I've been using a fixed size stack frame as
at temporary measure, it's been good enough for now, there isn't
a great deal of pressure on that memory especially as Exupery
can now spill directly into the context frame.

If you're planning on generating C style calls in code be careful.
If a GC happens as part of the call any object may be moved. Exupery
doesn't really save the C (machine) stack because it doesn't have any
state at any time it would risk making calls, it moves all the state
back into real objects so the GC can see it.

 > 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.

Bryce