develooper Front page | perl.perl6.internals | Postings from October 2005

[POC] nci interface using ffcall library

From:
Nick Glencross
Date:
October 28, 2005 13:23
Subject:
[POC] nci interface using ffcall library
Message ID:
436288A0.8020105@glencros.demon.co.uk
Guys,

As mentioned on the list yesterday I started evaluating ffcall as a way 
of providing NCI functionality.

  http://www.haible.de/bruno/packages-ffcall.html

I actually really like the current NCI implementation, although it 
suffers from a large nci.c file and all the usable prototypes need to be 
specified at compile time in call_list.txt. Over time as more libraries 
become supported this list will quickly grow.

My main reason for visiting this is that I couldn't write the simple NCI 
example that I had in mind because callbacks are too restrictive, and 
unlikely to be fixable.

I've now got a working POC for function calls, and although callbacks 
don't work yet, they're not far off. All but 11 of the 59 NCI tests 
pass, and those that don't work exercise callbacks or reading back 
values from types for which I haven't done yet.

For those that want to try it, you'll of course need ffcall installed 
and rerun Configure. Being a Proof of Concept, I've hacked the '-l's for 
the libraries into the Makefile in the wrong place which means some of 
the other tests fail. For now, just try:

   perl -Ilib t/pmc/nci.t

To recap the (mostly obvious) Pros & Cons.

Pros:

  * Makes any prototype possible, not just those in call_list.txt

  * Probably won't initially make code much smaller, but would over time
   (stripped nci_ffcall.o & library is currently < 1/6 size of nci.o)

  * Callbacks can have any prototype as well, not just a data/user data pair

  * Callbacks no longer require user data to be managed by the 3rd party 
library (this is a biggy)

  * Callbacks will be able to support a return type

Cons:

  * Reliance on a library, although NCI may be an optional feature

  * Performance? There are a few additional loops and switches, but I 
can't see this being a real issue

  * NCI would only be available on platforms which support the library 
we use; from what I've seen dynamic function calls is not easy to do 
cross-platform

  * Possibly incompatible 3rd party licensing

To address some of the points in the Cons section, it would be possible 
to maintain multiple NCI backends, although more work.

As far as PIR/PASM code, the interface is unchanged, although I would 
like to suggest that at some point the newclass signature include the 
return type in common with other opcodes, as hopefully we can support this.

Cheers,

Nick

p.s. As you can see, I've been won over by ffcall, but I've only been 
using it for a day so there may well be show stoppers to using it.




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About