[Haskell-cafe] Re: Could FFI support pass-by-value of structs?

[Duncan Coutts]

On Tue, 2009-06-30 at 18:59 -0700, John Meacham wrote:
> On Tue, Jun 30, 2009 at 01:18:32AM +0100, Duncan Coutts wrote:
> > On IA32 structs/unions passed as parameters go by value on the stack.
> > For structs/unions as function results, they are stored into a
> > caller-allocated area on the stack, pointed to by a "hidden" first arg.
> > 
> > It's different on each arch, but it's all completely specified.
> > 
> > > moreover, even for pointers-to-structures, there is no definitive
> > > layout due to packing problem
> > 
> > Actually the padding is also specified by the C ABI. See section 3-3.
> > Compiler pragmas to use packed layout are not ABI conformant (and so
> > typically are only used internally).
> 
> Yup. Unfortunately this doesn't help us, since in order to pass
> structures we need to know more than just the layout (offset and size)
> of the type, but we need to know the underlying C types as well which a
> Storable instance doesn't give us. depending on the ABI, struct passing
> may not be as simple as 'pass on stack' vs 'pass in registers'. it may
> be something like 'the floating point components get pulled out and put
> in registers, which the other components get pushed onto the stack'. So,
> without some compiler magic, like a 'deriving Storable' instance that
> derived some hidden methods to contain this extra information, or
> additions to storable, this won't work in general.

Yeah, I'm not suggesting going via Storable (for all those reasons),
just extending the FFI to say tuples of FFI types get passed as the
corresponding C ABI structs. All the magic to match the current platform
C ABI then lives in the compiler.

I was only half-serious in suggesting this btw, though as far as I can
see it should actually work. It doesn't help with unions of course and
it adds complexity to the compiler.

Duncan