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