Re: __builtin_constant_p and inline assembly constraints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux