... | ... | @@ -24,6 +24,11 @@ Other basic recommended reading is: |
|
|
- The GHC Commentary: [ The Native Code Generator](http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/the-beast/ncg.html); and,
|
|
|
- The GHC Commentary: [ Style Guidelines for RTS C code](http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/coding-style.html).
|
|
|
|
|
|
#### *Caveat*
|
|
|
|
|
|
>
|
|
|
> Beware! The main interest here is replacing GMP--GHC is still belongs to the University of Glasgow and those in charge still retain the purview to accept or reject a proposed solution.
|
|
|
|
|
|
### Reasons for Replacing GMP as the Bignum library
|
|
|
|
|
|
|
... | ... | @@ -40,7 +45,7 @@ There are several problems with the current GMP implementation: |
|
|
1. Memory Structure; Simultaneous Access to GMP by Foreign (C) code in the Same Binary
|
|
|
|
|
|
>
|
|
|
> In the current GMP implementation, GMP is configured to use GHC's GC memory and GMP can only have one allocator for memory. Since any single binary containing Haskell code compiled with GHC contains the RTS and GMP, C code in the same binary cannot use GMP. This problem was noted in [ bug Ticket \#311](http://hackage.haskell.org/trac/ghc/ticket/311). Simon Peyton-Jones suggested that a simple renaming of GHC-GMP functions would solve this problem and Bulat Ziganshin suggested simply using an automated tool to do this. See [ Replacement for GMP](http://www.haskell.org/pipermail/glasgow-haskell-users/2006-August/010679.html). Using different function names would make GMP into a separate, custom GHC library leaving the C part of the program free to use GMP.
|
|
|
> In the current GMP implementation, GMP is configured to use GHC's GC memory and GMP can only have one allocator for memory. Since any single binary containing Haskell code compiled with GHC contains the RTS and GMP, C code in the same binary cannot use GMP. This problem was noted in [ bug Ticket \#311](http://hackage.haskell.org/trac/ghc/ticket/311). The Simon Peyton-Jones suggested that a simple renaming of GHC-GMP functions would solve this problem and Bulat Ziganshin suggested simply using an automated tool to do this. See [ Replacement for GMP](http://www.haskell.org/pipermail/glasgow-haskell-users/2006-August/010679.html). Different function names would make GMP into a separate, custom GHC library leaving the C part of the program free to use GMP.
|
|
|
|
|
|
>
|
|
|
> GHC does not have a custom-modified version of GMP (in fact, GHC uses the system build of GMP if that is available). The memory configuration of GMP uses GMP's [ Custom Allocation](http://swox.com/gmp/manual/Custom-Allocation.html#Custom-Allocation) routines. Alternative libraries may not have this facility built in.
|
... | ... | @@ -73,9 +78,6 @@ There are several problems with the current GMP implementation: |
|
|
- interoperability between Haskell and other languages, especially C, would be more difficult so you would have to define a new primitive, say \#Int30 for the representation; and,
|
|
|
- representing a Haskell constructor (the Int\#) inside a pointer--a bit-size constructor--would limit the number of constructors you would be able to have (depending on the size of a pointer object, say the C99 uintptr_t, on a particular machine).
|
|
|
|
|
|
>
|
|
|
> Beware! The main interest here is replacing GMP--GHC is still belongs to the University of Glasgow and those in charge still retain the purview to accept or reject a proposed solution.
|
|
|
|
|
|
### Overview of the Current GMP Implementation
|
|
|
|
|
|
|
... | ... | |