<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 7:41 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi ALl,<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Feb 15, 2016 at 8:26 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Esteban, Hi All,<div><br></div><div> I thought I'd help by doing the ThreadedFFIPlugin subclass for x64. turns out that the System V x86-64 ABI and the Win64 x86-64 ABI are sufficiently different that I'm splitting it across two classes. But in doing so I've had a moment of clarity (increasingly rare these days ;-) ).</div><div><br></div><div>I've finally realised that Andreas put the type information in the right place, and that there is (I think) sufficient type information for structs to be parsed correctly.</div><div><br></div><div>Andreas puts the type information in the first literal of the method containing the FFI call. (There is also an eval form where the function is passed in). The point here is that the type information is associated with the function, and hence with the function's signature. This is correct.</div><div><br></div><div>In VisualWorks a big mistake was made by putting the type information in the actual parameter, so if one accidentally passes a parameter of the wrong type (types are only checked in debug mode) then it can be marshalled incorrectly.</div><div><br></div><div>This difference is really important with the System V x86-64 AB, because the ABI uses register parameters, 6 integer register args and 8 floating-point register args, and will pass fields of a struct in available registers of either type as available. So if one passes just the following structure:</div><div><br></div><div>struct foo { long a; double b; long c; double d; long e; double f; long g; double h; long i; double j; long k; double l; long m; double n; long o; double p; long q; double r; long s; double t; }</div><div><br></div><div>to a function declared as (long one, double two, struct foo), a,b,c,d & e get passed in integer registers (along with one), and b,d,f,h,j,l & n get passed in xmm registers (along with two), while g,i,k,m,n,o,p,q,r,s & t get passed on the stack (strange but true).</div></div></blockquote><div><br></div></span><div>Well I'm horribly embarrassed. I didn't read the spec carefully enough. It turns out that registers are only used for structs of size 4 eightbytes (e,g. version 0.99.6, <a href="http://www.x86-64.org/documentation/abi.pdf" target="_blank">http://www.x86-64.org/documentation/abi.pdf</a>) or 2 eightbytes (e.g. version 0.90, as used on Mac OS X x86_64, <a href="http://people.freebsd.org/~obrien/amd64-elf-abi.pdf" target="_blank">http://people.freebsd.org/~obrien/amd64-elf-abi.pdf</a>). But looking at linux x86_64 code tehre is no register passing for structures at all. Forgive the misinformation. And it looks like life is much easier. Nice to get rid of this baggage.</div></div></div></div></blockquote><div><br></div><div>And again I've got this wrong. Linux64 uses the same convention as Mac OS X, structures of up to two eightbytes are passed in registers. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>I had thought that this implies we need to generate machine code specific to each signature to efficiently marshall calls. But because the type information is flat, easily parsed and specific to each function rather than (as in VW) to a particular set of actual parameters, the interpreted approach we're currently using should at least be correct. So any marshalling code generation can be left as an optimization exercise, rather than an explicit requirement to achieve correctness.<br></div><div><br></div><div>I hope to have the ThreadedX64SysVFFIPlugin written and tested before the end of the month.</div><div><br></div><div><div><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
</blockquote></span></div><div><br></div><div><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>