<div dir="ltr">Ryan, <div style>if you look at line 270, you&#39;ll see the CAS is a C call <a href="https://github.com/ghc/ghc/blob/95e6865ecf06b2bd80fa737e4fa4a24beaae25c5/rts/PrimOps.cmm#L270">https://github.com/ghc/ghc/blob/95e6865ecf06b2bd80fa737e4fa4a24beaae25c5/rts/PrimOps.cmm#L270</a> </div>

<div style><br></div><div style>What Simon is alluding to is some work I started (but need to finish)</div><div style><a href="http://ghc.haskell.org/trac/ghc/ticket/7883">http://ghc.haskell.org/trac/ghc/ticket/7883</a> is the relevant ticket, and I&#39;ll need to sort out doing the same on the native code gen too<br>

</div><div style><br></div><div style>there ARE no write barrier primops, they&#39;re baked into the CAS machinery in ghc&#39;s rts</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 1:02 PM, Ryan Newton <span dir="ltr">&lt;<a href="mailto:rrnewton@gmail.com" target="_blank">rrnewton@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Yes, I&#39;d absolutely rather not suffer C call overhead for these functions (or the CAS functions).  But isn&#39;t that how it&#39;s done currently for the casMutVar# primop?</div>

<div><br></div>
<div><a href="https://github.com/ghc/ghc/blob/95e6865ecf06b2bd80fa737e4fa4a24beaae25c5/rts/PrimOps.cmm#L265" target="_blank">https://github.com/ghc/ghc/blob/95e6865ecf06b2bd80fa737e4fa4a24beaae25c5/rts/PrimOps.cmm#L265</a><br>



</div>
<div><br></div><div>To avoid the overhead, is it necessary to make each primop in-line rather than out-of-line, or just to get rid of the &quot;ccall&quot;?</div><div><br></div>Another reason it would be good to package these with GHC is that I&#39;m having trouble building robust libraries of foreign primops that work under all &quot;ways&quot; (e.g. GHCI).  For example, this bug:<div>




<br></div><div>    <a href="https://github.com/rrnewton/haskell-lockfree-queue/issues/10" target="_blank">https://github.com/rrnewton/haskell-lockfree-queue/issues/10</a><br></div><div><br></div><div>If I write .cmm code that depends on RTS functionality like stg_MUT_VAR_CLEAN_info, then it seems to work fine when in compiled mode (with/without threading, profiling), but I get link errors from GHCI where these symbols aren&#39;t defined.</div>




<div><br></div><div>I&#39;ve got a draft of the relevant primops here:</div><div><br></div><div><a href="https://github.com/rrnewton/haskell-lockfree-queue/blob/master/AtomicPrimops/cbits/primops.cmm" target="_blank">https://github.com/rrnewton/haskell-lockfree-queue/blob/master/AtomicPrimops/cbits/primops.cmm</a><br>




</div><div><br></div><div>Which includes:</div><div><ul><li>variants of CAS for MutableArray# and MutableByteArray#</li><li>fetch-and-add for MutableByteArray#</li></ul></div><div>
Also, there are some tweaks to support the new &quot;ticketed&quot; interface for safer CAS:</div><div><br></div><div>   <a href="http://hackage.haskell.org/packages/archive/atomic-primops/0.3/doc/html/Data-Atomics.html#g:3" target="_blank">http://hackage.haskell.org/packages/archive/atomic-primops/0.3/doc/html/Data-Atomics.html#g:3</a><br>




</div><div><br></div><div>I started adding some of these primops to GHC proper (still as out-of-line), but not all of them.  I had gone with the foreign primop route instead...</div><div><br></div><div>
   <a href="https://github.com/rrnewton/ghc/commits/master" target="_blank">https://github.com/rrnewton/ghc/commits/master</a><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>

<br></div><div>  -Ryan</div></font></span><div><br></div><div>P.S. Where is the write barrier primop?  I don&#39;t see it listed in prelude/primops.txt...</div><div><div class="h5">


<div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 11:41 AM, Carter Schonwald <span dir="ltr">&lt;<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>&gt;</span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I guess I should find the time to finish the CAS primop work I volunteered to do then. Ill look into in a few days. <div>




<div><span></span><br><br>On Friday, July 19, 2013, Simon Marlow  wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>

On 18/07/13 14:17, Ryan Newton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The &quot;atomic-primops&quot; library depends on symbols such as<br>
store_load_barrier and &quot;cas&quot;, which are defined in SMP.h.  Thus the<br>
result is that if the program is linked WITHOUT &quot;-threaded&quot;, the user<br>
gets a linker error about undefined symbols.<br>
<br>
The specific place it&#39;s used is in the &#39;foreign &quot;C&quot;&#39; bits of this .cmm code:<br>
<br>
<a href="https://github.com/rrnewton/haskell-lockfree-queue/blob/87e63b21b2a6c375e93c30b98c28c1d04f88781c/AtomicPrimops/cbits/primops.cmm" target="_blank">https://github.com/rrnewton/<u></u>haskell-lockfree-queue/blob/<u></u>87e63b21b2a6c375e93c30b98c28c1<u></u>d04f88781c/AtomicPrimops/<u></u>cbits/primops.cmm</a><br>






<br>
I&#39;m trying to explore hacks that will enable me to pull in those<br>
functions during compile time, without duplicating a whole bunch of code<br>
from the RTS.  But it&#39;s a fragile business.<br>
<br>
It seems to me that some of these routines have general utility.  In<br>
future versions of GHC, could we consider linking in those routines<br>
irrespective of &quot;-threaded&quot;?<br>
</blockquote>
<br>
We should make the non-THREADED versions EXTERN_INLINE too, so that there will be (empty) functions to call in rts/Inlines.c.  Want to submit a patch?<br>
<br>
A better solution would be to make them into primops.  You don&#39;t really want to be calling out to a C function to implement a memory barrier. We have this for write_barrier(), but none of the others so far.  Of couse that&#39;s a larger change.<br>






<br>
Cheers,<br>
        Simon<br>
<br>
<br>
<br></div></div>
______________________________<u></u>_________________<br>
ghc-devs mailing list<br>
<a>ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/ghc-devs</a><br>
</blockquote>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>