On Fri, Mar 18, 2016 at 12:11:22PM -0500, Craig, Ben via cfe-commits wrote: > A lot of it is a frontend decision. What goes in the libcall feels an awful > lot like the 386 vs 486 example that I hear a lot. If I want one binary > that can run on both a 386 (very limited atomic support) and a 486 (a bit > more atomic support), then I generate the binary such that it has library > calls to atomic routines. The library on the 386 uses the global lock > shard, and the library on the 486 uses native instructions. The same kind > of thing would apply for one byte atomics when only four byte atomics have > hardware support. The library call would use the lock shard as the default. > If the platform doesn't have byte granularity memory protection a different, > lockless implementation could be used that loads the surrounding four bytes > instead and does all the masking.
The situation here is quite different. If you have a way to do lock-free CAS for 32bit, you can implement it for 16bit and 8bit as well. On other hand, if you do not have a lock-free CAS of a given size, it can be implemented as lock-free libcall only if (a) no such MP configuration exists and (b) (non-atomic) load/store of that size is supported. I'm not even sure if such a thing as a SMP i386 ever existed, given that the APIC specifications are all for i486 and later. Joerg _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits