Paul's tests identified an small issue with the previous patch (a real corner-case for ARM v5). The patch below is fixing all known issues.
Btw, there is still room for volunteers for the .asm work. George. On Tue, Aug 5, 2014 at 2:23 PM, George Bosilca <bosi...@icl.utk.edu> wrote: > Thanks to Paul help all the inlined atomics have been tested. The new > patch is attached below. However, this only fixes the inline atomics, all > those generated from the *.asm files have not been updated. Any volunteer? > > George. > > > > On Aug 1, 2014, at 18:09 , Paul Hargrove <phhargr...@lbl.gov> wrote: > > I have confirmed that George's latest version works on both SPARC ABIs. > > ARMv7 and three MIPS ABIs still pending... > > -Paul > > > On Fri, Aug 1, 2014 at 9:40 AM, George Bosilca <bosi...@icl.utk.edu> > wrote: > >> Another version of the atomic patch. Paul has tested it on a bunch of >> platforms. At this point we have confirmation from all architectures except >> SPARC (v8+ and v9). >> >> George. >> >> >> >> On Jul 31, 2014, at 19:13 , George Bosilca <bosi...@icl.utk.edu> wrote: >> >> > All, >> > >> > Here is the patch that change the meaning of the atomics to make them >> always return the previous value (similar to sync_fetch_and_<*>). I tested >> this with the following atomics: OS X, gcc style intrinsics and AMD64. >> > >> > I did not change the base assembly files used when GCC style assembly >> operations are not supported. If someone feels like fixing them, feel free. >> > >> > Paul, I know you have a pretty diverse range computers. Can you try to >> compile and run a “make check” with the following patch? >> > >> > George. >> > >> > <atomics.patch> >> > >> > On Jul 30, 2014, at 15:21 , Nathan Hjelm <hje...@lanl.gov> wrote: >> > >> >> >> >> That is what I would prefer. I was trying to not disturb things too >> >> much :). Please bring the changes over! >> >> >> >> -Nathan >> >> >> >> On Wed, Jul 30, 2014 at 03:18:44PM -0400, George Bosilca wrote: >> >>> Why do you want to add new versions? This will lead to having two, >> almost >> >>> identical, sets of atomics that are conceptually equivalent but >> different >> >>> in terms of code. And we will have to maintained both! >> >>> I did a similar change in a fork of OPAL in another project but >> instead of >> >>> adding another flavor of atomics, I completely replaced the >> available ones >> >>> with a set returning the old value. I can bring the code over. >> >>> George. >> >>> >> >>> On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove <phhargr...@lbl.gov> >> wrote: >> >>> >> >>> On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm <hje...@lanl.gov> >> wrote: >> >>> >> >>> Is there a reason why the >> >>> current implementations of opal atomics (add, cmpset) do not >> return >> >>> the >> >>> old value? >> >>> >> >>> Because some CPUs don't implement such an atomic instruction? >> >>> >> >>> On any CPU one *can* certainly synthesize the desired operation >> with an >> >>> added read before the compare-and-swap to return a value that was >> >>> present at some time before a failed cmpset. That is almost >> certainly >> >>> sufficient for your purposes. However, the added load makes it >> >>> (marginally) more expensive on some CPUs that only have the native >> >>> equivalent of gcc's __sync_bool_compare_and_swap(). >> >
atomics.patch
Description: Binary data
