asm and "cc" "memory" volatile etc.. (slightly offtopic)

asm and "cc" "memory" volatile etc.. (slightly offtopic)

[Jan Hubicka]

Hi
I have some problems with asm keyword. I still dont understand to some
details, and since it seems to be quite high conecentration of gcc
gurus here, I decided to ask at this list..

Imagine that you are writing some memcpy replacement (like rep movsb at intel)

do I need to write "cc" into modified registers, since it changes flags?
is such construction w/o "cc" bug? 

I probably need to write "memory" since it modifies memory, but what for example
in memchr case, wich just reads memory, do I put there "memory" too to force
gcc update all memory locations (and do not store some data in registers)

Is there some way to say gcc, that is just updates given block of memory
(rtl expression for memcpy dont say clobbers:memory but says set BLK...
is there any way to write this in asm?)

When exactly I need to write volatile? Does memcpy implementation need
volatile or fact, that it changes memory is enought for gcc to do not
make "bad" optimizations?
What it memchr case?
I know that I need to write volatile in thinks like "cli" but it is required
here too?

Thank you very much...

Honza
-- 

Re: asm and "cc" "memory" volatile etc.. (slightly offtopic)

[Jeffrey A Law]

  In message < 19971111102912.23695@atrey.karlin.mff.cuni.cz >you write:
  > do I need to write "cc" into modified registers, since it changes flags?
  > is such construction w/o "cc" bug? 
I would think you should list "cc" in the clobbered registers.

  > I probably need to write "memory" since it modifies memory, but what
  > for example in memchr case, wich just reads memory, do I put there
  > "memory" too to force gcc update all memory locations (and do not store some data in registers)
  > 
  > Is there some way to say gcc, that is just updates given block of memory
  > (rtl expression for memcpy dont say clobbers:memory but says set BLK...
  > is there any way to write this in asm?)
I'm not aware of any way to selectively tell gcc that only a certain block
of memory is read/clobbered by an asm (or any BLKmode instruction).

This is something that has been talked about, but I don't see anything
happening in this area anytime soon.

  > When exactly I need to write volatile? Does memcpy implementation need
  > volatile or fact, that it changes memory is enought for gcc to do not
  > make "bad" optimizations?
  > What it memchr case?
  > I know that I need to write volatile in thinks like "cli" but it is require  > d
  > here too?
You can prevent an @code{asm} instruction from being deleted, moved
significantly, or combined, by writing the keyword @code{volatile} after
the @code{asm}.  For example:

So, if you need the asm to never be deleted, moved significantly or
combined, then you need the volatile.

jeff

Re: asm and "cc" "memory" volatile etc.. (slightly offtopic)

[Richard Henderson]

On Tue, Nov 11, 1997 at 10:59:21AM -0700, Jeffrey A Law wrote:
>   > Is there some way to say gcc, that is just updates given block of memory
>   > (rtl expression for memcpy dont say clobbers:memory but says set BLK...
>   > is there any way to write this in asm?)
> I'm not aware of any way to selectively tell gcc that only a certain block
> of memory is read/clobbered by an asm (or any BLKmode instruction).

The following has been found to be effective.

	struct large_struct { unsigned long buf[1234]; };
	#define m(x) (*(struct large_struct *)(x))
	
	extern inline int test_bit(int nr, void *addr)
	{
		int ret;
		__asm__("btl %2,%1\n\tsbbl %0,%0"
			: "=r"(ret)
			: "m"(m(addr)), "ir"(nr));
		return ret;
	}


r~

Re: asm and "cc" "memory" volatile etc.. (slightly offtopic)

[Paul Koning]

>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

 Richard> On Tue, Nov 11, 1997 at 10:59:21AM -0700, Jeffrey A Law
 Richard> wrote:
 >> > Is there some way to say gcc, that is just updates given block
 >> of memory > (rtl expression for memcpy dont say clobbers:memory
 >> but says set BLK...  > is there any way to write this in asm?)
 >> I'm not aware of any way to selectively tell gcc that only a
 >> certain block of memory is read/clobbered by an asm (or any
 >> BLKmode instruction).

 Richard> The following has been found to be effective.

 Richard> struct large_struct { unsigned long buf[1234]; }; #define
 Richard> m(x) (*(struct large_struct *)(x))
	
 Richard> extern inline int test_bit(int nr, void *addr) { int ret;
 Richard> __asm__("btl %2,%1\n\tsbbl %0,%0" : "=r"(ret) :
 Richard> "m"(m(addr)), "ir"(nr)); return ret; }

I've found that some backends are perfectly happy to rearrange asm
statements (gnu extended asm, that is) even if wrapped inside an
inline function.  As far as I understand it, the only reliable way to
force that not to happen is to say "asm volatile".  (Note that
declaring the inline function "volatile" doesn't help.)

Then again, for other back ends you may not see this, and for those
that will do this, they won't do it for all the test cases you feed
it.

	paul

Re: asm and "cc" "memory" volatile etc.. (slightly offtopic)

[Richard Henderson]

On Tue, Nov 11, 1997 at 05:48:55PM -0500, Paul Koning wrote:
>  Richard> extern inline int test_bit(int nr, void *addr) { int ret;
>  Richard> __asm__("btl %2,%1\n\tsbbl %0,%0" : "=r"(ret) :
>  Richard> "m"(m(addr)), "ir"(nr)); return ret; }
> 
> I've found that some backends are perfectly happy to rearrange asm
> statements (gnu extended asm, that is) even if wrapped inside an
> inline function.  As far as I understand it, the only reliable way to
> force that not to happen is to say "asm volatile".  (Note that
> declaring the inline function "volatile" doesn't help.)

Yes, but it primarily depends on what you want to have happen. 

In this case the asm does not affect the external system, it just looks
at it.  Thus if the result of test_bit() is not used, we want the asm to
be removed as well, which would not happen if you declared it volatile.

Mostly you just have to think "does this absolutely have to happen right
here to get correct results".


r~