------- Comment #5 from acahalan at gmail dot com 2006-09-22 02:24 ------- (In reply to comment #4) > I still don't see why my code should not compile even for register starved > x86. > Including the -fomit-frame-pointer optimization should allow using the ebp > register at least for leaf functions. So I should have six registers at hand > to > use as I please, and gcc should know about this and allow using them all, > especially since the constraints are all the same, so that any mapping between > variables and registers should work equally well.
IMHO you should have at least 7 registers available. Both ebp and ebx can be saved to the stack. In many cases, the use of esp should also work. Obviously the user would be responsible for ensuring that signals/exceptions/interrupts are not a problem, perhaps simply by ensuring that esp points to an area with some free space below it. If there is some other free register with which gcc can do an xchg instruction, the problem is solvable. If there are two free MMX or XMM registers, the problem is solvable. Non-threaded code can simply store esp in a memory location. Threaded code can be handled via xchg with a user-specified memory location in the fs or gs segment; the default should be suitable for the normal pthreads library if possible. Probably esp should never be automatically allocated. It's better to make the user specify esp because that is the only way to ensure that signals/exceptions/interrupts won't corrupt anything. There is no reason to restrict ebx and ebp in this way, although ebp without -fomit-frame-pointer should be the least-desirable choice. It is entirely legit to use registers this way. On a UNIX-like system, sigaltstack() can be used to ensure that signals do not arrive on the normal stack. The user could also just mask all signals. Win32 doesn't muck with the stack unless you do something that is like a SIGSEGV. Using the push/pop instructions to deal with an array can be a useful hack. If the user accepts the restrictions of an active stack, then they can even leave the signals/exceptions/interrupts as normal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28635
