+ffi: Enhanced Native Call Propose

[Francisco Lopes]

Hi, this topic has already been discussed in 2008, and became dead.

Time to make it born again.

I was talking with Bram about the limitations of libcall: the load/unload

of a library at every invocation and the arguments limitations.

I talked about a small change on it to avoid the load/unload problem

which is to split the function in three: libload, libcall and libfree. He gave

the idea of checking whether the first parameter of libcall is a string or

not, if not, it's a handle returned by libload, so a call without the overhead

of load/unload is to be made.

1 - That's a small propose to turn things a little better.

Then, he proposed to extend the idea for an implementation where a

VIM list would be passed as function arguments to call a native function, 

but pointed out the tricky part would be to make a call given a list of

unknown size.

I'd already known of approaches as that of libcallex but was a little

worried. So then, after some research, I found how python ctypes

and others do that by using libffi. It's just the libcallex approach, but

packed in a good interface and ported and tested in several

platforms and compilers.

FFI stands for Foreign Function Interface.

Here's an example of using libffi:

#include <stdio.h>
#include <math.h>
#include <ffi.h>

int main()
{
    ffi_cif     call_interface;
    ffi_type    *arg_types[2];
    ffi_type    *ret_type;

    /* pow signature */
    arg_types[0] = &ffi_type_double;
    arg_types[1] = &ffi_type_double;
    ret_type = &ffi_type_double;

    /* prepare pow function call interface */
    if (ffi_prep_cif(&call_interface, FFI_DEFAULT_ABI, 2, ret_type, arg_types) == FFI_OK)
    {
        void *arg_values[2];
        double x, y, z;

        /* arg_values elements point to actual arguments */
        arg_values[0] = &x;
        arg_values[1] = &y;

        x = 2;
        y = 3;
        z = 0;

        /* call pow */
        ffi_call(&call_interface, FFI_FN(pow), &z, arg_values);

        /* 2^3=8 */
        printf("%.0f^%.0f=%.0f\n", x, y, z);

        x = 3;
        y = 2;
        z = 0;

        /* call pow */
        ffi_call(&call_interface, FFI_FN(pow), &z, arg_values);

        /* 3^2=9 */
        printf("%.0f^%.0f=%.0f\n", x, y, z);
    }

    return 0;
}

2 - So, the hard propose is to create a new feature, +ffi, that would compile VIM

linked to libffi and allow for calling native functions "somehow".

How then would be an implementation of calling native functions?

• It could be an extended libcall accepting a VIM list to pass it's elements as arguments.
• It could be an extension to VIM Script allowing it to declare prototypes for native functions.

Conversion between VIM types and libffi types is necessary.

libffi is MIT licensed and is adopted in several projects.

In this embryonary stage (I know nothing about VIM internals),

any suggestions? criticisms?

Regards

---

Francisco Lopes

[Francisco Lopes]

> How then would be an implementation of calling native functions?
>
>

> It could be an extended libcall accepting a VIM list to pass it's elements as arguments.It could be an extension to VIM Script allowing it to declare prototypes for native functions.

>
>
> Conversion between VIM types and libffi types is necessary.
>
>

> In this embryonary stage (I know nothing about VIM internals),
> any suggestions? criticisms?
>
> Regards
> ---
> Francisco Lopes

Changed my mind a bit after some looking around at VIM sources. Now I'm thinking of implementing
this by passing around values between VIM and Native functions only through proper VIM internal types
(see typval_T). This allows for light calls without overhead of type conversion, which is in itself a
complex thing to do generically.

Since internal VIM types are going to be exposed in the C/C++ plugin, it should be able to deal with
then, so a library to deal with VIM internal types in a sane way is necessary.

[Francisco Lopes]

For continued discussion see https://groups.google.com/d/topic/vim_dev/kS8BkiqqwyY/discussion.

This topic is closed.