Re: End of Windows Vista support in GHC-8.6?

2018-03-05 18:29 GMT+01:00 Phyx : > > > No objections, however do make sure to test both 32 and 64 bit builds of > ghc when you use the API, it's new enough and rare enough that it may not > be implemented in both mingw-64 tool chains (we've had similar issues > before). >

Re: ghc, OpenBSD and stack pointer checking

ho, On Mon, Jan 22, 2018 at 09:52:01PM +0100, Matthias Kilian wrote: > On Thu, Jan 18, 2018 at 01:21:27PM -0500, Ben Gamari wrote: > > > So, if the stack pointer checking diff to OpenBSD is correct, and > > > if I'm not running into a completely unrelated problem: does ghc > > > and/or the

Re: FFI-free NaN checks? (isDoubleNan and friends)

On 03/05/2018 10:23 PM, Brandon Allbery wrote: > If the FFI version is done with "safe", consider using "unsafe" instead. > There are technical reasons why this is slightly incorrect, but unless > you're fiddling with the CPU's FP control flags they're mostly irrelevant > and you can treat isNaN

Re: FFI-free NaN checks? (isDoubleNan and friends)

On 03/06/2018 10:43 AM, Brandon Allbery wrote: > I'd in general expect good C code to optimize a little better; and in > particular, decomposing an IEEE float is almost certainly more expensive in > Haskell than in C, because unions let you cheat. (And I recall looking at > the implementation of

Re: FFI-free NaN checks? (isDoubleNan and friends)

Hi, You can try with foreign primops, it should be faster than the FFI: In IsDoubleNanPrim.s: .global isDoubleNan_prim isDoubleNan_prim:    xor %rbx,%rbx    ucomisd %xmm1, %xmm1    lahf    testb $68, %ah    jnp .Lout    mov $1, %rbx .Lout:    jmp * (%rbp) In IsDoubleNan.hs: {-# LANGUAGE

Re: FFI-free NaN checks? (isDoubleNan and friends)

I'd in general expect good C code to optimize a little better; and in particular, decomposing an IEEE float is almost certainly more expensive in Haskell than in C, because unions let you cheat. (And I recall looking at the implementation of decodeFloat once; it's significantly longer than that