Tom Bachmann <e_mc_h2@xxxxxx> 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
