2008/4/22 bryce@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? ;)
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.
And by dynamic stack size, you mean that instead of preallocating fixed amount of bytes on stack, in future, it can use pushes/pops in code based on demand?
I having nothing against both models, just need a safe way how i can manipulate stack directly without being endangered by register allocator to corrupt stack layout which developer expecting to have.
Let me elaborate the problem in the way how i see it. Suppose my compiler generates the code in form, what we call 'Exupery low-level intermediate'. So, there are a 'virtual' machine instructions arranged in blocks and using N temporary registers. Now, after register allocator did its job, we are know, that we need extra K bytes on stack to hold temporary values which is not fit in CPU registers at some points of code. And now, an instruction selector for particular temps should use instructions to store/read values on stack. But also there are need to generate instructions to preallocate the stack space to hold these values and deallocate it at some point, where they no longer needed. Now, who is controlling these actions? And can outer subsystem influence where to put stack allocation instruction, for instance?
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'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 _______________________________________________ Exupery mailing list Exupery@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery