GHCI/FFI/GMP/Me madness

Simon Marlow simonmar at
Wed Aug 11 09:27:19 EDT 2004

On 10 August 2004 16:04, Remi Turk wrote:

>>   - reset GMP's memory allocators before calling it from your code,
>>     and set them back to the RTS allocators afterward.  Slow, but it
>>     should work.  It doesn't solve the problem properly though:
>>     external libraries which use GMP are still broken.
> It does indeed seem to work, after a quick test. (new util.c attached)
> And it does solve _my_ immediate "problem": I can surround every
> gmp-operation with a gmp_begin()/gmp_end() and pretend to be
> happy. (and anyway, I'm just messing around, failure merely means
> I've got yet another unfinished project ;))
> Part of the reason for all this messy FFIing is your post:

Hmm yes, I now realise that it's not quite as easy as I implied in that
message.  The problem is the memory allocation.  If a GMP function
allocates some memory, we have to swizzle the pointer that comes back
(where swizzle(p) { return p-sizeof(StgArrWords) }).  Unfortunately you
have to do this without giving the GC a chance to run, and there's no
way to get this atomicity in plain Haskell+FFI, which is why the primops
are still necessary.

Perhaps one way to do it would be to define generic Integer primop
wrappers - i.e. one wrapper for an mpz function that takes two arguments
and returns one, etc.  The primop implementations already work like
this, except that the wrappers are CPP macros.  If the wrapper were
lifted to the level of a primop itself, then you could easily use
different mpz functions by calling the appropriate primop passing the
address of the mpz function.


More information about the Glasgow-haskell-users mailing list