Messages in this thread | | | From | Chase Venters <> | Subject | Re: [patch] spinlocks: remove 'volatile' | Date | Thu, 6 Jul 2006 09:05:51 -0500 |
| |
On Thursday 06 July 2006 08:39, J.A. Magallón wrote: > > // Read 10 samples from 2 A/D converters. > > int* ina; > int a[10]; > int* inb; > int b[10]; > > for (int i=0; i<10; i++) > { > a[i] = *ina; > barrier(); > b[i] = *inb; > } > > The barrier prevents the compiler of translating this to: > > for (int i=0; i<10; i++) > { > b[i] = *inb; > a[i] = *ina; > } > > or even to: > > for (int i=0; i<10; i++) > a[i] = *ina; > for (int i=0; i<10; i++) > b[i] = *inb; > > but does not prevent it to do this: > > register int tmp_a = *ina; > register int tmp_b = *inb; > > for (int i=0; i<10; i++) > { > a[i] = tmp_a; > b[i] = tmp_b; > } > > because nor 'ina' nor 'inb' change under what the compiler sees inside > the loop. 'volatile' prevents the compiler of do a high level cache of > *ina or *inb. >
Check the GCC documentation:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Extended-Asm.html
> If your assembler instructions access memory in an unpredictable fashion, > add `memory' to the list of clobbered registers. This will cause GCC to not > keep memory values cached in registers across the assembler instruction and > not optimize stores or loads to that memory. You will also want to add the > volatile keyword if the memory affected is not listed in the inputs or > outputs of the asm, as the `memory' clobber does not count as a side-effect > of the asm. If you know how large the accessed memory is, you can add it as > input or output but if this is not known, you should add `memory'. As an > example, if you access ten bytes of a string, you can use a memory input > like:
The reference to the volatile keyword here is of course talking about asm volatile usage to keep the compiler from optimizing out the seemingly pointless assembly (not usage on a variable).
Thanks, Chase - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |