Re: closure api return value types problem

[Andrew Haley <aph at redhat dot com>]

On 03/04/10 10:03, Sergei Trofimovich wrote:
>>>> If you came up with a small self-contained test case it'd help a lot.
>>>
>>> What kind of test you would like to see?
>>> The tests are in libffi tree and they all work correctly (even on ppc64):
>>> testsuite/libffi.call/cls_ushort.c
>>> testsuite/libffi.call/cls_float.c
>>> testsuite/libffi.call/cls_ulonglong.c
>>
>> Right, so there is no problem, then.  I thought you said there was a
>> problem with ghc that you wanted to solve.
> I'll answer to this slightly later [1].
> 
>>> But! The thing I don't understand is why libffi treats ushort, uint
>>> retval types (and _only_ retval types!) so specifically?
>>
>> I think this is just because of the common (universal?) C ABI
>> convention that integer typed return values of rank less than int are
>> returned as a whole word, suitably sign- or zero-extended.  It need
>> not have been done that way.
> 
> The thing is:
> * it's _very_ unintuitive (and not only for me) as that closure callback
>    (with args and resp parameters) is meant to be convention agnostic
>> integer typed return values of rank less than int are
>> returned as a whole word

Yes.  I take your point.

> * I think you meant 'less than word' here (ppc64 has 64bit word and 32bit int),
>    otherwise libffi has even stranger architecture specific assumptions and we
>    need more fixes.

Yes, I did mean "less than word".

> [1] Initial ghc assumption was to store result the same way as
> arguments are passed. Without any promotions. I had to add those
> promotions for intergal types less, than a word.
> 
> I was impressed by the fact: client has to know about magic ffi_arg
> argument type. He has to include ffi.h header, has to detect what kind
> of type he wants to return and build it properly.
> 
> I started this discussion to clarify whether this ABI is absolutely inevitable
> or it just was done in such an ug^W peculiar way at random.
> 
> So yes, ghc does not have known libffi problems right now.
> I wonder what ABI assumptions will be for non cconv closures. Will we have
> to add even more workarounds just to call libffi properly?

Sorry, I've no dea what this refers to.

Andrew.