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 > ghc-devs@haskell.org > http://www.haskell.org/**mailman/listinfo/ghc-devs<http://www.haskell.org/mailman/listinfo/ghc-devs> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
