<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">You just threw down the gauntlet to Xi
      Yang!! Time to<br>
      merge. :)<br>
      <br>
      On 2/13/2013 12:02 PM, Claus, Ric wrote:<br>
    </div>
    <blockquote
cite="mid:D375F1DC68902043B32DC09848C4A9E60136C236A906@EXCHCLUSTER1-01.win.slac.stanford.edu"
      type="cite">
      <pre wrap="">SMP is not available for ARM?  That's a big issue for me.  What's involved to provide that support?</pre>
    </blockquote>
    Compared to writing a BSP from scratch, not much. :)<br>
    <br>
    You can look at either the pc386 or leon3 BSPs and associated<br>
    ports for an idea of how much code is architecture<br>
    and BSP specific.<br>
    <br>
    Or even better.. help us merge the GSOC project by <span
      style="color: rgb(0, 0, 0); font-family: 'Times New Roman';
      font-size: medium; font-style: normal; font-variant: normal;
      font-weight: normal; letter-spacing: normal; line-height: normal;
      orphans: 2; text-align: left; text-indent: 0px; text-transform:
      none; white-space: normal; widows: 2; word-spacing: 0px;
      -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;
      display: inline !important; float: none;">Xi Yang.</span> <br>
    <br>
    <a class="moz-txt-link-freetext" href="http://www.rtems.com/ml/rtems-users/2012/august/msg00084.html">http://www.rtems.com/ml/rtems-users/2012/august/msg00084.html</a><br>
    has a github link. I suspect there may be some BSP or CPU model<br>
    variation between his work and yours.<br>
    <br>
    Our atomic code is based off that in FreeBSD. So this would be the<br>
    starting point for the atomic.h support.<br>
    <br>
<a class="moz-txt-link-freetext" href="http://svnweb.freebsd.org/base/head/sys/arm/include/atomic.h?view=log&pathrev=151334">http://svnweb.freebsd.org/base/head/sys/arm/include/atomic.h?view=log&pathrev=151334</a><br>
    <br>
    --joel<br>
    <blockquote
cite="mid:D375F1DC68902043B32DC09848C4A9E60136C236A906@EXCHCLUSTER1-01.win.slac.stanford.edu"
      type="cite">
      <pre wrap="">

Ric

________________________________________
From: <a class="moz-txt-link-abbreviated" href="mailto:rtems-devel-bounces@rtems.org">rtems-devel-bounces@rtems.org</a> [<a class="moz-txt-link-abbreviated" href="mailto:rtems-devel-bounces@rtems.org">rtems-devel-bounces@rtems.org</a>] On Behalf Of Joel Sherrill [<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a>]
Sent: Wednesday, February 13, 2013 8:42 AM
To: yangwei weiyang
Cc: RTEMS Devel
Subject: Re: [rtems commit] tests: atomic support for RTEMS. Uniprocessor tests for atomic ops.

On 2/13/2013 10:28 AM, yangwei weiyang wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">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
</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>