This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: __builtin_constant_p and inline assembly constraints
At Wed, 23 Aug 2006 12:51:33 +0100,
Andrew Haley wrote:
> > But I cannot quite understand where the difference comes from. What I
> > would like the original macro to generate is:
> >
> > .set push
> > .set noreorder
> > .long 0xfffe0009
> > .short 0xffff
> > .short 9
> > .set pop
>
> So why not do that, then? In a single asm.
I would love to, but I can't. That's what my original problem with
__builtin_constant_p was. My original syscall macro indeed looked like
this:
#define _syscall1(type,name,atype,a) \
type name(atype a) { \
register unsigned long __v0 asm("$2"); \
\
__asm__ volatile ( \
".set push" \
".set noreorder " \
".long %1" \
".long %2" \
".short 0xffff #" #name " " \
".short %3" \
".set pop" \
: "=&r" (__v0) \
:"r?i" (__builtin_constant_p(a) ? 0xfffd : 0xfffe), "r?i" (a), \
"i" (__NR_##name) ); \
\
return (type) __v0; \
}
and it didn't work because of the
:"r?i" (__builtin_constant_p(a) ? 0xfffd : 0xfffe), "r?i" (a), \
part. If __builtin_constant_p() would have behaved like a preprocessor
macro, I guess I could have done something like
#if __builtin_constant_p(a)
:"i"(0xfffd), "i"(a), \
#else
:"i"(0xfffe), "r"(a), \
#endif
. But it doesn't.
> GCC is entitled to put anything it likes between volatile asms, or
> move them around, as long as they get executed in the order you've
> asked for.
I understand, I just didn't quite get how GCC handled inline
assembly. The discussion have been very enlightening in that respect,
thanks :-)
> If you do anything in an asm statement that changes the global assmber
> state, you must undo it *before the end of that asm statement*.
I'll have to think about whether this is a problem. Probably not.
The outcome of all this is supposed to be parameters to a Java
function call, i.e., what the code GCC moved around before should
generate is
iload_3 # Push register 3 on the stack
L1:
invokestatic Syscalls.puts(I)I # ... as argument to puts
...
bipush 100 # Push constant 100
goto L1 # jump to the call above
and as long as the argument is on the top of the stack when puts is
invoked, it should be just fine.
// Simon