Support in the OCaml bytecode interpreter for libffi?

[bobot]

Would it be interesting to have the OCaml bytecode interpreter use libffi so that it is not necessary to create stubs specific to the bytecode? One could remove the need of a stub if they uses in addition the [@unboxed] annotation in an OCaml external declaration. As experts of libffi and ocaml stubs, would that be interesting? Would that simplify ocaml-ctypes? Do you foresee problems?

[yallop]

Would it be interesting to have the OCaml bytecode interpreter use libffi so that it is not necessary to create stubs specific to the bytecode?

Avoiding the need to have separate native and bytecode stubs? That'd be useful, but I'm not sure it's sufficient to justify adding a dependency to libffi in OCaml. The bytecode-specific stubs are fairly simple and libffi is quite a significant dependency.

One could remove the need of a stub if they uses in addition the [@unboxed] annotation in an OCaml external declaration.

However, this is more interesting; avoiding the need to write stubs altogether for functions that use only unboxed values would be worthwhile. I think @mshinwell has looked at stubless C calls with unboxed values for native code. Using libffi to complete the picture for stubless calls from bytecode is a good idea.

[bobot]

I looked at what it is the path to add such feature in the interpreter, and it boils down to one feature: to be able to get the function pointer of the C function. In fact if just this feature is added it is easy to write a ppx and a library that does the remaining part (have a generic primitive that takes a function pointer, a prototype with unboxing information and an array of arguments).

To the expression language external "name_of_the_symbol" could give a Nativeint.t which would be the address of the function symbol. "name_of_the_symbol" would be registered as a usual primitive in the bytecode and the interpreter would recover its address at startup as usual.

[yallop]

I like the idea of adding `external "name_of_the_symbol" to the expression language. It would be worth considering supporting the case where the symbol name is not static, too.