+1 to moving named primitive into image

+1 to make use of primitive returning value (this would affect the
code generator, but hell, its way better to have a notion why it
failed than simply guessing in the dark room,  like any currently
primitive failure code does)

+1 to eliminating pushRemappableOop:/popRemappableOop . (A question
however, how you would handle heap overflows, when evil primitive
generates massive object or lots of tiny objects?)

(a little OT .. )

Another question, is how would you sync there changes with Hydra (if
you having plans of course)?
I have many changes in CodeGenerator and some in VMMaker , to simplify
my day's job :)

In fact, it would be good to make a clean refactoring of it:
- make inst vars of Interpreter/ObjectMemory be the interpreter instance state
- make class vars be the part of VM global state
- make pool vars be the constants
- same could be applied to methods (instance/class side)

Currently things are little messy, since i made incremental changes to
existing model.

Another thing, which doesn't makes me sleep well, is that by using
thread specific storage, it would be possible to avoid passing
interpreter instance to each function/primitive. Too bad, GCC (on
windows) support a __thread__ specifier only in latest release , which
is 'technology preview' how they calling it :)
If we could use this, it would be possible to make Hydra nearly as
fast as current Squeak VM.
And there is no point to argue do we have right to use thread specific
storage or not: consider that Hydra can run on platforms which can
support threads. And since we already using threads, why we can't use
thread-specific storage.

... (stopping OT)

2008/7/1 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> 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.
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.