[squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

I am trying to make time to post a few articles on some future directions I consider interesting for the core system.

First one is up at http://people.squeakfoundation.org/article/89.html - do please comment on the relevant page, or even here.

It's just a prim, ie a function somewhere.

I'm proposing that we name all those prims that are currently numbered - primitive 1 would become "primitiveAdd" in a similar manner to say "primitiveDisablePowerManager".  This would allow all prims to be built as plugin components, thereby allowing on the fly replacement of those plugins (making due allowance for handling retained state etc, of course). (It's sometihng I've been wanting to see done since 1988; I had discussions with Alan Schiffman & Peter Deutsch about it way before I even move to ParcPlace). We would lose the primitive table, saving a 8 kb or so. Oh and the *really* obsoleteIndexPrimitiveTable, saving another 8Kb or so.

So do it.

Stef

Some code gets simplified, some space is saved, some flexibility is added, some bits are freed up in the CM header. THe downside is someone has to do some work.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Advanced design: Upper management doesn't understand it.

Am 01.07.2008 um 21:25 schrieb Eliot Miranda:

I would go further and rip out support for named primitives from the VM and put it up in the image where it belongs.  I would build the machinery for looking up named primitives in the image and have a primitive that allowed one to slam a function address into a method.

For me the VM should include an execution engine, a small and fast FFI and nothing else.  One needs some VM support to bootstrap the FFI.  i.e. the VM must include a primitive to load a platform library and another to lookup a name in it.  But other than that everything can be up in the image.  When one invokes a method with a primitive that has not been bound to a function yet then the primitive fails and the image's primitive failure code looks up the primitive's name and retries the call or reports an error if the library or name can't be found.

Well, until now FFI was intentionally optional. Making it mandatory would immensely widen the Smalltalk-System interface, in fact, there would be no clearly defined interface anymore. Until now, Squeak is a relatively safe place, bad crashes are rare etc. Whenever you deal with FFI the next crash is only minutes away. Also, you could expect that the image would soon fill up with lots of platform-specific code. But more importantly, it would make sand-boxing impossible, as any code in the image can do anything to your machine if it has access to FFI.

So it would simplify the VM at the expense of added complexity in the image. Which may of course fit the bill for Croquet which already relies on FFI, and except for Etoys nobody really uses the sand boxing anyway.

- Bert -

On 1-Jul-08, at 12:25 PM, Eliot Miranda wrote:

[snip]

Gettng rid of both obsolete tables is a really good thing (and I've already done it).

Good

Getting rid of indexed primitives for the core does not save anything.  There still has to be a table somewhere that maps the primitive name to the primitive function.  All you do is replace a table mapping indices to functions with one mapping strings to functions. You can't reply on the OS to do the lookup because you won't be able to strip VM executables if you do and that really costs space.

Sure; there's always got to be some way of looking up things. It will always take some space and time. But surely trading space/time for more flexible and smarter is what Smalltalk is all about?

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.