On Thu, May 30, 2019 at 11:53:58AM -0700, Paul E. McKenney wrote: > On Thu, May 30, 2019 at 11:22:42AM -0700, Vineet Gupta wrote: > > Hi Peter, > > > > Had an interesting lunch time discussion with our hardware architects pertinent to > > "minimal guarantees expected of a CPU" section of memory-barriers.txt > > > > > > | (*) These guarantees apply only to properly aligned and sized scalar > > | variables. "Properly sized" currently means variables that are > > | the same size as "char", "short", "int" and "long". "Properly > > | aligned" means the natural alignment, thus no constraints for > > | "char", two-byte alignment for "short", four-byte alignment for > > | "int", and either four-byte or eight-byte alignment for "long", > > | on 32-bit and 64-bit systems, respectively. > > > > > > I'm not sure how to interpret "natural alignment" for the case of double > > load/stores on 32-bit systems where the hardware and ABI allow for 4 byte > > alignment (ARCv2 LDD/STD, ARM LDRD/STRD ....) > > > > I presume (and the question) that lkmm doesn't expect such 8 byte load/stores to > > be atomic unless 8-byte aligned > > I would not expect 8-byte accesses to be atomic on 32-bit systems unless > some special instruction was in use. But that usually means special > intrinsics or assembly code. If the GCC of said platform defaults to the double-word instructions for long long, then I would very much expect natural alignment on it too. If the feature is only available through inline asm or intrinsics, then we can be a little more lenient perhaps. _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
