[rtems commit] tests: atomic support for RTEMS. Uniprocessor tests for atomic ops.

[Joel Sherrill]

On 2/13/2013 10:28 AM, yangwei weiyang wrote:
> OK i am studying how to implement a common ISR_Disable and ISR_Enable
> ops to simulate atomic ops. But it is just for the UP architectures,
> for SMP architectures which are not supported by atomic now this will
> not be suitable.
That's OK. The only architectures we currently support SMP on are
x86 and SPARC (only for LEON3).  Beyond powerpc and arm, I think
it is unlikely we will have SMP.

In general terms, if the CPU doesn't have atomic instructions
to implement these with, then it is very unlikely to ever show
up in an SMP configuration.  This makes the ISR disable/enable
implementation suitable for UP.

My biggest concerns is more general. I envision two common
scenarios within a single architecture:

+ certain cpu models or architecture revisions have atomic
    instructions and some don't. But this is defined in the
   architecture and can be handled in cpukit. ISR disable/enable
    in some cases, real atomic in others.
+ Similar case but CPU models have pulled instructions from
    architectural revisions "above" them. The instruction is
    there but not part of the real architectural revision the CPU
    model is based upon.

The isr disable/enable implementation may need to be available
all the time as a fallback.

--joel
> 2013/2/14 Gedare Bloom <gedare at rtems.org>:
>> On Wed, Feb 13, 2013 at 11:22 AM, yangwei weiyang <wei.a.yang at gmail.com> wrote:
>>> I will add some ops-stubs to other architectures which are not
>>> supported atomic functions now. It will pass the compiler problem but
>>> atomic function will not be implemented really. Then it will not be  a
>>> conditional API.
>>>
>> Can you implement the atomic ops using ISR_Disable and ISR_Enable?
>> Then you can provide a common cpuatomic.h that includes these
>> implementations. Yes they will be "heavy", but they will at least be
>> functional.
>>
>>> 2013/2/13 Ralf Corsepius <ralf.corsepius at rtems.org>:
>>>> On 02/08/2013 01:41 AM, Gedare Bloom wrote:
>>>>> On Thu, Feb 7, 2013 at 5:15 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>>>>> Module:    rtems
>>>>>> Branch:    master
>>>>>> Commit:    fb9fa1537a9765eae90124e5db5770ae7a527d5e
>>>>>> Changeset:
>>>>>> http://git.rtems.org/rtems/commit/?id=fb9fa1537a9765eae90124e5db5770ae7a527d5e
>>>>>>
>>>>>> Author:    WeiY <wei.a.yang at gmail.com>
>>>>>> Date:      Fri Jan 25 23:59:49 2013 +0800
>>>>>>
>>>>>> tests: atomic support for RTEMS. Uniprocessor tests for atomic ops.
>>>>>>
>>>>> The tests do not compile for sis at least. Maybe broken for other
>>>>> targets that do not have the atomics defined?
>>>>
>>>> RTEMS doesn't compile for all targets which do not have a file named
>>>> rtems/score/cpuatomic.h.
>>>>
>>>> i.e. all targets but the powerpc and the i386.
>>>>
>>>>
>>>>> In file included from
>>>>> ../../../../../sis/lib/include/rtems/rtems/atomic.h:26:0,
>>>>>                    from
>>>>>
>>>>> ../../../../../../../../rtems/c/src/../../testsuites/sptests/spatomic01/tasks.c:19:
>>>>> ../../../../../sis/lib/include/rtems/score/atomic.h:21:35: fatal
>>>>> error: rtems/score/cpuatomic.h: No such file or directory
>>>>> compilation terminated.
>>>>>
>>>>> $> find cpukit/score -name cpuatomic.h
>>>>> cpukit/score/cpu/i386/rtems/score/cpuatomic.h
>>>>> cpukit/score/cpu/powerpc/rtems/score/cpuatomic.h
>>>>>
>>>>> We should have some kind of stubs so that non-supported architectures
>>>>> will compile the atomic tests.
>>>> Well, I agree to some extend, but ...
>>>>
>>>> ... I feel this is playing with symptoms.
>>>>
>>>> The actual issue behind all this, is the atomic-API currently being
>>>> implemented as a conditional API - This is not good.
>>>>
>>>> I an ideal world, one would not have any conditional API, but would have a
>>>> target-independent API.
>>>>
>>>> That said, unless this issue can be resolved, IMO, all the atomic headers
>>>> should only be installed/pre-installed, if all ops and headers are
>>>> implemented for a specific target - ATM, this does not apply.
>>>>
>>>> Ralf
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtems-devel mailing list
>>>> rtems-devel at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>>
>>>
>>> --
>>> Wei Yang
>>> Best Regards
>>>
>>> wei.a.yang at gmail.com
>>> _______________________________________________
>>> rtems-devel mailing list
>>> rtems-devel at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985