Le 05/11/2016 à 15:10, Esteban Lorenzano a écrit :
On 5 Nov 2016, at 12:27, Thierry Goubier <thierry.goub...@gmail.com> wrote:
Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :
Hi,
With the latest 64bits VM (201611042126) and image (60282) UFFI is also
looking good. I'm testing a small library of mine [1] to interface with
LMDB [1], a memory mapped key-value database. Almost all tests are
green. This is great progress!
Hi Jan,
did you have to change your UFFI definitions to match the 64bits version of
your lib?
no.
but structures do change (because of sizes, of course).
I’m thinking a way to define a generic representation (keeping offsets
somewhere instead hardcoding it), but for now they have to be redefined for
each platform.
I'd really like, as I told Eliot a long time ago, to have fine control
on this sort of choices.
Mostly because in low-level libs and performance sensitive code, a 32
bits and a 64bits lib may have a very different API (in terms of
structure size, padding and alignment) (and even between versions of,
say, a 64bits lib). A C developper is allowed to handle and generate
differences by using #ifdefs and __attributes__ and typeof/alignof,
including things like that :
typedef struct {
long long __max_align_ll __attribute__((__aligned__(__alignof__(long
long))));
long double __max_align_ld
__attribute__((__aligned__(__alignof__(long double))));
} max_align_t;
Because a Pharo image (and a package) may be executed on a large set of
target platforms / versions, then it seems necessary to me to have the
ability to write ourself the code that adapt a FFI interface to the
target platform (boiler plate code to detect a target change at image
startup, default code for rebuilding the accessors, and the ability to
customize that default code).
Thierry
