Close #2695.
---
cpukit/score/Makefile.am| 1 +
cpukit/score/cpu/sparc/Makefile.am | 1 -
cpukit/score/cpu/sparc/sparcv8-atomic.c | 211
cpukit/score/src/libatomic.c| 79
4 files changed, 80 insertions(+), 212 dele
Close #2695.
---
cpukit/score/Makefile.am| 1 +
cpukit/score/cpu/sparc/Makefile.am | 1 -
cpukit/score/cpu/sparc/sparcv8-atomic.c | 211
cpukit/score/src/libatomic.c| 79
4 files changed, 80 insertions(+), 212 dele
On 02/10/14 11:16, Daniel Cederman wrote:
> I would not put too much time into this. Who needs this stuff?
Thanks for the comment. I thought it would be a quick fix to add support, but
looking at the code that gcc generates for _Atomic struct's I do not really
trust it to be correct. And on em
On 2014-10-02 15:09, Daniel Gutson wrote:
On Thu, Oct 2, 2014 at 6:16 AM, Daniel Cederman wrote:
I would not put too much time into this. Who needs this stuff?
Thanks for the comment. I thought it would be a quick fix to add support,
but looking at the code that gcc generates for _Atomic s
On October 2, 2014 8:09:33 AM CDT, Daniel Gutson
wrote:
>On Thu, Oct 2, 2014 at 6:16 AM, Daniel Cederman
>wrote:
>>> I would not put too much time into this. Who needs this stuff?
>>
>> Thanks for the comment. I thought it would be a quick fix to add
>support,
>> but looking at the code that
On Thu, Oct 2, 2014 at 6:16 AM, Daniel Cederman wrote:
>> I would not put too much time into this. Who needs this stuff?
>
> Thanks for the comment. I thought it would be a quick fix to add support,
> but looking at the code that gcc generates for _Atomic struct's I do not
> really trust it to be
> I would not put too much time into this. Who needs this stuff?
Thanks for the comment. I thought it would be a quick fix to add
support, but looking at the code that gcc generates for _Atomic struct's
I do not really trust it to be correct. And on embedded platforms it is
probably better to
On 01/10/14 16:20, Daniel Cederman wrote:
I'm looking at GCC's libatomic, which provides software emulation of atomic
operations that are not supported by hardware. It does this by using a
compare-and-swap loop, or, failing that, using locks. At the moment it is not
selected for compilation for R
mment also seems to indicate that interrupts should not
be disabled, but that would probably easily cause a deadlock in a
real-time system? I'm new to using locks in a real-time setting so any
comments on the matter are appreciated.
Does this seem like a possible approac
