[Vm-dev] Alien support in standard VM?
Eliot Miranda
eliot.miranda at gmail.com
Thu Sep 3 16:38:53 UTC 2009
On Thu, Sep 3, 2009 at 12:17 AM, John M McIntosh <
johnmci at smalltalkconsulting.com> wrote:
>
> I believe I had all the VMMaker changes in the alien vmmaker MC changesets.
> For the macintosh I have those in my current build image and currently I am
> merging in the production Vmmaker source. Obviously it would be good if
> the alien vmmaker stuff was folded into the production vmmaker.
>
> Also there was some confusion about the earlier changes for vm callback
> submitted by qwaq a few years back.
> I have for example in my PRIVATE sqVirtualMachine.h (did I mention PRIVATE)
> this code to expose the
> callbackEnter: callbackID: addGCRoot removeGCRoot
>
> If these are to be replaced by Alien then someone should clarify that since
> Mar on Squeak is exploiting the callbackEnter:
> to do Cocoa controller callbacks on os-x via the Objective-C plugin
> SqueakProxy logic
>
SAo keep the callback machinery. But I think we should not include
the internalIsImmutable & internalIsMutable calls, which are so far specific
to Newspeak, (and that I misnamed; they should be isImmutable & isMutable).
>
> #if VM_PROXY_MINOR > 7
> sqInt (*internalIsImmutable)(sqInt oop);
> sqInt (*internalIsMutable)(sqInt oop);
> sqInt (*primitiveFailFor)(sqInt code);
> sqInt (*classAlien)(void);
> sqInt *(*getStackPointer)(void);
> sqInt (*sendInvokeCallbackStackRegistersJmpbuf)(sqInt
> thunkPtrAsInt, sqInt stackPtrAsInt, sqInt regsPtrAsInt, sqInt
> jmpBufPtrAsInt);
> sqInt (*reestablishContextPriorToCallback)(sqInt callbackContext);
> sqInt (*classUnsafeAlien)(void);
> /* New methods for proxy version 1.8 */
>
> /* callbackEnter: Re-enter the interpreter loop for a callback.
> Arguments:
> callbackID: Pointer to a location receiving the callback ID
> used in callbackLeave
> Returns: True if successful, false otherwise */
> sqInt (*callbackEnter)(sqInt *callbackID);
>
> /* callbackLeave: Leave the interpreter from a previous callback
> Arguments:
> callbackID: The ID of the callback received from callbackEnter()
> Returns: True if succcessful, false otherwise. */
> sqInt (*callbackLeave)(sqInt callbackID);
>
> /* addGCRoot: Add a variable location to the garbage collector.
> The contents of the variable location will be updated accordingly.
> Arguments:
> varLoc: Pointer to the variable location
> Returns: True if successful, false otherwise. */
> sqInt (*addGCRoot)(sqInt *varLoc);
>
> /* removeGCRoot: Remove a variable location from the garbage
> collector.
> Arguments:
> varLoc: Pointer to the variable location
> Returns: True if successful, false otherwise.
> */
> sqInt (*removeGCRoot)(sqInt *varLoc);
> #endif
>
>
>
> On 2-Sep-09, at 7:00 PM, Eliot Miranda wrote:
>
>
>>
>> On Wed, Sep 2, 2009 at 9:54 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
>>
>> Actually, I think Michael's question was more on an immediate basis. As it
>> stands there is a significant number of patches that one needs to scrape
>> from the four corners of the universe before one can even begin to build the
>> Alien FFI plugin. It would be helpful if this could be folded into VMMaker
>> so that the plugin can be built out of the box.
>>
>> Right. But before it can go into the VM we need to throw away the
>> x86-specificities. And that means splitting the data manipulation
>> facilities from the ABI machinery. I can do that, but Michael volunteered
>> :)
>>
>> I think the pragma issue has already been solved right? There was a
>> commit for the compiler yesterday that did that.
>>
>>
>> Cheers,
>> - Andreas
>>
>> Eliot Miranda wrote:
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>>
>> On Wed, Sep 2, 2009 at 9:08 AM, Michael Haupt <mhaupt at gmail.com <mailto:
>> mhaupt at gmail.com>> wrote:
>>
>>
>> Hi,
>>
>> would it be a problem to package Alien support with the VMs by
>> default? Are there any reasons for not doing it? Can I help making
>> this happen?
>>
>> I think delivering standard images with Alien right away would be a
>> strong plus, but of course the VMs need to support that.
>>
>>
>> Two things need to happen.
>> 1. Alien's data manipulation facilities need to be separated from Alien's
>> very limited call facilities.
>> 2. FFI's marshalling needs to be extended to marshal Aliens.
>>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>>
>> Why reimplement libffi instead of use it directly?
>>
>> 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.
>>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> libffi makes a great reference for the ABI semantics, and can also be a
>> source of tests.
>>
>>
>> Best,
>>
>> Michael
>>
>>
>> cheers!
>> Eliot
>>
>>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com> Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090903/9a0a8117/attachment.htm
More information about the Vm-dev
mailing list