On Fri, 2009-06-05 at 04:07 -0400, Daniel Peebles wrote: > Hi all, > > I'm almost done with a FFI-based GMP binding (an attempt to remove > GHC's dependence on GMP primops). Currently I'm just using the default > GMP allocation functions (malloc/realloc/free), but it's tempting to > do as the current setup does and tell GMP to use the GHC allocator. I > have some questions about this:
I think it's a good idea to continue to use ghc's allocator. One thing you will need to watch out for is that the current integer primops call doYouWantToGC just prior to each gmp function that can allocate. Something equivalent will be required for the ffi binding if you use ghc's allocator. > 1) stgAllocForGMP from rts/sm/Storage.c seems relatively general. > Maybe it, along with realloc and free (a dummy function?), could be > renamed externalAlloc and be "exported" (made non-static) to allow for > FFI bindings to call back into GHC's allocator (several libs allow > callers to override the default allocation functions)? My plan was to move these functions out of the rts entirely, since they only use other "public" bits of the rts api. > 2) stgReallocForGMP currently appears to contain a manual memcpy (with > a for loop copying individual bytes). Is this for a specific reason? I doubt there's any good reason. > 3) If I do point my GMP binding to use the GHC allocator, would that > count as "calling back into haskell"? No, I don't think so. > I really don't want to have to > mark any GMP function that may allocate as "safe" in my foreign import > declarations, but if it needs it there's not much I can do about it. > My integer benchmark suite should tell if it's necessary, anyway. Great. I spent half a day last week as an experiment, ripping gmp and all the gmp-related primops out of the rts and compiler. This is the complement to your work on making a new integer-gmp package based on the ffi. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
