More primops for integer arithmetic with overflow reporting

Hello GHC HQ, As the {Int,Word}{,8,16,32,64} types in Haskell are usually regarded to follow modulo arithmetic (w.r.t. to the Num-class ops), I was trying to implement efficient non-modulo Safe{Int,Word}{,8,16,32,64} types which would throw exceptions when the result falls outside the value domain representable. As ISAs often have hardware support to detect such overflows (e.g. on x86-64 via the OF/CF flags), I guess that by exploiting hardware support, this might allow for a reasonably efficient implementation of non-modulo integer arithmetic. So far I've only found 'addIntC#' and 'subIntC#' which perform the kind of operation I'm looking for. But this is only for signed integers, and as far as multiplication is concerned, there's a 'mulIntMayOflo#' but that may provide false negatives according to the documentation. Therefore, I was wondering whether it'd make sense for GHC to provide more primops for the {Int,Word}{,8,16,32,64} types which return the result value together with an overflow-flag. Thanks, hvr

Hi hvr, On Tue, Jan 10, 2012 at 12:05:51PM +0100, Herbert Valerio Riedel wrote:
As the {Int,Word}{,8,16,32,64} types in Haskell are usually regarded to follow modulo arithmetic (w.r.t. to the Num-class ops), I was trying to implement efficient non-modulo Safe{Int,Word}{,8,16,32,64} types which would throw exceptions when the result falls outside the value domain representable.
Are you aware of http://hackage.haskell.org/package/safeint ?
As ISAs often have hardware support to detect such overflows (e.g. on x86-64 via the OF/CF flags), I guess that by exploiting hardware support, this might allow for a reasonably efficient implementation of non-modulo integer arithmetic.
safeint doesn't do this yet, but it's part of the plan.
So far I've only found 'addIntC#' and 'subIntC#' which perform the kind of operation I'm looking for. But this is only for signed integers, and as far as multiplication is concerned, there's a 'mulIntMayOflo#' but that may provide false negatives according to the documentation.
Therefore, I was wondering whether it'd make sense for GHC to provide more primops for the {Int,Word}{,8,16,32,64} types which return the result value together with an overflow-flag.
This is also relevant: http://hackage.haskell.org/trac/ghc/ticket/5598 Thanks Ian
participants (2)
-
Herbert Valerio Riedel
-
Ian Lynagh