Guess nobody got my Prolog VM suggestion. Here it is again in its full glory:
It would also be possible to add a rich FFI to SWI-Prolog. Currently SWI-Prolog emits the following Prolog VM code for a poor foreign function stub, where
<func> is the function pointer. The code is emitted depending on arity, no type information is used:
I_FCALLDET0 <func> /* arity 0 */ I_FCALLDET1 <func> /* arity 1 */ I_FCALLDET2 <func> /* arity 2 */ Etc..
Lets assume we have now a foreign function
alarm(integer) . What can be generated as rich foreign function stub. In as far the Albufeira Prolog interpreter is not unsuitable, having adopted the approach from the paper is not really an obstacle. New instructions
???1??? some guard to check whether the first argument is integer ???2??? some conversion to convert the Prolog tagged pointer into foreign integer I_FCALLDET1 alarm
The problem is probably garbage collection etc… since suddently foreign data type arguments are on the stack window. I don’t know how to solve this problem in the case of SWI-Prolog, because I don’t know enough about SWI-Prolog.
So yes, its non trivial somehow. Not sure. Also I_FCALLDETX has hard coded that the arguments are terms with call-by-reference, passing consecutive addresses. A rich FFI has usually also call-by-value, and not only call-by-reference.