GHCI/FFI/GMP/Me madness

[Simon Marlow]

On 11 August 2004 20:45, Remi Turk wrote:

> But as long as GMP doesn't mind about being abused the way my
> most recent util.c does, I can get away with the
> mp_set_memory_functions-trick, can't I?

Not really.  You can't let GMP realloc() a memory block that was
allocated using one method, with a different method.  Also, GMP must not
try to free() a block that was allocated using a different method.  

> ("*Be sure to call `mp_set_memory_functions' only when there are no
> active GMP objects allocated using the previous memory functions!
> Usually that means calling it before any other GMP function.*",
> and using undocumented features)
> 
> And with this trick and a ffi GMP-binding implement a working Mpz
> datatype.
> 
> And when (if?) this is done, drop in a "type Mpz = Integer", rip
> out all Integer-primops, remove the mp_set_memory_functions-trick
> and start benchmarking?
> (Conveniently forgetting that "fromInteger :: Integer -> Integer"
> most certainly has to stay a primop anyway...)

How do you arrange to free a GMP integer when it is no longer referenced
from the heap?  You'd need finalizers, and that way lies madness.  The
memory allocation tricks we play with GMP are all to support GC of
Integers.

> Or is the rts using Integers in such a way that any (standard
> malloc) allocations are forbidden while e.g. "(*) :: Integer ->
> Integer -> Integer" is running?

Not sure what you mean here - malloc() can always be used.

Cheers,
	Simon