On Tue, Jul 1, 2008 at 1:34 PM, tim Rowledge <tim at rowledge.org> wrote:

>
> On 1-Jul-08, at 1:20 PM, Eliot Miranda wrote:
>
>>
>> One doesn't have to *use* the FFI.   If the FFI isn't exposed via a
>> primitive then no FFI.  One can still have named primitives supported by the
>> image and not by the VM and not use the FFI.  To call a named primitive in a
>> primitive plugin the following sequence occurs:
>>
>> the method containing a named primitive spec is activated and the
>> primitive call fails because its function pointer is null.
>> the failure code extracts the plugin name and invokes a primitive to load
>> the plugin library
>> the failure code extracts the primitive name and uses the lookup primitive
>> to find the function in the loaded plugin library
>> the failure code uses a primitive to slam the function pointer into the
>> method
>> the failure code uses the executeMethodWithArgs primitive to retry the
>> bound named primitive method
>>
>> So the FFI is an optional extra.  One needs four primitives, load library,
>> lookup name in library, insert primitive function pointer. and
>> executemethodWithArgs (thanks Tim!).  Slamming the function into the method
>> could also be done using, say, objectAt:.
>>
>> So one can still have a nice small safe VM and have no direct support for
>> named primitives in the VM.
>>
>>
>
> Leaving aside my like of all-named-prims, I *like* this enhancement to the
> support for named prims.
>
> It would slightly complicate the post-prim-call code in each method because
> you would need to handle the failed-to-find-prim case as well as all the
> prim-failed cases. It would be helped by an old idea that I'm pretty sure
> eliot has plans for anyway (as indeed I have written about a few times) to
> add primitive error return values. For those that haven't heard of them,
> this is just a way of having the first temp in a context involved in a prim
> call be a slot for a return value from the prim if any error occurs. This
> means you can actually know wtf went wrong instead of guessing - "ooh, was
> the first arg a SmallInteger? Um, if not, was it a Float that might round
> nicley? Err, was the second arg a ByteArray with the first byte = 255?" etc.
> Instead you get "ah, errorValue was 1, so we have to explode the reactor
> core in order to stop the Dreen from eating the children". Much nicer.


I did primitive error codes at Cadence and they'll very probably b making it
into Cog real soon now.  They're simpler than VisualWorks', being only
symbols.  So extracting more information, such as a related error code
requires a subsequent call.  But I think the work I'm doing right now on
eliminating pushRemappableOop:/popRemappableOop will enable me to have a
structured object with a name and parameters, which is more generally
useful.

A nice thing is that the code is forwards and backewards compatible.  One
can use the VM to run older images.  One can run images that contain the
primitive error code on older VMs, where one simply gets a nil error code on
primitive failure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080701/9499c9fa/attachment.htm