atomic support for RTEMS

[Cláudio Silva]

Yes. Some versions of the LEON3 and the LEON4 support the CASA instruction
from SPARC v9.


On Tue, Apr 9, 2013 at 5:54 PM, Gedare Bloom <gedare at rtems.org> wrote:

> 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 [1] 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
> >
> > WeiY
> > 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.
> >>>
> >>> -WeiY
> >>>
> >>> 在 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.
> >>>>
> >>>> -Gedare
> >>>>
> >>>> 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
> >>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
> >>>
> >
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130409/7cbe378a/attachment.html>