FFI with ABI instead of C declaration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

FFI with ABI instead of C declaration

Maurí­cio CA
Hi, all,

I wonder: why, in Haskell and also in other languages like ML, FFI is
done with C type and code as references? Since, ultimately, compiled
code goes to, say, ELF files or (in Windows) DLLs, shouldn't foreign
interfaces be consistent with those?

I believe this could simplify writing foreign interfaces. Say, we could
write something like this:

        foreign haskell_name1 binary_name1 :: T1 -> T2 -> IO T1
        foreign haskell_name2 binary_name2 :: T1 -> T3 -> IO T4

Our FFI tool would take a set of binary libraries where to look for
binary_name[i], and match haskell_name[i] with those.  T[i] would be
made synonyms of types which would offer all capabilities consistent
with the corresponding types in those libraries ABIs. Inconsistency,
of course, would be an error (like if, in the example above, the first
parameter of both functions would not be the same).

Thanks for your thoughts,
Maurício



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: FFI with ABI instead of C declaration

Tyson Whitehead
On March 11, 2011 09:17:54 Maurício CA wrote:
> I wonder: why, in Haskell and also in other languages like ML, FFI is
> done with C type and code as references? Since, ultimately, compiled
> code goes to, say, ELF files or (in Windows) DLLs, shouldn't foreign
> interfaces be consistent with those?

Having an ELF file, a function name, and knowledge about the parameters for the
function, is still not sufficient information to invoke it.  I still need to
know what calling convention is being used.

That is, how to build the stack (which arguments to put on the stack and how
to put them on), what to do with the registers (which arguments to put in
them, which ones I can expect to be saved, any ones that are expected to be
global pointers), how to receive results back (registers, on the stack,
through a pointer), and, if I am expected to cleanup the stack afterwards.

http://en.wikipedia.org/wiki/X86_calling_conventions

Cheers!  -Tyson

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: FFI with ABI instead of C declaration

Maurí­cio CA
>> I wonder: why, in Haskell and also in other languages like ML, FFI is
>> done with C type and code as references? Since, ultimately, compiled
>> code goes to, say, ELF files or (in Windows) DLLs, shouldn't foreign
>> interfaces be consistent with those?
>
> Having an ELF file, a function name, and knowledge about the parameters
> for the function, is still not sufficient information to invoke it.
> I still need to know what calling convention is being used.

Is it possible to list the "set of sets" of suficient/consistent
specifications one needs to list for each parameter for a function call?

Types like those we have today (CInt, CSize, forall a. Ptr a etc.) are
examples of such sets, but my naive guess is that we could have weaker
ones. For instance, one doesn't need to know wheather a parameter is
a pointer or an integer of the same size, as long as it's not actually
used as a pointer, as opaque types sometimes do not identify themselves
as pointers, and that doesn't prevent us from using them.  Suppose we
have C functions below.

  type_name give_me_opaque (void);

  void use_opaque (type_name);

We could be able to say to Haskell (or other language) "foreign binder"
that we have a type named MyOpaque and that:

  Properties of MyOpaque: may be copied.

  foreign import give_me_opaque :: IO MyOpaque

  foreign import use_opaque :: MyOpaque -> IO ()

MyOpaque would be assigned a type whose only property is to have a value
(that you can copy and nothing else). The FFI tool would only have to
verify (from a binary library header) that 'use_opaque' uses a parameter
the same size of what 'give_me_opaque' returns.

Other properties one could list for a type: be usable as an int32 (or
int16, uint24 etc.), be usable as a pointer etc.  A foreign function
binding would have to list enough properties such that a set of suficient
and consistent specifications could be obtained by crossing those
properties with the information available in binary library headers.

Does that make sense?

Thanks for your toughts,
Maurício




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries