FFI: c/c++ struct on stack as an argument or return value
marlowsd at gmail.com
Wed Mar 19 12:12:05 UTC 2014
On 18/03/2014 11:42, Yuras Shumovich wrote:
> On Tue, 2014-03-18 at 12:37 +1100, Manuel M T Chakravarty wrote:
>>> Library implementation can't generate native dynamic wrapper, it has to
>>> use slow libffi.
>> When we first implemented the FFI, there was no libffi. Maintaining the adjustor code for all platforms is a PITA; hence, using libffi was a welcome way to improve portability.
> Do you think we can remove native adjustors? I can prepare a patch.
I believe native adjustors are sufficiently faster than libffi to want
to keep them; at least that was what I found the last time I checked.
It might be the case that either libffi is now faster, or we could
optimise our libffi support enough that it isn't worth keeping native
adjustors. I'd love it if that happened.
The benchmark I think I used is in nofib/smp/callback002.
> It requires minor changes to cache ffi_cif structure. On desugar phase
> for each wrapper we can generate fresh global variable to store cif
> pointer and pass it to createAdjustor.
>>> From my point of view, at this point it is more important to agree on
>>> the next question: do we want such functionality in ghc at all? I don't
>>> want to waste time on it if nobody wants to see it merged.
>> I still don’t see the benefit in further complicating an already murky corner of the compiler. Moreover, for this to make sense, it would need to work on all supported platforms. Unless you are volunteering to implement it on multiple platforms, this would mean, we’d use libffi for most platforms anyway. This brings me to my original point, a library or tool is the better place for this.
> OK, I don't buy it, but I see your point.
>> PS: I’d happily accept language-c-inline patches for marshalling structs.
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs