Hi David,
On Sep 28, 2014, at 12:44 PM, "David T. Lewis" lewis@mail.msen.com wrote:
On Sun, Sep 28, 2014 at 09:04:59AM -0400, David T. Lewis wrote:
On Sun, Sep 28, 2014 at 11:19:30AM +0200, Nicolai Hess wrote:
Who is the maintainer of the FFI-Package for Squeak and/or Pharo ? I especially interested in the FFI-Unix examples and the state on working FFI on linux for current squeak release (AFAIK it does not work with "squeak all in one" 4.5)
The FFI package, including the FFI-Unix examples that you mention, is at http://source.squeak.org/FFI.
The primary author was Andreas Raab. Eliot Miranda is the most recent contributor, and he is probably the most knowledgeable in this area. Currently, the Squeak core developers (those with commit rights to Squeak trunk) have commit rights to the FFI project, and can make updates as needed.
The FFI examples for Unix work with the old FFI plugin, which is still present in the interpreter VM. The active development of Squeak FFI is taking place in Cog, and I'm not sure if the old FFI examples work with the newer plugins (which would be present in the Squeak all-in-one). The FFI plugin in the interpreter VM (i.e. trunk VMMaker) needs to be updated, and presumably the FFI examples may need some updates as well.
A small but important correction: For the old plugin (currently in the interpreter VM), FFI works only for a 32-bit VM. It also works for a 64-bit VM, but only if the patches in http://bugs.squeak.org/view.php?id=7237 have been applied (in other words, if you compiled it yourself and included those patches).
Good point. It should be easier to adapt the ThreadedFFIPlugin to 64 bits because there's no assembler involved.
But this gets to the crux of why we need to rearchitect, because the x86-64/IA64 ABI is extremely complex to use interpretively and much easier to approach with a special-purpose compiler. Some steps are being taken in this direction in the Pharo community.
In fact there's more possibility of getting x86-64/IA64 working with the Squeak FFI than with eg VisualWorks because Andreas' type signature scheme (ExternalType et al) is richer than VW's. but it's work; much of the marshaling code in the plugin would need rewriting.
We're just starting the Spur 64-but VM and do will tackle this soon enough (some time mid next year?). Whether by that time it'll make more sense to extend the existing ThreadedFFIPlugin or go with the new architecture is too early to tell.
HTH
This is mainly of historical interest, although it is possible that some of the 64-bit patches will prove helpful for the newer FFI plugin. But the emphasis now should be on Eliot's more recent FFI work.
+1
Dave
Cheers, Eliot