[squeak-dev] The Primitive: I am not a number- I am a named prim!
- SqueakPeople article
tim Rowledge
tim at rowledge.org
Tue Jul 1 20:21:28 UTC 2008
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?
>
> But more importantly I think its pointless. The bulk of primitives
> in the system are named, and they're in plugins and that all works
> fine, even though lookup is a little involved and slow. But I see
> nothing wrong with the core language primitives being indexed. They
> are pretty well fixed with unchanged semantics and unchanged
> references in the system (e.g. SmallInteger>>#+ is where you find
> <primitive: 1> and has always been where you find it). The table is
> quick to index and simple.
The downside in my opinion is that you have an early bound lookup that
also requires a different mechanism to support it. Named prims allow
for a later binding, replacement dynamically, and removes one of the
lookup mechanisms. As an example, we could put the at: & at:put: prims
into a plugin; then have one version that uses a cache of recently
at:'d objects and one that doesn't. It would be possible to swap
between them at runtime. Why? No idea, it's just an example, damnit!
[snip]
>
> Primitives that absolutely should not be indexed primitives include
> things like
> (90 primitiveMousePoint)
> (91 primitiveTestDisplayDepth) "Blue Book: primitiveCursorLocPut"
> (92 primitiveSetDisplayMode) "Blue Book: primitiveCursorLink"
> (93 primitiveInputSemaphore)
> (94 primitiveGetNextEvent) "Blue Book: primitiveSampleInterval"
> (95 primitiveInputWord)
> (98 primitiveStoreImageSegment)
> (99 primitiveLoadImageSegment)
> (101 primitiveBeCursor)
> (102 primitiveBeDisplay)
> (103 primitiveScanCharacters)
> (105 primitiveStringReplace)
> (106 primitiveScreenSize)
> (107 primitiveMouseButtons)
> (108 primitiveKbdNext)
> (109 primitiveKbdPeek)
> (126 primitiveDeferDisplayUpdates)
> (127 primitiveShowDisplayRect)
> (133 primitiveSetInterruptKey)
> (134 primitiveInterruptSemaphore)
> (140 primitiveBeep)
> (141 primitiveClipboardText)
> (142 primitiveVMPath)
> (231 primitiveForceDisplayUpdate)
> (232 primitiveFormPrint)
> (233 primitiveSetFullScreen)
>
> as these are to do with the broader context, not the core execution
> engine.
I'd certainly agree with the principle.
>
> 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.
An interesting idea in a completely different direction. I like a lot
about it, though I still think that the core prims ought to be named
and live in plugins, including the FFI. Obviously there is a gnarly
bit where you can't load the FFI plugin if you rely on FFI to do the
plugin loading, but what the hell, there's a bunch of us and we're
smart[1].
A system built as you describe would be extremely nice. No argument
there. Nonetheless I think that late-bound and rebindable prims along
with replaceable VM internals would also have some interesting value.
I doubt it's impossible to do both.
tim
[1] sideways reference to a .sigline "The theorists tell us that this
isimpossible, but what hell, there are three of us and we're smart"
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"How many Motie Watchmakers does it take to change a lightbulb?" "One.
Four to change the lightbulb and seventeen to convert the old bulb
into an escape capsule for all the others."
More information about the Squeak-dev
mailing list
|