FFI

Started by steve64, August 06, 2021, 20:54:22

Previous topic - Next topic

steve64

Any plan to implement some kind of FFI inside SmallBasic ? Yabasic, for instance, has added this feature some time ago
and it expands a lot the language capability. I'm mainly interested in this support for interfacing Windows DLL
without writing C wrappers.

johnno56

Welcome Steve64.

Let's hope that your stay with us will benefit us all.

Please excuse my ignorance, "FFI"?

J
May your journey be free of incident.

Live long and prosper.

Aurel [banned]

Then SB need to support winApi CDCL protocols...as far as i know currently that is not the case.
but probably Chris can give you better answer
(Y)

chrisws

Quote from: Aurel on August 07, 2021, 08:27:39
Then SB need to support winApi CDCL protocols...as far as i know currently that is not the case.
but probably Chris can give you better answer

I wasn't entirely familiar with the term, but I'm guessing it's this: https://en.wikipedia.org/wiki/Foreign_function_interface

This could be implemented as a module (as per raylib etc mentioned previously).

The module could provide the connection to the other language environment.

steve64

#4
Yes, I'm referring to a "Foreign Function Interface", some kind of API to call external functions written in another language
(usually C inside DLLs) WITHOUT writing C code or using a C compiler. Most environments have this capability.
I mentioned Yabasic just since being quite similar to SmallBasic. Its author added FFI on my request
so I was able, for instance, to use his language interpreter for real world industrial applications.

The approach taken for Yabasic is quite interesting and could be a starting point.
I have attached the specs. Detailed documentation can be found at: https://2484.de/yabasic/whatsnew.html
following the link "Manual of yabasic"

Writing modules/plugins is an alternative but not so user friendly.

steve64

Thank Chris for your feedback.
Is there any document (even draft) about the SmallBasic plugin interface?
I taken a look at source code examples, it seems quite similar to the Lua API approach,
but it would be better to have some more precise indication.
Also, I tried to use the Windows GCC toolchain (Mingw32) for writing my plugin
to avoid cross-compilation on Linux, any expected issue with this?

Stefano

steve64

In the meanwhile I have been successful in writing my own SB plugin in C++ for Windows.
It's working with procs and funcs, passing parameters and returning results.

A couple of points:

1) C++ instead of C seems currently mandatory for plugins due to hashmap.cpp and param.cpp, confirmed?

2) the sblib_init() function does not seem to be called by the interpreter, why?

chrisws

Quote from: steve64 on August 11, 2021, 08:51:02
In the meanwhile I have been successful in writing my own SB plugin in C++ for Windows.
It's working with procs and funcs, passing parameters and returning results.

A couple of points:

1) C++ instead of C seems currently mandatory for plugins due to hashmap.cpp and param.cpp, confirmed?

2) the sblib_init() function does not seem to be called by the interpreter, why?

That's great!

C++ is not strictly required, I think you could rename the files locally to .c and it would probably work.

sblib_init(const char *sourceFile) should be invoked. you need to ensure module.h is include (#include "include/module.h") for the correct extern "C" { ...} declarations.

This assumes you are using the latest version of one of the builds.

Now that's you'd got this far, any chance you could write the missing documentation?

Is your module something to share or special purpose?

Cheers,
Chris


steve64

Buy adding module.h I can now see the slib_init() invoked. Thanks!

Even renaming your files from .cpp to .c I still see issues due to C++ headers that are included
by hashmap.cpp and param.cpp as well as
some function overloading (e.g. the error function). I could adapt this stuff but it is better
that you do on your side (if possible) in order to allow also C plugins directly
from the standard codebase.

Maybe I will try to help with documentation, but it is a bit early now.

The plugin I have written is just at the beginning and too much application-specific.



round157

Quote from: steve64 on August 11, 2021, 13:31:15

.................The plugin I have written is just at the beginning and too much application-specific.

Hello....I think that the author(chrisws) of SmallBASIC is a professional author.  In addition, there are several professional SmallBASIC users in the forum. They may be able to solve all problems faced by you in using SmallBASIC.

(Welcome to the forum!)

chrisws

Quote from: steve64 on August 11, 2021, 13:31:15
Buy adding module.h I can now see the slib_init() invoked. Thanks!

Even renaming your files from .cpp to .c I still see issues due to C++ headers that are included
by hashmap.cpp and param.cpp as well as
some function overloading (e.g. the error function). I could adapt this stuff but it is better
that you do on your side (if possible) in order to allow also C plugins directly
from the standard codebase.

Maybe I will try to help with documentation, but it is a bit early now.

The plugin I have written is just at the beginning and too much application-specific.

If it would help I could rework these as .c files. Is there a reason you don't want to compile c++ code?

steve64

I have existing code in plain C that I would like to reuse without extra effort.
And such C code must work also in other enviroments.

Ideally, it would be nice to have both C and C++ ways for SB plugin integration.