Replacement for GMP

[Peter Tanski]

Hey Esa,

Another great instructive email!  Thanks again!  I will keep this  
response short because I am sure you are busy and you have been more  
than helpful so far.  I also need to get back to working through the  
code...

> I hope my answer helps, but if it gets you more confused,
> maybe it's just because I'm confused...

No, you are just trying to understand what I am saying and since I am  
new to GHC's rts internals I do not yet have the knowledge to express  
my thoughts well.

> There are other nicer things about that as well - untying Integer
> (atleast mostly) from runtime/frontend and moving it more into
> domain of libraries.
>
> <snip>
>
> Another program?  I assume you meant outside pure haskell - "call- 
> outs"
> have side-effects.  We can get around by using unsafePerformIO,
> which doesn't really differ that much from writing it in
> C-- (and library in C), except we'd write haskell.

If the program (written in C--, C, C++, whatever) and the interface  
from Haskell to that program were well-typed it would not be any  
different than writing the entire program in Haskell, but the order  
of execution must remain in sync with the Haskell program.  If the  
rts is threaded or parallel you might imagine problems cropping up.   
In this case I have to evaluate whether, say, OpenSSL's BN library is  
threaded (or, for Parallel Haskell, also working through PVM), not  
merely thread safe and certainly not merely reentrant.

> Uhm, naturally, haskell rts needs to control lifetime of the memory.
> I am not sure what you're trying to say here, really.  Is the point
> that we cannot free almost anything without permission from
> garbage collector?  Because, yeah, we can't.

My problem was not with the garbage collector but with what the  
garbage collector depends on: when an object is evaluated and no  
longer in scope.
I am not insane enough to attempt writing high level mathematical  
operations such as pow() or sqrt() as primitives in an integrated  
Bignum implementation, but you might be able to imagine that at that  
level it would be possible to choose when to save and when to  
evaluate parts of a long equation.

> As I understand, you suggest here copying payload instead of merging
> memory handling.  I don't think it's clearly, if ever, less efficient
> than ForeignPtr-based approach.  But I'd guess it is *more* code
> than current solution.

Excellent point.

>> The third alternative I suggested previously was to embed the Bignum
>> processing in GHC itself.  I think it would be very difficult to
>> maintain a solution that was both optimised and portable, at least in
>> C--.  (I may be way-off here; I am simply going by a rudimentary
>> knowledge of BLAST implementations.)
>
> I don't think it differs much from doing the same in C.
> It does seem shame to write bignum in C--, as we don't get many
> elegance-style advantages from writing it in C-- instead of C.
>
>  <cut and paste from below>
>
> As for what it has to do with topic at hand, I have no idea.
> C-- is simply used as an intermediate language for the compiler, for
> convience of calling conventions and such, some low-level operations
> are written in it.

When I mentioned BLAS (not "BLAST", sorry) implementations I meant  
that--as I understand it--some may contain hand-optimised code  
written in assembler.  Certainly I would personally prefer  
implementing something in C but as you noted C-- allows GHC more  
convenience.  C-- may also allow GHC to manipulate fragments and  
produce native code in ways that may not be possible to express in C,  
including the Bignum implementation.  I don't know whether GHC takes - 
fasm to this extent, that is, further than patching object code from  
a Bignum library, but that I think that is one of the long-term goals.

>> ... One of the big ToDo's seems to be to correct the
>> method of configuring this stuff using machdep.h or the equivalent  
>> on a
>> local system, such as the sysctl-headers on Darwin.  For C-- this  
>> seems
>> like it would be a bit more difficult than simply confirming  
>> whether (or
>> how) the C implementation conforms to the current standard through  
>> the
>> usual header system.
>
> Neither C or C-- was meant to be used to detect what system can do.
> It is simply a byproduct, which autotools takes to the extreme.

I meant that the autotools  determine the correct configuration--the  
big ToDo--and that C or C-- code must be written to conform to the  
configuration that the autotools found.  C would certainly be the  
easiest; C-- would mean reaching deep into the specs.  C would also  
open the possibility for optimisations from compilers and system  
libraries that would not be available to C--.  One more reason to use  
a separate Bignum library...

Best regards,
Peter