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
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
