I haven't implemented an FFI in RETRO12 thus far. For me, I
don't need it, and generally prefer to expose functionality
via the standard I/O model, with a custom VM and image. But I
have given some thought as to the challenges involved.
Nga (my virtual machine) only addresses 32-bit signed integer
values. This presents some challenges. Anything needing to setup
smaller values will require new words that can unpack and repack
them into the actually addressable cells. This is certainly
doable, but slow.
The memory is also sandboxed. There will need to be VM additions
to translate between the sandboxed and physical addresses. This
is doable: I've implemented similar functionality in the native
RETRO system to allow drivers to access the physical RAM.
A bigger issue will involve memory sizes as related to pointers.
Since Nga is limited to 32-bit addressing, a VM handling FFI
will need to maintain translations between the values passed
into Nga and those used by the functions being called.
Syntax is something I've dabbled at. I'd like to keep the words
needed to a minimum. It'd probably look similar to:
Where the first line opens a shared library, and the second
maps in a foreign function. The import will need to take and
parse stack comments, to pull in the correct values and deal
with types. It'll also take the name of the function from the
shared library and the name to use when creating a RETRO word
to invoke it.
The `ffi` namespace would hold these words, along with others
to deal with memory translations, addressing, and other bits
needed to make all this work.
So when would this be started? Honestly, I don't know. It's
not needed for any of my projects, and I have a full slate of
personal and business projects in the coming months. I'd like
to attempt this someday, but it's very unlikely that I'll be
able to start on it anytime soon.
