Well, the contents of opal/asm/asm-data.txt and the arch-specific subdirs
below opal/include/opal/sys have served me as a list of the atomics
implementations. If those include architectures no longer officially
supported, then some cleanup may be in order (as SPARC_v8 was recently
removed from asm
I think the closest thing we have to a supported architecture list is in the
README.
On Aug 11, 2014, at 2:42 PM, Nathan Hjelm wrote:
>
> Which brings us back to Dave's question. Is there a list of supported
> architectures? I don't want to bother with DEC Alpha if we no longer
> support it.
Which brings us back to Dave's question. Is there a list of supported
architectures? I don't want to bother with DEC Alpha if we no longer
support it.
BTW, so far I have converted: AMD64, IA32, ARM. Working on IA64 now.
-Nathan
On Mon, Aug 11, 2014 at 01:57:21PM -0400, George Bosilca wrote:
>
Dave,
We all understand your concerns. However, the current issue has nothing to
do with Nathan, the code for supporting ARMv5 is already in the patch I
submitted and that Paul validated.
What Nathan said he might take a look at is a different method for
generating assembly code, one that only su
On Aug 11, 2014, at 11:54 AM, Paul Hargrove wrote:
> I am on the same page with George here - if it's on the list then support it
> until its been removed.
>
> I happen to have systems to test, I believe, every supported atomics
> implementation except for DEC Alpha, and so I did test them all
I am on the same page with George here - if it's on the list then support
it until its been removed.
I happen to have systems to test, I believe, every supported atomics
implementation except for DEC Alpha, and so I did test them all.
AFAIK ARMv5 is even out-dated as a smartphone platform.
-Paul
It is not that I care, but it was one of our supported platforms and we
don't usually drop support for anything without a proper RFC.
George.
On Mon, Aug 11, 2014 at 12:09 PM, Dave Goodell (dgoodell) <
dgood...@cisco.com> wrote:
> On Aug 7, 2014, at 11:37 PM, George Bosilca wrote:
>
> > Pa
On Aug 7, 2014, at 11:37 PM, George Bosilca wrote:
> 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.
Wait, why do we care about ARMv5? It's certainly not a serious HPC platform,
nor is it even a rele
: add atomic compare-and-swap that returns old
value
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
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 wrote:
> Thanks to Paul help all the
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.
atomics.patch
Description: Binary data
On Aug 1, 2014, at 18:09 , Paul
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 wrote:
> Another version of the atomic patch. Paul has tested it on a bunch of
> platforms. At this point we have confirmatio
MIPS32, MIPS64 and ARMv7 tests are also pending.
-Paul
On Fri, Aug 1, 2014 at 9:40 AM, George Bosilca 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.
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.
atomics.patch
Description: Binary data
On Jul 31, 2014, at 19:13 , George Bosilca wrote:
> All,
>
> Here is the p
George,
I compiled trunk with your patch for SPARCV9/Linux/GCC.
I see following warning/errors.
In file included from opal/include/opal/sys/atomic.h:175,
from opal/asm/asm.c:21:
opal/include/opal/sys/sparcv9/atomic.
In case someone else want to play with the new atomics here is the most
up-to-date patch.
George.
On Thu, Jul 31, 2014 at 10:26 PM, Paul Hargrove wrote:
> George:
>
> Have a failure with your patch applied on PPC64/Linux and gcc-4.4.6:
>
> Making all in asm
> make[2]: Entering directory
> `
George:
Have a failure with your patch applied on PPC64/Linux and gcc-4.4.6:
Making all in asm
make[2]: Entering directory
`/home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/BLD/opal/asm'
CC asm.lo
In file included from
/home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/openmpi-1.9a1r32369
Awesome, thanks Paul. When the results will be in we will fix whatever is
needed for these less common architectures.
George.
On Thu, Jul 31, 2014 at 7:24 PM, Paul Hargrove wrote:
>
>
> On Thu, Jul 31, 2014 at 4:22 PM, Paul Hargrove wrote:
>
>>
>> On Thu, Jul 31, 2014 at 4:13 PM, George Bo
On Thu, Jul 31, 2014 at 4:22 PM, Paul Hargrove wrote:
>
> On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca
> wrote:
>
>> Paul, I know you have a pretty diverse range computers. Can you try to
>> compile and run a "make check" with the following patch?
>
>
> I will see what I can do for ARMv7, MIP
On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca wrote:
> Paul, I know you have a pretty diverse range computers. Can you try to
> compile and run a "make check" with the following patch?
I will see what I can do for ARMv7, MIPS, PPC and IA64 (or whatever subset
of those is still supported).
The
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
ope
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
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 flavo
On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm 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
What: Add new versions of opal_atomic_cmpset_* that return the old value
not whether they succeeded.
Why: I plan on adding support for network atomics to the BTL
interface. The compare-and-swap function will return the old value from
the target memory location. In order to implement a similar ope
25 matches
Mail list logo