Simon, I finally managed to implement that for major NCG backends. Phabricator revision is here: https://phabricator.haskell.org/D252
Here is a link to the review you did before: https://github.com/Yuras/ghc/commit/7295a4c600bc69129b6800be5b52c3842c9c4e5b I don't have implementation for mac os x86, ppc and sparc. Are they actively used today? I don't have access to hardware to test them. Do you think it has it's own value without exposing to haskell FFI? What is the minimal feature set I should implement to make it merged? Thanks, Yuras On Sat, 2014-06-14 at 18:57 +0300, Yuras Shumovich wrote: > Hello, > > I implemented support for returning C structures by value in cmm for > x86_64 (most likely it works only on linux). You can find it here: > https://github.com/Yuras/ghc/commits/cmm-cstruct > > It supports I8, I16, I32, I64, F_, D_ cmm types, and requires special > annotation. For example: > > #include "Cmm.h" > > #define MyStruct struct(CInt, I8, struct(I8, CInt)) > > cmm_test(W_ i) > { > CInt i1; > I8 i2, i3; > float32 i4; > (i1, i2, i3, i4) = ccall c_test(W_TO_INT(i)) MyStruct; > return (TO_W_(i1), TO_W_(i2), TO_W_(i3), i4); > } > > (See "test" directory for full examples.) > > > Do you think it is right approach? > Could anyone review the code please? > > And the last thing, I need mentor for this project. Is anyone interested? > > Thanks, > Yuras > > On Tue, 2014-03-18 at 21:30 +0000, Simon Marlow wrote: > > So the hard parts are: > > > > - the native code generators > > - native adjustor support (rts/Adjustor.c) > > > > Everything else is relatively striaghtforward: we use libffi for > > adjustors on some platforms and for GHCi, and the LLVM backend should be > > quite easy too. > > > > I would at least take a look at the hard bits and see whether you think > > it's going to be possible to extend these to handle struct args/returns. > > Because if not, then the idea is a dead end. Or maybe we will need to > > limit the scope to make things easier (e.g. only integer and pointer > > fields). > > > > Cheers, > > Simon > > > > On 18/03/2014 17:31, Yuras Shumovich wrote: > > > Hi, > > > > > > I thought I have lost the battle :) > > > Thank you for the support, Simon! > > > > > > I'm interested in full featured solution: arguments, return value, > > > foreign import, foreign export, etc. But it is too much for me to do it > > > all at once. So I started with dynamic wrapper. > > > > > > The plan is to support structs as arguments and return value for dynamic > > > wrapper using libffi; > > > then implement native adjustors at least for x86_64 linux; > > > then make final design decision (tuple or data? language pragma? union > > > support? etc); > > > and only then start working on foreign import. > > > > > > But I'm open for suggestions. Just let me know if you think it is better > > > to start with return value support for foreign import. > > > > > > Thanks, > > > Yuras > > > > > > On Tue, 2014-03-18 at 12:19 +0000, Simon Marlow wrote: > > >> I'm really keen to have support for returning structs in particular. > > >> Passing structs less so, because working around the lack of struct > > >> passing isn't nearly as onerous as working around the lack of struct > > >> returns. Returning multiple values from a C function is a real pain > > >> without struct returns: you have to either allocate some memory in > > >> Haskell or in C, and both methods are needlessly complex and slow. > > >> (though allocating in Haskell is usually better.) C++ code does this all > > >> the time, so if you're wrapping C++ code for calling from Haskell, the > > >> lack of multiple returns bites a lot. > > >> > > >> In fact implementing this is on my todo list, I'm really glad to see > > >> someone else is planning to do it :-) > > >> > > >> The vague plan I had in my head was to allow the return value of a > > >> foreign import to be a tuple containing marshallable types, which would > > >> map to the appropriate return convention for a struct on the current > > >> platform. Perhaps allowing it to be an arbitrary single-constructor > > >> type is better, because it allows us to use a type that has a Storable > > >> instance. > > >> > > >> Cheers, > > >> Simon > > >> > > > > > > > > _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
