C ABI support

[guysv]

Oak's FFI supports calling C functions, only if the target function follows the oak FFI protocol (e.g. receive a vm object, and interact with it)

~~As Oak is advertised to be more portable than C~~ (not relevant, but still), being able to call any C function is a useful feature.

I guess a better description for the feature would be: "Be compatible with C's calling conventions on a variety of C-capable architectures"

Any thoughts on that?

[kevinramharak]

I made a similar suggestion in a different issue. Any ideas on how to implement this? And what the rules of such an interaction should be?

[guysv]

Well, for the C backend, implementation is simple. All we need to do is to define some syntax that maps between oak's types and C types, and generate C function calls. That way don't even care about the interworking of certain C calling conventions, we rely on the C compiler for the implementation.

I guess this feature should not be part of the standard, as it ranges from being tricky to implement (go) to impossible without major dependencies (typescript).

[kevinramharak]

I'm not sure I understand. Would this require additional syntax in the Oak language? I think It should be somewhat abstract so that each backend can implement it. For example:

• Pop arguments off the tape into memory allocated at runtime
• transfer execution to native function while passing the arguments
• Push return value back on the tape

These are abstract definitions thus they can be implemented by any backend.

[guysv]

Yes! I was thinking about generalizing the new behavior too! So, to summerize:

1. define a new syntax to call "native" functions
2. every backend gets to define what "native" means
   • e.g. for typescript: call a typescript function.

I guess you'll also want to pass some metadata to the compiler (cdecl/stdcall pops into mind)