On 19/07/13 18:02, Ryan Newton wrote:
Yes, I'd absolutely rather not suffer C call overhead for these
functions (or the CAS functions). But isn't that how it's done
currently for the casMutVar# primop?
https://github.com/ghc/ghc/blob/95e6865ecf06b2bd80fa737e4fa4a24beaae25c5/rts/PrimOps.cmm#L265
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 "ccall"?
The best thing would be to get rid of the overhead, but the native code
generators need to be taught how to generate code for cas.
Another reason it would be good to package these with GHC is that I'm
having trouble building robust libraries of foreign primops that work
under all "ways" (e.g. GHCI). For example, this bug:
https://github.com/rrnewton/haskell-lockfree-queue/issues/10
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't defined.
That's a bug, I'll fix it.
I've got a draft of the relevant primops here:
https://github.com/rrnewton/haskell-lockfree-queue/blob/master/AtomicPrimops/cbits/primops.cmm
Which includes:
* variants of CAS for MutableArray# and MutableByteArray#
* fetch-and-add for MutableByteArray#
Also, there are some tweaks to support the new "ticketed" interface for
safer CAS:
http://hackage.haskell.org/packages/archive/atomic-primops/0.3/doc/html/Data-Atomics.html#g:3
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...
https://github.com/rrnewton/ghc/commits/master
Ok, will you make a ticket and attach the patches when you're ready?
-Ryan
P.S. Where is the write barrier primop? I don't see it listed in
prelude/primops.txt.
It's not a primop. Perhaps it should be. It's a MachOp in Cmm, you
write it as
prim write_barrier;
Cheers,
Simon
On Fri, Jul 19, 2013 at 11:41 AM, Carter Schonwald
<[email protected] <mailto:[email protected]>> wrote:
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.
On Friday, July 19, 2013, Simon Marlow wrote:
On 18/07/13 14:17, Ryan Newton wrote:
The "atomic-primops" library depends on symbols such as
store_load_barrier and "cas", which are defined in SMP.h.
Thus the
result is that if the program is linked WITHOUT "-threaded",
the user
gets a linker error about undefined symbols.
The specific place it's used is in the 'foreign "C"' bits of
this .cmm code:
https://github.com/rrnewton/__haskell-lockfree-queue/blob/__87e63b21b2a6c375e93c30b98c28c1__d04f88781c/AtomicPrimops/__cbits/primops.cmm
<https://github.com/rrnewton/haskell-lockfree-queue/blob/87e63b21b2a6c375e93c30b98c28c1d04f88781c/AtomicPrimops/cbits/primops.cmm>
I'm trying to explore hacks that will enable me to pull in those
functions during compile time, without duplicating a whole
bunch of code
from the RTS. But it's a fragile business.
It seems to me that some of these routines have general
utility. In
future versions of GHC, could we consider linking in those
routines
irrespective of "-threaded"?
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?
A better solution would be to make them into primops. You don'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's a larger change.
Cheers,
Simon
_________________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/__mailman/listinfo/ghc-devs
<http://www.haskell.org/mailman/listinfo/ghc-devs>
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
