Richard Earnshaw <rearnsha@buzzard.freeserve.co.uk> writes:

> > Richard Earnshaw <rearnsha@buzzard.freeserve.co.uk> writes:
> > 
> > > +/* set_stackptr without changing mode */
> > > +void
> > > +static __inline set_current_stackptr(u_int address)

[...]

> > > It wouldn't surprise me if this seriously upsets the compiler.  Even
> > > making this non-inline may not work.
> > 
> > Why do you say that. It did not complain when I compiled it iirc. Of
> > course if you do anything that touches the old stack after that you
> > are sunk, but that's your lookout fooling around with this stuff
> > anyway.
> 
> Because of the way the stack is laid out.
> 
> Because of the way function return is done
> 
> Because of the way functions needing more than four words of arguments 
> pass items on a pre-allocated stack chunk
> 
> Because the compiler might not see the stack update and might move 
> operations dependent on it across the stack adjustment (ok, this one 
> shouldn't happen, but the stack and the frame aren't as conceptually tied 
> together in the compiler as one might hope).
> 
> Because variables that don't get allocated to registers get put on the 
> stack.
> 
> I could go on...

set_current_stackptr is a low level primitive. Its semantics mean that
it does lowlevel stuff. If you use it wrong, you get screwed. So
what. Caveat emptor. (Ben Harris suggested that the compiler might
mess with the stack with inline functions so I've turned it into a
macro.)

Please explain in more detail the reason for which it is impossible to
use. 

[...]

-- 

	http://ape.n3.net