On Sat, 17 Nov 2018 14:55:05 -0800 Matthew Macy <mat.m...@gmail.com> wrote: > When looking at powerpc io.h raw and relaxed are not aliases, but it > appears that on x86, they are: > https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/io.h > > Sorry for the noise. But let's starting moving the x86 specific > atomic.h and io.h under asm/x86.
Yes, I agree that the file should be moved to an arch specific location. And the functions should probably be implemented using inline asm like they are on Linux in case there are differences in the way compilers treat the C code versus the asm code. > On Sat, Nov 17, 2018 at 2:01 PM Matthew Macy <mat.m...@gmail.com> wrote: >> You should probably revert this. The implied understanding of the >> _relaxed version is incorrect. compiler_membar is there to prevent >> instruction reordering which is possible on FreeBSD because the accesses >> are done in C. The relaxed variants still do not permit instruction >> reordering. On Linux __compiler_member (referred to as barrier there) >> isn’t necessary in the mmio accessors because they always use volatile >> asm which can’t be reordered. The distinction between the relaxed and >> non relaxed variants is that the relaxed variant lacks memory barriers >> (sync / lwsync / eieio on ppc, membar on sparc, etc). Quoting https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html: "Note that the compiler can move even volatile asm instructions relative to other code, including across jump instructions." So I think the Linux implementation of the relaxed variant lacks both CPU and compiler barriers. >> Most of the time we don’t run in to problems on x86 because with TSO >> the only reordering possible is writes that happen before reads can >> become visible in memory after they occur in the instruction stream. Note that these functions are normally used on uncacheable memory which is strongly ordered on x86. There should be no reordering at all. On PowerPC barrier instructions are needed to prevent reordering. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
