How to understand the "memory" and the volatile keyword?
Hi,
I want to know how to use inline assembler instruction, and wonder
what is the meaning of "memory" in clobbered register list. According to
the manual of GCC, the "memory" will cause GCC to not keep memory values
cached in registers across the assembler instruction and not optimize
stores or loads to that memory. IMO, that means the "memory" notifies
GCC the assembler instruction meant to modify memory locations; If
variables are cached into registers before the assembler instruction,
then these varialbes should be written back to relevant memory locations
before the assembler instruction, and read when being used again after
the assembler instruction. On the other hand, the "memory" affected
inputs and outputs of the assembler instruction only. Then the volatile
keyword play its role, if the memory affected is not listed in the
inputs and outputs of the assembler instruction. So, I think the
"memory" and the volatile keyword should be used to implement a barried.
I write the following C code to test the effect of the twos:
/* asm.c */
int foobar() {
int i, t, sum = 0;
for (i = 0; i <= 10; i++) {
t = 1 << i;
sum += t;
}
asm volatile ("nop" : : : "memory");
return sum;
}
... ...
I compiled the asm.c using gcc 4.4.7:
gcc -S -O1 asm.c
Then, the asm.s is generated as follows:
foobar:
pushl %ebp
movl%esp, %ebp
pushl %ebx
movl$0, %eax
movl$0, %ecx
movl$1, %edx
.L2:
movl%edx, %ebx
sall%cl, %ebx
addl%ebx, %eax
addl$1, %ecx
cmpl$11, %ecx
jne .L2
#APP
# 10 "hello.c" 1
nop
# 0 "" 2
#NO_APP
negl%eax
popl%ebx
popl%ebp
ret
... ...
It is obvious that every variables are cached into register, and even
though the 'sum' is used after the barrier, it does not written back to
its memory location and read again. I think my idea about the "memory"
and the volatile keyword must be misunderstanding. Any suggestion?
Re: How to understand the "memory" and the volatile keyword?
On January 29, 2017 4:56:46 PM GMT+01:00, parmenides via gcc
wrote:
>Hi,
>
> I want to know how to use inline assembler instruction, and wonder
>what is the meaning of "memory" in clobbered register list. According
>to
>the manual of GCC, the "memory" will cause GCC to not keep memory
>values
>cached in registers across the assembler instruction and not optimize
>stores or loads to that memory. IMO, that means the "memory" notifies
>GCC the assembler instruction meant to modify memory locations; If
>variables are cached into registers before the assembler instruction,
>then these varialbes should be written back to relevant memory
>locations
>before the assembler instruction, and read when being used again after
>the assembler instruction. On the other hand, the "memory" affected
>inputs and outputs of the assembler instruction only. Then the volatile
>
>keyword play its role, if the memory affected is not listed in the
>inputs and outputs of the assembler instruction. So, I think the
>"memory" and the volatile keyword should be used to implement a
>barried.
>I write the following C code to test the effect of the twos:
>
> /* asm.c */
> int foobar() {
> int i, t, sum = 0;
>
> for (i = 0; i <= 10; i++) {
> t = 1 << i;
> sum += t;
> }
> asm volatile ("nop" : : : "memory");
> return sum;
> }
> ... ...
>
>I compiled the asm.c using gcc 4.4.7:
> gcc -S -O1 asm.c
>
>Then, the asm.s is generated as follows:
>
> foobar:
> pushl %ebp
> movl%esp, %ebp
> pushl %ebx
> movl$0, %eax
> movl$0, %ecx
> movl$1, %edx
> .L2:
> movl%edx, %ebx
> sall%cl, %ebx
> addl%ebx, %eax
> addl$1, %ecx
> cmpl$11, %ecx
> jne .L2
> #APP
> # 10 "hello.c" 1
> nop
> # 0 "" 2
> #NO_APP
> negl%eax
> popl%ebx
> popl%ebp
> ret
> ... ...
>
>It is obvious that every variables are cached into register, and even
>though the 'sum' is used after the barrier, it does not written back to
>
>its memory location and read again. I think my idea about the "memory"
>and the volatile keyword must be misunderstanding. Any suggestion?
Local variables are not memory unless they have their address taken and it
escapes.
Richard.
gcc-7-20170129 is now available
Snapshot gcc-7-20170129 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170129/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 245017 You'll find: gcc-7-20170129.tar.bz2 Complete GCC MD5=3b542dcfda0e9c250812e65efa45ee34 SHA1=19d79de32adbe93824d0826e72cf3ba7b625d7ac Diffs from 7-20170122 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
