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

[Eliot Miranda]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141212/6e46ed8e/attachment-0001.htm