2008/7/2 Eliot Miranda eliot.miranda@gmail.com:
A foreign call is a perfect time to do a stack switch. One has to marshall arguments from one language to another so it doesn't add asny overhead to marshall objects one one stack into values passed out on another stack. You pay a little bit extra on the return path where you do have to change stacks, but its not a huge cost (system calls are not that expensive anymore).
yeah, yeah, boring stuff just to make two environments live together without much conflicts. However it adds complexity in managing running machine state. And against nature of simplicity and flexibility. But there is not much choices... I just asking myself, why OS designers didn't thought a bit, about enabling user process to provide control on own stack? Why there is no option to provide a buffer for initial stack, when creating new native thread? Or if not a buffer, then at least a reserved address space.
If you take this approach (which is taken by the VisualWorks VM for all primitives written in C, everything except a subset of the core language primitives) you can easily manage your own stack. (It is even easy to allocate the small amount of stack you use on the thread's C stack using alloca. :) )
It seems the only viable way on modern OSes. Since i don't have to care about primitives (they not exists), the only what i should care of is when it does foreign calls. And since foreign calls are up to implementor - it has nothing to do with compiler. Its only a matter of writing a correct callout code and correctly handling return from it an returned value(s), if any.
The native Cog will do this. The StackInterpreter Cog (that today executes 325k bytecodes before hitting incomplete simulation code in BitBltSimulator, sob - I wanted to see some pixels) also does this but only interprets in the stack rather than running natively on it.