On Tue, Jul 07, 2009 at 02:40:02PM +0200, Andreas Schwab wrote:
> Gabriel Paubert writes:
>
> > On Fri, Jul 03, 2009 at 10:57:12PM +0200, Andreas Schwab wrote:
> >> The 'Z' constraint is required for a memory operand for insns that don't
> >> have an update form (which would be selected by the %U
Gabriel Paubert writes:
> On Fri, Jul 03, 2009 at 10:57:12PM +0200, Andreas Schwab wrote:
>> The 'Z' constraint is required for a memory operand for insns that don't
>> have an update form (which would be selected by the %U modifier).
>
> Hmmm, I believed that it was for instructions that only
On Fri, Jul 03, 2009 at 10:57:12PM +0200, Andreas Schwab wrote:
> Brad Boyer writes:
>
> > On Fri, Jul 03, 2009 at 12:14:41PM +0530, kernel mailz wrote:
> >> b. using m or Z with a memory address. I tried replacing m/Z but no change
> >> Is there some guideline ?
> >> gcc documentation says Z is
kernel mailz writes:
> My query was more on %U1%X1, I guess it is specifying U and/or X for %1 right
> ?
> what does U/X stand for (is it similar to u - unsigned and x for a hex
> address)
> are there any more literals like U/X/...
The 'U' and 'X' modifiers expand to 'u' and 'x' resp, dependin
Brad Boyer writes:
> On Fri, Jul 03, 2009 at 12:14:41PM +0530, kernel mailz wrote:
>> b. using m or Z with a memory address. I tried replacing m/Z but no change
>> Is there some guideline ?
>> gcc documentation says Z is obsolete. Is m/Z replaceable ?
>
> No idea. I don't remember ever seeing 'Z
Hi Brad,
Thanks for responding.
My query was more on %U1%X1, I guess it is specifying U and/or X for %1 right ?
what does U/X stand for (is it similar to u - unsigned and x for a hex address)
are there any more literals like U/X/...
-Manish
On Fri, Jul 3, 2009 at 11:10 PM, Brad Boyer wrote:
> On
On Fri, Jul 03, 2009 at 12:14:41PM +0530, kernel mailz wrote:
> Thanks for responding to my previous mail. A few more queries
>
> a. What is the use of adding format specifiers in inline assembly
> like
> asm volatile("ld%U1%X1 %0,%1":"=r"(ret) : "m"(*ptr) : "memory");
The format specifiers limit
On Tue, 2009-06-30 at 10:57 +0530, kernel mailz wrote:
> Hi Scott,
> I agree with you, kind of understand that it is required.
> But buddy unless you see some construct work or by adding the
> construct a visible difference is there, the concept is just piece of
> theory.
In this case you'd rather
On Mon, 2009-06-29 at 16:57 +0100, David Howells wrote:
> kernel mailz wrote:
>
> > asm("sync");
>
> Isn't gcc free to discard this as it has no dependencies, no indicated side
> effects, and isn't required to be kept? I think this should probably be:
>
> asm volatile("sync");
It should
kernel mailz writes:
> Consider atomic_add and atomic_add_return in kernel code.
> I am not able to figure out why "memory" is added in latter
The "memory" indicates that gcc should not reorder accesses to memory
from one side of the asm to the other. The reason for putting it on
the atomic ops
kernel mailz wrote:
> Consider atomic_add and atomic_add_return in kernel code.
>
> On Tue, Jun 30, 2009 at 2:59 AM, Ian Lance Taylor wrote:
>> kernel mailz writes:
>>
>>> I tried a small example
>>>
>>> int *p = 0x1000;
>>> int a = *p;
>>> asm("sync":::"memory");
>>> a = *p;
>>>
>>> and
>>>
>>>
Hi Scott,
I agree with you, kind of understand that it is required.
But buddy unless you see some construct work or by adding the
construct a visible difference is there, the concept is just piece of
theory.
I am trying all the kernel code inline assembly to find an example
that works differently
Consider atomic_add and atomic_add_return in kernel code.
On Tue, Jun 30, 2009 at 2:59 AM, Ian Lance Taylor wrote:
> kernel mailz writes:
>
>> I tried a small example
>>
>> int *p = 0x1000;
>> int a = *p;
>> asm("sync":::"memory");
>> a = *p;
>>
>> and
>>
>> volatile int *p = 0x1000;
>> int a = *
kernel mailz writes:
> I tried a small example
>
> int *p = 0x1000;
> int a = *p;
> asm("sync":::"memory");
> a = *p;
>
> and
>
> volatile int *p = 0x1000;
> int a = *p;
> asm("sync");
> a = *p
>
> Got the same assembly.
> Which is right.
>
> So does it mean, if proper use of volatile is done, th
David Howells writes:
> kernel mailz wrote:
>
>> asm("sync");
>
> Isn't gcc free to discard this as it has no dependencies, no indicated side
> effects, and isn't required to be kept? I think this should probably be:
>
> asm volatile("sync");
An asm with no outputs is considered to be vo
On Mon, Jun 29, 2009 at 09:19:57PM +0530, kernel mailz wrote:
> I tried a small example
>
> int *p = 0x1000;
> int a = *p;
> asm("sync":::"memory");
> a = *p;
>
> and
>
> volatile int *p = 0x1000;
> int a = *p;
> asm("sync");
> a = *p
>
> Got the same assembly.
> Which is right.
>
> So does it
kernel mailz wrote:
> asm("sync");
Isn't gcc free to discard this as it has no dependencies, no indicated side
effects, and isn't required to be kept? I think this should probably be:
asm volatile("sync");
David
___
Linuxppc-dev mailing list
Thanks Ian,
For the "memory" clobber
I tried with the a function in linux kernel
--
/*
* Atomic exchange
*
* Changes the memory location '*ptr' to be val and returns
* the previous value stored there.
*/
static inline unsigned long
__xchg_u32(volatile void *p, unsigned long val)
{
uns
18 matches
Mail list logo
