Re: [commit: packages/integer-gmp] master: Clean-up Cmm of import/export primitives (dfd65a2)

I suppose the integer-simple library also needs the <new-primops> treatment.
Many embedded platforms won't have GMP.
Should we just provide 'error "unimplemented"' stubs?
Cheers,
Gabor
On 11/5/13, git@git.haskell.org
Repository : ssh://git@git.haskell.org/integer-gmp
On branch : master Link : http://git.haskell.org/packages/integer-gmp.git/commitdiff/dfd65a28de3fe6093...
---------------------------------------------------------------
commit dfd65a28de3fe6093d7e39fab6de960408abeb7e Author: Herbert Valerio Riedel
Date: Tue Nov 5 21:26:17 2013 +0100 Clean-up Cmm of import/export primitives
This is a follow-up to e94799c9 fixing the Cmm implementation of the primops based on suggestions by Duncan Coutts.
Signed-off-by: Herbert Valerio Riedel
---------------------------------------------------------------
dfd65a28de3fe6093d7e39fab6de960408abeb7e cbits/gmp-wrappers.cmm | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/cbits/gmp-wrappers.cmm b/cbits/gmp-wrappers.cmm index 186cfad..0da3db8 100644 --- a/cbits/gmp-wrappers.cmm +++ b/cbits/gmp-wrappers.cmm @@ -71,47 +71,48 @@ import "integer-gmp" integer_cbits_decodeDouble;
integer_cmm_importIntegerzh (P_ ba, W_ of, W_ sz, W_ e) { - P_ p; - W_ mp_result1; + W_ src_ptr; + W_ mp_result;
again: STK_CHK_GEN_N (SIZEOF_MP_INT); MAYBE_GC(again);
- p = ba + SIZEOF_StgArrWords + of; + mp_result = Sp - SIZEOF_MP_INT;
- mp_result1 = Sp - SIZEOF_MP_INT; + src_ptr = BYTE_ARR_CTS(ba) + of;
- ccall __gmpz_init(mp_result1 "ptr"); - ccall __gmpz_import(mp_result1 "ptr", sz, W_TO_INT(e), W_TO_INT(1), W_TO_INT(0), 0, p "ptr"); + ccall __gmpz_init(mp_result "ptr"); + ccall __gmpz_import(mp_result "ptr", sz, W_TO_INT(e), W_TO_INT(1), W_TO_INT(0), 0, src_ptr "ptr");
- return(TO_W_(MP_INT__mp_size(mp_result1)), - MP_INT__mp_d(mp_result1) - SIZEOF_StgArrWords); + return(TO_W_(MP_INT__mp_size(mp_result)), + MP_INT__mp_d(mp_result) - SIZEOF_StgArrWords); }
+/* :: Int# -> ByteArray# -> MutableByteArray# s -> Word# -> Int# -> State# s -> (# State# s, Word# #) */ integer_cmm_exportIntegerzh (W_ s1, P_ d1, P_ mba, W_ of, W_ e) { - P_ dst; + W_ dst_ptr; W_ mp_tmp; - W_ cnt_result1; + W_ cnt_result;
again: STK_CHK_GEN_N (SIZEOF_MP_INT + SIZEOF_W); MAYBE_GC(again);
- mp_tmp = Sp - SIZEOF_MP_INT; + mp_tmp = Sp - SIZEOF_MP_INT; MP_INT__mp_alloc(mp_tmp) = W_TO_INT(BYTE_ARR_WDS(d1)); MP_INT__mp_size(mp_tmp) = (s1); MP_INT__mp_d(mp_tmp) = BYTE_ARR_CTS(d1);
- cnt_result1 = Sp - (SIZEOF_MP_INT + SIZEOF_W); - W_[cnt_result1] = 0; + cnt_result = Sp - (SIZEOF_MP_INT + SIZEOF_W); + W_[cnt_result] = 0;
- dst = mba + SIZEOF_StgArrWords + of; + dst_ptr = BYTE_ARR_CTS(mba) + of;
- ccall __gmpz_export(dst "ptr", cnt_result1 "ptr", W_TO_INT(e), W_TO_INT(1), W_TO_INT(0), 0, mp_tmp "ptr"); + ccall __gmpz_export(dst_ptr "ptr", cnt_result "ptr", W_TO_INT(e), W_TO_INT(1), W_TO_INT(0), 0, mp_tmp "ptr");
- return (W_[cnt_result1]); + return (W_[cnt_result]); }
integer_cmm_int2Integerzh (W_ val)
_______________________________________________ ghc-commits mailing list ghc-commits@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits

On 2013-11-05 at 22:08:11 +0100, Gabor Greif wrote:
I suppose the integer-simple library also needs the <new-primops> treatment. Many embedded platforms won't have GMP. Should we just provide 'error "unimplemented"' stubs?
Well, I extended the precedent set by http://www.haskell.org/ghc/docs/latest/html/libraries/integer-gmp-0.5.0.0/GH... where the underlying `gcdInteger#` and `lcmInteger#` primitives are provided only by `integer-gmp`, and their wrappers are located in a module whose name clearly denotes these as being specific to GMP. This should be regarded as an optimization to tap into GMP's highly optimized primitives, which afaik can't be easily added outside of integer-gmp. However, in the long-term, I don't think packages should build-depend directly on integer-{gmp,simple} (I was surprised to see that `text` does this), but instead an `integer` "super-package" could abstract over the decision whether `integer-gmp` or `integer-simple` is used as Integer "backend" library, and pass-thru a common set of functions, while enforcing that no function is missing and/or has a diverging type. Cheers, hvr

On 11/5/13, Herbert Valerio Riedel
On 2013-11-05 at 22:08:11 +0100, Gabor Greif wrote:
I suppose the integer-simple library also needs the <new-primops> treatment. Many embedded platforms won't have GMP. Should we just provide 'error "unimplemented"' stubs?
Well, I extended the precedent set by
http://www.haskell.org/ghc/docs/latest/html/libraries/integer-gmp-0.5.0.0/GH...
Oh, I see. I'll shut up now :-) Gabor
where the underlying `gcdInteger#` and `lcmInteger#` primitives are provided only by `integer-gmp`, and their wrappers are located in a module whose name clearly denotes these as being specific to GMP.
This should be regarded as an optimization to tap into GMP's highly optimized primitives, which afaik can't be easily added outside of integer-gmp.
However, in the long-term, I don't think packages should build-depend directly on integer-{gmp,simple} (I was surprised to see that `text` does this), but instead an `integer` "super-package" could abstract over the decision whether `integer-gmp` or `integer-simple` is used as Integer "backend" library, and pass-thru a common set of functions, while enforcing that no function is missing and/or has a diverging type.
Cheers, hvr
participants (2)
-
Gabor Greif
-
Herbert Valerio Riedel