MIPS32, MIPS64 and ARMv7 tests are also 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(). > >>> > >>> -Paul > >>> -- > >>> Paul H. Hargrove phhargr...@lbl.gov > >>> Future Technologies Group > >>> Computer and Data Sciences Department Tel: +1-510-495-2352 > >>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > >>> _______________________________________________ > >>> devel mailing list > >>> de...@open-mpi.org > >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > >>> Link to this post: > >>> http://www.open-mpi.org/community/lists/devel/2014/07/15328.php > >> > >>> _______________________________________________ > >>> devel mailing list > >>> de...@open-mpi.org > >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > >>> Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15369.php > >> > >> _______________________________________________ > >> devel mailing list > >> de...@open-mpi.org > >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > >> Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15370.php > > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15462.php > -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900