64 bit FFI...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

64 bit FFI...

Göran Krampe
Hi folks!

Just want to check with you guys how we are on the 64 bit VM front.

I have a dynamic library that is 64 bits that I want to call using FFI
(any FFI!). AFAICT this is a big no, no. NB FFI doesn't do 64 bits,
well, in fact NB is only available in Cog and Cog is only available in
32 bits, right?

And even if Cog was available in 64 bits (Eliot?) I guess the NB FFI
would need work to function in 64 bits too?

Ok, so what about the standard VM 64 bit? It doesn't seem to have a
working FFI plugin, so no go.

I do not think I can get the lib in 32 bits (but I have asked upstream)
it is the libhyperclient.so for HyperDex (www.hyperdex.org).

Could someone confirm the above or tell me about any other reasonable route?

regard, Göran

PS. One way would be to write some wrapper around the lib in C and
communicate with it by some other means - like stdin/stdout etc. But...
uuuugly. :)

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit FFI...

David T. Lewis
On Fri, Jan 18, 2013 at 10:32:53AM +0100, G?ran Krampe wrote:

> Hi folks!
>
> Just want to check with you guys how we are on the 64 bit VM front.
>
> I have a dynamic library that is 64 bits that I want to call using FFI
> (any FFI!). AFAICT this is a big no, no. NB FFI doesn't do 64 bits,
> well, in fact NB is only available in Cog and Cog is only available in
> 32 bits, right?
>
> And even if Cog was available in 64 bits (Eliot?) I guess the NB FFI
> would need work to function in 64 bits too?
>
> Ok, so what about the standard VM 64 bit? It doesn't seem to have a
> working FFI plugin, so no go.
>
> I do not think I can get the lib in 32 bits (but I have asked upstream)
> it is the libhyperclient.so for HyperDex (www.hyperdex.org).
>
> Could someone confirm the above or tell me about any other reasonable route?
>
> regard, G?ran
>
> PS. One way would be to write some wrapper around the lib in C and
> communicate with it by some other means - like stdin/stdout etc. But...
> uuuugly. :)

Hi G?ran,

This issue affects VM, a plugin in VMMaker, the image, and the external
FFI package. I had this working in 2008 for the interpreter VM and original
plugin, and I expect that the patches will still work today, although I
have not verified it recently. The patches are on Mantis if you want to
have a look at it: http://bugs.squeak.org/view.php?id=7237

This overall summary is still valid:

http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051595.html

I still think it is really important to get this fixed, but making it
happen will be a challenge. We are facing an increasing proliferation
of code bases, along with a sadly reduced VM team. I'm sure we'll
figure something out, but right now might not be the best time :(

I'm not sure what your application requirements are, but if you are
willing to compile your own VMs for this application, and if you can
use an interpreter VM with FFI plugin, then I can probably help you
get it working. It would be good to revisit those patches and get rid
of the code rot anyway.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: 64 bit FFI...

Göran Krampe
On 01/18/2013 02:51 PM, David T. Lewis wrote:

> On Fri, Jan 18, 2013 at 10:32:53AM +0100, G?ran Krampe wrote:
>> Hi folks!
>>
>> Just want to check with you guys how we are on the 64 bit VM front.
>>
>> I have a dynamic library that is 64 bits that I want to call using FFI
>> (any FFI!). AFAICT this is a big no, no. NB FFI doesn't do 64 bits,
>> well, in fact NB is only available in Cog and Cog is only available in
>> 32 bits, right?
>>
>> And even if Cog was available in 64 bits (Eliot?) I guess the NB FFI
>> would need work to function in 64 bits too?
>>
>> Ok, so what about the standard VM 64 bit? It doesn't seem to have a
>> working FFI plugin, so no go.
>>
>> I do not think I can get the lib in 32 bits (but I have asked upstream)
>> it is the libhyperclient.so for HyperDex (www.hyperdex.org).
>>
>> Could someone confirm the above or tell me about any other reasonable route?
>>
>> regard, G?ran
>>
>> PS. One way would be to write some wrapper around the lib in C and
>> communicate with it by some other means - like stdin/stdout etc. But...
>> uuuugly. :)
>
> Hi G?ran,
>
> This issue affects VM, a plugin in VMMaker, the image, and the external
> FFI package. I had this working in 2008 for the interpreter VM and original
> plugin, and I expect that the patches will still work today, although I
> have not verified it recently. The patches are on Mantis if you want to
> have a look at it: http://bugs.squeak.org/view.php?id=7237
>
> This overall summary is still valid:
>
> http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051595.html
>
> I still think it is really important to get this fixed, but making it
> happen will be a challenge. We are facing an increasing proliferation
> of code bases, along with a sadly reduced VM team. I'm sure we'll
> figure something out, but right now might not be the best time :(
>
> I'm not sure what your application requirements are, but if you are
> willing to compile your own VMs for this application, and if you can
> use an interpreter VM with FFI plugin, then I can probably help you
> get it working. It would be good to revisit those patches and get rid
> of the code rot anyway.

It seems I might actually be able to sidestep and get the library to
compile in 32 bits, so I will try that first. But yes, we need to get
going to 64 bits in general I think, it is starting to hurt. :)

But I think the current "driver" for this to happen is Cog and thus
Eliot - he is the only person that realistically can move Cog to 64 bits
- and Cog is the VM that most people use these days, I guess.

regards, Göran