[Bug target/28635] Interaction between different asm statements
acahalan at gmail dot com
Fri Sep 22 02:24:00 GMT 2006
------- 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.
More information about the Gcc-bugs