[Vm-dev] 64-bit FFI (was: egg sucking alert)

[David T. Lewis]

Hi Eliot,

Yes, I am sure it is/was a working FFI for at least some 64-bit host
platforms.

To be honest I have forgotten many of the details by now, but according to
my testing notes, we had this:

unix x86_64-unknown-linux-gnu any-libffi.c 64 bit 32 bit GREEN
unix x86_64-unknown-linux-gnu any-libffi.c 64 bit 64 bit GREEN
unix x86_64-unknown-linux-gnu x86_64-sysv.c+x86_64_sysv-asm.S 64 bit 32
bit Not implemented(*)
unix x86_64-unknown-linux-gnu x86_64-sysv.c+x86_64_sysv-asm.S 64 bit 64
bit Not implemented(*)

So yes the any-libffi.c version works on 64-bits, and no the the assembler
bindings for sysv-asm.S were not implemented.

There is some other summary info on the Mantis report that might be of
interest.

I certainly would not suggest worrying about the old bindings at this
point, although I do think you might find some useful clues in the type
declarations in the platforms patches (in ffi-patches-5-dtl.zip on the
Mantis report). I am not sure if these are relevant to the work you are
doing now, but they very well might be.

Sorry I have not really looked at this in a while, I just want to make
note of it for those who may not have been aware.

Dave

>  Hi David,
>
> On Thu, Dec 11, 2014 at 8:32 PM, David T. Lewis <lewis at mail.msen.com>
> wrote:
>
>>
>> On Thu, Dec 11, 2014 at 10:28:04AM -0800, Eliot Miranda wrote:
>> >
>> > On Thu, Dec 11, 2014 at 3:12 AM, Bert Freudenberg
>> <bert at freudenbergs.de>
>> wrote:
>> > >
>> > > On 11.12.2014, at 03:01, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>> > >
>> > > There's an oddity of a 32-bit VM compiled in 64-bit mode on a 64-bit
>> > > machine.  I don't know of anyone using it.
>> > >
>> > Right.  But since the rationale for this VM is only to interface with
>> > 64-bit libraries, it depends on a 64-bit FFI, which we do not have.
>>
>> I realize that this refers to the VMs and FFI implementations that are
>> actually available in released VMs, but just for the historical record:
>>
>> A working 64-bit FFI has been available since 2008, but the patches were
>> not
>> adopted. Source patches and issue status are here:
>>
>
> I'm sorry to be so relentlessly negative but are you sure this is a
> working
> FFI?  Having read the change comments I see nothing which will cope with
> the key problem of implementing an FFI for x86_64 ABIs which is that
> struct
> parameters are fragmented across available integer and floating-point
> argument registers as available with the remainder being passed on the
> stack.  So given
>
> typedef struct {
>     long a;
>     double b;
>     long c;
>     double d;
> } foo;
>
> void (long p, foo s)
>
> p is passed in arg reg 0, s.a in arg reg 1, s.b in fp arg reg 0, s.c in
> arg
> reg 2 and s.d in fp arg reg 1.  AFAICT none of this is handled in the 2008
> code.  Am I wrong?
>
>
>>   http://bugs.squeak.org/view.php?id=7237
>>
>> My intention had been to make this a top priority for the VM team circa
>> 2009,
>> but other priorities took precedence.
>>
>> Since then, the original FFI has been rendered obsolete by later
>> development,
>> and as a practical matter there is no 64-bit FFI available today.
>>
>> There were image side changes to the Mantis 7237 patches, and I'm not
>> sure
>> if these will be relevant to Eliot's newer FFI implementation. I'll try
>> to look into this and report back if I find anything of interest.
>>
>
> While I could cobble together an x86_64 FFI in the ThreadedFFIPlugin
> framework that depends on the argument metadata for structs being
> sufficiently detailed and I've yet to check that.  But in any case such an
> interpreted implementation is doomed to have poor performance so I'm
> collaborating in producing a more powerful FFI framework that will use an
> in-image ABI compiler to generate and cache marshalling code just-in-time,
> targeting Ronie Salgado's Lowcode, the same RTL instruction set we're
> using
> to implement the optimized code for Sista.  SO whether the existing FFI
> will properly support x86_64 will depend on whether the metadata is
> present, whether the new UFFI project is quick to deliver results or not,
> and how much time is available for a ThreadedX64FFIPlugin.
>
> In the mean time I'll try and remember to add test cases
> to platforms/Cross/plugins/SqueakFFIPrims/sqFFITestFuncs.c that probe the
> fabulously complex x86-64 ABI.
>
> Dave
>>
>
> --
> best,
> Eliot
>