Re: Maintaining multiple stacks

[Ian Lance Taylor <iant at google dot com>]

Tom Bachmann <e_mc_h2@web.de> writes:

> > As far as providing a traditional secondary stack, such as to put
> > large and dynamically-sized arrays on, that would be a LOT easier.
> > That is the sort of secondary stack that I keep banging on about;
> > by removing those from the primary stack, it improves cache locality
> > and makes it easier for debuggers and tracebacks.
> > 
> 
> This sounds like what I was looking for.

I think this would be a feasible addition to gcc.  The main issue is
that you would have to introduce a new fixed register, which would
break the existing ABI for your processor.  You would have to
recompile all code to use the new feature, by which I mean all code
including the system library and the kernel.  To see why, consider
what would happen if a function invoked by a signal handler needed to
allocate a variable on the secondary stack.

If you were willing and able to do that, then supporting a new
attribute or just putting large variables on the secondary stack would
simply involve calling a new allocation routine, just like the
existing one but using a different base register.  The prologue and
epilogue code would have to be adjusted to change the value of the new
base register as appropriate.  Everything else should more or less
work.

OK, I thought of another approach.  Instead of using a new fixed
register, you use a thread local variable to hold the value of the
secondary stack pointer.  Then you don't have to worry about
recompiling the world, though of course the code will run slower.  The
changes to the compiler become more complex, but you should still only
have to change the same parts.

Ian