<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 03/26/2012 11:00 AM, Yang Wei wrote:
    <blockquote
      cite="mid:C9C2B75C-2463-4E46-B755-3E4B7F618308@gmail.com"
      type="cite">
      <pre wrap="">

在 2012-3-26,23:45,Sebastian Huber <a class="moz-txt-link-rfc2396E" href="mailto:sebastian.huber@embedded-brains.de"><sebastian.huber@embedded-brains.de></a> 写道:

</pre>
      <blockquote type="cite">
        <pre wrap="">On 03/26/2012 05:32 PM, Gedare Bloom wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Maybe we should design our API to be at least a superset of what the
compiler must provide for C11 compliance. Target architectures /
compilers that do not support the C11 atomics will need the atomic
operations implemented in assembly language. For targets that are
supported the API will thinly wrap the C-language atomic features and
can share code.
</pre>
        </blockquote>
        <pre wrap="">
This is reinventing the wheel.  I don't see why we need the 100th atomic library.

</pre>
      </blockquote>
      <pre wrap="">The C11 support for atomic primitive since 2011. Whether the compiler like gcc has support all the atomic primitives and for all architectures? And Rtems does not use standard library provided by compiler, so we still support all the atomic primitives on the newlib. There are also lots of work to do if we support all the atomic primitives defined by C11 standard</pre>
    </blockquote>
    GCC 4.7 is making progress. There is the P99 collection:<br>
    <br>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <a href="http://p99.gforge.inria.fr/p99-html/group__atomic.html">http://p99.gforge.inria.fr/p99-html/group__atomic.html</a><br>
    <br>
    and this:<br>
    <br>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <a
href="http://svnweb.freebsd.org/base/head/include/stdatomic.h?view=markup">http://svnweb.freebsd.org/base/head/include/stdatomic.h?view=markup</a><br>
    <br>
    which claims to support three different types of compilers:<br>
    <br>
    + Clang 3.1's atomic intrinsics (not released yet)<br>
    + GCC 4.7's atomic intrinsics <br>
    + GCC's __sync interface<br>
    <br>
    I don't know if clang 3.1 has been released but gcc 4.7 has been
    released<br>
    since the description of stdatomic.h was written.<br>
    <br>
    FWIW there is also the small set of TAS, CMP/SWP type operations<br>
    used in the shmdr in RTEMS. Updating those would be an appropriate<br>
    part of this task.<br>
    <br>
    But in general, my concern for all of this is what are the use cases<br>
    from RTEMS perspective.<br>
    <br>
    + Is it only for SMP or AMP use?<br>
    <br>
    + MP as in shared memory MP found in RTEMS for years. Kernel locks
    in [AS]MP? <br>
    <br>
    + Is there a uniprocessor use case?<br>
    <br>
    Off the top of my head, I have trouble seeing how stdatomic.h<br>
    wouldn't be a good starting spot for RTEMS for kernel locking.<br>
    <br>
    If we are generalizing all SMP/CPU interface points, then the<br>
    idea of current CPU core is another thing to consider.<br>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <blockquote
      cite="mid:C9C2B75C-2463-4E46-B755-3E4B7F618308@gmail.com"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : <a class="moz-txt-link-abbreviated" href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
</pre>
      </blockquote>
      <pre wrap="">
_______________________________________________
rtems-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>
<a class="moz-txt-link-freetext" href="http://www.rtems.org/mailman/listinfo/rtems-users">http://www.rtems.org/mailman/listinfo/rtems-users</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a>        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

</pre>
  </body>
</html>