2008/7/2 Eliot Miranda <eliot.miranda at 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.
>



-- 
Best regards,
Igor Stasenko AKA sig.