Yes, this points too much toward C++. But Paolo's find: #define _Compiler_barrier() \ _STL_DISABLE_DEPRECATED_WARNING _ReadWriteBarrier() \ _STL_RESTORE_DEPRECATED_WARNING suggests we should

Since the first two are of unequal power -- volatile for specific accesses and the compiler fence being a general barrier across which the compiler does not optimize memory accesses I think we should

“inline assembly is not supported on the ARM and x64 processors. “ [1]. Kind of looks like MSVC replaced inline assembly with intrinsics [2]. Looks like _ReadBarrier, _ReadWriteBarrier [3] are

In theory, atomic_thread_fence (and in this case, more specifically, atomic_signal_fence) is available also on C11. But if it is possible to assume that _RWB is present on Microsoft toolchains (even

[*] Doesn't look too specific: https://docs.microsoft.com/en-us/cpp/assembler/inline/optimizing-inline-assembly?view=msvc-160 I've found this article very relevant:

Generally, yes. But I already mentioned non-cache coherent DMA devices, and we also have some ARM platforms that use non-shareable mappings for SRAM, which is used as temporary PEI memory in

This seems consistent with the fact that Paolo recommended variants of "dmb ish" for all the memory (not compiler) fences -- I guess we don't care about actual RAM content as long as all CPUs and

<snip> I don't think the message passing paradigm is 100% accurate but it is very close. You should realize that a modern system is a network of CPUs, caches, DRAM controllers and other bus masters,

I am sorry for redirecting to the C++11 share memory model. It has nothing to do with EDK2 here because EDK2 is C based. It's not that TRUE today. If you look into UefiCpuPkg, MpInitLib,

Looks like we are heading for a crash too. So good thing we are thinking about it. The good news is EFI does not have threads and the PI MpServices protocol is indirectly messaging based as you wait

rant warning Thanks. I think what happened here is a catastrophic impedance mismatch. The underlying, physical architecture is a message-passing one. Yet the mental abstraction that is built atop,

Got it, it's a very good question. All edk2 porting targets should naturally align all types not larger than pointers. I can only think of old m68k that had 2-byte aligned 32-bit pointers. Another

Laszlo, Clang treats unaligned pointers as undefined behavior (UB). I’m not sure if this is due to C11? What I know is clang choses to NOT optimize away UB from alignment errors, but if you run the

Ray, In C calling out to assembly is also a barrier/fence operation from the compilers point of view. Actually calling an indirect procedure call (gBS->*, Protoco->*) is also a barrier. The compiler

This is exactly what the fence API implementations should have in their comments, preferably with Intel / AMD manual references... Same, just with the ARM ARM. Thanks! Laszlo

My question was unclearly asked, sorry. Let's say we have a UINT32 at an address that's not a multiple of 4, but a multiple of 2. A pointer to that UINT32 is "acceptably aligned" on x86, but not

To expand: it is an assumption on the implementation of the C compiler; it admittedly goes beyond the C standard but it is a reasonable assumption, compilers may *merge* loads and stores but have no

Wow! Thank you Paolo for explaining everything! I read a bit about c memory model. https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync Do you have any documentation that can explain how the different

This is why I'd like someone else to write the primitives :) - Where is this documented? - Is it architecture-dependent? - Is it alignment-dependent? etc... :) (I'm not challenging your statement

On x86 load-load, load-store and store-store ordering is already guaranteed by the processor. Therefore on x86 the AcquireMemoryFence and ReleaseMemoryFence are just like CompilerFence: they only have