Arc Forum | FFI and Inline on the git

Arc Forum

FFI and Inline on the git

17 points by sacado 6131 days ago | 5 comments

Well, I finally added to the git the FFI stuff I worked on recently. It is mainly based on mzscheme's FFI, with an Arcish feeling. It only deals with C-Arc communication.

I defined a few more symbols (see ffi.scm) that defines mainly the C types : cint, cuint, cbyte, clong, cfloat, cdouble, cvoid, cptr (equivalent of void ), ...

You can tell you want to use a .so file (or .dll under windows) by using the w/ffi* macro. Its parameters are : a string (the filename minus the extension), and cdef declarations.

A cdef declaration defines a new Arc function taken from the FFI. It has the following arguments : the newly defined symbol, a string indicating the C name of the function, a return type (or cvoid) and a list of parameter types.

  (w/ffi "matrix"
    (cdef zeros "zeros" cptr (cint cint))
    (cdef add "add" cptr (cptr cptr))
    (cdef del "delete" cvoid (cptr)))

  (= m (zeros 100 200))
  ...

Finally, I defined a macro called w/inline. It is equivalent to w/ffi, except that its first argument is not the name of a preexisting lib file, but raw C code that gets compiled as a shared library and then can be used as a pre-existing lib. Probably not working under windows, sorry... :(

  (w/inline "int add (int a, int b) { return a + b; }"
    (cdef plus "add" cint (cint cint)))

  (plus 1 2)
  -> 3

It is quite uncomplete as for now, but already useable.

2 points by sacado 6131 days ago | link

There is another optional parameter to cdef : a finalization function. This function is called when the object return by the imported function is GCed. That way, you've got C and garbage collection :

  (cdef zeros "zeros" cptr (cint cint) del)

In the above, del is called on objects returned by zeros once they are collected.

The sad thing is that, if memory is allocated on the C side, Arc can't know it. If you define (zeros 5000 5000), you eat 200 MB. You can run out of memory before the GC thinks "Hey, let's clean up !"

-----

2 points by eds 6129 days ago | link

Is w/inline hardcoded to look for .dll files on Windows? Because when I tried to use MSYS and MinGW the file produced was a .so file rather than a .dll, which caused an error when w/inline looked for a .dll file. Thanks.

-----

1 point by sacado 6129 days ago | link

Well, the library extension is added automatically to the generated file by mzscheme. A .so is added on Unix systems, a .dll on Windows. The solution would be to change the compilation command in ffi.arc : it's something like "gcc -O3 --shared -o foo.so foo.c". Just change it to foo.dll and it might be working. I don't know how to automate this however. If someone has an idea...

-----

2 points by almkglor 6129 days ago | link

http://arclanguage.com/item?id=3522

-----

1 point by sacado 6129 days ago | link

The funny thing is that I wrote FFI for one reason besides optimization : I wanted a POSIX interface, so as not to rely on the system function, which is as broken as any shell script.

Imagine you make a script to remove all files ending with a ~ as they are backup files : foo.tex~, bar.c~ and so on. Now imagine your stupid user named a file ~. Guess what happens if you call "rm -r $file" in your script. It also works with files starting with - and many other funny things.

-----