atomic support for RTEMS
gedare at rtems.org
Tue Apr 9 16:54:57 UTC 2013
I think the sparc leon3 includes the casa instruction from the sparcv9
instruction set. It is a special case..
On Tue, Apr 9, 2013 at 10:26 AM, Deng Hengyi <wei.a.yang at gmail.com> wrote:
> Hi all,
> About the first part of this project(to make atomic support other architectures), i have add a wiki  to summary the atomic hardware support about all architectures. But there are still some blank in my unfamiliar architectures, if you are familiar with them please help me fill in.
> And i also have a new idea to develop a kernel lock debug tool, just like witness of FreeBSD and lockdep of Linux. witness is a good framework to be ported to RTEMS. This type of tool is very useful to debug lock primitives like mutex and spinlock, especially under SMP environment.
> This is just a preliminary idea, your comments are very useful for me to write a good GSOC proposal.
> 1. http://wiki.rtems.org/wiki/index.php/Atomic-support
> Best Regards
> 在 2013-4-3，上午12:22，Gedare Bloom <gedare at rtems.org> 写道：
>> Remember that Linux code is not an option because it is GPL.
>> On Tue, Apr 2, 2013 at 11:23 AM, Deng Hengyi <wei.a.yang at gmail.com> wrote:
>>> yeah, recently i am doing this work. I have found some architectures like ARM, before ARMV6 there is no really atomic instruction and after ARMV6 it has support ll/sc atomic instruction. But for unprocessor which really has its own atomic instruction the cost of atomic instruction is also heavier than general atomic ops(Disable/Enable ISR), So in my option we should implement the general atomic ops for all unprocessor or unprocessor mode(some SMP-enable architecture). And then port the available atomic ops for SMP-mode architecture in the BSD or Linux to RTEMS. A guide is a must material should be provided.
>>> 在 2013-4-2，下午11:06，Gedare Bloom <gedare at rtems.org> 写道：
>>>> Overall this looks good. Try to find which of the architectures in
>>>> RTEMS we want to support, and whether they have the atomic ops
>>>> available in FreBSD or OpenBSD, or where. Also, develop a guide for
>>>> doing the update to latest upstream as part of this work if there is
>>>> not already a guide available.
>>>> On Tue, Apr 2, 2013 at 10:25 AM, Deng Hengyi <wei.a.yang at gmail.com> wrote:
>>>>> Hi, all
>>>>> The project atomic support for RTEMS a GSOC2012 proposal which implemented architecture-independent API design and two architecture X86 and powerpc support. This year i will continue to doing more work to implement this project. The main tasks include:
>>>>> 1. implement a series of general atomic ops for unprocesse.
>>>>> As we know the atomic instruction has performence cost because of costs of cache misses. There is a picture which list atomic instruction costs. The atomic instruction introduces instruction execution uncertainty. So if the architecture does not support SMP mode it should use general atomic ops which rely the Disable/Enable-IRQ method.
>>>>> 2. support atomic primitive for more architectures like ARM,MIPS,SPARC,etc.
>>>>> If the architecture supports SMP mode(define macro RTEMS_SMP)it will use its own atomic hardware instruction, otherwise it will use general atomic ops.
>>>>> 3. update atomic implementation with the latest freebsd(the powerpc and x86 implementation is ported from freebsd).
>>>>> 4. make existing kinds of synchronization primitives on RTEMS support SMP and to add some new SMP-safe synchronization primitives based on atomic operations.
>>>>> RTEMS existing synchronization primitives:
>>>>> 1. semaphore
>>>>> 2. message
>>>>> 3. event
>>>>> 4. mutexs
>>>>> 5. rwlock
>>>>> 6. spinlock
>>>>> 5. If possible i want to implement some lock-free algorithms or data structures based on atomic ops.
>>>>> This just my preliminary ideas if you have any comment and requirement please repley freely.
>>>>> rtems-devel mailing list
>>>>> rtems-devel at rtems.org
More information about the devel