------- Comment #24 from acahalan at gmail dot com 2006-04-21 02:11 ------- PIC register: while the user could save and restore this, the whole point of this fancy assembly notation is so that gcc can do nice scheduling and register allocation. The save and restore should thus be done by gcc. Perhaps the PIC register won't soon be needed, so gcc could use it for something else until it gets reloaded with the normal content. At the very least, gcc could pick a good location for the save/restore operations.
Frame pointer register: this is the same as the PIC register. It's good to schedule the save/restore nicely. Stack pointer register: this one is special. For app code, signals may arrive. For kernel code, interrupts might be delivered without a stack change. Not supporting a clobbered stack pointer is definitely tolerable. Ideally this case could be handled (making the code non-reentrant), but the resulting mess is probably of very limited use. I could imagine abusing push/pop to iterate over arrays, but that's insane. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
