GHCI/FFI/GMP/Me madness

[Remi Turk]

On Thu, Aug 12, 2004 at 09:30:58AM +0100, Simon Marlow wrote:
> 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.  

I know, but my (latest) util.c doesn't do that. Every GMP-operation
is enclosed in two mp_set_memory_functions-calls.

> > ("*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.

Errr, I guess I'll have to start looking for a straitjacket then ;)
Finalisers where exactly what I was thinking about, and though
below implementation without doubt contains a bunch of bugs,
perhaps even show-stoppers, the following code _does_ print True:

import Mpz

main= print $ show (z::Integer) == show (z::Mpz)
    where
        -- some random calculations
        x, y, z :: Blub a => a
        x   = 2^64 - sum (take 100 $ iterate (63*) 3)
        y   = 3^200 * 234233432 - (34 `pow` 38) + sum [1,87..20000]
        z   = fac 5000 * (x + y) `div` (2^100)

Or are finalisers simply going to be too slow to take seriously
for this?

> > 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.

Never mind. You answered my question anyway ;)

Greetings,
Remi

-- 
Nobody can be exactly like me. Even I have trouble doing it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mpz.tar.gz
Type: application/x-tar-gz
Size: 3651 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/glasgow-haskell-users/attachments/20040813/e5d91537/Mpz.tar.bin