FFI: c/c++ struct on stack as an argument or return value

[Yuras Shumovich]

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
> > >>
> > >
> > >
> 
>