On 04/01/2016 22:29, Peter Maydell wrote:
On 4 January 2016 at 13:24, Jakob Bohm <jb-gnumli...@wisemo.com> wrote:
For your information, the x86 memory model only requires
barriers in the following cases (this is somewhat
implemented on modern machines with multiple actual x86
CPU sockets, as opposed to multicore chips, it may also
be observed when using any kind of DMA/bus-master
hardware such as GPUs):
[list elided]
This still leaves the majority of code not doing memory barriers.
This implies that x86 has no stricter restrictions on
reordering of plain loads and stores than ARM does. That
surprises me -- I thought x86's memory model imposed
stricter constraints on the implementation. (For instance
https://en.wikipedia.org/wiki/Memory_ordering#In_symmetric_multiprocessing_.28SMP.29_microprocessor_systems
lists several cases like load-after-load that ARM might
reorder but x86 forbids reordering for.)
But I haven't looked into the details beyond mentally
tagging the situation as "here be dragons" for if/when
I ever need to review any code dealing with it.
Looking briefly at that table, I am unsure which items are covered by
those first 3 lines they say are not permitted on x86, but are
permitted on ARMv7.
The key difference I am aware of is that most traditional x86 atomic
operations are defined to also act as full memory barriers, meaning
that any memory operations that logically occur before/after the
operation also do so as seen by other CPUs (the lines in the table
marked "atomic reordered with...").
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
