<br><br><div class="gmail_quote">On Wed, Sep 2, 2009 at 9:08 AM, Michael Haupt <span dir="ltr"><<a href="mailto:mhaupt@gmail.com">mhaupt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hi,<br>
<br>
would it be a problem to package Alien support with the VMs by<br>
default? Are there any reasons for not doing it? Can I help making<br>
this happen?<br>
<br>
I think delivering standard images with Alien right away would be a<br>
strong plus, but of course the VMs need to support that.<br></blockquote><div><br></div><div>Two things need to happen.</div><div>1. Alien's data manipulation facilities need to be separated from Alien's very limited call facilities.</div>
<div>2. FFI's marshalling needs to be extended to marshal Aliens.</div><div><br></div><div>Alien's call support only works on very simple ABIs such as typical IA32 (x86) ones. As soon as one confronts a machine with a register-based calling convention the simple approach falls apart for many cases (structure arguments, floating-point).</div>
<div><br></div><div>Further on I want to build an ABI interface compiler above the JIT that can efficiently marshal arbitrary calls in arbitrary ABIs, essentially reimplementing libffi.</div><div><br></div><div>So Michael, it would help if you would extract the data manipulation parts of the IA32ABI plugin into e.g. Alienlugin and rewrite all the data manipulation methods to use it. Then shoe-horn Alien marshalling into the FFIPlugin.</div>
<div><br></div><div><br></div><div>Why reimplement libffi instead of use it directly?</div><div><br></div><div>First, libffi only does call-outs, not call-backs. Alien's callback architecture is quite nice; one gets a pointer to a register struct (null on x86) and the stack pointer at the point of callback, wrapped up in Aliens and extracts the arguments there-from. But this needs to be wrapped up in some platform-specific abstractions to present the programmer with a portable interface.</div>
<div><br></div><div>Second, libffi does nothing to help translating Smalltalk objects to C equivalents (mapping String instances to to null-terminated char * or wchar_t * arrays, etc, etc).</div><div><br></div><div>Third, libffi's architecture involves building up an AST of a call signature, passing the AST to a compiler which answers some marshalling thunk, and then using the marshallng thunk to make a call. The AST and the marshalling thunk are C objects that one has to associate with e.g. a Smalltalk compiled method and arrange that if the compiled method is GCed the marshalling thunk is reclaimed.</div>
<div><br></div><div>Fourth, the marshalling thunk itself looks to be interpreted, and to apply it one must call the marshaling machinery with the thunk and a pointer to the vector of arguments, to have the call made. This is a little bit too much intervening machinery.</div>
<div><br></div><div>I'd rather have the JIT build the marshalling code directly into the machine code generated for an external call method, translating some RTL sequence that describes the marshalling operations in a platform-specific manner, and write the call spec to RTL compiler in Smalltalk and have it live in the image.</div>
<div><br></div><div>libffi makes a great reference for the ABI semantics, and can also be a source of tests.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Best,<br>
<font color="#888888"><br>
Michael<br></font></blockquote><div><br></div><div>cheers!</div><div>Eliot </div></div><br>